You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Current »

 

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

Unable to show "metadata-from": No such page "_space_variables"
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
    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 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