Archive for September, 2010

28
Sep

nu doar mortii stiu cum e sa mori

   Posted by: cristina_crow    in media-culture

Asta ziceau cei de la Luna Amara acum ceva vreme in Asfalt. Mi s-a parut multa vreme foarte aiurea, apoi am vazut cum poti muri, desi te misti si pare ca esti viu. Sunt oameni care te omoara zi de zi, incetul cu incetul, ucigand incet-incet cu egoismul si indiferenta lor tot ce e frumos in personalitatea ta. YouTube Preview Image

Esti doar durere topindu-mi linistea
Urasc tot ce-ai facut din viata mea
Asfalt
Inchide ochii si arunca-te in gol
E singura ta sansa s-arati ca ai control
Taci, nu vorbi. Nu vreau sa mai aud
Nici urletul din mine stins pe asfaltul ud
Bridge:
Nu doar mortii stiu cum e sa mori
N-ai sa zbori
Refren:
Ia-mi tot ce mi-ai dat
Ia-mi tot ce-am visat (x2)
Ca si cand m-ai fi ingropat
Bridge:
Mi-e dor dor dor
Sa fiu iar intreg

Tags: ,

No Comments
24
Sep

Mozart and Madness

   Posted by: cristina_crow    in media-culture

Savatage - si cine zicea ca italienii nu stiu rock?

YouTube Preview Image

Tags: ,

2 Comments
19
Sep

Israel – day 1

   Posted by: cristina_crow    in travel

Nice people, not so frightening as I’ve been told at the airport verifications :P

Tags:

2 Comments
14
Sep

IMS dumps

   Posted by: cristina_crow    in technical

Continuing from 4G – GTPv2 dumps:

First of all, bare in mind that this is NOT the actual end-to-end testing procedure, so I can only show so far a basic IMS call coming from plain IP, therefore with no indication to the Access Network:

Register

The P-CSCF listens on port 4060 UDP (as we will see in the next episode, the configuration of the IMS Core), and the phone is on 5060:

Session Initiation Protocol
Request-Line: REGISTER sip:open-ims.test SIP/2.0
Method: REGISTER
Request-URI: sip:open-ims.test
Request-URI Host Part: open-ims.test
[Resent Packet: False]
Message Header
Call-ID: [email protected]
CSeq: 19 REGISTER
Sequence Number: 19
Method: REGISTER\r\nFrom
From: <sip:[email protected]>;tag=1020
SIP from address: sip:[email protected]
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1020
To: <sip:[email protected]>
SIP to address: sip:[email protected]
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
Branch: z9hG4bK163b18a8645e3542f3430be441fc7021
Max-Forwards: 20
Expires: 3600
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT
Content-Length: 0
401 Unauthorized

Session Initiation Protocol
Status-Line: SIP/2.0 401 Unauthorized – Challenging the UE
Status-Code: 401
Message Header
Call-ID: [email protected]
CSeq: 19 REGISTER
Sequence Number: 19
Method: REGISTER\r\nFrom
From: <sip:[email protected]>;tag=1020
SIP from address: sip:[email protected]
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1020
To: <sip:[email protected]>;tag=d7837ce6bbd631122d10546eb75bb4cf-cb8c
SIP to address: sip:[email protected]
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
SIP tag: d7837ce6bbd631122d10546eb75bb4cf-cb8c
Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK163b18a8645e3542f3430be441fc7021
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
RPort: 5060
Branch: z9hG4bK163b18a8645e3542f3430be441fc7021
Path: <sip:[email protected]:4060;lr>
Service-Route: <sip:[email protected]:6060;lr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO
Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))
Content-Length: 0
Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19702 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3″
WWW-Authenticate: Digest realm=”open-ims.test”, nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”, algorithm=AKAv1-MD5, qop=”auth,auth-int”
Authentication Scheme: Digest
realm=”open-ims.test”
nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”
algorithm=AKAv1-MD5
qop=”auth

Register
- the one with credentials :P
Session Initiation Protocol
Request-Line: REGISTER sip:open-ims.test SIP/2.0
Method: REGISTER
Request-URI: sip:open-ims.test
Request-URI Host Part: open-ims.test
[Resent Packet: False]
Message Header
Call-ID: [email protected]
CSeq: 20 REGISTER
Sequence Number: 20
Method: REGISTER\r\nFrom
From: <sip:[email protected]>;tag=1021
SIP from address: sip:[email protected]
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1021
To: <sip:[email protected]>
SIP to address: sip:[email protected]
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
Via: SIP/2.0/UDP 40.0.0.1:5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Max-Forwards: 20
[truncated] Authorization: Digest username=”[email protected]”,uri=”sip:open-ims.test”,realm=”open-ims.test”,nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”",response=”edfe66ab211e300fea4da5bd308605c3″,algoritm=AKAv1-MD5,qop=auth-int
Authentication Scheme: Digest
username=”[email protected]”
uri=”sip:open-ims.test”
realm=”open-ims.test”
nonce=”BgaX3TR54oTr38cLlKykVfaXmB8A2wAAxGSzQfrUAWU=”"
response=”edfe66ab211e300fea4da5bd308605c3″
algoritm=AKAv1-MD5
qop=auth-int
nc=00000001
cnonce=”48525798509797101″
Expires: 3600
Contact: <sip:[email protected]:5060>
Contact-URI: sip:[email protected]:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
User-Agent: Fokus MONSTER Version: 0.9.9-SNAPSHOT
Content-Length: 0
200 OK

