SIP URI Overview

Posted on by

Everyone knows that SIP headers like R-URI, To, From, P-Asserted-Identity, Path, Route and others contain Uniform Resource Identifiers (URI) –  sip uri or tel uri. But do you know what formats we can use, with what parameters? As URI is one of the IP communication’s corner stones, it worth to have some better understanding.

volte-sip-uri

SIP URI in VoLTE

Let’s start from the beginning. SIP URI is defined in RFC 3261, TEL URI in RFC 3966 (this RFC defines also modem and fax URL schemes).

SIP URI has a similar form to an email address. It contains typically a username and a hostname, for example test@realtimecommunication.info, where realtimecommunication.info is the domain of a SIP service provider. TEL URI is simply a telephone (landline or mobile) number as tel:+611234567890. It is needed mainly to support CS related scenarios and Mobile Number Portability (MNP). In practice we can see various forms of sip-uris:

sip:+611234567890@operator.com
sip:+611234567890@ims.mnc000.mcc000.3gppnetwork.org
sip:ims.mnc000.mcc000.3gppnetwork.org
tel:+611234567890
sip:+611234567890@ims.mnc000.mcc000.3gppnetwork.org;user=phone;npdi
tel:4567890;phone-context=+61123
tel:7890;phone-context=operator.com
sip:ffffffff@tas.ims.operator.com:5060;transport=udp

Last but not least we have also a SIPS URI, which specifies that the resource is to be contacted securely. For that we use TLS as a transport layer protocol. The format for a SIPS URI is the same, except that the scheme is “sips” instead of sip. Note, that any resource described by a SIP URI can be “upgraded” to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely.

SIP URI Syntax

A SIP or SIPS URI identifies a communications resource. Its general form, in the case of a SIP URI, is:

 sip:user:password@host:port;uri-parameters?headers
  • user: The identifier of a particular resource at the host being addressed.
      • E.g. to address a context we have created for a particular session on S-CSCF we’d use sip uri
    sip:46646-65f9g4-6974-5adf@scscf.volte.operator.com
      • The “userinfo” of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and may be absent, for instance SIP REGISTER in R-URI doesn’t have the user part.
Request-Line: REGISTER sip:ims.mnc000.mcc000.3gppnetwork.org SIP/2.0 
Method: REGISTER 
Request-URI: sip:ims.mnc000.mcc000.3gppnetwork.org 
Request-URI Host Part: ims.mnc000.mcc000.3gppnetwork.org
  • password: we don’t use passwords in VoLTE networks in SIP Protocol
  • host: The host is providing the SIP resource. The term “host” in this context refers either to a domain or a particular SIP server. The host part contains either a fully-qualified domain name (FQDN) or numeric IPv4 or IPv6 address. The usage of FQDN is recommended whenever possible. (However in enterprise environment we can see mostly addresses based on numeric IPs.)
  • port: The port number where the request is to be sent. URI parameters: Parameters affecting a request constructed from the URI.

The significance of numeric IP and port information in sip uri for routing is explained in SIP Illustrated 5: Session Routing or DNS articles.

URI parameters take the form:

            parameter-name "=" parameter-value
  • parameters
    • comp: compression (sigcomp)
    • user: allows to distinguish telephone numbers from user name, see below
    • maddr: indicates the server address to be contacted for this user
    • method: method of the SIP request constructed from the URI can be specified with the method parameter
    • lr: Indicates loose routing.
    • ttl: Time To Live
    • other (user-defined) parameters are allowed – SIP elements have to silently ignore any uri-parameters that they do not understand!    

TEL URI Syntax

“tel” URI has the following syntax:

 tel:telephone-subscriber

The ‘telephone-subscriber’ part of the URI indicates the number. The phone number is represented in either Global  – E.164 or Local notation. All phone numbers have to use the global form unless they cannot be represented as such. Numbers from private numbering plans, emergency (“911”, “112”), and some directory-assistance numbers (e.g., “411”) and other “service codes” (numbers of the form N11 in the United States) cannot be represented in global (E.164) form and need to be represented as a local number with a context. Local numbers are tagged with a ‘phone-context‘.

Global TEL URI:

  tel:+1-234-555-0123

A local phone number valid within  “operator.com”:

  tel:0123;phone-context=operator.com

A local phone number that is valid within a particular phone prefix:

  tel:555-1234;phone-context=+1-123-456

URI Comparasion

