5.6. SIP Routing

The key functionality of the ABC-SBC is that of SIP routing: based on criteria chosen by the administrator, the SIP destination for a SIP dialog is chosen. The routing decision is the step “B” in the A-B-C process: After A-rules are applied based on who sent the SIP traffic to the SBC, the destinatination Call Agent is chosen in the B-rules. The final step is processing of the outbound C-rules, that are specific to the Call Agent chosen in the step B.

The routing decision is also an important part of the network reliability concept: it has implications to the way how traffic is re-routed if downstream destinations are unavailable or overloaded.

Unlike steps A and C, the routing step B is global: it is executed for every combination of inbound and outbound call agents and realms. It can be seen like the wiring board between these. Also unlike A and B rules, matched rules can have only one action: selection of the destination.

The routing rules are processed sequentially until one is found that matches. Repetative rules, such as least-cost-routing tables, can also be managed by provisioned tables as described in the Section Provisioned Tables. If no route matches, the ABC-SBC stops processing the SIP request and returns a 404 SIP response.

The outcome of the routing process is unique determination of the destination Call Agent. This decision determines the following aspects:

  • which C-rules are executed
  • which backup Call-Agent is used, if forwarding to the chosen Call Agent fails
  • which interfaces are used for forwarding
  • which IP address or addresses are used as next hop for forwarding

Note that the routing process is applied only to dialog-initiating or out-of-dialog SIP requests. During the dialog life-time, routing of in-dialog SIP requests follows a fixed path established in the process of the dialog initiation with the peering SIP devices. The path may or may not be the same as that of dialog-initiating transaction and is formed using Record-Route and Contact header-fields as governed by the RFC 3261 specification. Only if the “use on first request only” option is turned off, or “Dialog NAT handling” is enabled, the ABC-SBC routes subsequent requests in a sticky way to the same hop as the initial one.

The following subsections decribe how routing rules are organized and how to use the three types of routing rules: “static” for well-known next-hop Call Agents, “table-based dynamic” for a massive amount of static routes, and “request-URI based” for destinations identified in request URI. Eventually we show how the abstract destination is translated into next-hop IP addresses for request forwarding.

5.6.1. Routing Rules (B)

The routing rules are an ordered list of routes, which are processed one by one after completion of A rules processing. When the first rule condition matches, the destination call agent is chosen and route processing stops.

The configured Routing (B) rules can be viewed when clicking on the “Routing” menu entry.

_images/10000201000007960000037A31133D12.png

Figure 1: List or routing rules

A new routing rule can be created either at the beginning of the list (“Insert new Rule”) or at the end (“Append new Rule”).

When creating a new Routing (B) rule, one or more conditions can be entered, see Fig. Define matching conditions for routing, similar to the other types of rules (inbound (A) and outbound (C) rules).

_images/100002010000049600000136D69EBB92.png

Figure 2: Define matching conditions for routing

It is also possible to define a default routing rule by omitting the condition(s). In this case, the rule will always match, and thus finish the Routing rules evaluation. In case there is no such default rule and no other rule matches, the SBC answers the request with a 404 response.

There are several types of routing rules, that can be combined with each other and processed in sequential order:

  • Static route  – In a static route, all data describing the routing decision must be entered manually. If the static route matches, routing finishes, otherwise it proceeds to the next rule.
  • Dynamic route – if multiple repetative rules, such as with Least Cost Routing, are configured, they are better placed in a provisioned table as described in the Section Provisioned Tables. To make a lookup in the table, select the table name in the “Route using” drop down list and indicate by what key the lookup shall be performed. Like with static routes, if a matching entry is found, routing finishes, otherwise it proceeds to the next rule.
  • Call Agent based on R-URI – the ABC-SBC tries to find a Call Agent that matches host in request URI. This can be particularly useful if A-rules change hostname in request URI, for example by ENUM lookup. If the lookup yields an address of a valid Call Agent, it is used for routing and routing finishes, otherwise it proceeds to the next rule.

These route types are described in more detail in the following sections.

5.6.2. Static Routes

Static route is the simplest type: the administrator explicitely chooses the destination Call Agent. If no further specific treatment is desired, that’s all. The Call Agent is chosen, subsequently its C-rules are executed and eventually signaling is forwarded through the interface associated with the Call Agent.

