In this section:

Related articles:

 This section provides details regarding various SIP headers supported by the SBC. For a complete list of supported SIP headers by the SBC, refer to Supported SIP Headers.

Note

The SBC supports up to 20 parameters per SIP header to accommodate enhanced services such as IMS and VoLTE using call flows such as ICS and SRVCC.


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.

Diversion and History-Info Header Interworking

The SBC Core supports interworking between Diversion header and History-Info header based on RFC 6044. In addition to handling the History-Info header in SIP messages in the dotted notation of indexes, the SBC Core manages the cause parameter as specified in RFC 4458 or Reason header as specified in RFC 4244.

The IP Signaling Profile flag "diversionHistoryInfoInterworking" indicates to the egress side that the interworking is accomplished as per the RFC 6044. In addition, the existing Redirecting Info flag of Diversion and History-Info headers identifies the target interworking header to send out in egress INVITE message. The Diversion and History-Info headers received on the ingress side are transparently passed to the egress where transparency profile configuration determine the corresponding header to use to pass on this information in outgoing INVITE.

This feature is supported across GW-GW with the SBC as the egress node.

SIP Proprietary Headers (X-Headers)

The SBC Core supports SIP proprietary headers (X-headers) from the X-header profile for both IPv4 and IPv6 addresses, and facilitates mapping information received in these headers to ISUP parameters, and vice versa.

Use following CLI syntax to configure an X-header Profile:

% set profile signaling XHeaderProfile <XHeaderProfileName> X-HeaderExtensions <extension_type> RecvHeader <disable|enable> SendHeader <disable | enable>
% set profile signaling XHeaderProfile <XHeaderProfileName> X-Header-default-value
% set profile signaling XHeaderProfile <XHeaderProfileName> X-HeaderFlags

Use the following CLI syntax to attach configured X-header and ISUP profile to trunk group:

% set addressContext <addressCcontext_name> zone <zone_name> sipTrunkGroup <sipTrunkGroup_name> signaling X-Headers HeaderFlag <none | xHeaders>

SIP Resource Priority Headers

SBC supports processing Resource-Priority Header (RPH) to classify a call as an emergency call. If the namespace and r-priority of a received r-value in the initial INVITE RPH exactly matches with the namespace and r-priority respectively of a configured value, then the call is considered an emergency call. The comparison is case-insensitive, and multiple r-values can be processed in incoming INVITE.

SBC can use the IPSP transparency flag 'resourcePriorityOptionTag' to transparently pass the 'resource-priority' option tag received in Require or Supported header of various SIP messages, such as INVITE, REGISTER, SUBSCRIBE (but not in-dialog SUBSCRIBE), PUBLISH, REFER, NOTIFY, UPDATE, MESSAGE, OPTIONS, CANCEL, OOD, and GW-GW transparency. This flag is available to both the ERE and external PSX. Refer to Common IP Attributes - SIP - CLI or Signaling - IP Signaling Profile - Common IP Attributes (EMA) for configuration details.

3GPP Header Support

For information on the 3GPP header support, refer to P-Headers page.

CRLFs in SIP Messages

In order to interoperate with Broadsoft, the SBC supports requests with up to three consecutive Carriage Return/Line Feeds (CRLFs) between message headers and multi-part message bodies as described below:

  • A CRLF at the end of the last header
  • A CRLF separating the headers from the body
  • A CRLF at the end of the preamble

Header Tag Length

The SBC supports a header tag length of up to 256 characters.

P-DCS-LAES Header Support

P-DCS-LEAS header support is defined in RFC 3603 for PacketCable 2.0 Electronic Surveillance. The P-DCS-LAES extension contains the information needed to support Lawfully Authorized Electronic Surveillance. This header contains the address and port of an Electronic Surveillance Delivery Function for delivery of a duplicate stream of event messages related to a call. This header is only used between proxies and trusted User Agents. An example of this header is:

P-DCS-LAES: 10.252.139.180:1813; content=10.252.139.180:45006;
bcid=D0E4965A2020202020373035302D30353030303000423403; cccid=015E8061

If SBC receives this particular header (in 18x or 2xx), the SBC will send the two-way media in PCLI (PacketCable Lawful intercept) format with the “cccid” derived from the P-DCS-LAES header to the address and port identified by “content” parameter. The duplicate stream is formed at the point where the P-DCS-LAES header is received. The implication of this is media played in the “backwards” direction from the opposite side of the call prior to full media cut-through will not be present in the tapped media stream. One example of this is when Local Ringback Tone is enabled, it will not be present in the tapped media information. However, the advantage of this methodology is that it ensures that only the information from the specific endpoint where the tap request came from will be tapped.


  • No labels