Mercuro IMS Client and IETF/3GPP/OMA specifications

On every subject, the Mercuro IMS Client tries to be as close as it can to the IETF/3GPP/OMA specifications. This means that we have to harvest and collect information spread accross thousand pages of specifications in order to provide a compliant IMS client.

Most of the development is done on the basis of these specifications; the remaining is done on the basis on the users' feedback. Because the Mercuro IMS Client is still a work in progress, your feedback is really important to us.

So, please take some time to log on http://feedback.mercuro.net/ and drop some lines about what goes wrong, what you would like to see, or anything else. Thank you.

New Release of Mercuro IMS Client (4.0.899)

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]).

For more information about Mercuro IMS Client visit http://www.mercuro.net/.

New Release of Mercuro IMS Client (4.0.864)

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
- ...

For more information about Mercuro IMS Client visit http://www.mercuro.net.

RCS (Rich Communication Suite): Image sharing

The Mercuro IMS Client is partially compliant with RCS phase 1 and support Image Sharing as defined in the GMSA IR.79 - Image Share Interoperability Specification v1.0.

In 3GPP/GSMA specifications Image sharing is define as a service for sharing images between users during a mobile phone call. These specifications were defined by the GSM Association for cellular network. Because Mercuro IMS Client is an IMS Client for PC desktop all these specifications do not apply. This mean that no CS voice call set up is required prior to sharing the images.


In case of Mercuro IMS Client context, Image Sharing session (based on SIP protocol for signalling) could be started before or after the voice call is set up. Image Sharing session is based on packet switched connection (PS). Before setting up Image Sharing session, capabilities negotiation is performed to present (GUI side) the possibility of sharing one or several images. In this beta version only one image can be shared for each session.

When the endpoint accepts the images, then image transfer start using packet switched connection with MSRP (RFC 4975) protocol to transport media (chunks). This transfer is done as peer2peer service, i.e. no server required in the network for sharing the images.

The end-user can send multiple pictures during the PS session by establishing a new SIP session for transferring the next picture after the previous session has been torn down.

The Message Session Relay Protocol (MSRP), IETF RFC 4975, is mandatory for the Image Share Service. Image data information settings in SIP/SDP follow IETF File transfer draft “draft-ietf-mmusic-file-transfer-mech-07.txt” (Mercuro IMS Client use version 8).

Mercuro IMS Client uses multi-body (both SDP+icon) messages as defined in “draft-ietf-mmusic-file-transfer-mech-08.txt” but only base64 format is used to embed icons.

Only pre-stored images can be shared using Mercuro IMS Client (no way to share live images).

In Mercuro IMS Client Image Sharing session consists of the following steps:

1. Capability query
2. Invitation procedure (SIP)
3. Image transmission (MSRP)
4. Termination procedure (SIP)

Capability query

Mercuro IMS Client uses service identifier (3GPP TS 24.229 – subclause 7.2A.9 and 7.2A.8) to query for terminal capabilities (endpoint is capable to support certain media features?). For this, service identifier tag is used to identify the media aspects of service/application for variety of purposes both by terminal and network side.

Mercuro IMS Client uses ‘urn:urn-xxx:3gpp-application.ims.iari.gsma-is’ as IARI to indicate support of Image Sharing IMS service.

OPTIONS sip:bob@192.168.16.33 SIP/2.0
Via: SIP/2.0/UDP 192.168.16.108:1223;rport;branch=z9hG4bK19912
From: <sip:mamadou@v4.ims.test>;tag=16015
To: <sip:bob@v4.ims.test>;tag=49a4177c-1235491482375000-037
Call-ID: 1235491356210@192.168.16.108
CSeq: 402 OPTIONS
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, REFER
Contact: <sip:mamadou@192.168.16.108:1223;transport=udp>;expires=1000;+g.oma.sip-im
User-Agent: IM-client/OMA1.0 Mercuro-Gold/v4.0.1196.0
P-Preferred-Service: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
Accept-Contact: *;+g.3gpp.icsi%5fref="urn%3Aurn-xxx%3A3gpp-service.ims.icsi.mmtel"
Route: <sip:mo@pcscf.v4.ims.test:4060;lr>,<sip:mo@scscf.v4.ims.test:6060;lr>,<sip:mt@scscf.v4.ims.test:6060;lr>,<sip:mt@pcscf.v4.ims.test:4060;lr>
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
Privacy: none
P-Preferred-Identity: <sip:mamadou@v4.ims.test>
Content-Length: 0

