One of the key reasons why we need the IMS is the support of multiple devices for the same public identity. Simply put we don’t care what physical device our counterpart has, we just call and it is up to the network to select the particular device or more devices. For example my buddy can be connected via 3G or 4G and wifi from his smartphone, and he can be also connected from a web browser using the WebRTC (and well there are already some operators testing this).
As the logic says the key headers which are being used for routing will remain the same.
The examples here are taken from real networks (AS/CSCF). The exact ids and IPs were modified. You can enjoy the diversity of headers we can find all around the world. There could be much more of them, but I don’t want to have the post too long and boring.
INVITE sip:0123456789; email@example.com; user=phone SIP/2.0
INVITE sip:+firstname.lastname@example.org; user=phone SIP/2.0
INVITE sip:email@example.com SIP/2.0
P-Served-User: <sip:+firstname.lastname@example.org>; sescase=orig;regstate=reg
But what differs are the Contact and P-Access-Network-Info headers. In the Contact header we can find a very important information in the sip.instance attribute.
The instance-id is defined in the RFC 5626 and RFC 7255. Each UA must have an Instance Identifier with Uniform Resource Name (URN) that uniquely identifies the device so that the registrar (S-CSCF) can recognize that the contacts from multiple registrations correspond to the same UA. The specification says that the URN has to stay persistent across power cycles of the device and the instance ID can’t change as the device moves from one network to another.
To convey its instance-id in both requests and responses, the UA includes a “sip.instance” media feature tag as a UA characteristic (see RFC3840). This media feature tag is a part of the Contact header field as the “+sip.instance” parameter. (In case where the UA it is making an anonymous request or has some other privacy concerns, it can prefer to omit the “sip.instance” tag.)
A UA should create a Universally Unique Identifier (UUID) URN (see the RFC4122) as its instance-id:
UUID = time-low "-" time-mid "-" time-high-and-version "-" clock-seq-and-reserved clock-seq-low "-" node time-low = 4hexOctet time-mid = 2hexOctet time-high-and-version = 2hexOctet clock-seq-and-reserved = hexOctet clock-seq-low = hexOctet node = 6hexOctet hexOctet = hexDigit hexDigit hexDigit = "0" / "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" / "9" / "a" / "b" / "c" / "d" / "e" / "f" / "A" / "B" / "C" / "D" / "E" / "F"
The UUID URN allows for non-centralized computation of a URN based on time, unique names (such as a MAC address), or a random number generator.
However the UUID is not mandatory and the specifications is met also by specifying the GSMA IMEI URN (see the RFC 7254):
gsma-urn = "urn:" gsma-NID ":" gsma-NSS gsma-NID = "gsma" gsma-NSS = imei-specifier / future-gsma-specifier imei-specifier = "imei:" ( imeival / ext-imei ) [ ";" sw-version-param ] [ ";" imei-version-param ] ext-imei = gsma-defined-nonempty ;GSMA defined and ;IETF consensus ;required sw-version-param = "svn=" software-version imei-version-param = "vers=" imei-version-val software-version = 2DIGIT imei-version-val = DIGIT future-gsma-specifier = future-specifier *( ";" future-param ) future-specifier = gsma-defined-nonempty ;GSMA defined future-param = par-name [ EQUAL par-value ] par-name = gsma-defined-nonempty par-value = gsma-defined-nonempty EQUAL = "=" gsma-defined-nonempty = 1*gsma-urn-char gsma-urn-char = ALPHA / DIGIT / "-" / "." / "_" / "%" / ":"
The P-Access-Network-Info is defined in the RFC 7315. Maybe you remember some details about the location which we discussed along with Emergency calls.
Contact: <sip:+email@example.com:5060; fw=220.127.116.11:8040;transport=udp>; expires=600000; q=0.1; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; +g.3gpp.smsip; +sip.instance="<urn:uuid:A1A1A1A1A-1234-5678-90AB-123456789ABCD>"; reg-id=1
Contact: <sip:id-123456789@sbc_01.network.operator.com:5060>; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; language="en,es"; +g.oma.sip-im
but we can find also imei there (as we use the same client for both wifi and lte)
Contact: <sip:firstname.lastname@example.org:5060;transport=udp>; reg-id=1; +sip.instance="<urn:gsma:imei:00110235-125103-0>"; video; +g.3gpp.smsip; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Contact: <sip:email@example.com:5060>; q=1.00; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; video; +sip.instance="<urn:gsma:imei:53716175-044719-0>"
Contact: <sip:10.1.1.236:11024>; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; +sip.instance="<urn:gsma:imei:10320254-095567-0;svn=12>"
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=12345678abcd123de P-Access-Network-Info: 3GPP-GERAN;cgi-3gpp=12301003a000f
Contact: <sip:client_id-Instance_hash123@18.104.22.168:5091; id-1-2-3456-78;transport=udp>; +sip.instance="<urn:uuid:14244fa5306ae778-90ac134-460e-96f3-17253054b63771102>"; video; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel.gsma.videocall"; +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"