You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »

In this section:

Related articles:

 

This section provides details regarding various SIP headers supported by the

Unable to show "metadata-from": No such page "_space_variables"
. For a complete list of supported SIP headers by the
Unable to show "metadata-from": No such page "_space_variables"
, refer to Supported SIP Headers.

The

Unable to show "metadata-from": No such page "_space_variables"
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.

Diversion and History-Info Header Interworking

The 

Unable to show "metadata-from": No such page "_space_variables"
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
Unable to show "metadata-from": No such page "_space_variables"
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 newly introduced flags determine the corresponding header to use to pass on this information in outgoing INVITE.

This feature is supported across GW-GW with the

Unable to show "metadata-from": No such page "_space_variables"
as the egress node.

SIP Proprietary Headers (X-Headers)

The

Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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.

Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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

Unable to show "metadata-from": No such page "_space_variables"
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