There is more than one way how to write an address. And we need to know whether two SIP or SIPS URIs are equivalent. E.g. S-CSCF needs to compare bindings in Contact URIs in REGISTER requests. The most important rules are:

  • A SIP and SIPS URI are never equivalent.
  • Comparison of the userinfo of SIP and SIPS URIs is case-sensitive.
  • Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise.
  • The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs.
  • An IP address that is the result of a DNS lookup of a host name does not match that host name.
  • For two URIs to be equal, the user, password, host, and port components must match.

SIP URIs and tel URLs, Mobile Number Portability

A TEL URL can be converted to a SIP or SIPS URI. The entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI.

SIP URI in its user part can contain alphanumeric characters. E.g. example1@operator.com. Or +12345679012@operator.com. So how to find out if we’re supposed to treat the username as a telephone number or not? A user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value “phone” is resent.

(But even without this parameter, recipients of SIP and SIPS URIs can still interpret the user part as a telephone number if local restrictions on the name space for user name allow it.)

tel:+123-555-1234567 becomes

sip:+123-555-1234567@operator.com;user=phone

or
sips:+123-555-1234567@operator.com;user=phone

So if TAS recieves a request

INVITE sip:+19023412345@ims.mnc019.mcc234.3gppnetwork.org;user=phone SIP/2.0

it means, treat the sip uri as a tel uri

tel:+19023412345

The reason is that when we’re calling someone, we have no idea what network he or she belongs to. We know only the number. And thanks to MNP we can’t even derive this information from the number. That is a task for TAS or S-CSCF to do an ENUM dip.

The related specification is RFC 4694, which specifies additional tel uri parameters such as “rn“, “npdi“, or “cic“.

IMS and Identities

IMS Servers

I-CSCFs used in registration are allocated SIP URIs, which are also provisioned in DNS. In general I-CSCF is representing the whole domain.

 Queries
 operator.com: type NAPTR, class IN
 Name:operator.com
 Type: NAPTR (Naming authority pointer)
Authoritative nameservers
operator.com: type SOA, class IN, mname dns_01.operator.com
...
;      order pref flags service regexp replacement 
IN NAPTR 10 50 "s" "SIPS+D2T" "" _sips._tcp.icscf.ims.operator.com. 
IN NAPTR 20 50 "s" "SIP+D2T" "" _sip._tcp.icscf.ims.operator.com. 
IN NAPTR 100 50 "s" "SIP+D2U" "" _sip._udp.t.ims.operator.com.

Other IMS elements have their own specific SIP URIs, which can also contain a username.

sip:pcscf.operator.com 
sip:<impl-specific-info>@pcscf-site_a.operator.com

If the user part exists, it is an essential part of the address and can’t be omitted when copying or moving the address. How these addresses are assigned to the logical entities is up to the network operator. For example, a single SIP URI may be assigned to all I-CSCFs, and the load shared between various physical boxes by underlying IP capabilities, or separate SIP URIs may be assigned to each I-CSCF, and the load shared between various physical boxes using DNS SRV capabilities.

 ;;          Priority Weight Port   Target
     IN SRV  0        1      5060   icscf1.ims.operator.com
     IN SRV  0        2      5060   icscf2.ims.operator.com

IMS Subscribers

The subscriber is allocated a private user identity (IMPI) by the home network operator. This IMPI is available to the SIP application within the UE. Depending on a  device and technology, various arrangements exist within the UE for retaining this information:

  • where an ISIM is present, IMPI is stored within the ISIM
  • where no ISIM is present but USIM is present, the private user identity is derived
  • if either ISIM nor USIM is present, but IMS Credentials (IMC) is present, IMSI is set within IMC (e.g for Wifi)
  • when neither ISIM nor USIM nor IMC is present, the private user identity is available to the UE via othermeans (e.g for WebRTC using WebRTC GW retrieves IMPI from a configuration server)

In a similar way the subscriber is allocated one or more public user identities (IMPUs) by the home network operator.

For each TEL URI, there is at least one alias SIP URI in the set of implicitly registered public user identities that is used to implicitly register the associated tel URI.

P-Associated-URI: <sip:+441234567890@operator.co.uk>,
<sip:+441234567890@operator.co.uk;user=phone>

The IMPUs can be shared across multiple UEs. If the TEL URI is a shared public user identity, then the associated alias SIP URI is a shared public user identity too. And also if the alias SIP URI is a shared public user identity, then the associated TEL URI is also a shared public user identity.

Registration

