|
|---|
The 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
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 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
as the egress node.The
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 |
|---|
|
% 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> |
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. 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. See CLI Common IP Attributes - SIP - CLI or EMA Signaling - Ip Signaling Profile - Common Ip Attributes for configuration details.For information on the 3GPP header support, see P-Headers page.
CRLFs in SIP Messages
In order to interoperate with Broadsoft, the
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
The SBC supports a header tag length of up to 256 characters.
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
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.