In this section:

Related articles:

 

NOTE: This configuration is not supported on ERE and is intended for use only with an external PSX.

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 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 by the PSX, refer to PSX Documentation.

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. Beginning with 5.0 release, the SBC is enhanced with the following capability to support conditional use of PSX routing.

    This option is used along with the 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 the PSX.

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

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

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

    Note

    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. The SBC sends URI along with the DTG route information to the 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. The 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 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.
    • Zone Level Loop Detection Flag to override Global Loop Detection flag (Applicable to the 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

 

  • No labels