Session Initiation Protocol
Status-Line: SIP/2.0 200 OK – SAR succesful and registrar saved
Status-Code: 200
[Resent Packet: False]
[Request Frame: 81]
[Response Time (ms): 106]
Message Header
Call-ID: [email protected]
CSeq: 20 REGISTER
Sequence Number: 20
Method: REGISTER\r\nFrom
From: <sip:[email protected]>;tag=1021
SIP from address: sip:[email protected]
SIP from address User Part: cristina
SIP from address Host Part: open-ims.test
SIP tag: 1021
To: <sip:[email protected]>;tag=d7837ce6bbd631122d10546eb75bb4cf-3d08
SIP to address: sip:[email protected]
SIP to address User Part: cristina
SIP to address Host Part: open-ims.test
SIP tag: d7837ce6bbd631122d10546eb75bb4cf-3d08
Via: SIP/2.0/UDP 40.0.0.1:5060;rport=5060;branch=z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
Transport: UDP
Sent-by Address: 40.0.0.1
Sent-by port: 5060
RPort: 5060
Branch: z9hG4bK84169db88bb0b4032667a8e0e81d2cbc
P-Associated-URI: <sip:[email protected]>
Contact: <sip:[email protected]:5060>;expires=3600
Contact-URI: sip:[email protected]:5060
Contactt-URI User Part: cristina
Contact-URI Host Part: 40.0.0.1
Contact-URI Host Port: 5060
Contact parameter: expires=3600
Path: <sip:[email protected]:4060;lr>
Service-Route: <sip:[email protected]:6060;lr>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, PUBLISH, MESSAGE, INFO
Server: Sip EXpress router (2.1.0-dev1 OpenIMSCore (i386/linux))
Content-Length: 0
Warning: 392 127.0.0.1:6060 “Noisy feedback tells:  pid=19703 req_src_ip=127.0.0.1 req_src_port=5060 in_uri=sip:scscf.open-ims.test:6060 out_uri=sip:scscf.open-ims.test:6060 via_cnt==3″

Tags: , , , , , , , , , , , , , , , , , , ,

2 Comments
14
Sep

4G – GTPv2 dumps

   Posted by: cristina_crow    in technical

Knowing it is not very nice to talk a lot about a certain thing, but to offer no tangible results, I’ve tried to create some minimal dump information for the things discussed lately on my posts.

They should be, though not end-to-end results, at least some hope-by-hope information.

So, let’s see first how an Initial Attach to the 4G network would look like, then how the UE asks for a dedicated bearer to put traffic on (specifically to put VoIP traffic on), and then take a closer look at a IMS call flow.

For the 4G dumps I must give credit to the wonderful company I work in, which helps me develop on the 4G core network side. While the IMS flows are generated using OpenIMSCore and Monster, the 2 solutions from the cool guys from Fraunhofer.

While my company’s solution is proprietary and closed-source, I would rather recommend you to buy it, but I am not able to give so much details on its architecture :D , the Fraunhofer solution is free and open-source and is nicely installed on a debian :D .

So, let’s first take a look at the attach procedure, which is captured on the S11 4G interface, between the MME and the SGW. The message here are Create Session Request and Create Session Response.

GTPv2 runs over UDP, so I’ll just show the message from the GTPv2 control-plane message above in the TCP/IP stack:

First the Create Session Request, coming from the MME to the SGW, by which the UE asks for an IP address and connectivity the PDN – Packet Data Network:

GPRS Tunneling Protocol V2
Create Session Request
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Create Session Request (32)
Message Length: 201
Tunnel Endpoint Identifier: 0
Sequence Number: 7660
Spare: 45056
International Mobile Subscriber Identity (IMSI) :
IE Type: International Mobile Subscriber Identity (IMSI) (1)
IE Length: 8
000. …. = CR flag: 0
…. 0000 = Instance: 0
IMSI(International Mobile Subscriber Identity number): 220614000000001
MSISDN :
IE Type: MSISDN (76)
IE Length: 6
000. …. = CR flag: 0
…. 0000 = Instance: 0
Country Code: 40 Romania length 2
Address digits: 700000001
Mobile Equipment Identity (MEI) :
IE Type: Mobile Equipment Identity (MEI) (75)
IE Length: 8
000. …. = CR flag: 0
…. 0000 = Instance: 0
MEI(Mobile Equipment Identity): 999900000000100
User Location Info (ULI) :
IE Type: User Location Info (ULI) (86)
IE Length: 13
000. …. = CR flag: 0
…. 0000 = Instance: 0
…1 …. = ECGI Present Flag): True
…. 1… = TAI Present Flag): True
…. .0.. = RAI Present Flag): False
…. ..0. = SAI Present Flag): False
…. …0 = CGI Present Flag): False
Mobile Country Code (MCC): Romania (226)
Mobile Network Code (MNC): Orange Romania (10)
Tracking Area Code: 4113
Mobile Country Code (MCC): Romania (226)
Mobile Network Code (MNC): Orange Romania (10)
ECI (E-UTRAN Cell Identifier): 0
Serving Network :
IE Type: Serving Network (83)
IE Length: 3
000. …. = CR flag: 0
…. 0000 = Instance: 0
Mobile Country Code (MCC): Romania (226)
Mobile Network Code (MNC): Orange Romania (10)
RAT Type :
IE Type: RAT Type (82)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
RAT Type: EUTRAN (6)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 1010 = Interface Type: S11 MME GTP-C interface (10)
TEID/GRE Key: 3300033
F-TEID IPv4: 30.0.1.1 (30.0.1.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0001 = Instance: 1
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0111 = Interface Type: S5/S8 PGW GTP-C interface (7)
TEID/GRE Key: 0
F-TEID IPv4: 20.0.0.1 (20.0.0.1)
PDN Type :
IE Type: PDN Type (99)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. .001 = PDN Type: IPv4 (1)
Selection Mode :
IE Type: Selection Mode (128)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. ..00 = Selection Mode: MS or network provided APN, subscribed verified (0)
PDN Address Allocation (PAA) :
IE Type: PDN Address Allocation (PAA) (79)
IE Length: 5
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. .001 = PDN Type: IPv4 (1)
PDN IPv4: 0.0.0.0 (0.0.0.0)
Indication :
IE Type: Indication (77)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
0… …. = DAF (Dual Address Bearer Flag): False
.0.. …. = DTF (Direct Tunnel Flag): False
..0. …. = HI (Handover Indication): False
…0 …. = DFI (Direct Forwarding Indication): False
…. 0… = OI (Operation Indication): False
…. .0.. = ISRSI (Idle mode Signalling Reduction Supported Indication): False
…. ..0. = ISRAI (Idle mode Signalling Reduction Activation Indication): False
…. …0 = SGWCI (SGW Change Indication): False
…. 0… = PT (Protocol Type): False
…. .0.. = TDI (Teardown Indication): False
…. ..0. = SI (Scope Indication): False
…. …0 = MSV (MS Validated): False
Access Point Name (APN) :
IE Type: Access Point Name (APN) (71)
IE Length: 18
000. …. = CR flag: 0
…. 0000 = Instance: 0
APN (Access Point Name): visited.com
APN Restriction :
IE Type: APN Restriction (127)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
APN Restriction: 0
Aggregate Maximum Bit Rate (AMBR) :
IE Type: Aggregate Maximum Bit Rate (AMBR) (72)
IE Length: 8
000. …. = CR flag: 0
…. 0000 = Instance: 0
AMBR Uplink (Aggregate Maximum Bit Rate for Uplink): 1
AMBR Downlink(Aggregate Maximum Bit Rate for Downlink): 1
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 31
000. …. = CR flag: 0
…. 0000 = Instance: 0
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0101 = EPS Bearer ID (EBI): 5
Bearer Level Quality of Service (Bearer QoS) :
IE Type: Bearer Level Quality of Service (Bearer QoS) (80)
IE Length: 22
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. …1 = PVI (Pre-emption Vulnerability): True
..00 00.. = PL (Priority Level): 0
.0.. …. = PCI (Pre-emption Capability): False
Label (QCI): 4
Maximum Bit Rate For Uplink: 65536000
Maximum Bit Rate For Downlink: 65536000
Guaranteed Bit Rate For Uplink: 0
Guaranteed Bit Rate For Downlink: 0
Recovery (Restart Counter) :
IE Type: Recovery (Restart Counter) (3)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
Restart Counter: 0
And then the Create Session Response, coming from the PGW (which obtained the UE’s IP address), via the SGW, towards the MME and UE. This is captured on S11, between the SGW and MME:
GPRS Tunneling Protocol V2
Create Session Response
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Create Session Response (33)
Message Length: 126
Tunnel Endpoint Identifier: 3300033
Sequence Number: 7660
Spare: 45056
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
PDN Address Allocation (PAA) :
IE Type: PDN Address Allocation (PAA) (79)
IE Length: 5
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. .001 = PDN Type: IPv4 (1)
PDN IPv4: 40.0.0.1 (40.0.0.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 1011 = Interface Type: S11/S4 SGW GTP-C interface (11)
TEID/GRE Key: 1
F-TEID IPv4: 30.0.2.1 (30.0.2.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0001 = Instance: 1
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0111 = Interface Type: S5/S8 PGW GTP-C interface (7)
TEID/GRE Key: 1
F-TEID IPv4: 20.0.0.1 (20.0.0.1)
APN Restriction :
IE Type: APN Restriction (127)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
APN Restriction: 0
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 63
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0101 = EPS Bearer ID (EBI): 5
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)
TEID/GRE Key: 33
F-TEID IPv4: 30.0.2.1 (30.0.2.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0001 = Instance: 1
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0101 = Interface Type: S5/S8 PGW GTP-U interface (5)
TEID/GRE Key: 33
F-TEID IPv4: 20.0.0.1 (20.0.0.1)
Bearer Level Quality of Service (Bearer QoS) :
IE Type: Bearer Level Quality of Service (Bearer QoS) (80)
IE Length: 22
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. …0 = PVI (Pre-emption Vulnerability): False
..00 00.. = PL (Priority Level): 0
.0.. …. = PCI (Pre-emption Capability): False
Label (QCI): 9
Maximum Bit Rate For Uplink: 8640000
Maximum Bit Rate For Downlink: 8640000
Guaranteed Bit Rate For Uplink: 0
Guaranteed Bit Rate For Downlink: 0
Recovery (Restart Counter) :
IE Type: Recovery (Restart Counter) (3)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
Restart Counter: 0
Then the creation of the default bearer:
Modify Bearer Request
 

GPRS Tunneling Protocol V2
Modify Bearer Request
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Modify Bearer Request (34)
Message Length: 30
Tunnel Endpoint Identifier: 1
Sequence Number: 7660
Spare: 45568
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 18
000. …. = CR flag: 0
…. 0000 = Instance: 0
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0101 = EPS Bearer ID (EBI): 5
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0000 = Interface Type: S1-U eNodeB GTP-U interface (0)
TEID/GRE Key: 33
F-TEID IPv4: 30.0.0.1 (30.0.0.1)

Modify Bearer Response
 

GPRS Tunneling Protocol V2
Modify Bearer Response
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Modify Bearer Response (35)
Message Length: 42
Tunnel Endpoint Identifier: 3300033
Sequence Number: 7660
Spare: 45568
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 24
000. …. = CR flag: 0
…. 0000 = Instance: 0
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0101 = EPS Bearer ID (EBI): 5
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)
TEID/GRE Key: 33
F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Then the creation (by the network) of a dedicated bearer:
Create Bearer Request
 

GPRS Tunneling Protocol V2
Create Bearer Request
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Create Bearer Request (95)
Message Length: 86
Tunnel Endpoint Identifier: 3300033
Sequence Number: 0
Spare: 256
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0101 = EPS Bearer ID (EBI): 5
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 69
000. …. = CR flag: 0
…. 0000 = Instance: 0
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0000 = EPS Bearer ID (EBI): 0
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)
TEID/GRE Key: 34
F-TEID IPv4: 30.0.2.1 (30.0.2.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0001 = Instance: 1
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0101 = Interface Type: S5/S8 PGW GTP-U interface (5)
TEID/GRE Key: 34
F-TEID IPv4: 20.0.0.1 (20.0.0.1)
EPS Bearer Level Traffic Flow Template (Bearer TFT) :
IE Type: EPS Bearer Level Traffic Flow Template (Bearer TFT) (84)
IE Length: 8
000. …. = CR flag: 0
…. 0000 = Instance: 0
001. …. = Operation Code: Create New TFT (1)
…. 0001 = Number of Packet Filters: 1
…0 …. = Ebit: False
Packet Filter 1
…. 0010 = Packet Filter Identifier: 2
..11 …. = Direction: bidirectional (3)
Evaluation Precedence: 2
Length of Packet Filter: 3
Component Type: Single remote port type (5060)
Single remote port type: 5060
Bearer Level Quality of Service (Bearer QoS) :
IE Type: Bearer Level Quality of Service (Bearer QoS) (80)
IE Length: 22
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. …0 = PVI (Pre-emption Vulnerability): False
..01 11.. = PL (Priority Level): 7
.0.. …. = PCI (Pre-emption Capability): False
Label (QCI): 3
Maximum Bit Rate For Uplink: 65535000
Maximum Bit Rate For Downlink: 65535000
Guaranteed Bit Rate For Uplink: 65535000
Guaranteed Bit Rate For Downlink: 65535000

Create Bearer Response
 

GPRS Tunneling Protocol V2
Create Bearer Response
Flags: 72
010. …. = Version: 2
…. 1… = T: 1
Message Type: Create Bearer Response (96)
Message Length: 55
Tunnel Endpoint Identifier: 1
Sequence Number: 0
Spare: 256
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
Bearer Context : [Grouped IE]
IE Type: Bearer Context (93)
IE Length: 37
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause :
IE Type: Cause (2)
IE Length: 2
000. …. = CR flag: 0
…. 0000 = Instance: 0
Cause: Request accepted (16)
…. …0 = Cause Source (CS: True-Error originated by remote node, False-Error originated by Node sending the Message): False
EPS Bearer ID (EBI) :
IE Type: EPS Bearer ID (EBI) (73)
IE Length: 1
000. …. = CR flag: 0
…. 0000 = Instance: 0
…. 0110 = EPS Bearer ID (EBI): 6
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0000 = Instance: 0
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0000 = Interface Type: S1-U eNodeB GTP-U interface (0)
TEID/GRE Key: 34
F-TEID IPv4: 30.0.0.1 (30.0.0.1)
Fully Qualified Tunnel Endpoint Identifier (F-TEID) :
IE Type: Fully Qualified Tunnel Endpoint Identifier (F-TEID) (87)
IE Length: 9
000. …. = CR flag: 0
…. 0001 = Instance: 1
1… …. = V4 (True-IPV4 address field Exists,False-Doesn’t Exist in F-TEID): True
.0.. …. = V6 (True-IPV6 address field Exists,False-Doesn’t Exist in F-TEID): False
…0 0001 = Interface Type: S1-U SGW GTP-U interface (1)
TEID/GRE Key: 34
F-TEID IPv4: 30.0.2.1 (30.0.2.1)

Tags: , , , , , , , , , , , , , , , , , , ,

2 Comments
14
Sep

4G to IMS call flow – Register to IMS – part 7

   Posted by: cristina_crow    in technical

28. Register

29. Register

This is the REGISTER message that the UA composes AFTER receiving the 401 Unauthorized. The UA retrieves the authentication information from the UE, which, in the case of 3GPP phones, is stored in the UICC – Universal Integrated Circuit Card. The new Register message looks like this:

REGISTER sip:home.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 70
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
From: <sip:[email protected]>;tag=s8732n
To: <sip:[email protected]>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”[email protected]”,realm=”home.net”,
nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″,algorithm=AKAv1-MD5, uri=”sip:home.net”, response=”6629fae49393a05397450978507c4ef1″
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=909767; spi-s=421909;
port-c:4444; port-s=5058
Require: sec-agree
Proxy-Require: sec-agree
Cseq: 2 REGISTER
Supported: path
Content-Length: 0
The only difference between them is the Via header, due to the SIP message passing through the
servers.
Now, when this Register message reaches the P-CSCF, this device will do a new DNS query for the I-CSCF IP address. This is usual, as there are usually multiple I-CSCF servers in a network and there is no rule that once an I-CSCF responds to the first UA query this same I-CSCF must also respond to the subsequent queries. This rule dose NOT apply though for the S-CSCF server -which, as we’ve seen in the previous posts, is allocated per UA. So, the P-CSCF gets a (new) IP address of an I-CSCF and forwards there this message.

30. Diameter UAR

At this point, the I-CSCF gets the Register message above. As the I-CSCF has no state of the UA status on the home network, and it also does not know if the HSS already assigned an S-CSCF to the UA or not, the I-CSCF has to contact the HSS again, via the Cx interface, get the address of the S-CSCF allocated for this UA and forward this Register to the right S-CSCF.

31. Diameter UAA

Diameter UAR and Diameter UAA have the same format as before:

4G to IMS call flow – Register to IMS – part 6

32. Register

This is the step where the Register message is transmitted from the I-CSCF to the S-CSCF. The S-CSCF is the one allocated by the HSS in the previous Register flow (answered with 401 Unauthorized) and now the HSS sends the URI of this allocated S-CSCF to the I-CSCF in the Diameter UAA message from Step 31 above.

33. Diameter SAR

When the S-CSCF receives the Register message with credentials from the UA, it authenticates this UA versus the AV – Authentication Vector is received from the HSS in the previous Step 24. Diameter MAA message. After this, the UA is considered authenticated, so now the S-CSCF should have also its profile (stored in the HSS), in order to know which services are available for it. In order to get this profile and also so let the HSS know that the UA is now registered, the S-CSCF sends the Cx-Put or Diameter SAR – Server-Assignment-Request message to the HSS, via the Cx interface.

According to RFC 4740 – section 8.3, the Diameter SAR message should look like this:

       <SAR> ::= < Diameter Header: 284, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-Server-Assignment-Type }
                 { SIP-User-Data-Already-Available }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
               * [ SIP-Supported-User-Data-Type ]
               * [ SIP-AOR ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

34. Diameter SAA

This is the reply sent by the HSS to the S-CSCF, Cx-Put response or Diameter SAA – Server-Assignment-Answer, which contains the user profile. This user profile contains all the Public User Identities of this UA, identities that are associated to the Private User Identity, and also all the public identities that are to be automatically (or implicitly) registered in the S-CSCF.

The user profile also has a set of initial filter criteria – a set of rules which determine when a SIP request is forwarded to an Application Server for a certain service request. The Contact URI of the UA that the S-CSCF store in the HSS it the actual value of the Contact header from the Register message. The S-CSCF also stores the values from the Path header in order to know where to route the SIP initial requests for that UA to.

As per RFC 4740 – section 8.4, this message looks like this:

       <SAA> ::= < Diameter Header: 284, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
               * [ SIP-User-Data ]
                 [ SIP-Accounting-Information ]
               * [ SIP-Supported-User-Data-Type ]
                 [ User-Name ]
                 [ Auth-Grace-Period ]
                 [ Authorization-Lifetime ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

35. 200 OK

Then the S-CSCF responds to the Register message by sending a 200 OK message. This message contains also a P-Associated-URI list – list of the Associated URIs where this UA can be located, according to the S-CSCF – this list is not necessarily the same as the list of implicitly registered public user identities.

The S-CSCF also inserts a Service-Route header, which contains its own URI with a string in the user part, in order to differentiate mobile originated requests from mobile terminating requests.

36. 200 OK

37. 200 OK

These messages are basically the same, except the Via header. When it reaches the UE, the 200 OK message looks like this:

SIP/2.0 200 OK

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab

Path: <sip:[email protected];lr>

Service-Route: <sip:[email protected];lr>

From: <sip:[email protected]>;tag=s8732n

To: <sip:[email protected]>;tag=409sp3

Call-ID: 23fi57lju

Contact: <sip:[5555::aaa:bbb:ccc:ddd]:5059;comp=sigcomp>;expires=600000

Cseq: 2 REGISTER

Date: Wed, 21 January 2004 18:19:20 GMT

P-Associated-URI: <sip:[email protected]>,<sip:[email protected]>,

<sip:[email protected];user=phone>

Content-Length: 0

Tags: , , , , , , , , , , , , , , , , , , ,

No Comments
11
Sep

4G to IMS call flow – Register to IMS – part 6

   Posted by: cristina_crow    in technical

Hey there. ‘ve got back from holiday, live and kicking !!! :D

19. Register – message created by the UE – described in Step 17 – http://www.imacandi.net/windancer/2010/08/29/4g-to-ims-call-flow-–-register-to-ims-–-part-4.html

The Register message is then forwarded by the local / visited network (in this case) P-CSCF to the remote/home-network’s I-CSCF.

Here is the (big) picture again, in case somebody forgot it – and we are at Step 19. Register:

And here is how this message should look like after crossing from the visited network to the home network domain:

REGISTER sip:registrar1.home.net SIP/2.0
Via:SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 69
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
Path: <sip:[email protected];lr>
Require: Path
P-Visited-Network-ID: “Cristina Visited  Network”
P-Charging-Vector: icid-value=”1234bc9876e”
From: <sip:[email protected]>;tag=s8732n
To: <sip:[email protected]>
Contact: <sip:[5555::aaa:bbb:ccc:ddd];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”[email protected]”,realm=”registrar1.home.net”, nonce=””,uri=”sip:registrar1.home.net”, response=””,integrity-protected=”no”
Cseq: 1 REGISTER
Supported: path
Content-Length: 0
As you may have already noticed, the bolded parts are new or changes from the previous REGISTER message in Step 17.
1. The Method is the same: Register
2. The Via header changed: the visited network P-CSCF added its address in the path, before the address of the UE. Basically, when each sip-aware device in the way processes this message, it will add its own address before the other ones, not deleting anyone, so there will be a looong lines of Vias. But, when the reply comes back to this UE, each device will be in the path (in reverse order, of course) and it will remove its address from the path, so that the Via lines decrease and remain only with the UE’s address in the end.
So, now our Via header has first the URI of the P-CSCF in the visited network, then the URI of the UE.
3. Max-Forwards value, of course, decreases, from 70 forwards we only have 69 now, as our message has already been forwarded once so far.
4. Path is new. The visited P-CSCF puts here its URI in order to make sure every message headed to this UE will be forwarded via this device, the visited P.
Now, about that lr thinggie. LR stands for loose routing. Basically loose routing means (as per RFC 3261) that the proxies in a SIP message path don’t have to rewrite the Request-URI of the next hop in order to be able to route the SIP message till the destination. They simply leave this URI with the address of the destination and only look at the Router header for routing purpose. And there is also a thinggie called strict routing – which does the opposite, changing and changing the Request-URI at each step. The cool guys from IPTEL describe these concepts briefly and really nice on their site: http://www.iptel.org/sip/intro/scenarios/rr/strict_vs_loose .
5. At this point, our P-CSCF has put its URI in the Path, in order for every SIP message destined to this UE to pass through it, because otherwise that message will never reach this UE. What it needs to do now is to make sure the other SIP guys also understand this Path requirement and make sure they comply. So, it uses the Require header to indicate to the other fellow SIP proxies that it means business with this Path thing and it really must be in the path of the SIP messages. Technically, this assures that, if any proxy on the way does not support Path, it will have to send a response back stating it cannot comply to this requirement. The response code is 420 and it will also include a Unsupported header which will have the value “Path”.
6. P-Visited-Network-ID: “Cristina Visited  Network”
As I was also saying previously, the P-Visited-Network-ID is included by the visited network P-CSCF in order to tell the home network about itself. This information is important for the home network, because based on this value here, the HSS will verify the existence of a roaming agreement between the home network of the UE and the visited network where it is located in the moment of the IMS Registration.
7. P-Charging-Vector: icid-value=”1234bc9876e”
This is populated by the P-CSCF with a globally unique value. The P-Charging-Vector is described in RFC 3455 – section 4.6. The same RFC describes also the P-Visited-Network-ID and other 3GPP extensions to the SIP protocol, in order to accommodate it to the 3GPP – IMS requirements. The actual name of the RFC 3455 is Private Header (P-Header) Extensions to the Session Initiated Protocol (SIP) for 3rd-Generation Partnership Project (3GPP).
** Now we are in the Home Network. We have our home I-CSCF (Interrogating) which has just received the Register message from the visited P-CSCF. It looks at it message, but has no idea whether the HSS has already registered or not this UE and, as a consequence, whether or not the HSS has already assigned a S-CSCF (Serving) to this UE. So, first of all, it creates a Diameter session to the HSS to clarify things up.
Ah, BTW, this Diameter thinggie is a real pain in the rear :) . It has a bunch of ramifications from the base protocol and I will only list some of them. To be honest, I haven’t yet got the chance to closely study Diameter, but I hope to come back soon with more details in this. I believe here the WIKIPEDIA is a good start up point to have the listing:

20. Diameter UAR
As I was saying there A LOT of Diameter standards. But the precise one used here in SIP-IMS authorization belongs to RFC 4740 – Diameter Session Initiation Protocol (SIP) Application.
Message 20 is called Diameter Cx-Query or Diameter UAR – User-Authorization-Request and it is sent from the I-CSCF to the HSS, via the Cx interface. The I-CSCF makes this request in order to obtain information about the registration status of this Subscriber. As the I-CSCF proxies to not store any UA (User Agent) status on their own, they need to contact the HSS each time to see whether any S(Serving)-CSCF has already been allocated to this User Agent. As in our case this is a first time registration, the UA doesn’t have any S allocated previously, but the I does not know that at this point in time. So, the I sends the HSS in this UAR message the private user identity of the UA ([email protected]), public user identity ([email protected]) and the visited domain identifier (Cristina Visited Network).
As per RFC 4740 – section 8.1, this UAR command would look something like this:
       <UAR> ::= < Diameter Header: 283, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Visited-Network-Id ]
                 [ SIP-User-Authorization-Type ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]
21. Diameter UAA
The HSS analyzes the UAR command, matches the information about the UA and the visited network, and it decides whether this is its UE or not, whether it can authorize this access to the network or not, which S-CSCF capabilities to allocate to it and, also very important, if this operator has a roaming agreement with the specified visited network and if so, in which terms. If this were not a first register message, so this UE would already have allocated an S-CSCF, then the HSS would have included in this UAA message also the SIP URI of the S-CSCF in question, so that the I-CSCF would contact this S-CSCF directly.
Afterwards, it sends a Diameter Cx-Query response or Diameter UAA – Diameter User-Authorization-Answer command back to the I-CSCF. This message should contain, in a favorable case, the capabilities of the S-CSCF server that this I would have to look for in order to allocate to that UE.
As per RFC 4740 – section 8.2, this command message should look like this:
       <UAA> ::= < Diameter Header: 283, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Result-Code }
                 { Origin-Host }
                 { Origin-Realm }
                 [ SIP-Server-URI ]

                 [ SIP-Server-Capabilities ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]
