IMS Routing for Route Header and Roaming User

Routing for Route Header

The routing parameter, useRouteSet, is used in conjunction with the PSX in the context of performing its routing logic (i.e gathering the address of the called party for instance). In this way, routing information can be sent from the SBC to the PSX and Destination Trunk Group (DTG) using the route sent by PSX for REGISTER request.

The SBC determines whether the PSX should perform pattern matching logic or not using "skipPatternMatching" option of SIP trunk group's useRouteSet parameter. If this new indication is set, the PSX returns the destination routing information provided to it in the Routing AVP of the Policy request back to the SBC in the Policy response. For more information on Pattern Matching in PSX, refer to PSX Routing Enhancements for Route Header.

This feature also allows the SBC to eliminate all the extraneous routing decisions and always uses the information returned to it by the PSX in the policy response to determine the next immediate destination.

SBC Route Set Options

The below useRouteSet options describes the various routing scenarios supported by the SBC.

1. Stored -- This legacy option is used for P-CSCF functionality in supporting Registration for generic IMS support.The new enhancement to this option in 5.0 is to add additional capability to support conditional use of PSX routing.
   

   This option is used along with the new flag "sendRouteUriToPsx" (see SIP Trunk Group - Call Routing - CLI for CLI details).

   1. When you enable sendRouteUriToPsx flag, the Stored service Route or Path header is sent to PSX.

      1. SBC sends Stored Service-Route or Path along with the DTG route information to PSX .

      2. The PSX sends back the route to SBC with the exact route information.

   2. When you disable sendRouteUriToPsx option, route-URI is not sent to PSX.

   The stored service-Routes will be used for UE originated calls and path headers will be used for UE terminating calls.

2. Roaming or Stored – This option is used in P-CSCF for supporting the roaming as well as non-roaming scenarios. This option is used along with the "sendRouteUriToPsx" flag.

   For Roaming User

   1. The register URI routing information is send to PSX.

      1. SBC sends URI along with the DTG route information to PSX .

      2. The PSX sends back the route to SBC with the exact route information.

   For Non-Roaming User

   1. The register URI routing information is send to PSX.

      1. SBC sends route URI along with DTG route information.

      2. Set SkipPatternMatch flag to TRUE.
         
         

3. Rcb Next Hop And Stored – This option is used when the operator wants to ensure the messages from registered subscriber go to the same next immediate destination as the registration.

   When using this option, ensure "sendRouteUriToPsx" flag is enabled. 

   1. If you enable sendRouteUriToPsx option, the register URI routing information (registrar IP along with the DTG route information) is send to PSX.

       

4. Received
   

   This is a legacy option. This option is used for the IBCF functionality when stateless Registration Relay is in effect. This indicates that the routing information received in the route header portion of the incoming message. This routing information is used for determining the next immediate destination route.

   This option is used along with the "sendRouteUriToPsx" option to either enable/disable. You need to also enable " skipDTGLookupForRouteHdr" to use the received option.

   1. When you enable sendRouteUriToPsx option, the top-most non-SBC Route-URI is sent PSX.

   2. When you disable sendRouteUriToPsx option, route-URI is not sent to PSX.

Identifying Roaming User and Routing for Loop Back Scenario

The SBC as a P-CSCF marks a registered user as roaming based on the data provided by PSX in the policy response of a REGISTER message, and also routes the Non-REGISTER message from roaming UE based on DTG provided by PSX during REGISTRATION. Additional SBC routing functionality is described below.

SBC as P-CSCF

• Identify a user as Roaming User by passing Request-URI as Home-Domain-URI in PSX Request.
• Support Request-URI based routing for REGISTER messages.
• Perform DTG-based routing for Roaming User (applicable to both INVITE and Non-INVITE OOD messages) [This is accomplished using new useRouteSet option "roamingOrStored"].
• Pass Stored-Service Route as Route Header towards egress for Roaming UE and copy the next hop (i.e PSX returned route) as top-most route header towards egress.
• Loop Detection Enhancement: 
  
  • Use host-part of Request-URI to generate branch-parameter of Via Header, in addition to existing user information part of the Request-URI and Call-ID, to disallow loop to be detected when user-part is same while host-part of Request-URI is different.
  • New Zone Level Loop Detection Flag to override Global Loop Detection flag (Applicable to SBC configured as EATF).
• Display Roaming status in CDR and in CLI.

• Send Domain Name in PATH Header of Outgoing REGISTER.

SBC as IBCF

• If DTG/Trunk-Context is received in top-most Non-NBS route header perform DTG based routing (existing logic)
• If DTG is not sent to PSX, perform Heavy DIP using Route-URI for INVITE and Non-INVITE if 'sendRouteUriToPsx' flag on the ingress trunk group is enabled.
• Perform FQDN Suffix Matching for ROUTE URI in Route-Header of received SIP Request.

• Send Domain Name in PATH Header of Outgoing REGISTER.

Honor PSX Route during Roaming Based Routing (PCSCF) or Route-URI Based Routing (IBCF)

• If useRouteSet is set to roamingOrStored and UE is Roaming User, the PSX route is honored.
• If useRouteSet is received and ROUTE-URI is passed to PSX, the PSX route is honored.

Simplified Call Flow for Roaming UE Registration and Call Origination

Below is a simplified call flow diagram depicting call origination and REGISTRATION of roaming UE.

Roaming UE Call Flow Diagram