When Mercuro IMS Client receive an OPTIONS request then it creates a 200 OK response including Image Share IARI in the Contact header and send it back.

Invitation procedure

After capabilities of both ends are known and the user has located the target image to share, the next step is the actual Image Share session setup. SIP/SDP offer/answer model is used to perform negotiation.

INVITE sip:bob@v4.ims.test SIP/2.0
Via: SIP/2.0/UDP 192.168.16.108:1223;rport;branch=z9hG4bK3548
From: <sip:mamadou@v4.ims.test>;tag=2520
To: <sip:bob@v4.ims.test>
Call-ID: 1235491356211@192.168.16.108
CSeq: 501 INVITE
Max-Forwards: 70
Allow: INVITE, ACK, CANCEL, BYE, MESSAGE, OPTIONS, NOTIFY, PRACK, REFER
Contact: <sip:mamadou@192.168.16.108:1223;transport=udp>;+g.3gpp.app%5fref="urn%3Aurnxxx%3A3gpp-application.ims.iari.gsmais";explicit;+g.oma.sip-im
User-Agent: IM-client/OMA1.0 Mercuro-Gold/v4.0.1196.0
Supported: sdp-anat
Route: <sip:192.168.16.225:4060;lr=true;transport=udp>,<sip:orig@scscf.v4.ims.test:6060;lr>
P-Preferred-Service: urn:urn-xxx:3gpp-service.ims.icsi.mmtel
Accept-Contact: *;+g.3gpp.app%5fref="urn%3Aurnxxx%3A3gpp-application.ims.iari.gsmais";explicit
Accept-Contact: *;+g.oma.sip-im
Content-Type: application/sdp
P-Access-Network-Info: ADSL;utran-cell-id-3gpp=00000000
Privacy: none
P-Preferred-Identity: <sip:mamadou@v4.ims.test>
Allow-Events: presence, presence.winfo
Content-Length: 555

v=0
o=- 3344 3344 IN IP4 192.168.16.108
s=Mercuro IMS Client Session
t=0 0
m=message 1248 TCP/MSRP *
c=IN IP4 192.168.16.108
a=sendonly
a=accept-types:text/plain message/cpim
a=accept-wrapped-types:*
a=file-selector:name:"Image 18.png" type:image/png size:78169 hash:sha-1:4A:FB:E2:01:A9:0B:C0:6F:EB:C7:23:BD:2E:26:21:A6:5D:2B:6C:DB
a=file-disposition:render
a=file-date:creation:2008-10-15T10:40:46.405Z
a=file-icon:cid:test@mercuro.net
a=path:msrp://192.168.16.108:1248/fnfozvsrtkj;tcp
a=file-transfer-id:prepggxrpnrvystmwcysyycqpevikeff



Image transmission

If the invitation procedure succeeds, then the image will be transmitted via uni-directional MSRP connection (TCP). Large images will be sent in several chunks (2048 bytes per chunk).

Transmission is done following the RFC 4975.

Termination procedure

When Transfer is done Mercuro IMS Client will tear down SIP session (UDP) and media transfer side (Close TCP connection). See RFC 4975 for more information.

RCS Release 2 update

This subclause has been added to provided which changes have been made to be compliant with GSMA RCS 2.

- GSMA IR79 document version changed from v1.0 (IR79_11) to v1.2 (IR7912)
- "draft-ietf-mmusic-file-transfer-mech-07.txt" becomes RFC 5547
- Use "urn:urn-7:3gpp-application.ims.iari.gsma-is" instead of "urn:urnxxx:3gpp-application.ims.iari.gsmais" as IARI

References:
http://en.wikipedia.org/wiki/Image_share
http://www.gsmworld.com/documents/ireg/ir79_11.pdf
http://www.gsmworld.com/documents/IR7912.pdf

Rich Communication Suite phase 1

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.

Since February 2007 INEXBEE is working to release the first desktop IMS Client compliant with RCS phase 1. The beta version of this client (Codename MERCURO) is expected for September 2008.
Mercuro IMS Client is under test and RCS features are only available in commercial version.
For more information visit http://www.mercuro.net.

In next posts I will introduce all features mentioned above and explain how they are used in Mercuro IMS Client.

References:
http://en.wikipedia.org/wiki/Rich_Communication_Suite
http://www.nokiasiemensnetworks.com/global/Press/Press+releases/news-archive/Rich_Communication_Suite_Initiative.htm