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.
Request-URI
INVITE sip:0123456789; phone-context=ims.mnc000.mcc000.3gppnetwork.org@ims.mnc000.mcc000.3gppnetwork.org; user=phone SIP/2.0
or
INVITE sip:+12345678912@ims.operator.com; user=phone SIP/2.0
or just
INVITE sip:12345678912@server.networks.operator.com SIP/2.0
P-Prefered-Identity
P-Preferred-Identity: sip:+12345678912@ims.operator.com
P-Asserted-Identity
P-Asserted-Identity: sip:+12345678912@ims.operator.com
P-Served-User
P-Served-User: <sip:+12345678912@ims.operator.com>; 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.
Examples
VoWifi:
Contact
Contact: <sip:+1234567812-id-12345abcd@182.2.1.18:5060; fw=155.49.210.65: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
or
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:sbc01@ims.operator.com:5090;lr>;
+sip.instance="<urn:gsma:imei:12349402-123436-0>"
P-Access-Network-Info
P-Access-Network-Info: IEEE-802.11;i-wlan-node-id=0123456789ab
Packet network
Contact
Contact: <sip:id@192.133.1.74: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"
or
Contact: <sip:12345678912@10.1.55.121: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>"
or
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
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=12345678abcd123de P-Access-Network-Info: 3GPP-GERAN;cgi-3gpp=12301003a000f
WebRTC
Contact
Contact: <sip:client_id-Instance_hash123@45.105.212.3: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"
Pingback: Much Ado about Registration | Real Time Communication
Pingback: Summer & IMS | Real Time Communication
Pingback: WebRTC GW | Real Time Communication
Pingback: How to read tcpdump – Registration | Real Time Communication
Pingback: Call-ID and Other Message Identifiers | Real Time Communication