SIP URI Overview

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.



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, where 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:

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:

  • 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
      • 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/2.0 
Request-URI Host Part:
  • 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:


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:


A local phone number valid within  “”:


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


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. Or 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;user=phone


So if TAS recieves a request

INVITE;user=phone SIP/2.0

it means, treat the sip uri as a tel uri


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 type NAPTR, class IN
 Type: NAPTR (Naming authority pointer)
Authoritative nameservers type SOA, class IN, mname
;      order pref flags service regexp replacement 
IN NAPTR 10 50 "s" "SIPS+D2T" "" 
IN NAPTR 20 50 "s" "SIP+D2T" "" 
IN NAPTR 100 50 "s" "SIP+D2U" ""

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

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
     IN SRV  0        2      5060

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: <>,

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.


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.


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.


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: <;lr>,<;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
  • MSISDN represented as a SIP URI;user=phone
  • MSISDN represented as a tel URI

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.


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


    • 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:


  2. 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?



    • 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.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s