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.


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.

 

In existing telecommunications systems, many well-known communication and information services are offered by loosely coordinated entities across a large geographic region, with well- known identifiers. These services are characterized by long-term stability of user- visible identifiers, decentralized administration of the underlying service, and a well-defined resolution or mapping mechanism. A Uniform Resource Name (URN) allows us to define such global, well-known services while distributing the actual implementation across a large number of service-providing entities.

A URN is a hierarchical service identifier with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level service', while names to the right are called 'sub-services'. The set of allowable characters is the same as that for domain names [RFC1123] and a subset of the labels allowed in [RFC3958]. Labels are case-insensitive, but MUST be specified in all lower-case. For any given service URN, service-identifiers can be removed right-to-left; the resulting URN is still valid, referring to a more generic service. In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs.

The SBC Core supports the following services:

  • Emergency URN—Ability to route an incoming message with SIP URNs (in Request-URI and To headers) towards the destination (next-hop). The SBC determines the destination based on the URI in the Request-URI. The destination is configured in ERE or external PSX. The SBC classifies an incoming call with SIP URN in Request-URI as an emergency call if the same is present in Emergency Profile (attached to ingress Trunk Group), and then translate SIP URN in Request-URI and To header to a number or user-name. The translated number is in SIP or Tel format.
  • URN—Transparently passes the following headers/parameters in INVITE, In-Dialog REFER and other OOD requests:
    • Request-URI and To headers in SIP URN format.
    • URN used in P-Preferred-Service, P-Asserted-Service headers and unknown headers by enabling unknown header transparency.
    • URNs in Accept-Contact by enabling transparency flag.
    • URN as a parameter in Request Line, To Header, and Contact Header in both request and responses by enabling Request-URI/To/Contact Header transparency.
  • SIP URN in Refer-To header of a REFER message—When the SBC receives a 3xx response for a MESSAGE, the SBC relays it towards the ingress leg.
  • Recursion handling of 3xx response for a MESSAGE—This is similar to 3xx recursion handling of 3xx response for INVITE message.
  • SIP URN in Gateway-to-Gateway signaling (SBC-to-SBC)—For gateway signaling between the SBC and GSX9000, SIP URNs are translated to SIP/TEL before forwarding to the GSX9000.
When a 3xx response is received with both Diversion and History-Info data, Diversion data is processed on priority in received 3xx irrespective of the diversion or history-info configuration support on new egress route where call is redirected.

  • No labels