Headers in User-centric networks

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"
Advertisements

5 thoughts on “Headers in User-centric networks

  1. Pingback: Much Ado about Registration | Real Time Communication

  2. Pingback: Summer & IMS | Real Time Communication

  3. Pingback: WebRTC GW | Real Time Communication

  4. Pingback: How to read tcpdump – Registration | Real Time Communication

  5. Pingback: Call-ID and Other Message Identifiers | Real Time Communication

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s