The choice of Call Agent is accompanied by several other options. The most important is that of routing method which specifies how the next-hop IP address is determined. Either it is determined from request URI or from pre-provisioned information. Note that whichever method is chosen to determine the next-hop IP address, Call-Agent does not change and its C-rules are used for request processing. Both methods may yield multiple IP addresses, in which case the ABC-SBC load-balances among them by their respective priorities.

The “Route via R-URI” method uses the request URI to find out the next-hop IP address. That is particularly useful when A-rules altered the request URI using actions like reverse registration cache or ENUM lookup. If the host part of request URI includes a DNS name that resolves to multiple destinations per RFC 3263, the ABC-SBC load-balances among the respective destinations by their priorities.

If “Set Next Hop” (also known as “outbound proxy”) is used instead, the next-hop IP address is determined using pre-provisioned information. Either the IP address (or addresses) associated with the Call Agent is taken, or these are explicitely overriden using the option “Use another destination instead of CAs’ destination(s)”. Further method-specific options include:

  • “Use on first request only” – this option changes default behaviour for forwarding subsequent in-dialog requests. By default when turned off, all subsequent outbound requests will follow exactly the same the path of the previous dialog-initiating request. If however this option is turned on, the next-hop logic for subsequent requests is governed only by the SIP standard procedures. Particularly, if the next hop in the INVITE path was a non-record-routing proxy, it will not be included in request’s path.
  • “Update R-URI Host”. This option rewrites host part of request URI with the address of the next hop. By default it is turned off and the request URI remains untouched when forwarding.
  • “Add Route HF”. This option is also known as “preloaded Route”. It prints the next-hop destination in Route Header-field. Use only if downstream SIP hop is known to require such behaviour.

The following advanced options can be also used with both methods:

  • “Replace DNS name in R-URI through the resolved IP address” makes sure that if DNS names appears in request URI, it is rewritten to IP address before forwarding.
  • “Force transport”. Allows to override transport protocol to be used for the next hop. One of the following protocols can be chosen: UDP, TCP, TLS.
  • “Enable redirect handling”. If this option is turned on, incoming 302 are not passed upstream. Instead, the ABC-SBC takes content of Contact header field and uses it as another next-hop for forwarding the original request. Particularly the Contact URI in the 302 response is used to rewrite request URI, determine the next-hop IP address and look up a Call Agent whose C-rules are processed. Note that an error occurs and a 500 response is sent upstream if none or more than one matching Call-Agents are found, or the Contacts include DNS names. Use this option with care only for trusted destinations since the 3xx responses may greatly impact where and how requests are forwarded.

An example is shown in Figure Static Routing destination: the Call Agent “users” is chosen so that its C-rules will be processed. There is no additional IP address included in the “set-next-hop” choice of routing, so that the dialog-initiating request is forwarded to IP addresses associated with the particular Call Agent.

_images/route_static.png

Figure 3: Static Routing destination

5.6.3. Table-based Dynamic Routes

Long repetative routing rulesets can be better managed as tables. All other aspects of the routing logic remain the same as with staticaly defined rules.

To deploy dynamic rules the following steps must be performed:

The lookup definition requires two parameters: name of the table defined in the first step, and the value used to lookup a matching table row defined in the second step. The value is defined in form of a replacement expression. For example, $rU can be used to trigger lookups by userpart of request URI.

The table than includes rows identified by unique keys. In the screenshots bellow, the userpart of request URI ($rU) is compared against a row with key 911. If a match occures, the call agent “external_callagents” is used for call forwarding.

When the table lookup is performed and the value matches no key, routing proceeds to the next entry in the routing table. If there is no more such, routing failes and the SIP request is declined using the 404 SIP response.

_images/route_table.png

Figure 4: Configure a route lookup in a provisioned routing table

_images/route_table_new.png

Figure 5: Adding a new entry to routing table

5.6.4. Request-URI Based Routes

In some scenarios, the next-hop Call Agent is not exactly known at the time of devising a routing policy. Instead it is known that a request URI identifies the Call Agent. This is often the case if the request URI is rewritten by an external query, such as ENUM or REST. There would be little point in formulating rules like “if a CA’s IP address present in R-URI, route to the CA” for every single CA.

