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 - - - - - oPath 2xx - - - - - - oService-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:
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
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
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?
Enregistrer un commentaire