SIP URN Support

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

• Emergency URN—Ability to route an incoming message with SIP URNs (in Request-URI and To headers) towards the destination (next-hop). The
  Unable to show "metadata-from": No such page "_space_variables"
  determines the destination based on the URI in the Request-URI. The destination is configured in ERE or external PSX. The
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  receives a 3xx response for a MESSAGE, the
  Unable to show "metadata-from": No such page "_space_variables"
  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
  Unable to show "metadata-from": No such page "_space_variables"
  and GSX9000, SIP URNs are translated to SIP/TEL before forwarding to GSX9000.