The SBC Core supports embedded headers received in Contact headers of a 3xx message. Details of this support include:
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
honorEmbeddedHeadersin3xx
flag on the leg that receives a 3xx response,The preceding egress IPTG selection applies to a standalone transaction, which includes methods such as REGISTER (Reg Relay), SUBSCRIBE, OPTIONS, REFER, PUBLISH, MESSAGE, and INFO.
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
honorEmbeddedHeadersin3xx
flag on the leg that receives a 3xx response,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 the Route header points to the SBC, the Route header is either in the FQDN format and matches the Zone FQDN of the Zone that receives the 3xx response, or is in the IP Address format and matches the IP address or port of that Zone's signaling port.
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.
Whether the NST lookup is successful or unsuccessful, you cannot disable the forceRequeryForRedirection
flag. This configuration combination is invalid.
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:
Ensure "Force Re-query for Redirection" flag associated with the specified IPSP is enabled when using this feature.
Embedded PAI Header is present in the redirected INVITE only if “Include Embedded PAI” flag is enabled in this IPSP.
A 3xx with embedded headers over GW-GW is rejected with '403 Forbidden' message when "Honor embedded headers in 3xx" enabled.
The following call flows are supported: