How to read tcpdump – Registration

Posted on by

In telco tracing has always been very important. It helps us to understand the flows, the content and – sure – to find bugs. SS7 used to be much more strict and we didn’t need to go in the detail traces that often. The flow and a few fields was usually enough. With SIP and SDP it is a different story. SIP is a very flexible protocol. That means powerful but also complex and sometimes quite confusing.

Let’s take a look on IMS Registration. I’m sure you remember the idea behind from a previous posts about Registration and 3rd party registration and at least the basic flow:

 

IMS Registration

IMS Registration

The registration flow is very important – in practice if something goes wrong, it is most probably registration. Once is a subscriber correctly registered,  the other flows (call, sms, fileshare) usually works fine.

There are many documents describing the message flow and important values. For VoLTE I’d recommend to go through VoLTE Service Description and Implementation Guide or A Definitive Guide to Successful Deployments. Would you have any doubts about a particular header please refer to http://www.iana.org/assignments/sip-parameters/sip-parameters.xhtml. Now let’s go through the particular messages.

 

 

The examples are taken from real VoLTE networks (test UE). The IP, FQDNs, IDs, URIs etc. were modified.

1. UE -> REGISTER SBC

Session Initiation Protocol (SIP as raw text)
 REGISTER sip:ims.mnc000.mcc000.3gppnetwork.org SIP/2.0 
 Expires: 3600 
 User-Agent: SLICK IMS 4.5.0 
 P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890123456 
 Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK 
 Supported: path 
 Contact: <sip:123456789012345@10.1.1.221:5060>;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>" 
 Authorization: Digest username="123456789012345@ims.mnc000.mcc000.3gppnetwork.org",realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="",uri="sip:ims.mnc000.mcc000.3gppnetwork.org",response="" 
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593 
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org> 
 Call-ID: 39510918
 CSeq: 1 REGISTER 
 Max-Forwards: 70 
 Via: SIP/2.0/UDP 10.1.1.221:5060;branch=z9hG4bK987772968;transport=UDP;rport 
 Content-Length: 0

In the message we can firstly see the Request-URI header:

 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

It indicates what is the domain user is registering to. This will be used an input for DNS NAPTR/SRV query.

The information about the registered user is in the To header:

To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>
 SIP to address: sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 SIP to address User Part: 123456789012345
 SIP to address Host Part: ims.mnc000.mcc000.3gppnetwork.org

Note that these days probably all operators use an MSISDN or IMSI as a part of the sip uri.

The S-CSCF needs to know the binding between the real point of presence and the user identity. It also needs to know about the capabilities. All this information is stored in the Contact:

 Contact: <sip:123456789012345@10.1.1.221:5060>;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>"
 Contact URI: sip:123456789012345@10.1.1.221:5060
 Contact URI User Part: 123456789012345
 Contact URI Host Part: 10.1.1.221
 Contact URI Host Port: 5060
 Contact parameter: q=1.00
 Contact parameter: +g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
 Contact parameter: video
 Contact parameter: +sip.instance="<urn:gsma:imei:12345678-123456-2>"\r\n

As we mentioned in previous post the sip.instance is used to identify a particular client instance.

Last but not least we can find the famous PANI header which contains the information about the access network and also the information about location which can be used for example in case of an emergency call.

P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890123456

The Authorization header contains the Username and Realm, but as the Response field is empty we know that the S-CSCF will challenge the UE to prove its identity first.

 

2. SBC -> I-CSCF

 Request-Line: REGISTER sip:ims.mnc000.mcc000.3gppnetwork.org SIP/2.0
 P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890123456
 Contact: <sip:123456789012345@10.1.1.221:5060>;expires=3600;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>"
 Authorization: Digest username="123456789012345@ims.mnc000.mcc000.3gppnetwork.org",realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="",uri="sip:ims.mnc000.mcc000.3gppnetwork.org",response=""
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>
 Call-ID: 39510918@10.1.1.221
 CSeq: 1 REGISTER
 [truncated] Via: SIP/2.0/TCP sbc-atcf_01.volte.operator.com:5060;rport;branch=z9hG4bK836829-0-158-2-1-e0ff0002-1ca94bec4a7d15e8,SIP/2.0/TCP sbc_01.volte.operator.com:5060;NwkIntf=2;Realm=mwmx;recvdSrvPort=5060;r
 Require: path
 P-Visited-Network-ID: sbc_01_epc.volte.operator.com
 P-Charging-Vector: icid-value=255.370.1073741823-1422879486.25995;orig-ioi=Ioi1;icid-generated-at=211.98.143.25
 Path: <sip:836829-0-159-3fffffff-1-6b8b480d@sbc-atcf_01.volte.operator.com:5060;038592-0-158-18-1-6b8b480d;mtcall;lr>,<sip:038592-0-115-1cc-2-400aa44c@sbc_01.volte.operator.com:5060;lr;mtcall>
 P-Charging-Function-Addresses: ecf="aaa://PCF.charging.operator.com";ccf="aaa://PCF.charging.operator.com"

The SBC is a gateway into the IMS network. It is responsible for security – topology hiding, privacy protection, IPv4 – IPv6 interworking and plenty of other things. For that reason the SBC usually modifies the contact header and will replace the IP and port with its own.  (In our example this is not the case. Very often UE is on IPv6 and IMS network on IPv4.)

SBC checks the PANI header and if the information is not correct it should update the value. Based on the access network it also adds the PVNI:

 P-Visited-Network-ID: sbc_01_epc.volte.operator.com

SBC can add also an information related to charging.

 P-Charging-Vector: icid-value=255.370.1073741823-1422879486.25995;orig-ioi=Ioi1;icid-generated-at=211.98.143.25



 P-Charging-Function-Addresses: ecf="aaa://PCF.charging.operator.com";ccf="aaa://PCF.charging.operator.com"

The P-CSCF requires the path header as this field is used to forward its address to S-CSCF. S-CSCF then knows for each user what SBC is maintaining the dialog with UE.

 Require: path
 Path: <sip:836829-0-159-3fffffff-1-6b8b480d@sbc-atcf_01.volte.operator.com:5060;038592-0-158-18-1-6b8b480d;mtcall;lr>,<sip:038592-0-115-1cc-2-400aa44c@sbc_01.volte.operator.com:5060;lr;mtcall>

Finally it adds its own address in the Via header for the routing of the response message.

 

3. UAR

AVP: Session-Id(263) l=64 f=-M- val=avk6-icscf-1-vip-sip.volte.operator.com;1205554747;27712
AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
AVP: Origin-Host(264) l=47 f=-M- val=icscf-1-vip-sip.volte.operator.com
AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: Destination-Realm(283) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
AVP: Public-Identity(601) l=65 f=VM- vnd=TGPP val=sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org
AVP: Visited-Network-Identifier(600) l=49 f=VM- vnd=TGPP val=61766b362d7561672d312d7669702d6570732e766f6c7465...
AVP: User-Authorization-Type(623) l=16 f=VM- vnd=TGPP val=REGISTRATION (0)
AVP: Supported-Features(628) l=56 f=V-- vnd=TGPP
AVP: Vendor-Id(266) l=12 f=-M- val=10415
AVP: Feature-List-ID(629) l=16 f=V-- vnd=TGPP val=1
AVP: Feature-List(630) l=16 f=V-- vnd=TGPP val=4

The main purpose of the UAR is to get the address of s-cscf for the given IMPU in the UAA.

 

Public-Identity – IMPU

Visited-Network-Identifier – HSS compares with it’s Home Networks List

User-Authorization-Type – Used to determine handling of the request and if the server name should be returned or only the capabilities

 

4. UAA

AVP: Session-Id(263) l=64 f=-M- val=icscf-1.volte.operator.com;1205554747;27712
AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
AVP: Origin-Host(264) l=58 f=-M- val=hss_01-ims.mnc000.mcc000.3gppnetwork.org
AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: Supported-Features(628) l=56 f=V-- vnd=TGPP
AVP: Feature-List-ID(629) l=16 f=V-- vnd=TGPP val=1
AVP: Feature-List(630) l=16 f=V-- vnd=TGPP val=4
AVP: Experimental-Result-Code(298) l=12 f=-M- val=DIAMETER_FIRST_REGISTRATION (2001)
AVP: Server-Capabilities(603) l=88 f=VM- vnd=TGPP
AVP: Mandatory-Capability(604) l=16 f=VM- vnd=TGPP val=1
AVP: Optional-Capability(605) l=16 f=VM- vnd=TGPP val=2
AVP: Server-Name(602) l=42 f=VM- vnd=TGPP val=sip:scscf.volte.operator.com:5070

Each user has an assigned S-CSCF.  The server name and capabilities can be missing. In that case a default decision can be taken by I-CSCF.

Server-Name – Stored S-CSCF name in the user profile. If it is not available, Server-Capabilities will be used.

 

5. I-CSCF -> S-CSCF

as I-CSCF and S-CSCF are often collocated in the same box (CSCF/IMSCore) don’t be confused if this message is missing. Anyway except the Via header there is no new information there.

 

6. MAR

AVP: Session-Id(263) l=64 f=-M- val=scscf-1.volte.operator.com;1804289384;17133
AVP: Vendor-Specific-Application-Id(260) l=32 f=-M-
AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
AVP: Origin-Host(264) l=47 f=-M- val=scscf-1.volte.operator.com
AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: Destination-Realm(283) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
AVP: Public-Identity(601) l=65 f=VM- vnd=TGPP val=sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org
AVP: SIP-Auth-Data-Item(612) l=32 f=VM- vnd=TGPP
AVP: SIP-Authentication-Scheme(608) l=19 f=VM- vnd=TGPP val=Unknown
AVP: SIP-Number-Auth-Items(607) l=16 f=VM- vnd=TGPP val=1
AVP: Server-Name(602) l=60 f=VM- vnd=TGPP val=sip:scscf-1.volte.operator.com:5070

Via MAR the S-CSCF asks for the authentication vectors.

Public-Identity – IMPU

SIP-Auth-Data-Items – Authentication scheme selection

Server-Name – The S-CSCF name for the user profile

 

7. MAA

AVP: Session-Id(263) l=64 f=-M- val=scscf-1.volte.operator.com;1804289384;17133
AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
AVP: Origin-Host(264) l=58 f=-M- val=hss_01-ims.mnc000.mcc000.3gppnetwork.org
AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
AVP: SIP-Auth-Data-Item(612) l=160 f=VM- vnd=TGPP
AVP: SIP-Authorization(610) l=20 f=VM- vnd=TGPP val=af6bd8008b872643
AVP: Confidentiality-Key(625) l=28 f=VM- vnd=TGPP val=82f23289d03df16d163ebe8fcf1062d5
AVP: Integrity-Key(626) l=28 f=VM- vnd=TGPP val=9737cdbaabb7c563f896f5dcf2311f7a
AVP: SIP-Number-Auth-Items(607) l=16 f=VM- vnd=TGPP val=1
AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
AVP: Public-Identity(601) l=65 f=VM- vnd=TGPP
AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_SUCCESS (2001)

Based on this data the S-CSCF will challenge the UE.

AKA

SIP-Auth-Data-Item::SIP-Authenticate – RAND+AUTN, base64 encoded

SIP-Auth-Data-Item::SIP-Authorize – XRES

SIP-Auth-Data-Item::SIP-Confidentiality-Key – CK

SIP-Auth-Data-Item::SIP-Integrity-Key – IK

 

SIP Digest

 AVP: SIP-Authentication-Scheme(608) l=28 f=VM- vnd=TGPP val=SIP Digest
 AVP: SIP-Authenticate(609) l=44 f=VM- vnd=TGPP
 AVP: SIP-Digest-Authenticate AVP(635) l=124 f=VM- vnd=TGPP
 AVP: Digest-Realm(104) l=23 f=-M- val=operator.com
 AVP: Digest-Domain(119) l=23 f=-M- val=operator.com
 AVP: Digest-Algorithm(111) l=11 f=-M- val=md5
 AVP: Digest-HA1(121) l=40 f=-M- val=d6ec6eba8e80921cb040920da18f4cd4

If the Digest-Algorithm value is “MD5” or unspecified, then HA1 is

HA1=MD5(username:realm:password)

If the algorithm directive’s value is “MD5-sess”, then HA1 is

HA1=MD5(MD5(username:realm:password):nonce:cnonce)
If the qop directive’s value is “auth” or “auth-int”, then compute the response as follows:

response=MD5(HA1:nonce:nonceCount:clientNonce:qop:HA2)

If the qop directive is unspecified, then compute the response as follows:

response=MD5(HA1:nonce:HA2)

8. 401 S-CSCF -> SBC

 SIP/2.0 401 Unauthorized 
 [truncated] Via: SIP/2.0/TCP sbc-atcf_01.volte.operator.com:5060;received=211.98.143.17;rport=50604;branch=z9hG4bK836829-0-158-2-1-e0ff0002-1ca94bec4a7d15e8,SIP/2.0/TCP sbc_01.volte.operator.com:5060;NwkIntf=2;Realm=
 WWW-Authenticate: Digest algorithm=AKAv1-MD5,realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY=",ik="9737cdbafbb7c563f896f6dcf2311f7a",ck="82f23389d03df16d063ebe8fcf1062d5" 
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593 
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=836829-0-4b-a4-1-ffffffc7-_005056A220EB-2b43-9aa8700-2acdf-54cf6afe-3d46e 
 Call-ID: 39510918@10.1.1.221 
 CSeq: 1 REGISTER 
 P-Charging-Vector: icid-value=255.370.1073741823-1422879486.25995;term-ioi=12345;orig-ioi=Ioi1 
 Content-Length: 0

In the 401 the user will get the information about the authentication algorithm which is being used and its parameters

 WWW-Authenticate
 Authentication Scheme: Digest
 Algorithm: AKAv1-MD5
 Realm: "ims.mnc000.mcc000.3gppnetwork.org"
 Nonce Value: "I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY="
 Integrity Key: "9737cdbafbb7c563f896f6dcf2311f7a"
 Cyphering Key: "82f23389d03df16d063ebe8fcf1062d5"

Nonce is a one-time generated value which ensures that the response can be used only once. So even in case that someone would intercept the response he will get a key which can be used only once  (nonce=base64(RAND, AUTN, server specific data)).

9. 401 SBC->UE

 SIP/2.0 401 Unauthorized 
 Via: SIP/2.0/UDP 10.1.1.221:5060;received=10.1.1.221;branch=z9hG4bK987772968smg;transport=UDP;rport=5060 
 WWW-Authenticate: Digest algorithm=AKAv1-MD5,realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY=" 
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593 
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=836829-0-4b-a4-1-ffffffc7-_005056A220EB-2b43-9aa8700-2acdf-54cf6afe-3d46e 
 Call-ID: 39510918@10.1.1.221 
 CSeq: 1 REGISTER 
 Content-Length: 0

Note that the P-Charging-Vector is missing. That’s because SBC protects the IMS network and its responsibility is not to reveal any private data to untrusted network.

10. 2nd Register UE->SBC

 REGISTER sip:ims.mnc000.mcc000.3gppnetwork.org SIP/2.0 
 Expires: 3600 
 User-Agent: SLICK IMS 4.5.0 
 P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890123456 
 Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK 
 Supported: path 
 [truncated] Authorization: Digest username="123456789012345@ims.mnc000.mcc000.3gppnetwork.org",realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY=",algorithm=AKAv1-MD5,uri="sip:ims.mnc000.mcc000.3g
 Contact: <sip:123456789012345@10.1.1.221:5060>;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>" 
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593 
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org> 
 Call-ID: 39510918@10.1.1.221 
 CSeq: 2 REGISTER 
 Max-Forwards: 70 
 Via: SIP/2.0/UDP 10.1.1.221:5060;branch=z9hG4bK3219487738smg;transport=UDP;rport 
 Content-Length: 0

This is the second REGISTER message that we can learn from the CSeq header. It doesn’t necessarily have to contain ‘2’ but the value from the previous REGISTER has to be incremented.

 

The user authentication is done based data sent in the Authorization header:

 Authorization: Digest username="123456789012345@ims.mnc000.mcc000.3gppnetwork.org",realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY=",algorithm=AKAv1-MD5,uri="sip:ims.mnc000.mcc000.3g
 Authentication Scheme: Digest
 Username: "123456789012345@ims.mnc000.mcc000.3gppnetwork.org"
 Realm: "ims.mnc000.mcc000.3gppnetwork.org"
 Nonce Value: "I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY="
 Algorithm: AKAv1-MD5
 Authentication URI: "sip:ims.mnc000.mcc000.3gppnetwork.org"
 Digest Authentication Response: "79171c573124021f38000357c002252"

The key information here is the Response. This is the value which the S-CSCF will compare with the data retrieved HSS. If the Response is matching the user is successfully registered.

11. 2nd Register SBC->CSCF

REGISTER sip:ims.mnc000.mcc000.3gppnetwork.org SIP/2.0
Expires: 3600
User-Agent: SLICK IMS 4.0.0
P-Access-Network-Info: 3GPP-E-UTRAN-FDD;utran-cell-id-3gpp=1234567890123456
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,INFO,REFER,NOTIFY,MESSAGE,PRACK
Supported: path
[truncated] Authorization: Digest integrity-protected="ip-assoc-pending",username="123456789012345@ims.mnc000.mcc000.3gppnetwork.org",realm="ims.mnc000.mcc000.3gppnetwork.org",nonce="I4/NoSUbPgmC/NR2+Z+7CODMb/sjtAAAB9znc+wceNY=",algorithm=
Contact: <sip:123456789012345@10.1.1.221:5060>;expires=3600;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>"
From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593
To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>
Call-ID: 39510918@10.1.1.221
CSeq: 2 REGISTER
Max-Forwards: 68
[truncated] Via: SIP/2.0/TCP sbc-atcf_01.volte.operator.com:5060;rport;branch=z9hG4bK836829-0-158-3-1-e0ff0003-382c2c3a265b3cd9,SIP/2.0/TCP sbc_01.volte.operator.com:5060;NwkIntf=2;Realm=mwmx;recvdSrvPort=5060;r
 Content-Length: 0
 Require: path
 P-Visited-Network-ID: sbc_01_epc.volte.operator.com
 P-Charging-Vector: icid-value=255.370.1073741823-1422879486.25996;orig-ioi=Ioi1;icid-generated-at=211.98.143.25
 Path: <sip:836829-0-159-3fffffff-1-6b8b480d@sbc-atcf_01.volte.operator.com:5060;038592-0-158-18-1-6b8b480d;mtcall;lr>,<sip:038592-0-115-1cc-2-400aa44c@sbc_01.volte.operator.com:5060;lr;mtcall>
 P-Charging-Function-Addresses: ecf="aaa://PCF.charging.operator.com";ccf="aaa://PCF.charging.operator.com"

The S-CSCF receives in the Path header the information about what P-CSCF and what ATCF (in case of eSRVCC) are anchoring the user. This information is valid for the whole duration of registration.

 

12. 200 OK CSCF->SBC

SIP/2.0 200 OK
 [truncated] Via: SIP/2.0/TCP sbc-atcf_01.volte.operator.com:5060;received=211.98.143.17;rport=50604;branch=z9hG4bK836829-0-158-3-1-e0ff0003-382c2c3a265b3cd9,SIP/2.0/TCP sbc_01.volte.operator.com:5060;NwkIntf=2;Realm=
 Path: <sip:836829-0-159-3fffffff-1-6b8b480d@sbc-atcf_01.volte.operator.com:5060;lr;mtcall;038592-0-158-18-1-6b8b480d>,<sip:038592-0-115-1cc-2-400aa44c@sbc_01.volte.operator.com:5060;mtcall;lr>
 Service-Route: <sip:836829-0-4a-57e-1-ffffffff-75@scscf-1.volte.operator.com:5070;lr>
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=836829-0-4b-a4-1-ffffffc7-_005056A220EB-2b43-9aa8700-2ace0-54cf6afe-811bc
 Call-ID: 39510918@10.1.1.221
 CSeq: 2 REGISTER
 Contact: sip:123456789012345@10.1.1.221:5060;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>";expires=1800
 P-Associated-URI: <sip:+46739613233@ims.mnc000.mcc000.3gppnetwork.org>
 P-Charging-Function-Addresses: ecf="aaa://efc-charging.operator.com"
 P-Charging-Vector: icid-value=255.370.1073741823-1422879486.25996;term-ioi=12345;orig-ioi=Ioi1
 Content-Length: 0

 

In the Service-Route header the S-CSCF informs the SBC about its own address. From now on we don’t need to go through the I-CSCF anymore.

In the P-Associated-URI header the S-CSCF send the user’s identity which is then later inserted by SBC into subsequent messages (e.g. SIP INVITE, SIP MESSAGE) as P-Asserted-Identity.

13. 200 OK SBC->UE

SIP/2.0 200 OK
 Via: SIP/2.0/UDP 10.1.1.221:5060;received=10.1.1.221;branch=z9hG4bK3219487738smg;transport=UDP;rport=5060
 From: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=197554593
 To: <sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org>;tag=836829-0-4b-a4-1-ffffffc7-_005056A220EB-2b43-9aa8700-2ace0-54cf6afe-811bc
 Call-ID: 39510918@10.1.1.221
 CSeq: 2 REGISTER
 Contact: sip:123456789012345@10.1.1.221:5060;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-2>";expires=1800
 P-Associated-URI: <sip:+46739613233@ims.mnc000.mcc000.3gppnetwork.org>
 Content-Length: 0
 Service-Route: <sip:sbc_01_epc.volte.operator.com;038592=0-115-1cc-2-400aa44c;lr>

14. SAA

 AVP: Session-Id(263) l=64 f=-M- val=scscf-1.volte.operator.com;1804289384;17134
 AVP: Vendor-Specific-Application-Id(260) l=32 f=-M-
 AVP: Vendor-Id(266) l=12 f=-M- val=10415
 AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
 AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
 AVP: Origin-Host(264) l=47 f=-M- val=avk6-scscf-1-vip-sip.volte.operator.com
 AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
 AVP: Destination-Host(293) l=58 f=-M- val=hss01-imscore.mnc000.mcc000.3gppnetwork.org
 AVP: Destination-Realm(283) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
 AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 AVP: Supported-Features(628) l=56 f=V-- vnd=TGPP
 AVP: Vendor-Id(266) l=12 f=-M- val=10415
 AVP: Feature-List-ID(629) l=16 f=V-- vnd=TGPP val=1
 AVP: Feature-List(630) l=16 f=V-- vnd=TGPP val=4
 AVP: Public-Identity(601) l=65 f=VM- vnd=TGPP val=sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 AVP: Server-Name(602) l=60 f=VM- vnd=TGPP val=sip:scscf-1.volte.operator.com:5070
 AVP: Server-Assignment-Type(614) l=16 f=VM- vnd=TGPP val=REGISTRATION (1)
 AVP: User-Data-Already-Available(624) l=16 f=VM- vnd=TGPP val=USER_DATA_NOT_AVAILABLE (0)
 AVP: SCSCF-Restoration-Info(639) l=520 f=V-- vnd=TGPP
 AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 AVP: Restoration-Info(649) l=420 f=V-- vnd=TGPP
 AVP: Path(640) l=220 f=V-- vnd=TGPP val=3c7369703a6d61766f64692d302d3135392d336666666666...
 AVP: Contact(641) l=186 f=V-- vnd=TGPP val=3c7369703a3234303037303630343034333832314031302e...
 AVP: SIP-Authentication-Scheme(608) l=28 f=VM- vnd=TGPP val=Digest-AKAv1-MD5
 AVP: Multiple-Registration-Indication(648) l=16 f=V-- vnd=TGPP val=MULTIPLE_REGISTRATION (1)

In the SAA we inform the HSS about the capabilities of the S-CSCF in the Feature-List header:

 Feature-List Flags: 0x00000004
 0000 0000 0000 0000 0000 0000 0000 0... = Spare bit(s): 0x00000000
 .... .1.. = IMS Restoration Indication: Supported
 .... ..0. = Alias Indication: Not supported
 .... ...0 = Shared IFC Sets: Not supported

We store the Restoration-Info which contains the Path and Contact header from the SIP REGISTER message:

 Paths
 Path: <sip:836829-0-159-3fffffff-1-6b8b480d@sbc-atcf_01.volte.operator.com:5060;038592-0-158-18-1-6b8b480d;mtcall;lr>
 Path: <sip:038592-0-115-1cc-2-400aa44c@sbc_01.volte.operator.com:5060;lr;mtcall>
 Contact: 3c7369703a3234303037303630343034333832314031302e...
Contact: <sip:123456789012345@10.1.1.221:5060>;expires=3600;q=1.00;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel";video;+sip.instance="<urn:gsma:imei:12345678-123456-1>"

Public-Identity – IMPU, note that there can be more IMPUs associated with the subscriber. This particular IMPU will be used for this registration (e.g. each IMPU can use a different service profile).

15. SAA

   AVP: Session-Id(263) l=64 f=-M- val=scscf-1.volte.operator.com;1804289384;17134
   AVP: Auth-Session-State(277) l=12 f=-M- val=NO_STATE_MAINTAINED (1)
   AVP: Vendor-Specific-Application-Id(260) l=32 f=-M-
   AVP: Vendor-Id(266) l=12 f=-M- val=10415
   AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP CX/DX (16777216)
   AVP: Origin-Host(264) l=58 f=-M- val=hss01-imscore.mnc000.mcc000.3gppnetwork.org
   AVP: Origin-Realm(296) l=41 f=-M- val=ims.mnc000.mcc000.3gppnetwork.org
   AVP: Supported-Features(628) l=56 f=V-- vnd=TGPP
   AVP: Feature-List(630) l=16 f=V-- vnd=TGPP val=5
   AVP: Vendor-Id(266) l=12 f=-M- val=10415
   AVP: User-Data(606) l=2632 f=VM- vnd=TGPP val=3c3f786d6c20766sda7273696f6edasd22312e302220656e636f...
   AVP: User-Name(1) l=57 f=-M- val=123456789012345@ims.mnc000.mcc000.3gppnetwork.org
   AVP: Charging-Information(618) l=48 f=VM- vnd=TGPP
   AVP: Result-Code(268) l=12 f=-M- val=DIAMETER_SUCCESS (2001)

In the SAA we receive the very important information about Service Profile in the User-Data header:

AVP Vendor Id: 3GPP (10415)
        User-Data: 3c3f786d6sdf657273696f6e3d22fsd2e302220656e636f...
        eXtensible Markup Language
<?xml
 version="1.0"
 encoding="UTF-8"
 ?>
 <IMSSubscription
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="CxDataType.xsd">
 <PrivateID>
 123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 </PrivateID>
 <ServiceProfile>
 <PublicIdentity>
 <BarringIndication>
 0
 </BarringIndication>
 <Identity>
 sip:+46739613233@ims.mnc000.mcc000.3gppnetwork.org
 </Identity>
 </PublicIdentity>
 <PublicIdentity>
 <BarringIndication>
 1
 </BarringIndication>
 <Identity>
 sip:123456789012345@ims.mnc000.mcc000.3gppnetwork.org
 </Identity>
 </PublicIdentity>
 <CoreNetworkServicesAuthorization>
 <SubscribedMediaProfileId>
 4
 </SubscribedMediaProfileId>
 </CoreNetworkServicesAuthorization>
 <InitialFilterCriteria>
 <Priority>
 0
 </Priority>
 <TriggerPoint>
 <ConditionTypeCNF>
 1
 </ConditionTypeCNF>
 <SPT>
 <Group>
 1
 </Group>
 <Method>
 REGISTER
 </Method>
 </SPT>
 </TriggerPoint>
 <ApplicationServer>
 <ServerName>
 sip:tas.volte.operator.com
 </ServerName>
 <DefaultHandling>
 0
 </DefaultHandling>
 <ServiceInfo>
 </ServiceInfo>
 </ApplicationServer>
 </InitialFilterCriteria>
 <InitialFilterCriteria>

  ...
 </IMSSubscription>

How to read IFCs is described in its own post.

We also receive the information related to charging in the Charging-Information header:

AVP: Primary-Event-Charging-Function-Name(619) l=36 f=VM- vnd=TGPP val=aaa://efc-charging.operator.com
                AVP Code: 619 Primary-Event-Charging-Function-Name
                AVP Flags: 0xc0
                    1... .... = Vendor-Specific: Set
                    .1.. .... = Mandatory: Set
                    ..0. .... = Protected: Not set
                    ...0 .... = Reserved: Not set
                    .... 0... = Reserved: Not set
                    .... .0.. = Reserved: Not set
                    .... ..0. = Reserved: Not set
                    .... ...0 = Reserved: Not set
                AVP Length: 36
                AVP Vendor Id: 3GPP (10415)
                Primary-Event-Charging-Function-Name: aaa://efc-charging.operator.com

 

I’m quite sure that we were too brief today. On the other hand this is not a spec and the post can be already a bit difficult to read. Let me know if there is any header which deserves more attention.

Advertisements

7 thoughts on “How to read tcpdump – Registration”

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

  2. Pingback: VoLTE flows – close encounters | Real Time Communication

  3. Pingback: VoLTE in IMS | Real Time Communication

  5. Pingback: Rainy-day Scenarios – S-CSCF Restoration | Real Time Communication

  6. Pingback: SIP Illustrated 2: SIP Message | Real Time Communication

  7. Pingback: SIP Illustrated 3: Routing and IMS Registration | Real Time Communication

Leave a Reply

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

Gravatar
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 )

Cancel

Connecting to %s