Embedded Headers Support in 3xx Contact Headers

Overview

The SBC Core supports embedded headers received in Contact headers of a 3xx message. Details of this support include:

• Contact header information is used to form the R-URI of the redirected INVITE.
• Embedded Route header information is used for determining the egress IPTG and next hop of the redirected INVITE.
  • Route header with FQDN or IP Address pointing to the SBC (received FQDN matches configured FQDN of zone on which 3xx is received or received address matches Signaling Ports address) is removed.
  • Egress IPTG selection is based on the following criteria in the order shown.
    • Embedded Route header parameters presence.
      • dtg parameter if dtg is present.
      • tgrp parameter if tgrp and trunk-context are present and processTgrpContext is enabled and trunk-context points to the SBC.
      • tgrp parameter if tgrp is present.
    • "skipDTGLookupForRouteHdr” flag.
      • Network Selector Table (NST) lookup (using embedded Route header content and zone on which the 3xx is received) if this flag is disabled (for the IPTG that received the 3xx).
      • PSX/ERE routing analysis (embedded Route header content is used as the called party information) if this flag is enabled.
  • Top-most Route Header not pointing to SBC is used for determining the next hop.
• Embedded From header information is used as the calling party. Embedded To header is the new To header in the redirected INVITE.
• All embedded headers received are present (in non-embedded form) in received order in the redirected INVITE (other than any removed Route header pointing to SBC and headers which replace the ingress INVITE headers).

The “Honor Embedded Headers in 3xx” flag is added to the IP Signaling Profile (IPSP) allowing SBC to handle embedded headers in 3xx Contact headers. This flag is associated with the trunk group that received the 3xx, and is disabled by default.

The SBC handles a 3xx response to the non-INVITE OOD SIP messages with a Contact header that has the tgrp and trunk-context parameters in the embedded Route header (see 3xx Response with Tgrp and Trunk-Context in the Embedded Route Header). 

For non-INVITE OOD messages, the SBC selects the egress IPTG based on the tgrp parameter and uses the embedded Route header as the next hop address if

• you enable the honorEmbeddedHeadersin3xx flag on the leg that receives a 3xx response,
  
• the embedded Route header in the Contact header of a 3xx response the SBC uses for routing has the tgrp and trunk-context parameters, and
  
• the trunk-context points to the SBC.

For non-INVITE OOD messages, the SBC uses the Route header tgrp and trunk-context parameters for the egress IPTG determination and the Route header for the next hop address selection if

• you enable the honorEmbeddedHeadersin3xx flag on the leg that receives a 3xx response,
• the Contact header of a 3xx response has tgrp and trunk-context as URI parameters, and
• the embedded Route header the SBC uses for routing has the tgrp and trunk-context parameters.

If you enable the honorEmbeddedHeadersin3xx flag on the leg that receives the 3xx response, the SBC treats the embedded Route headers in the Contact header of a 3xx response as if the SBC received those headers in an ingress non-INVITE OOD request from the routing perspective. The Contact header removes the topmost Route header if that Route header points to the SBC and the SBC uses the next Route header for routing.

When you enable the honorEmbeddedHeadersin3xx flag for the IPTG that receives the 3xx response, the SBC copies all embedded headers to the corresponding non-INVITE OOD request. The copied headers overwrite any header values that the SBC inherits from the ingress non-INVITE OOD message.

For the IPTG that receives the 3xx response, a Network Selector Table (NST) lookup finds the egress IPTG and the SBC uses the next hop address based on the Route header content. If the NST lookup is successful and you enable the forceRequeryForRedirection flag, a PSX lite-dip occurs to fetch the profiles that correspond to the found IPTG. If the NST lookup is not successful and you enable the forceRequeryForRedirection flag, a full PSX dip occurs and determines the egress IPTG.

The SBC includes tgrp and trunk-context parameters in the R-URI of the redirected non-INVITE OOD messages when you configure the destinationTrunkGroupOptions parameter in the IP Signaling Profiles (IPSP).

When the SBC receives a 3xx response for the non-INVITE OOD SIP messages with a Contact header that has the tgrp and trunk-context parameters and if you enable the routeUsingRecvdFqdn flag in the IPSP, the SBC acts on the tgrp and trunk-context parameters. When the SBC does not act on the tgrp and trunk-context parameters, the SBC populates the Contact header of the 3xx response as an R-URI for the redirected Request.

For configuration details, refer to:

• Egress IP Attributes - SIP - CLI
• Redirect - Flags (EMA)

Call Flows

The following call flows are supported: