samedi 8 novembre 2008

Proxy and Service Route discovery in IMS

In this post I will try to explain how these two SIP extensions are used in IMS context and show differences between them.
Service Route discovery is an important mechanism in IMS context. The Service Route discovery mechanism usage is explained in RFC 3608 and 3GPP TS 24.229 and Path extension in RFC 3327.

Syntax

Service-Route = "Service-Route" HCOLON sr-value *( COMMA sr-value)
sr-value = name-addr *( SEMI rr-param )
Path = "Path" HCOLON path-value *( COMMA path-value )
path-value = name-addr *( SEMI rr-param )

Usage

Header field          where   proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Path                    R       ar   -   -   -   -   -   o
Path                   2xx      -    -   -   -   -   -   o
Service-Route          2xx      ar   -   -   -   -   -   o

The Service-Route header is inserted by the S-CSCF in the 200 (OK) responses to SIP REGISTER requests. The Service-Route header contains the S-CSCF SIP URI with a character string indicating the request type (mobile-originating or mobile-terminating). It is stored by the P-CSCF and associated to the registered public user identity. The UE MAY also store the value of the Service-Route header field in an association with the address-of-record for which the REGISTER transaction had registered a contact.
For example: <sip:orig@scscf.v4.ims.test:6060;lr>.

Support for the Path header extension MAY be indicated by a UA by including the option-tag "path" in a Supported header field. The Path header is inserted by the P-CSCF while forwarding REGISTER requests and contains its own SIP URI. This value is inserted by the P-CSCF to inform the S-CSCF where all terminating requests MUST be routed.
For example: <sip:term@pcscf.v4.ims.test:4060;lr>.
Both headers are only applicable to the 200 (OK) response of REGISTER requests and shall be supported by the P-CSCF (but shall not be supported by the MGCF or the BGCF).

Call Flow


IMS Client         P-CSCF             ICSCF                  S-CSCF
|                    |                  |                       |
|----(1)REGISTER---->|                  |                       |
|                    |                  |                       |
|<----(2)401---------|                  |                       |
|                    |                  |                       |
|----(3)REGISTER---->|                  |                       |
|                    |                  |                       |
|<----(4)200---------|                  |                       |
|                    |                  |                       |
|----(5)SUBSCRIBE--->|                  |                       |
|                    |                  |                       |
|<----(6)200---------|                  |                       |
|                    |                  |                       |
|----(7)REGISTER---->|                  |                       |
|                    |                  |                       |
|<----(8)200---------|                  |                       |
|                    |                  |                       |
|----(9)REGISTER---->|                  |                       |
|                    |                  |                       |
|<----(10)200--------|



1-The UE sends the initial REGISTER request without Service-Route header and includes the option-tag "path" in the Supported header field. Before forwarding this request to the I-CSCF, the P-CSCF will add its SIP URI in the Path header to inform the S-CSCF where to route terminating requests.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 901 REGISTER


2-The P-CSCF sends an authentication challenge (401/407) to the UE. This response already contains Path header added by the P-CSCF in step 1.

SIP/2.0 401 Unauthorized - Challenging the UE
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
CSeq: 901 REGISTER


3-The UE sends a new registration request with authentication information.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq: 902 REGISTER


4-The P-CSCF forwards the 200 OK (from the S-CSCF) response and stores the Service-Route value. At this point the Service-Route value is associated to the registered public user identity. In UE side the Service-Route value is also saved to be reused in next requests.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 902 REGISTER


5-The UE try a first presence subscription (watcher info package). New Route header MUST be added to all initial requests. This header contains the P-CSCF address, plus the associated S-SCSCF URI (Service Route) learnt during Service Route discovery.

SUBSCRIBE sip:mamadou@v4.ims.test SIP/2.0
Route: <sip:v4.ims.test:4060;lr=true;transport=tcp>,<sip:orig@scscf.v4.ims.test:6060;lr>
Event: presence.winfo
CSeq: 301 SUBSCRIBE


6-The P-CSCF forwards the response to the UE. You can notice that we new Record-Route header. This header contains that dialog routes.

SIP/2.0 200 OK
Record-Route: <sip:mo@scscf.v4.ims.test:6060;lr>,<sip:mo@pcscf.v4.ims.test:4060;lr>
CSeq: 301 SUBSCRIBE


7-UE initiated reregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0
Supported: path
CSeq:903 REGISTER


8-Reregistration response. This response contains both Path and Service-Route headers.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER


9-UE initiated deregistration. MUST not contain headers Path or Service-Route.

REGISTER sip:v4.ims.test SIP/2.0

Supported: path
Contact: <sip:[::::]:1010>;expires=0

CSeq:90 4 REGISTER


10-Deregistration response.

SIP/2.0 200 OK - SAR succesful and registrar saved
Path: <sip:term@pcscf.v4.ims.test:4060;lr>
Service-Route: <sip:orig@scscf.v4.ims.test:6060;lr>
CSeq: 903 REGISTER


Conclusion


Requests

Routes

Initial REGISTER

None

REREGISTRATION

None

DEREGISTRATION

None

Initial requests (except REGISTER)

P-CSCF and Service Routes

Early* dialogs without dialog routes

P-CSCF and Service Routes

Early* dialogs with dialog routes

Dialog Routes

Confirmed* dialogs

Dialog Routes







(*) A dialog is in the "early" state when it is created with a provisional response, and then transition to the "confirmed" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates.
Be careful:
- PUBLISH request does not create dialog
- SUBSCRIBE, INVITE, … requests create dialog

3 commentaires:

Anonyme a dit…

Hi Mamadou,
Thank for this good article. I'd like to know if PRACK request creates dialog or not. Could you give me an example with PRACK and service routes.
Thanks

DP a dit…

Dear Mamadou!

Thank you for the great description. I was wondering what happens if a client does not include 'path' in its 'supported' header? Does the proxy's address have to be attached in the initially constructed 'route' header anyway?

Thanks!

Cheers,
Peter

Anonyme a dit…

Hi. Thanks a lot for this valuable blog. I am new to this field and I want to know what exactly "dialog" means. I have a requirement that subscribe and re-subscribe should have same dailog. What shall I do for this requirement?