On sending an unprotected REGISTER request, the UE creates the header fields as follows:

  •  a From header field set to the SIP URI that contains:
    • IMPU to be registered;
  •  a To header field set to the SIP URI that contains:
    • IMPU to be registered;
  •  a Contact header field set includes SIP URI(s) containing the IP address or FQDN of the UE in the hostpart parameter.

Emergency

Identification of the UE to a PSAP with point of presence in the CS domain is not possible if a TEL URI is not included in the set of implicitly registered IMPUs. If the included TEL URI is associated either with the first entry in the list of IMPUs provisioned in the UE or with the temporary IMPU, then a PSAP can uniquely identify the UE that the emergency registration is performed.

Mind that the Emergency registration is not always supported!

E-CSCFs themselves are allocated multiple SIP URIs. The SIP URI configured in the P-CSCF, AS or IBCF to reach the E-CSCF is distinct from the one given by the E-CSCF to the EATF such that EATF can reach the E-CSCF.

NNI

The “iotl” SIP URI parameter containings traffic leg information. It can be used by IBCF and transit networks to make policy decisions related to e.g. media anchoring, screening of SIP
signalling, insertion of media functions (e.g. transcoder) and charging.

Route: <sip:ibcf.operator-visited.com;lr>,<sip:contextX@scscf.operator-home.com;lr:iotl="visitedNethomeNet">

VoLTE Identifiers

Contact header

UE includes a user part in the URI of the contact address such that the user part is globally unique and does not reveal any private information. To generate this user part, the UE can use a time-based UUID (Universal Unique Identifier) generated as per RFC 4122.

VoLTE Public User Identities

All IMPUs provided in the implicit registration set used for VoLTE by the IMS are alias user identities and include a TEL URI. The IMPU is assigned to the implicit registration set used for VoLTE and it is used by the UE when registering for VoLTE:

  • When ISIM is used, the IMPU in the first (or only) record in the Elementary File in the ISIM (3GPP TS 31.103);
  • or the temporary public user identity derived from the IMSI (3GPP TS 24.229).

No other implicit registration set can be used for VoLTE.

For VoLTE IMS the support for ISIM based authentication in the UE is mandatory. The UE and IMS core network also support the procedures for USIM based authentication if there is no ISIM present on the UICC.

Moreover this includes support for the P-Associated-URI header to handle barred IMPUs.

Public Service Identifiers (PSIs)

The support of PSIs is defined in 3GPP TS 23.003, and includes the following types of addresses:

  • Alphanumeric SIP-URIs 
    sip:voicemail@operator.com
  • MSISDN represented as a SIP URI 
    sip:+447700900123@operator.com;user=phone
  • MSISDN represented as a tel URI 
    tel:+447700900123

Note: Some more requirements for support of Public User Identities in the network are specified in IR.65.

Local numbers

As per IR.92 the UE sets the dial string containing the local number to the user part of SIP URI in the Request URI, and set the “user=phone” parameter, with the “phone-context” TEL URI parameter to the user part.

  • for home local numbers the UE must set the “phone-context” parameter to the home domain name, as it is used to address the SIP REGISTER request.
  • for geo-local numbers the UE must set the “phone-context” parameter with additional visited network information when available.

 

Related articles:

6 thoughts on “SIP URI Overview”

  1. one user has a 3 device with different Ip address. in that case if user has already registered with one device. my question is that suppose same user is going to register with other device in IMS network.
    Does first device get de register automatically. please share your comments on this.

    appreciate your comments in advance.

    Like

    Reply

    • No, you can have multiple devices registered for 1 user. All the registrations will be handled by the same S-CSCF.

      Like

      Reply

    • A public service identity identifies a service, or a specific resource created for a service on an application server. E.g. this way we can trigger some function, like a chatbot or conference service:
      sip:chatbot@operator.com

      Like

      Reply

  3. Hi

    Can the SCSCF modify the URI to incorporate special service prefix codes to identify a service (eg: translating B party number into xxxB) and how is that then correlated back to the originating INVITE via the PCSCF for CDR billing purposes?

    Thanks!

    Like

    Reply

    • Although this is typically done by AS, in general any network element can change a URI (suppose we’re talking about R-URI). So let’s say that you change R-URI on S-CSCF and then TAS will apply Online Charging. But that should be based on P-Served-User identity. Offline charging then should use P-Charging-Vector. Still we should be careful with R-URI manipulation and rather use some tags if possible.

      Like

      Reply

Leave a Reply