Page History
| add_docset_workflowworkflow_for_techpubs | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
The
| Spacevars | ||
|---|---|---|
|
- 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 SBC the
(received FQDN matches configured FQDN of zone on which 3xx is received or received address matches Signaling Ports address) is removed.Spacevars 0 product - 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 SBCthe
.Spacevars 0 product - 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.
- Embedded Route header parameters presence.
- Top-most Route Header not pointing to SBC is used for determining the next hop.
- Route header with FQDN or IP Address pointing to SBC the
- 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” flagis added to the IP Signaling Profile (IPSP) allowing SBC to handle embedded headers in 3xx Contact headers. This flagisassociated with the trunk group that received the 3xx, and is disabled by default.
The
| Spacevars | ||
|---|---|---|
|
For non-INVITE OOD messages, the
| Spacevars | ||
|---|---|---|
|
- you enable the
honorEmbeddedHeadersin3xxflag on the leg that receives a 3xx response, - the embedded Route header in the Contact header of a 3xx response the
uses for routing has the tgrp and trunk-context parameters, andSpacevars 0 product - the trunk-context points to the
.Spacevars 0 product
| Info | |
|---|---|
|
For configuration details, see:
| |
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
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 Spacevars 0 product
- you enable the
honorEmbeddedHeadersin3xxflag 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
uses for routing has the tgrp and trunk-context parameters.Spacevars 0 product
If you enable the honorEmbeddedHeadersin3xx flag on the leg that receives the 3xx response, the
treats the embedded Route headers in the Contact header of a 3xx response as if the Spacevars 0 product
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 Spacevars 0 product
and the Spacevars 0 product
uses the next Route header for routing.Spacevars 0 product
| Info | ||||
|---|---|---|---|---|
| ||||
When the Route header points to the
|
When you enable the honorEmbeddedHeadersin3xx flag for the IPTG that receives the 3xx response, the
copies all embedded headers to the corresponding non-INVITE OOD request. The copied headers overwrite any header values that the Spacevars 0 product
inherits from the ingress non-INVITE OOD message.Spacevars 0 product
For the IPTG that receives the 3xx response, a Network Selector Table (NST) lookup finds the egress IPTG and the
| Spacevars | ||
|---|---|---|
|
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.| Info | ||
|---|---|---|
| ||
Whether the NST lookup is successful or unsuccessful, you cannot disable the |
The
| Spacevars | ||
|---|---|---|
|
destinationTrunkGroupOptions parameter in the IP Signaling Profiles (IPSP).When the
| Spacevars | ||
|---|---|---|
|
routeUsingRecvdFqdn flag in the IPSP, the | Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
| Spacevars | ||
|---|---|---|
|
For configuration details, refer to:
- Egress IP Attributes - SIP - CLI
- Redirect - Flags (EMA)
- CLI: egressIpAttributes - SIP - CLI
- EMA: Redirect - Flags
| Note |
|---|
Ensure "Force Re-query for Redirection" flag associated with the specified IPSP is enabled when using this feature. |
...
The following call flows are supported:
...
C in IP Address
...
Format
| Noprint | ||||
|---|---|---|---|---|
|
| Cloak | ||
|---|---|---|
|
...
|
...
...
C in FQDN
...
Format
| Noprint | ||||
|---|---|---|---|---|
|
| Cloak | ||
|---|---|---|
|
...
|
Anchor call_flow_3 call_flow_3
3xx Response with Tgrp and Trunk-Context in the Embedded Route Header
| call_flow_3 | |
| call_flow_3 |
| Noprint | ||||
|---|---|---|---|---|
|
| Cloak | ||
|---|---|---|
| ||
| Pagebreak |
|---|
Overview
Content Tools