Therefore there is the “route via R-URI” routing type, which finds a Call Agent based on address in request URI and if found, routes to it.

Note that this is different from the “route via R-URI” option, which is only used to override the transport destination but does not determine the Call Agent with its rules.

_images/route_uri.png

Figure 6: Route by Request URI

Like with Static Routes, there are two routing methods for determining the next IP-hop: Either it is taken from request-URI (the “Route via R-URI” method) or it is taken from Call Agent’s profile. The difference is subtle because by use of the lookup an IP address gained from the request URI must match an IP address of a Call Agent. A difference may occur when some other IP addresses linked with the DNS name are different from those linked with the Call Agent’s profile. Also if an IP address comes in request URI and the “route-via-r-uri” method is used, alternate destinations associated with the Call Agent will not be used.

5.6.5. Determination of the IP destination and Next-hop Load-Balancing

When the destination Call Agent is selected, one or multiple IP addresses are chosen for forwarding. These may come from Call Agent definition, explicit addresses in the route or from request URI. Capability to choose more than one IP address is important for load-balancing downstream hosts and for dealing with their unavailability. If there are multiple IP addresses (so called “destination set”) the ABC-SBC “hunts” through them based on their priorites to find one that is responsive.

The destination set is formed depending on the choice of routing method described in previous sections. It works the same way for static, dynamic and request-URI based types and it can be one of the following:

  • if the “Set-next-hop” routing method is chosen without the “Use another destination instead of CAs’ destination(s)” option, the addresses specified in Call Agent’s profile are used
  • if the “Set-next-hop” routing method is chosen with the “Use another destination instead of CAs’ destination(s)” option, the addresses specified in this option are used. Addresses associated with the Call Agent are not used for forwarding.
  • if “Route via R-URI” is chosen, the address is taken from the request URI.

If an address in the destination set is a DNS name, it is resolved to IP address(es) using procedures specified in RFC 3263 before further processing.

If the resulting destination set includes multiple entries they are attempted in successive order. An 8-second timer is used to try up to 4 destinations, so that the hunting attempts complete before standard SIP transaction timeout of 32 seconds. A 503 reponse makes the ABC-SBC to attempt the next destination in the set immediatelly.

The hunting order is determined by priorites specified in DNS, “Use another destination” option or CA profile. The way priorities are set complies to the RFC 2782: the ABC-SBC initially contacts hosts with lowest-number priorities. If there are multiple hosts with the same priority they are tried by probablity as defined in their weight field. The weight field specifies a relative weight, larger weights are given a higher probability of selection.

When no responsive destination is found, the ABC-SBC will check if there is a backup Call Agent defined in the current Call Agent’s profile. If so, it will undo previous mediation changes, process backup Call Agent’s C-rules and retry the IP calculation process for the backup Call Agent.

The whole process is shown in Figure Flowchart of Process for Determination of the Next-hop IP Address.

_images/next-hop-flowchart.png

Figure 7: Flowchart of Process for Determination of the Next-hop IP Address

5.6.6. IP Blacklisting: Adaptive Availability Management

Attempts to forward traffic to IP addresses known to be unavailable would be futile and impair call setup time. Therefore the ABC-SBC keeps a “blacklist” of IP addresses that were detected as unresponsive. The ABC-SBC dispatches no traffic to such destinations until the blacklisting time-to-live expires and the destination are removed from the blacklist.

Additionally the ABC-SBC can proactively probe destinations using OPTIONs packets so that their unavailability is detected even before real traffic reaches them.

Note that this type of blacklisting is different from that used in the context of security policies as described in the section Blacklisting.

To turn IP blacklisting on, set the time-to-live blacklisting period to a positive value under global options in “Config ‣ Global Config ‣ Blacklisted Destination TTL” or under Call Agent properties as shown in Figure Configuration of Blacklisting under Call Agent Properties.

_images/call_agent_blacklisting.png

Figure 8: Configuration of Blacklisting under Call Agent Properties

