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
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.
Very Nice
LikeLike
Can you write the same in case VoLTE to VoLTE call flow
LikeLike
Hi, thank you for reading!
You can try SIP Illustrated 5: SIP Session Routing, where we discuss the most important SIP routing headers. The trace is on my todo list (along with 1000 other things :))
Cheers, Karel.
LikeLike
What is IMPI and IMPU? IMPU means mobile number and impI means mobile number + mnc+mcc + domain name. So how one IMPI can have multiple IMPU.
LikeLike
IMPI – privation identity known only to the device and network (stored in SIM and HSS)
IMPU – public identity – e.g. tel or sip uri
LikeLike
and yes, one IMPI can have multiple IMPUs associated with it (the other way around it works too)
LikeLike
How one IMPI can have a multiple IMPU in Volte.
Can you please take example of IMPI and IMPU. Thanks in advance.
LikeLike
e.g.
IMPI: @ims.mnc000.mcc000.3gppnetwork.org
IMPU: sip:@ims.mnc000.mcc000.3gppnetwork.org
tel:
LikeLike
What is the diff between first UAR/UAA and the second UAR/UAA
LikeLike
In case of the first request we don’t know what S-CSCF to use (unless the subscriber is already registered using some other device). With the second message we have to make sure, that the same S-CSCF is used (as it handles the authentication).
LikeLike