22. Register
After looking at the S-CSCF capabilities it received from the HSS, the I-CSCF looks through its S-CSCFs list and selects one that matches the capabilities indicated by the HSS. Then it forwards the Register message to this S-CSCF. These capabilities are some mandatory and some optional. The I-CSCF must select an S that matches the mandatory capabilities and may match some, all or none of the optional ones. The exact implementation of these capabilities is at the operator’s discretion, this entire communication being on his internal network.
The REGISTER message between the I-CSCF and the S-CSCF looks like this:
REGISTER sip:home.net SIP/2.0
Via: SIP/2.0/UDP icscf1.home.net;branch=z9hG4bKea1dof,
SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
Max-Forwards: 68
P-Access-Network-Info: 3GPP-EUTRAN-FDD;eutran-cell-id-3gpp=C359A3913B20E
From: <sip:[email protected]>;tag=s8732n
To: <sip:[email protected]>
Contact: <sip:[1080::8:800:200C:417A];comp=sigcomp>;expires=600000
Call-ID: 23fi57lju
Authorization: Digest username=”[email protected]”,realm=”home.net”, nonce=”", uri=”sip:home.net”, response=”", integrity-protected=”no”
Require: path
Supported: path
Path: <sip:[email protected];lr>
P-Visited-Network-ID: “Cristina Visited Network”
P-Charging-Vector: icid-value=”1234bc9876e”
Cseq: 1 REGISTER
Content-Length: 0
The only thing new here is the fact that the I-CSCF adds its URI on top of the Via header content.
23. Diameter MAR
The next message in the flow is the one sent by the S-CSCF chosen by the I-CSCF (the one that received the REGISTER message above) to the HSS.
There are 2 reasons the S-CSCF communicates with the HSS:
a. to retrieve the AV – Authentication Vector with challenges for this UE, in order to be able to authenticated it
b. to save its Request-URI into the HSS, so that for any further requests that may be received by the network from this subscriber, the HSS knows it has already assigned a S-CSCF for this user
The S-CSCF sends to the HSS a message called Diameter MAR – Multimedia-Auth-Request. According to RFC 4740 – section 8.7, this message should look like this:

       <MAR> ::= < Diameter Header: 286, REQ, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 { Destination-Realm }
                 { SIP-AOR }
                 { SIP-Method }
                 [ Destination-Host ]
                 [ User-Name ]
                 [ SIP-Server-URI ]
                 [ SIP-Number-Auth-Items ]
                 [ SIP-Auth-Data-Item ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

24. Diameter MAA

Diameter MAA – Multimedia-Auth-Answer, as per RFC  4740 – section 8.8, is the message sent from the HSS to the S-CSCF containing the AV – authentication vectors – one or more. Based on this vectors, the S-CSCF is able to authenticate the user by sending a SIP 401 Unauthorized message to this UA.

The MAA message should look like this:

       <MAA> ::= < Diameter Header: 286, PXY >
                 < Session-Id >
                 { Auth-Application-Id }
                 { Result-Code }
                 { Auth-Session-State }
                 { Origin-Host }
                 { Origin-Realm }
                 [ User-Name ]
                 [ SIP-AOR ]
                 [ SIP-Number-Auth-Items ]
               * [ SIP-Auth-Data-Item ]
                 [ Authorization-Lifetime ]
                 [ Auth-Grace-Period ]
                 [ Redirect-Host ]
                 [ Redirect-Host-Usage ]
                 [ Redirect-Max-Cache-Time ]
               * [ Proxy-Info ]
               * [ Route-Record ]
               * [ AVP ]

25. 401 Unauthorized

This message contains the important information for authenticating the UA: the WWW-Authenticate header.

This message would look the following, between the S-CSCF and I-CSCF:

SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP icscf1.home.net;branch=z9hG4bKea1dof,
SIP/2.0/UDP pcscf1.visited.net;branch=z9hG4bKoh2qrz,
SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd];comp=sigcomp;branch=z9hG4bK9h9ab
From: <sip:[email protected]>;tag=s8732n

To: <sip:[email protected]>;tag=n3278s

Call-ID: 23fi57lju

WWW-Authenticate: Digest realm=”home.net”,nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093″,algorithm=AKAv1-MD5

Security-Server: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96;spi-c=909767; spi-s=421909;port-c:4444; port-s=5058
Cseq: 1 REGISTER
Content-Length: 0

26. 401 Unauthorized

27. 401 Unauthorized

Messages 26. and 27. are pretty much the same as the one above, with the only difference of the Via header, which will only contain the Request URI of the User Agent.

—– what the UE does with this message and what happens next: in the next episode :P —–

Tags: , , , , , , , , , , , , , , , , , , ,

1 Comment
10
Sep

holiday

   Posted by: cristina_crow    in personal

Kemer, Antalya, Turkey

7 nights, Fantasia DeLuxe

Wonderful, relaxing, lots of pool, dolphins, great smiling people, lots of Russians (which I didn’t like, cuz I don’t know the language and everybody was speaking russian), lots of yummy food, lots of sun and swimming, lots of funny fish close to the shore – we could see them when diving just 1 meter into the sea.

Scuba diving and ATV riding. A la Carte restaurants. Just Great!

Pictures on facebook.

Tags: ,

No Comments
Back to top