IP blacklisting occurs in an almost automated way and does typically require minimum administrative attention. Addresses are added to the blacklist once they are identified as unavailable and hold on the list for a predefined period of time, known as “time-to-live”. The following procedures may still be of use to an administrator:

  • Monitoring blacklisted addresses. It is possible to inspect the addresses which are currently blacklisted. The list is available from the main menu under “Monitoring ‣ Blacklist”.
  • Manual blacklisting. Administrator may add a new address to the blacklist from the main menu under “Monitoring ‣ Blacklist ‣ New Destination/Save”.
  • Testing presence on blacklist. Rule conditions may include a test if a Call Agent is present on a blacklist using the “Blacklist” condition type. The condition returns true of all Call Agent’s IP addresses are blacklisted.
  • Changing Time-to-Live (TTL). The addresses are hold on blacklist for period of time specified under “Config ‣ Global Config ‣ Blacklisted Destination TTL”. This value is used for newly blacklisted destinations, unless a CA-specific TTL takes precedence. If TTL is set to zero, no blacklisting takes place.
  • Configuring Call Agent specific handling. There are the following options available under Call Agent profile:
    • Blacklist TTL (seconds). This value overrides the globally specified time to live.
    • Blacklist grace timer (ms). This value provides some extra time before a downstream element is blacklisted. That is especially useful when there is a proxy server between the ABC-ABC and an unresponsive User Agent Server. A too aggressive blacklisting process would otherwise blacklist the proxy before it times out and sends a 408 message and make the proxy and elements behind it unreachable.
    • Blacklist error reply codes. This feature allows to blacklist destinations that answer to monitoring requests using these codes. Useful for example if a destination signals overload condition using 503. To activate the feature, include a comma-separated list of response codes that lead to inclusion of a destination on a black-list.
    • monitoring interval (seconds). If set to a non-zero value, the ABC-SBC tests availability of the destination by sending test message (OPTIONS). This allows to detect unavailable destinations even before a real call hits it.

Whenever an address is added to the IP blacklist, an event of type ‘notice’ is generated. The same occurs when the TTL expires and the address is delisted.

5.6.7. SIP Routing by Example

One important configuration step is the definition of routing rules, i.e. to which IP address shall incoming traffic be forwarded. If a proper routing entry is not set up, the ABC SBC does not know where to forward traffic and returns the SIP reply “404 Not Found”.

In our example, the routing configuration is very simple: What comes from the external Realm is routed to the internal Realm and vice versa. That takes two rules defined from the “Routing” section of the web user interface: Traffic coming from the Call Agent “Proxy” is routed to the Call Agent “Users” in the external realm and traffic coming from the “external” Realm will be routed to the “proxy” Call Agent in internal Realm. The resulting configuration is depicted in Fig. Example Routing Rules.

_images/10000201000003C7000001BCB186B4E1.png

Figure 9: Example Routing Rules

When you define the respective routing destinations, specifying the abstract Call Agent may not be enough. You may additionally need to help the SBC to determine to which IP address to forward the SIP message and which hostname to use in the Request URI. For example, traffic leaving the SIP proxy carries the final destination in the Request URI. You must configure the ABC-SBC to use the IP address from the request-URI as the next hop. The particular configuration is called Route via R-URI. On the other hand, all traffic from the public Internet goes to the same proxy server. The appropriate configuration choice is Set Next Hop. You may specify the IP address explicitly, if you do not do so, the IP address is taken from definition of the Call Agent.

The routing rule for the proxy-to-external traffic flow is shown in the Fig. ref:fig-Route-proxy-ext, whereas the rule for the opposite direction is shown in the Fig. Routing Rule for external to internal traffic. That’s it. We now have the routing policy which specifies that traffic from the external Realm shall be forwarded to the internal Realm and vice versa. This simple policy can in fact serve an incredible number of use-cases.

_images/10000201000003C7000003E63382A02E.png

Figure 10: Routing Rule for internal to external traffic

_images/10000201000003C8000003E417FCCB63.png

Figure 11: Routing Rule for external to internal traffic

Nevertheless, if needed it can use more sophisticated matching criteria to specify routing decisions: It can divert Message-Waiting-Indication traffic to a different server based on SIP method, different media servers based upon codecs in use, different destinations based on custom-defined header fields, and so on, and so forth.

Footnotes

[1]If the target Call Agent is defined as an IP network, it is obvious that the subnet cannot be used as a target destination.