SBC feature on ASR1k have flexible, but maybe not easy to configure call routing policy mechanism. Many factors can be taken into consideration while deciding how call should be routed including time, category, prefix and you can even apply round robin fashion of call distribution. Let’s look at the simplest of possible call routing.
The simplest thing you can do is allowing calls to pass from one adjacency to another. You can have multiple adjacency defined on SBC therefor this policy will set call flows between which segments are allowed. For our purposes we have two adjacency defined – Public and Private. This is how our policy looks like.
call-policy-set 1 first-call-routing-table CallPolicy first-reg-routing-table CallPolicy rtg-src-adjacency-table CallPolicy entry 1 action complete dst-adjacency Private match-adjacency Public entry 2 action complete dst-adjacency Public match-adjacency Private active-call-policy-set 1
Policy is defined as call-policy-set. In production network you can have many policies defined but only one can be active at the time, so it have to cover all possible situations.
Call routing policies are segmented into tables. Each table type is named after factor that is taken into consideration in process of deciding if call should be routed, and where. In our example we use rtg-src-adjacency-table table type. Criteria of selection for this table is where this call comes from. Under each table set of entries is present, each of them define action to be taken if particular entry criteria are satisfied. Our example is quite simple – entry 1 says nothing more than if calls comes from adjacency Public and it’s destination is adjacency Private then call should be routed (action complete). Other actions you can define is to drop call or test another table. This process continues until first action complete is found.
Table that have to be checked first is defined under call-policy-set. You have to define table to be checked for registration routing (first-reg-routing-table) and call routing (first-call-routing-table). This allows building of flexible policies in distributed architectures. Last thing to do is activation of particular policy using active-call-policy-set command.