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:

Overview

A SIP URI is the SIP addressing scheme used to contact other SIP users on other SIP networks. The standard format for a SIP URI is:

USER@ADDRESS

A SIP URI must not contain special characters, such as "(), [], {}, *, #, $, !, ^". Using these characters may cause problems as these are special characters and may provide an unintended result.


Caution

The SBC supports SIP URI messages containing up to 20 parameters in any SIP header. However, increasing the number of URI parameters impacts memory usage. For example, increasing the number of parameters from 10 to 20 will increase memory usage by approximately 10%.


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.

Info

Refer to the following pages to configure URIs for a SIP Adaptor Profile:

SIPS URI Scheme

SIP URI scheme allows resources to require a secure connection using TLS for each hop over which a request is forwarded to the target domain. SIPS scheme enables protection against attackers trying to listen in on the signaling link.

The SBC currently does not carry the URI scheme received in the ingress leg forward to the egress leg, and does not provide an option to enforce TLS as a secured transport when the SIP URI scheme is “sips”. This feature provides the requisite options to achieve the following using new Trunk Group configuration:

  • Enforce SIPS if egress transport is TLS.
  • Enforce TLSIfSipsUriScheme if ingress URI has SIPS.

The SBC rejects a request received in following scenarios:

  1. In non-TLS transport if the Request URI scheme is SIPS if “EnforceTlsIfSipsUriScheme” is enabled at the trunk group on which request is received.
  2. With SIPS scheme in contact, but SIP scheme in Request-Uri, if “EnforceSipsIfEgressIsTls” is enabled at the trunk group on which request is received.
Info

Refer to the following pages for configuration details:

SIP URI Transparency

In a mixed FQDN and IP environment when a message is outbound, SIP URIs or TEL URIs may contain identities/usernames that are not global and may also contain private IP addresses.This makes the message meaningless when the call is forwarded to another IP-domain. The SBC Core overcomes this obstacle by providing the following SIP URI transparency capabilities.

  • Standardizing telephone numbers representations in the network by globalizing the user part of URIs in various headers of outgoing SIP PDUs.
  • Supporting mixed FQDN and IP environments by defining domain mapping rules to rewrite host part of URIs in various headers of outgoing SIP PDUs.

These capabilities ensure that SIP-URIs and TEL-URLs in a network always describe an unambiguous valid global user identity.

SIP headers considered for user name globalization and domain mapping rules are categorized as:

  • Originating Identities: FROM, PAI and DIVERSION
  • Terminating Identities: TO and RURI

User Name Globalization

Publicly accessible telephone number formats are shown below. Any additional publicly accessible telephone number formats are rewritten at the network border.

TEL:+<ISN>
SIP:+<ISN>@domain.name;user=phone 

Private accessible telephone number formats are shown below. These formats are an allowed identities, but are not publicly accessible telephone numbers.

sip:<digits>@some.domain
sip:user@domain.com

A Globalization example is provided below.

Ingress Message:

SIP:0<NSN>@domain.name;user=phone

Egress Message:

SIP:+<CC><NSN>@domain.name;user=phone

Domain Name Mapping Rules

Some networks allow mixed ingress traffic supporting both FQDN and IP addresses requiring manipulation to preserve the FQDNs or replace IP addresses. This is achieved by defining domain mapping rules to rewrite the host part of URIs in various headers of outgoing SIP PDUs.The domain names used for originating identities are based on inbound trunk group. The domain names used for terminating identities are related to the outbound trunk group or to the routing label.

Example of domain name mapping for SIP URIs:

Ingress Message:

SIP:+<ISN>@<IP-address>;user=phone

Egress Message:

TEL:+<ISN

OR

SIP:+<ISN>@some.domain;user=phone

SIP URI Preference Over TEL URI

For domain name mapping, the SBC gives preference to SIP URI over TEL URL for a given originating/terminating identity when URI preference is set to SIP.

Ingress Message:

TEL:0<NSN>

Egress Message:

SIP:+<CC><NSN>@some.domian;user=phone
Note

The PSX Globalize Profile provides globalization information for all originating and terminating identities individually in policy response to the SBC. For more information, refer to the "Globalize Profile Screen" in PSX documentation.

To configure Domain Name Mapping details for all the originating and terminating identities individually, refer to the PSX document "DM/PM Rule Screen".

SIP header UserInfo support up to 512 bytes

The PSX contains two flags, Ignore Unmodified Called Userpart If Truncated and Ignore Unmodified Calling Userpart If Truncated, in the PSX IP Signaling Profile (IPSP) to control the length of the user part sent in the egress message. When a operator enables these IPSP flags, the SBC/SIPE supports up to 512 characters in the username field, including the null characters for RURI, FROM, TO, and CONTACT headers. 

The SBC supports the SIP header username field length of up to 512 bytes, including the null character for the RURI, FROM, TO, and CONTACT headers, when the PSX IPSP flags are enabled. When transparency is enabled, the SBC supports all headers that contain username length of up to 512 bytes. 

The SBC rejects any Request URI that has a username length greater than or equal to 512 bytes with the "414 Request-URI Too Large" error message. 

This enhancement is based on TGRP/Trunk-Context and Domain Name routing. Username routing is not considered. The PSX still only accepts a username field of up to 64 bytes and returns a value of up to 64 bytes in the policy response. However, the PSX adds two IPSP flags to manage the length of the username sent in the policy response. The flags are disabled by default.

For details about the PSX IPSP flags refer to the PSX documentation at IP Signaling Profile Screen.