Mercuro Pocket is fully compliant with main 3GPP/IETF specifications and can be used to make voice calls over wireless connection (Both IPv4 and IPv6 networks are supported).
This IMS client includes OMA/IETF XDM features that make possible to store your buddy list on a remote server with presence information using XCAP protocol.
Inexbee has developed a special mechanism that allows routing all IMS/SIP calls through the earpiece to avoid poor audio quality if needed (HTC, BenQ, SAMSUNG …).
GSMA Image Sharing and Video Sharing features are under development and will be released soon.
In this post I will try to explain how security mechanisms are negotiated between an IMS Client and the Proxy CSCF (only SIP headers) and how to setup SAs using Linux IPSec tools. The main purpose of Security agreement is to agree on which mechanisms, algorithms or security parameters to use.
There are five main mechanisms used in VoIP networks:
digest
tls
ipsec-ike
ipsec-man
ipsec-3gpp
We will focus on 3GPP IPSec because the IMS makes it mandatory.
The security mechanism to use is known after the negotiation between the IMS Client and the Proxy CSCF succeeds. This negotiation is performed during the IMS registration and authentication procedures.
Three new SIP header fields have been defined, namely Security-Client,Security-ServerandSecurity-Verify.
Call Flow
IMS ClientP-CSCFS-CSCF
|||
|----(1)REGISTER---->||
|||
||---(2)REGISTER--->|
|||
||<-----(3) 401 ----|
|||
|<----(4) 494/401----||
|||
|<==IPSec in place==>||
|||
|----(5)REGISTER---->||
||----(6)REGISTER-->|
|||
||<---(7) 200 OK----|
|<---(8) 200 OK------||
|||
In step (1) the IMS Client sends an unprotected registration request including the security-client header. The Client must indicate that it is able to negotiate security mechanism by adding “Require” and “Proxy-Require” headers. The security-client header includes two ports (client and server ports) that the client wants to negotiate with the proxy CSCF.
In step (2) the Proxy CSCF forwards the request to the Serving CSCF.
In step (3) the Serving CSCF (registrar) challenges the Proxy CSCF. The 401 response is sent to the Proxy CSCF (challenge parameters are under WWW-Authenticated header). The Serving CSCF must include the security-server header.
In step (4) the Proxy CSCF forwards the 401/494 response to the IMS Client. At this stage the Proxy CSCF opens the IPsec security association (SA) for the IMS Client. The IMS Client also setup a SA (this is a temporary SA).
The lifetime of the created SA (between the IMS Client and the Proxy CSCF) is equal to the value of reg-await-auth timer.
In step (5) the IMS Client sends a new registration (to the Proxy CSCF) request including its credentials and copies the content of security-server header to the security-verify header. Before forwarding the request to the Serving CSCF, the Proxy CSCF will check that the previous security-server header and the security-verify headers (added by the IMS Client) are the same. If these values are different, the Proxy CSCF sends an error message to the IMS Client and terminates the created SAs.
In step (6) the Proxy CSCF forwards the request to the Serving CSCF.
In step (7) the Serving CSCF authenticates the IMS Client, and responds with 200 OK.
In step (8) the Proxy CSCF forwards the response to the IMS Client. At this step new SAs will be created. The temporary SAs will be destroyed (or not) by the Proxy CSCF.
Here we suppose that: - We are using Ubuntu (Linux Kernel 2.6 + KAME-tools) - the Proxy-CSCF address is '192.168.0.10' and Mercuro IMS Client address is '192.168.0.11' - for secure ports see above SIP capture - protocol is esp - algorithm is 'hmac-md5' - encrypt-algorithm is 'des-ede3-cbc' - mode is 'transport' - confidentiality key is '123456789012123456789012' (see function f2345 in 3GPP milenage algorithms) - integrity key is '1234567890123456' (see function f2345 in 3GPP milenage algorithms)
1. Install the tools
sudo apt-get install ipsec-tools
2. Edit /etc/ipsec-tools file and add the following script #Incoming Requests [US <- PC] spdadd 192.168.0.10/32[5066] 192.168.0.11/32[5064] udp -P in ipsec esp/transport//require; add 192.168.0.10 192.168.0.11 esp 2222 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";
#Incoming Replies [UC <- PS] spdadd 192.168.0.10/32[5068] 192.168.0.11/32[5062] udp -P in ipsec esp/transport//require; add 192.168.0.10 192.168.0.11 esp 1111 -m transport -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";
#Outgoing Requests [UC -> PS] spdadd 192.168.0.11/32[5062] 192.168.0.10/32[5068] udp -P out ipsec esp/transport//unique:1; add 192.168.0.11 192.168.0.10 esp 4444 -m transport -u 1 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";
#Outgoing Replies [US -> PC] spdadd 192.168.0.11/32[5064] 192.168.0.10/32[5066] udp -P out ipsec esp/transport//unique:2; add 192.168.0.11 192.168.0.10 esp 3333 -m transport -u 2 -E des-ede3-cbc "123456789012123456789012" -A hmac-md5 "1234567890123456";
3. Run the script
sudo /etc/init.d/setkey start
The same can be done under Windows vista using WFP(Windows Filtering Platform) API. For more information on How IPSec (in IMS context) feature could be implemented under Windows you can contact Mercuro Team at [tech dot mercuro -at- inexbee dot com].
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.
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.
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.
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
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/).
The latest Beta release of Mercuro IMS Client(Version 4.0.899) 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:
- Change default document names in XDM (WARN: it can potentially breaks existing configuration) - Add support for expiration negotiation in REGISTER (3GPP TS-24.229) - Add full support for "qop" authorization attribute (RFC-2617) - Add support for Uri negotiation in XDM RLS Services (RFC-4825) - Add message waiting indication event package support (RFC-3842) - Add support for XCAP Capabilities retrieval (RFC-4825) - Add support for OMA XCAP Directory (OMA-TS-XDM_Core-V1_1) - Add support for '423 Interval Too Brief' responses (RFC-3261) - Add SHA-1 hash computation in 'file-selector' header for MSRP file transfers (IETF draft-ietf-mmusic-file-transfer-mech) - Add meaningful status bar to make long-lasting operation bearable - Fix missing authorization header in initial REGISTER (3GPP TS-24.229) - Fix invalid PUBLISH request when dealing with 401/407 responses - Fix authorization handling in MSRP dialogs (401/407 challenges) - Fix invalid presence rules document when dealing with authorizations - Fix a crash when making a call to a bogus Uri - Fix minor UI problems
Mercuro IMS Client is in beta stage and has been tested with many IMS Core (provided by our technical partners). To improve interoperability between Mercuro IMS Client and your IMS Core/Client we are willing to give you some help and tips (send us a mail to [tech dot mercuro -at- inexbee dot com]).
The latest Beta release of Mercuro IMS Client(Version 4.0.864) 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 new audio and video codecs (GSM, Speex, Theora, etc) - Full screen mode support - Add the ability to choose the codecs used during Voice/Visio calls - Add a better validation of Uri values - Add ability to set custom XDMS documents - Add a dialog box when a connection error occurs - Add an anonymous crash report sending to ease feedback - Add a DTMF sound feedback - Fix a crash when running under Microsoft Remote Desktop - Fix a crash when making a Voice call with IMS Communicator - Fix the jitter buffer for a better sound quality - Fix the session rejection with IM SIMPLE Session - Fix the ugly noise when playing the ring tones - Fix label alignment under Windows Vista - Fix the tab-stop order of various screens - ...
RCS (Rich Communication Suite) is a join industry effort aiming to speed up the evolution of mobile phone communication towards rich communication. The RCS initiative includes network operators, network and device vendors (Orange, Telecom Italia, Telefonica, TeliaSonera, Ericsson, Nokia Siemens Networks, Nokia, SK Telecom, Sony Ericsson and Samsung).
The main purpose of RCS is to allow interoperability between network vendors and software editors.
RCS phase 1 defines 4 main features:
1. Enhanced Address Book (Service capabilities, presence contacts information, Video Call, …) 2. Content Sharing (Video Share, Image Share, …) 3. File Transfer (based on OMA Simple 1.0 specifications) 4. Converged Messaging (base on OMA Simple 1.0 specifications)
The RCS Initiative has defined a core feature set, developed reference implementations of the services and conducted interoperability testing in multi-vendor environment.
In next posts I will introduce all features mentioned above and explain how they are used in IMS Clients (Mercuro).
My name is Mamadou I. DIOP and I'm a telco engineer at Doubango Telecom
I'm specialized in NGN (3GPP, 3GPP2, TISPAN, Packet Cable, WiMax, GSMA, OMA, RCS, IETF ... standards).
