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

vendredi 7 novembre 2008

New Release of Mercuro IMS Client (4.0.1011)

The latest Beta release of Mercuro IMS Client(Version 4.0.1011) is now available for download at http://www.mercuro.net/.
This release comes with a lot of fixes and improvements. Here is a non-exhaustive list:

- Add P-Preferred-Identity for non-REGISTER dialogs and standalone
transactions
- Add loop detection on PUBLISH and SUBSCRIBE to deal with
mis-configured proxies
- Add support full support for rport parameter when registering
- Add pre-authorization of public identity in pres-rules to enable
self-presence awareness
- Add support for Do Not Disturb
- Add support for Auto-Answering in Voice/Visio calls
- Enhance shutdown time when closing the client (connected or not)
- Fix the route headers for non-REGISTER dialogs and standalone transactions
- Fix the handling of multiple Contact bindings
- Fix the handling of multiple P-Associated-Uri headers
- Fix the malformed fmtp parameter for iLBC and Speex codecs
- Fix the User-Agent string for XCAP request
- Fix the mis-saving of extended properties when using OMA Directory
discovery
- Fix the focus activation when receiving an INVITE request
- Fix a crash when using OMA Directory discovery with multiple document
per AUID
- Fix a crash when watcher-info document has no xmlns attribute
- Fix a crash when an Uri does not have a scheme in presence document
- Fix a crash when an INVITE has an incomplete Uri
- Fix a crash when an header contains an odd number of quotes.
- ....

your feedback is welcomed (http://feedback.mercuro.net/).