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.
SIP URI has a similar form to an email address. It contains typically a username and a hostname, for example email@example.com, 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:+firstname.lastname@example.org sip:+email@example.com sip:ims.mnc000.mcc000.3gppnetwork.org tel:+611234567890 sip:+firstname.lastname@example.org;user=phone;npdi tel:4567890;phone-context=+61123 tel:7890;phone-context=operator.com sip:email@example.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:
- 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
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.
URI parameters take the form:
parameter-name "=" parameter-value
- 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 “operator.com”:
A local phone number that is valid within a particular phone prefix:
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. firstname.lastname@example.org. Or +email@example.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:+firstname.lastname@example.org;user=phone or sips:+email@example.com;user=phone
So if TAS recieves a request
INVITE sip:+firstname.lastname@example.org;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
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.
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
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:+email@example.com>, <sip:+firstname.lastname@example.org;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.
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.
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
- MSISDN represented as a tel URI
Note: Some more requirements for support of Public User Identities in the network are specified in IR.65.
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.