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.

In this section:

Related articles:

CLI

EMA


Random User-Info in Contact Header

The SBC supports optionally using random alphanumeric string for the useInfo of Contact header in Register messages, INVITE requests, 1xx and 2xx responses (except for '100 trying') of terminating INVITE messages generated by the SBC. To facilitate this, an optional control flag useRandomUserInfoInContactHdr is added at the egress Trunk Group level (from message direction perspective). The default setting is 'disabled'. See command syntax below.

In support of this feature, the SBC generates a random number including a static prefix depending upon the type of request generated:

  • Registration request – The random number is composed of GKzReg + regId associated with registration RCB.
  • Invite request – The random number is composed of KgzInv + 14 randomly-generated alphanumeric characters.

The userInfo part length can be up to 20 bytes. Because the Contact header length is limited to 64 bytes, use an SMM rule to remove "reg-info", "dtg", "q", Expires, and other parameters from Contact header of Register request. Add the Expires header in the request using expires parameter value if Expires header does not already exist. Apply the SMM profile as the "outputAdapterProfile" for the IP trunk group facing the Network/Registrar using the syntax.

% set addressContext <acName> zone <zoneName> sipTrunkGroup <tgName> signaling messageManipulation outputAdapterProfile <SMM profile name>

To use this feature, the following actions must be taken:

  1. Configure the remoteDeviceType as "appServer" for the zone facing the Network/Registrar to specify call direction from Registrar/AppServer using CLI syntax:

    % set addressContext <acName> zone <zoneName> remoteDeviceType appServer

  2. Disable the transparency flags "passCompleteContactHeader" and "contactHeader" in the IP Signaling Profile facing the Registrar/network using CLI syntax:

    % set profiles signaling ipSignalingProfile <profile_name> commonIpAttributes transparencyFlags passCompleteContactHeader disable
% set profiles signaling ipSignalingProfile <profile_name> commonIpAttributes transparencyFlags contactHeader disable

Contact Header Transparency


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.

The SBC acting as P-CSCF supports Contact header full transparency under the following conditions:

  • SBC transparently passes Contact header towards core in the REGISTER if Contact header is in the form of an FQDN or if no IP interworking is performed between UE and core.
  • SBC transparently passes Contact header towards UE in the 200 OK to REGISTER if Contact header is in the form of an FQDN or if no IP interworking is performed between UE and core.
  • SBC transparently passes Contact header parameters towards core in the REGISTER if IP interworking is performed between V6 UE to V4 core (and vice versa).
  • SBC transparently passes Contact header parameters towards UE in the 200 OK to REGISTER if IP interworking is performed between V6 UE to V4 core (and vice versa).
  • SBC transparently passes Contact header in the egress INVITE/non-INVITE if Contact header is in the form of an FQDN or if no IP interworking is performed between UE and core.
  • SBC transparently passes Contact header in the egress 1xx or 2xx or 4xx or 5xx or 6xx to INVITE/non-INVITE if Contact header is in the form of an FQDN or if no IP interworking is performed between UE and core.
  • SBC transparently passes Contact header parameters in the egress INVITE/non-INVITE if IP interworking is performed between V6 UE to V4 core (and vice versa).
  • SBC transparently passes Contact header parameters in the egress 1xx or 2xx or 4xx or 5xx or 6xx to INVITE/non-INVITE if IP inter-working is performed between V6 UE to V4 core (and vice versa).

  • SBC transparently passes Contact header when "gr" parameter is present in Contact header even when full Contact header transparency is not enabled.

  • SBC can be configured to pass Contact header when "isFocus" parameter is present in Contact header even when full Contact header transparency is not enabled.

To enable Contact header full transparency, enable the passCompleteContactHeader flag in the IP Signaling Profiles associated with the core and peer SIP trunk groups.

Example:

% set profiles signaling ipSignalingProfile DFL_PCSCF_UE_TG_PROF commonIpAttributes transparencyFlags passCompleteContactHeader enable
% commit
% set profiles signaling ipSignalingProfile DFL_PCSCF_CORE_TG_PROF commonIpAttributes transparencyFlags passCompleteContactHeader enable
% commit

Refer to Common IP Attributes - SIP - CLI for CLI command details.

Contact Header 'isFocus'

The 3GPP specification 24.229 (release 12) requires the contact header to pass transparently when the contact header contains isFocus parameter. In previous releases, the SBC used passCompleteContactHeader flag to control "Contact" header transparency used to achieve this functionality. However, this parameter enables contact header transparency for all the requests.

The SBC includes the IP Signaling Profile contactTransparencyForIsFocusMediaTag flag to allow contact header transparency for all requests and responses when isFocus parameter is received in Contact header.  When enabled, contact header is transparently sent in outgoing message if isFocus parameter is received in contact header. This parameter is disabled by default. This flag is configurable from an external PSX.

For SBC configuration details, refer to:

For PSX-related information, refer to the PSX documentation.

  • No labels