SIP Routing
This section describes SIP session routing. When routing SIP call requests, the Oracle Communications Session Border Controller communicates with other SIP entities, such as SIP user devices, other SIP proxies, and so on, to decide what SIP-based network resource each session should visit next. The Oracle Communications Session Border Controller processes SIP call requests and forwards the requests to the destination endpoints to establish, maintain, and terminate real-time multimedia sessions.
Certain items in the messages are matched with the content of the local policy, within constraints set by the previous hop session agent, and the SIP configuration information (for example, carrier preferences) to determine a set of applicable next hop destinations.
The sending session agent is validated as either a configured session agent or a valid entry in a user cache. If the session INVITATION does not match any registering user, the SIP proxy determines the destination for routing the session INVITATION.
Limiting Route Selection Options for SIP
You can configure the local policy to use the single most-preferred route. And you can configure the SIP configuration max routes option to restrict the number of routes which can be selected from a local policy lookup:
- A max-routes=1 value limits the Oracle Communications Session Border Controller to only trying the first route from the list of available preferred routes.
- A max-routes=0 value or no max-routes value configured in the options field allows the Oracle Communications Session Border Controller to use all of the routes available to it.
A Oracle Communications Session Border Controller configured for H.323 architectures will have access to all of the routes it looks up by default.
About Loose Routing
According to RFC 3261, a proxy is loose routing if it follows the procedures defined in the specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field).
When the SIP NAT’s route home proxy field is set to enabled, the Oracle Communications Session Border Controller looks for a session agent that matches the home proxy address and checks the loose routing field value. If the loose routing is:
- enabled—A Route header is included in the outgoing request in accordance with RFC 3261.
- disabled—A Route header is not included in the outgoing request; in accordance with the route processing rules described in RFC 2543 (referred to as strict routing). That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present.
Whether loose routing field is enabled is also checked when a local policy ‘s next hop value matches a session agent. Matching occurs if the hostname or the session agent’s IP address field value corresponds to the next hop value. If loose routing is enabled for the matching session agent, the outgoing request retains the original Request-URI and Route header with the next hop address.
About the Ingress Realm
You can create a list of realms in your local policy that is used by the Oracle Communications Session Border Controller to determine how to route traffic. This list determines from which realm traffic is coming and is used for routing by ingress realm.
The source realm values must correspond to valid identifier entered when the realm was configured.
About the Egress Realm
An egress realm allows SIP signaling to travel out of the Oracle Communications Session Border Controller through a network other than the home realm. The Oracle Communications Session Border Controller uses egress realms for signaling purposes (when matching flows). When a packet arrives at the Oracle Communications Session Border Controller with a destination address that does not match any defined session agents, the Oracle Communications Session Border Controller uses the address associated with the realm that is, in turn, associated with the SIP configuration’s egress realm ID, as the outgoing network. With the use of the egress realm ID, it is possible to define a default route for SIP requests addressed to destinations outside the home realm. If no egress realm is defined, the home realm (default ingress realm) is used as the default egress realm.
With session agent egress realm configured, the Oracle Communications Session Border Controller adds a default egress realm to the session agent to identify the signaling interface used for ping requests. The Oracle Communications Session Border Controller also uses the default egress realm when the normal routing request does not yield an egress realm—for example, when a local policy does not specify the next hop’s realm.
When you configure session agents, you can define them without realms or you can wildcard the realm value. These are global session agents, and multiple signaling interfaces can reach them. Then, when you use session agent pinging, the Oracle Communications Session Border Controller sends out ping requests using the signaling interface of the default egress realm defined in the global SIP configuration. The global session agents in certain environments can cause problems when multiple global session agents residing in multiple networks, some of which might not be reachable using the default SIP interface egress realm.
The Oracle Communications Session Border Controller uses the session agent egress realm for ping messages even when the session agent has a realm defined. For normal request routing, the Oracle Communications Session Border Controller uses the egress realm for global session agents when local policies or SIP-NAT bridge configurations do not point to an egress realm.
Ping Message Egress Realm Precedence
For ping messages, the egress realm precedence occurs in the following way (in order of precedence):
- Egress realm identified for the session agent.
- Session agent realm (set in the realm-id parameter) or the wildcarded value
- Global SIP configuration egress realm, when configured in the egress-realm parameter
- Global SIP configuration home realm
Normal Request Egress Realm Precedence
For normal request routing, the egress realm precedence occurs in the following way (in order of precedence):
- Egress SIP-NAT realm, when the route-home-proxy parameter is set to forced and no local policy match is found
- Matching local policy realm, when configured in the local policy attributes
- Session agent realm (set in the realm-id parameter) or the wildcarded value
- Session agent egress realm, when configured in the egress-realm-id parameter
- Global SIP configuration egress realm, when configured in the egress-realm parameter
- Global SIP configuration home realm
About SIP Redirect
SIP redirect involves proxy redirect and tunnel redirect.
Proxy Redirect
You can configure the SIP proxy mode to define how the SIP proxy will forward requests coming from the session agent. This value is used if the session agent’s proxy mode has no value (is empty).
Tunnel Redirect
You can use tunnel redirect when requests are routed to a server behind a SIP NAT that sends redirect responses with addresses that should not be modified by the SIP NAT function. For example, a provider might wish to redirect certain calls (like 911) to a gateway that is local to a the UA that sent the request. Since the gateway address is local to the realm of the UA, it should not be modified by the SIP NAT of the server’s realm. Note that the server must have a session agent configured with the redirect-action field set to the proxy option in order to cause the redirect response to be sent back to the UA.
SIP Method Matching and To Header Use for Local Policies
For SIP, this feature grants you greater flexibility when using local policies and has two aspects: basing local policy routing decisions on one or more SIP methods you configure and enabling the Oracle Communications Session Border Controller to use the TO header in REGISTER messages for routing REGISTER requests.
SIP Methods for Local Policies
This feature allows the Oracle Communications Session Border Controller to include SIP methods in routing decisions. If you want to use this feature, you set a list of one or more SIP methods in the local policy attributes. These are the SIP methods you can enter in the list: INVITE, REGISTER, PRACK, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE, MESSAGE, and PUBLISH.
After the Oracle Communications Session Border Controller performs a local policy look-up for SIP, it then searches for local policy attributes that have this methods list configured. If it finds a a set of policy attributes that matches a method that matches the traffic it is routing, the Oracle Communications Session Border Controller uses that set of policy attributes. This means that the Oracle Communications Session Border Controller considers first any policy attributes with methods configured before it considers those that do not have methods. In the absence of any policy attributes with methods, the Oracle Communications Session Border Controller uses the remaining ones for matching.
In cases where it finds neither matching policy attributes with methods or matching policy attributes without them, the Oracle Communications Session Border Controller either rejects the calls with a 404 No Routes Found (if the request calls for a response) or drops the call.
You configure local policy matching with SIP methods in the local policy attributes parameter calls methods. This parameter is a list that takes either one or multiple values. If you want to enter multiple values, you put them in the same command line entry, enclosed in quotation marks and separated by spaces.
To configure SIP methods for local policy matching:
Routing Using the TO Header
For the Oracle Communications Session Border Controller’s global SIP configuration, you can enable the use of an ENUM query to return the SIP URI of the Registrar for a SIP REGISTER message. Without this feature enabled, the Oracle Communications Session Border Controller uses the REQUEST URI. This ability can be helpful because REGISTER messages only have the domain in the REQUEST URI, whereas the SIP URI in the To header contains the user’s identity.
There are two parts to enabling this feature. First, you must enable the register-use-to-for-lp parameter in the global SIP configuration. Then you can set the next-hop in the applicable local policy attributes set to ENUM.
To enable your global SIP configuration for routing using the TO header: