Versions Compared

Old Version 2

changes.mady.by.user Ribbon Communications

Saved on

compared with

New Version Current

changes.mady.by.user Ribbon Communications

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Panel

...

borderColorgreen
bgColortransparent
borderWidth2
Noprint

Back to Table of Contents

Back to SIP Services

In this section:

Table of Contents
maxLevel3

Info
iconfalse

Related articles

...

:

Children Display

...

styleh6
Panel

In this section:

Table of Contents
maxLevel3

 

This section provides details regarding various SIP headers supported by the

...

Spacevars
0product
. For a complete list of supported SIP headers by the

...

Spacevars
0product
, refer to Supported SIP Headers.

Div
classexcerptdiv
Excerpt
Info

...

titleNote

The

Spacevars
0product
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.

Include Page
Transparency_Profile_Note
Transparency_Profile_Note

Diversion and History-Info Header Interworking

The 

Spacevars
0series4
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
Spacevars
0series4
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

Spacevars
0

...

product
as the egress node.

SIP Proprietary Headers (X-Headers)

The

Spacevars
0series4
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:

Code Block
languagenone
% 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:

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

SIP Resource Priority Headers

Spacevars
0product
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.

Spacevars
0product
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

Spacevars
0product
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

Spacevars
0product
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.

 

 

Pagebreak