DO NOT SHARE THESE DOCS WITH CUSTOMERS!

This is an LA release that will only be provided to a select number of PLM-sanctioned customers (PDFs only). Contact PLM for details.


IMPORTANT

Ribbon recommends using the Transparency Profile to configure transparency on the SBC Core for new deployments, as well as applying additional transparency configurations to existing deployments. Do not use IP Signaling Profile flags in these scenarios because the flags will be retired in upcoming releases.

Refer to the SBC SIP Transparency Implementation Guide for additional information.

According to RFC 3261, a SIP spiral is "a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition."

The SBC includes a proprietary parameter, "call-info", to the Record-Route header of outgoing requests to avoid such a spiral condition. This parameter received in subsequent Route headers is used to perform call association for responses and OOD requests (such as SUBSCRIBE, REFER, OPTIONS, NOTIFY, INFO, MESSAGE, and so on) for both dialog transparency and non-dialog transparency call flows. This necessitates having the SIPFE pre-process Route headers in the context of the Dialog Transparency functionality.

OOD Spiral Support with Dialog Transparency Call Flow

OOD Spiral Support without Dialog Transparency Call Flow


  • No labels