SMS over 3GPP IMS Network

SMS stands for Short Message Service or Silent Messaging Service and is a communication service standardized in the GSM mobile communication system, using standardized communications protocols allowing the interchange of short text messages between mobile telephone devices.

SMS technology has been specified by the ETSI in GSM 03.40 and 03.38 documents (3GPP TS 23.040 and 3GPP TS 23.038 respectively). These documents only describe how to use SMS over mobile networks (nothing for IP networks).
In real world there are two way to receive SMS messages over mobile networks: Binary (PDU) and Text mode.
In this post I will explain how to use SMS technology over IP within the IP Multimedia (IM) Core Network (CN) subsystem based on the Session Initiation Protocol (SIP) and SIP Events as defined in 3GPP TS 24.229.
Note: In the coming chapters, « SMS over IMS Network » and « SMS over IP Network » have the same meaning.

Text mode

The message payload is transfered « as is ». This mode is out of scope.

Binary mode

Also know as PDU (Protocol Data Unit) mode, it is use to encode the payload of the SMS sent over IMS networks. In this case the payload only contains a sequence of hexa-decimal octets or decimal semi-octets strings. The overall PDU string contains some useful information (SMSC address, Service center time stamp, sender number, message reference ...) plus the actual message.

The message length can be up to 160 characters where each character represent 7bits [160/7bits], [140/8bits] or [70/16bits]. By default, each character represent 7bits encoded as per GSM 03.38.

For IMS Networks, SMS message shall be encapsulated in RPDUs (Relay Protocol Data Unit) data string as defined in 3GPP TS 24.011, subclause 7.3. The RPDU data is transfered from SM entity to SM entity using SIP MESSAGE requests. These SIP requests shall use the MIME type "application/vnd.3gpp.sms" for this purpose.

GSM 7 bit Default Alphabet

Each character represent 7bits. For more information see 3GPP TS 23.038 or ETSI GSM 03.38.

Figure 1: GSM 7bit alphabet

3GPP IMS Registration

On sending a REGISTER request, the IMS Client shall indicate its capability to receive traditional short messages over IMS network by including a "+g.3gpp.smsip" parameter into the Contact header according to RFC 3840.

Figure 2: SIP/IMS registration request

Mobile-Originated SMS (MO-SMS)

The IMS Client sender shall build and populate RP-DATA message (RPDU encapsulating TPDU data string), containing all the information that a mobile station submitting an SMS message according to 3GPP TS 24.011 would place, for successful delivery. The sender shall parse and interpret RP- DATA, RP-ACK and RP-ERROR messages, containing all the information that a mobile station receiving an SM according to 3GPP TS 24.011 would see, in a SM submission or status report.

Figure 3: Signaling flows demonstrating successful UE originated SM submit procedure over IP as per 3GPP TS 24.341

** [1,2,4] RP-DATA (SMS-SUBMIT)

Below is represented the first request (RP-DATA(SMS-SUBMIT)) sent from the IMS Client to the P-CSCF.

Figure 4: RP-DATA(SMS-SUBMIT) from Mercuro to the P-CSCF

The SIP MESSAGE (Figure 4) request sent from the IMS client to the P-SCSF carry the RP-DATA (Mobile station to IMS Network) message encoded as per 3GPP TS 24.011 chapter 7.3.1.2.

Figure 5: RP-DATA (Mobile Station to Network) as per 3GPP TS 24.011 subclause 7.3.1.2

The SIP MESSAGE content (Figure 4) can be dissected as following:

RP-MESSAGE: 000000069133010000F019069133010000F011000A9133163254760000AA05F330BB4E07
RPDU:000000069133010000F019

TPDU (SMS-SUBMIT):069133010000F011000A9133163254760000AA05F330BB4E07

The RP-MESSAGE can be dissected as follow (Figure 6):

Figure 6: RP-DATA (Mobile Station to Network) content dissection

** [9,10,11] RP-ACK(SMS-SUBMIT-REPORT)

The SIP MESSAGE payload includes the RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-SUBMIT-REPORT.

Figure 7: RP-ACK as per 3GPP TS 24.011 subclause 7.3.3

RP-MESSAGE:020009069133163254760080

For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.2a for TPDU (SMS-SUBMIT-REPORT) encoding. If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.

Mobile-Terminated SMS (MT-SMS)

Figure 8: UE originated SM deliver procedure over IP signaling as per 3GPP TS 24.341

** [2,3,4] RP-DATA(SMS-DELIVER)

This request sent from the IP-SM-GW includes a vnd.3gpp.sms payload that includes the short message and routing information for the S-CSCF to forward the short message.

The payload includes the RP-DATA message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER.

Figure 9: RP-DATA (Network to Mobile Station ) as per 3GPP TS 24.011 subclause 7.3.1.1

RP-MESSAGE: 0100069133010000F0001E069133010000F0040A91331632547600000000000000000005F330BB4E07

For more information, see 3GPP TS 24.011 subclause 7.3.1.1 for RPDU (RP-DATA) data and 3GPP TS 23.040 subclause 9.2.2.1 for TPDU (SMS-DELIVER) encoding.

** [8,9,11] RP-ACK(SMS-DELIVER-REPORT)

This request includes a vnd.3gpp.sms payload that includes the SMS-DELIVER-REPORT and routing information for the IP-SM-GW to forward the delivery report.
The payload includes an RP-ACK message. Its RP-User-Data information element includes a TPDU of type SMS-DELIVER-REPORT.

RP-MESSAGE:020109069133163254760080

For more information, see 3GPP TS 24.011 subclause 7.3.3 for RPDU (RP-ACK) data and 3GPP TS 23.040 subclause 9.2.2.1a for TPDU (SMS-DELIVER-REPORT) encoding.
If error occurs when decoding the message, RP-ERROR (3GPP TS 24.011 subclause 7.3.4) message is sent instead of RP-ACK.

References:

• http://en.wikipedia.org/wiki/SMS

• 3GPP TS 23.038 - Alphabets and language-specific information
• 3GPP TS 23.040 - Technical realization of Short Message Service (SMS)
• 3GPP TS 24.011 - Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface.
• 3GPP TS 24.341 - Support of SMS over IP networks; Stage 3
• 3GPP TS 24.451 - Support of SMS and MMS over NGN IMS subsystem; Stage 3 [Endorsement of 3GPP TS 24.341 Release 7]

OpenIPSec: Introduction (Part 1)

This is the first part of a series of articles in which I will explain how I will develop an open source IPSec Framework (Ndis Driver, Crypto API and Command Line Tools) for Windows OS.
This Framework will be available under GPLv3 license and all the source code will be available for download.

This first part is an introduction to IPSec and a kick overview of OpenIPSec project.

1. IPSec

IPSec stands for Internet Protocol Security and has been specified by the Internet Engineering Task Force (IETF).
IPSec operates at at the Network Layer (OSI Layer 3). This imply that it can protect all upper protocols such as UDP, TCP or ICMP.
IPSec is a successor of the ISO standard Network Layer Security Protocol (NLSP). NLSP was based on the SP3 protocol that was published by the NIST but designed by the Secure Data Network System project of the National Security Administration (NSA). Because it operates at OSI layer 3 it must be integrated at the Kernel/OS Layer. On Windows OS all Network APIs (e.g. Windows Sockets 2 or Layered Service Provider) operate at the upper layers (user/application Layer).
An example of security protocols working at user/application layer are Secure Sockets Layer (SSL), Transport Layer Security (TLS) or Secure Shell (SSH).

1.1 Protocols

IPSec have three main protocols: AH, ESP and IKE. AH and ESP are commonly called Security Protocols.

=>AH: Stands for Authentication Header and has been defined in RFC4302. It is used to provide connectionless integrity and data origin authentication for IP datagrams and to provide protection against replays.


=>ESP: Stands for Encapsulating Security Payload and has been defined in RFC4303. It is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and (limited) traffic flow confidentiality. It may be applied alone or in combination with AH.

=>IKEv1/IKEv2: Stands for Internet Key Exchange and have been defined in RFC4109 and RFC4306 respectively. Both are used for mutual authentication between two parties and establishes an IKE security association (SA) that includes shared secret information that can be used to efficiently establish SAs for Encapsulating Security Payload (ESP) and/or Authentication Header (AH) and a set of cryptographic algorithms to be used by the SAs to protect the traffic that they carry.

1.2 Security Association (SA)

IPSec Security Association (SA) is a virtual unidirectional association between two or more peers/entities (IP:port) . This mean that you should create two SAs for bidirectional communications. Each SA has its own ID called SAID stored in the Security Association Database (SAD) as per RFC4301. The SA defines:

• A unique security parameter index (SPI)
• Shared security Keys
• Lifetime
• Encryption algorithm to use : DES, 3DES or AES (all supported by OpenSec)
• Authentication algorithm to use: HMAC-MD5-96, AES-XCBC-MAC-96 or HMAC-SHA-1-96 (all supported by OpenSec)
• Which Protocol to use: ESP or AH

1.3 Key Management

Key Management mechanism is used to exchange mandatory security keys to setup SAs. Can be manual or automated using IKE.
For Example, 3GPP IMS use SIP to exchange security information and manually setup SAs (e.g. using ipsec command line tools).

1.4 Mode of operation (transport and tunnel)

Both ESP and AH may be applied individually or in combination with each other to provide IPv4 and IPv6 security services. Both supports two modes of use: transport mode and tunnel mode. In transport mode, AH and ESP provide protection primarily for next layer protocols; in tunnel mode, AH and ESP are applied to tunneled IP packets.

==>Transport: only the payload (without IP header) of the IP packet is encrypted (ESP) and/or authenticated (ESP or AH) before (re)transmission. This is the default mode in 3GPP IMS context (Both UE and P-CSCF).

=>Tunnel: both the IP header and the payload are encrypted (ESP) and/or authenticated (ESP or AH) before (re)transmission. It is used to create Virtual Private Networks (VPN).

2. OpenIPSec Framework

OpenIPSec is an open source IPSec Framework for Windows XP/Vista/Blackcomb/CE. The Framework will include an API for software development, command line tools, open source code (GPLv3) and documentation.
Development is done from scratch and all dependent projects are my own projects (To ease bug fix; release a soft 100% free and open source). This project depends on OpenSec and libonid. The first, contains IPSec algorithms implementation and the second allows monitoring Network cards. These two projects are under development (OpenSec: 90% done - libonid: 40% done) and the source code is freely available for download. To ease adoption, command line tools (setkey, spdadd, add ...) will have same name and options than those provided on Linux.

2.1 Standards

* RFC1825 - Security Architecture for the Internet Protocol (Obsoleted by: 2401)
* RFC2401 - Security Architecture for the Internet Protocol (Obsoletes: 1825 and Obsoleted by: 4301 and Updated by: 3168)
* RFC2402 - IP Authentication Header (Obsoleted by: 4302, 4305 and Obsoletes: 1826)
* RFC2410 - The NULL Encryption Algorithm and Its Use With IPsec
* RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
* RFC2406 - IP Encapsulating Security Payload (ESP) (Obsoleted by: 4303, 4305 and Obsoletes: 1827)
* RFC2407 - The Internet IP Security Domain of Interpretation for ISAKMP (Obsoleted by: 4306)
* RFC2408 - Internet Security Association and Key Management Protocol (ISAKMP) (Obsoleted by: 4306)
* RFC2409 - The Internet Key Exchange (IKE) (Obsoleted by: 4306 and Updated by: 4109)
* RFC2481 - A Proposal to add Explicit Congestion Notification (ECN) to IP (Obsoleted by: 3168)
* RFC3168 - The Addition of Explicit Congestion Notification (ECN) to IP (Updates: 2474, 2401, 793 and Obsoletes: 2481)
* RFC3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec
* RFC4109 - Algorithms for Internet Key Exchange version 1 (IKEv1) (Updates: 2409)
* RFC4301 - Security Architecture for the Internet Protocol
* RFC4302 - IP Authentication Header
* RFC4303 - IP Encapsulating Security Payload (ESP) (Obsoletes: 2406)
* RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Obsoleted by: 4835 and Obsoletes: 2404, 2406 )
* RFC4306 - Internet Key Exchange (IKEv2) Protocol
* RFC4307 - Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2)
* RFC4835 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (Obsoletes: 4305)

/!\ OpenSec is now available for download at http://code.google.com/p/opensec/

References:
http://en.wikipedia.org/wiki/IPsec

OpenSec Beta 0.3

First beta version of OpenSec is now available for download.
To download source code:
- go to http://code.google.com/p/opensec/ or
- use command line "svn checkout http://opensec.googlecode.com/svn/trunk/ opensec-read-only"

OpenSec is an Open-Source Security API. This project is part of OpenIPSec project.
This API contains all mandatory or recommanded security algorithms needed to implement an IPSec Framework.

Already supported algorithms: MD5, SHA-1, HMAC-MD5-96, HMAC-SHA-1-96, DES-ECB, DES-CBC, 3DES-ECB, 3DES-CBC, AES[128,192,256]-ECB, AES[128,192,256]-CBC and AES[128]-XCBC-MAC-96.

The source code includes a test application to see how these algorithms can be used.

Standards

* RFC1321 - The MD5 Message-Digest Algorithm
* RFC1829 - The ESP DES-CBC Transform
* RFC1853 - IP in IP Tunneling
* RFC2104 - HMAC: Keyed-Hashing for Message Authentication
* RFC2402 - IP Authentication Header
* RFC2403 - The Use of HMAC-MD5-96 within ESP and AH
* RFC2404 - The Use of HMAC-SHA-1-96 within ESP and AH (Obsoleted by RFC4305)
* RFC2405 - The ESP DES-CBC Cipher Algorithm With Explicit IV
* RFC2406 - IP Encapsulating Security Payload (ESP) (Obsoleted by RFC4305)
* RFC2451 - The ESP CBC-Mode Cipher Algorithms
* RFC3174 - US Secure Hash Algorithm 1 (SHA1)
* RFC3566 - The AES-XCBC-MAC-96 Algorithm and Its Use With IPsec
* RFC3602 - The AES-CBC Cipher Algorithm and Its Use with IPsec
* RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)

* FIPS 197 - AES (Advanced Encryption Standard)
* FIPS-46-1/3 - DES and Triple DES (Data Encryption Standard)
* FIPS 81 - DES MODES OF OPERATION

* RFC2144 - The CAST-128 Encryption Algorithm

* RFC2202 - Test Cases for HMAC-MD5 and HMAC-SHA-1

Google Android NDK

Weeks ago, Google announced the first public release of Android NDK.

I was so excited because the IMS Client I'm developing is written in pure C/C++ (Only Java was supported).
Before Android NDK, I have looked at Google's Android SDK and I found that they are using non-standard JVM. This mean that applications developed using J2ME can't run on Android devices. Thanks to Dalvik virtual machine.
It was clear that I won't rewrite xxx thousand lines of code for Android mobile devices which represent less than 1 percent of all mobile devices.
It's amazing to think that Android OS will gain momentum without compliant embedded JVM. First deception.

Because performance is critical for us and we don't have time and money to rewrite an application which will only run on Android devices, we decided to wait for the Android NDK.

The first release of Android NDK only comes with these native libraries:
# libc (C library)
# libm (math library)
# libz (Zlib compression)
# liblog (Android logging)

This mean that you don't have:
# STL support (string, list, map, queue, ....)
# C++ exceptions handling
# Threading support
# Cryptography support
# Secure sockets/transport (SSL, TLS, S/MIME, ...)
# Classes to access the system resources (webcam, soundcard, drivers, ...)
# .... to be continued

Of course, you must use JNI if you want to have access to the native libraries. I let you imagine about performance ...
Second deception.

Mercuro with MMS

Support for MMS (Multimedia Messaging Service) messaging has been added in the last release of Mercuro IMS Client.
MMS messages are sent over the network using MSRP/SMIL to one or multiple contacts (using conference factory).

libSigComp Beta 0.2

First beta version of libSigComp is now available for download.
To download source code:
- go to http://code.google.com/p/libsigcomp or
- use command line "svn checkout http://libsigcomp.googlecode.com/svn/trunk/ libsigcomp-read-only"

Released under LGPLv3

libSigComp: THE Open-Source SigComp framework

I’m writing today to announce the launch of libSigComp, an Open-Source SigComp Framework. This project is intended to develop a complete and compliant SigComp Framework to speed-up SigComp integration in Open-Source IMS projects.

As many operators have begun to commercially deploy IMS, the relevance of using SigComp to lower bandwidth usage will come quickly. In my own opinion I think that most operators (especially those using RCS) will question how to reduce SIP signaling (registration, billing, presence, messaging …) bandwidth usage (who will pay bits?).

These questions will especially concern using SIP (or all other text-based protocols) in wireless handsets as part of 2.5G and 3G cellular networks.

SigComp stands for Signaling Compression and has been defined in RFC 3320 by Internet Engineering Task Force (IETF) ROHC working group.

Many application protocols used for multimedia communications are text-based and engineered for bandwidth rich links. As a result the messages have not been optimized in terms of size. For example, typical IMS/SIP messages range from a few hundred bytes up to two thousand bytes or more. For this reason, SigComp is a mandatory part of 3GPP IMS.

SigComp could also be useful for RCS (Rich Communication Suite) networks because of the size of the SIP packets (more than three thousand bytes for presence publication). Using SigComp in IMS/RCS context will reduce the round-trip over slow radio links.

The goal of this project is to provide a SigComp framework which:

- Could be used as an external API or Framework

- Highly portable (Coded in C/C++ without any external dependencies)

- Easily configurable (memory usage, priorities in static dictionaries, stateful/stateless modes, dynamic/static/shared compression types …)

- Easy to integrate with any existing SIP/IMS stack, Proxy-CSCF, PoC client …

- Allow to easily plug your own compressor (DEFLATE –RFC 1951- will be the default)

- Robust

- Efficiently run on mobile handsets (small footprint)

- Use small memory (UDVM decompression)

- Run fast without high CPU usage

COMPLIANCE:

RFC 3320: Signaling Compression (SigComp)

RFC 3321: Signaling Compression (SigComp) - Extended Operations

RFC 4464: Signaling Compression (SigComp) Users' Guide

RFC 4465: Signaling Compression (SigComp) Torture Tests

RFC 4077: A Negative Acknowledgement Mechanism for Signaling Compression

RFC 3485: The Session Initiation Protocol (SIP) and Session Description Protocol

(SDP) Static Dictionary for Signaling Compression (SigComp)

RFC 5112: The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)

RFC 1951: DEFLATE Compressed Data Format Specification version

3GPP TR23.979 Annex C: Required SigComp performance

Released under LGPLv3

MORE INFORMATION:

• To have feedbacks or if you are interested for IOTs don’t hesitate to contact me at diopmamadou{at yahoo}dot fr.
• libSigComp homepage: http://code.google.com/p/libsigcomp/

GSMA Rich Communication Suite Experience

1. Presentation

RCS (Rich Communication Suite) was 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 RCS is now managed by the GSM Association (GSMA). For more information about GSMA RCS program look at this dedicated website (http://www.gsmworld.com/rcs/programme.shtml)
The main goal of GSMA RCS is to provide a set of fully interoperable rich services to be used both in mobile and fixed network (Network/Access Convergence). These services will enrich call experience.
To be compliant with the GSMA RCS an IMS client MUST at least support these services:

- Enhanced Address Book (defined by the OMA –Open Mobile Alliance-)
- Enhanced Messaging (OMA)
- Content Sharing (GSMA)
- File Transfer (OMA)

An easy way to show how RCS work is to share with you RCS Experience using Mercuro IMS Client. Mercuro is one of the most complete and compliant IMS/RCS client used today.

Mercuro is developed by Inexbee.

2. Enhanced Address Book

This service (also called Enhanced Phonebook or EAB) is the main RCS Service and could be seen as an enriched buddy list with rich presence information. It should be possible to launch all other services (Image/Video Sharing, File transfer, SMS, MMS …) by selecting a contact from the phonebook.
The buddy list is expressed as XML documents and stored in various document repositories in the network where such documents can be located, accessed and manipulated (created, changed, deleted) by authorized principals.
Such documents are accessed and manipulated using IETF XML Configuration Access Protocol (XCAP).
Mercuro could be seen as a XDM Client (XDMC) and the server (XDMS) as a HTTP origin server.
Mercuro can automatically synchronize your EAB with your Terminal Address Book (TAB) to backup or restore your local buddies.
Synchronization between your TAB and the Network Address Book (NAB) must be done using a SyncML agent which will do translation from SyncML (OMA DS Synchronization) to OMA XDM.
Mercuro will support NAB synchronization in release 5.0.

Figure 1: Mercuro IMS Client EAB

2.1 XDM Storage

All contacts are remotely stored in the XDM server. Remote storage allows the user to get his buddy list everywhere and makes Convergence easier (Same contacts on your PC, PDA or mobile phone even if roaming). A contact is stored with some mandatory information (id and display-name) and extended with social information (e.g. nickname, e-mail, free text, dynamic avatar, birthday, labels, favorite link …). To keep XML documents compliant and interoperable, all Mercuro specific information are stored in separate documents.

Mercuro buddies are displayed with minimal information (nickname, msisdn …) and full profile is shown only when requested by the user. It is possible for the user to sort stored his contacts by nickname, e-mail, birthday …

2.2 History

All communications history is saved (for each contact) on behalf of the user. Retrieving a particular saved entry from the UI can be performed using dynamic filters.

Mercuro IMS Client allows the user to start new session (Voice/Video call, Image Sharing, Messaging …) from the history by selecting an entry. You can sort history by date, communication type...

2.3 Groups

Each contact could be part of one or many Groups (e.g. friends, family, biz …).

Mercuro buddies are displayed by Group. You can sort your buddies by group, name, sphere ….

2.4 Enhanced Address Book Presence

This feature is mainly based on OMA SIMPLE Presence 1.1 which partially uses IETF presence data model (RFC 4479).
Mercuro offers the possibility to publish your status (online, offline, out to lunch, on the phone …), dynamic avatar, favorite link, notes, availability, willingness, mood or per service/device capabilities at any time. Dynamic avatar publication (Based on OMA Presence Content) is an important element of EABP and gives Mercuro the look and feel of some well-known VoIP software (Skype or Windows Live Messenger).
It is possible to retrieve presence information for each contact in the phonebook using subscription mechanism (asynchronous). Presence could be retrieved one by one or per list.

All contacts are displayed with their presence information (all mentioned above). You have the possibility to sort your buddies by presence information (availability or willingness).
See below for capabilities indication.

2.5 Capabilities Enhanced Address Book

Mercuro can publish/store (persistent) end-user’s current communication capabilities and retrieve them later (new session). In the other side, capabilities information is retrieved for each contact using presence subscription. All contacts are displayed with their capabilities information. The list of capabilities to be shown to the user by Mercuro 4.x includes:

Video Call (3G CS video call)
Image Sharing (PRD IR.79 Image Share Interoperability Specification 1.0)
Video Sharing (PRD IR.74 Video Share Interoperability Specification, 1.0)
File Transfer (OMA SIMPLE IM 1.0)
Session Mode Messaging (OMA Instant Messaging using SIMPLE, 1.0)

Capabilities indication can be seen as “what type of communication I’m willing to accept”.

2.6 Presence authorization

Once your presence information is published you can choose with who you want to share it. At any time you can choose to accept, block, ignore or revoke an existing (or incoming request) authorization. Rules could be managed per lists (black-hat, white-hat …) or per buddy.

You can easily (UI) retrieve associated pres-rules (blocked, allowed …) for each contact.

2.7 Multimedia Element Integration

It is possible to integrate multimedia elements such as photos, portrait icon, free text …

3. Enhanced Messaging

Mercuro supports 1-to-1 and Ad-hoc mode messaging (Instant Messaging using SIMPLE v1.0 chapter 4.3.1). Peer-to-peer IM Session is also supported (chap. 4.3.2).
These services are supported as part of GSMA RCS Phase 1.

Mercuro also supports Pager mode (chap. 4.2.1) and Large Message Mode messaging (chap. 4.2.1).

Group Messages (chap. 4.2.2), Deferred Messages (chap. 4.2.3) and Predefined session mode messaging (chap. 4.3.1) will be supported in release 5.0.

Mercuro (PC version) uses Pager Mode and Large Message Mode messaging to simulate SMS/MMS services.
Mercuro uses OMA Final Delivery Reports (chap. 5.7) to simulate Negative/Positive Acknowledgement Mechanism for MMS messages.

For 1-to-1 mode the caller or callee can add new participants at any time. The exchanged message can contain both text and/or multimedia content (SMIL, images, videos ...).

End party activity (typing/composing) is indicated to all participants.

4. Content Sharing

4.1 Image Sharing

In 3GPP specifications Image sharing is defined as a service for sharing images between users during a mobile phone call (CS Call). These specifications were defined by the GSM Association for cellular network. For packet-only devices (e.g. Mercuro PC version) all these specifications do not apply. This mean that no CS voice call set up is required prior to sharing the images.
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 RFC 5547 (previously [draft-ietf-mmusic-file-transfer-mech]).

To see how this feature is used in Mercuro IMS Client --> [http://imsclient.blogspot.com/2008/09/rcs-rich-communication-suite-image.html].

4.2 Video Sharing

This feature will be supported in release 5.0.

GSMA Video Sharing is vendor independent and a Peer-To-Peer service and doesn’t require special/dedicated server.
A compliant RCS Client shall be able to share live Video (by sharing the camera capture) and sharing pre-recorded Video is a handset implementation option.
Video codec H.263-2000 profile 0 level 45 is mandatory (QCIF). To have better Video quality MPEG4 Visual Simple Profile 0b and H.264/AVC Baseline Profile Level 1b could be optionally used.

5. File Transfer

Many technical references are common to GSMA Image Sharing but this service allows exchanging different types of content (text, documents, SMIL, videos …).
Both end clients (caller/callee) can start file transfer session during an ongoing session (CS/PS call) or without having an ongoing session.
Only 1-to-1 file transfer feature is supported in GSMA RCS phase 1 and only a single file can be transferred per session. Only sending/receiving files are supported and requesting files is not part of the GSMA RCS phase 1 use cases.

6. Main IETF/OMA specifications (3GPP omitted)

6.1 Enhanced address Book

[OMA-TS-XDM_Core-V1_1-20080627-A]
[OMA-WP-XDM_1_1_Implementation_Guidelines-20080627-C]
[OMA-TS-Presence-SIMPLE_Content_XDM-V1_0-20081223-C]
[OMA-TS-Presence_SIMPLE-V1_1-20080627-A]
[RFC 2387] + [RFC 3265] + [RFC 3857] + [RFC 3858] + [RFC 3863] + [RFC 3903] + [RFC 4662] + [RFC 4479] + [RFC 4480] + [RFC 4482] + [RFC 4483] + [RFC 4825] + [RFC 5025] + [RFC 5262] + [RFC 5264]

6.2 Enhanced Messaging (-minus those listed above)

[OMA-TS-SIMPLE_IM-V1_0-20080903-C]
[RFC 3862] + [RFC 3891] + [RFC 3994] + [RFC 4028] + [RFC 4145] + [RFC 4353] + [RFC 4488] + [RFC 4575] + [RFC 4579] + [RFC 4975] + [RFC 5366]

6.3 Image Sharing

[GSMA PRD IR.79 Image Share Interoperability Specification 1.0]
[RFC 4145] + [RFC 4575] + [RFC 4975] + [RFC 5547]

6.4 File Transfer

[OMA-TS-SIMPLE_IM-V1_0-20080903-C]
[RFC 4145] + [RFC 4575] + [RFC 4975] + [RFC 5547]

DSCP marking under Windows at application level

DSCP stands for Differentiated Services Code Point and is a field in the header of IP packets (v4 and v6) for packet classification purposes. As defined in the RFC 2474 Differentiated Services enhancements to the Internet protocol are intended to enable scalable service discrimination in the Internet without the need for per-flow state and signaling at every hop.

 0   1   2   3   4   5   6   7
+---+---+---+---+---+---+---+---+
|         DSCP          |  CU   |
+---+---+---+---+---+---+---+---+

DSCP: Differentiated Services CodePoint (0x00-0x3F)
CU: Currently Unused

Out-of-Scope

- Using End-to-end QoS features in IMS context. However, you can read 3GPP TS 23.207 for more information.
- Using DSCP tagging under Windows at host level (Network administrators).

In-Scope

- Using DSCP tagging under Windows at application level (General Information).

The IP_TOS socket option

By default, individual applications are not allowed to manipulate TOS (Type Of Services) bits, because this can defeat system policy mechanisms. This is why using IP_TOS option on WINSOCK socket has no effect.

Follow these steps to enable the IP_TOS option for the Winsock setsockopt function and the -v option for the ping utility on Windows 2000, Windows XP, or Windows Server 2003 (Microsoft KB 248611):

1. Start Registry Editor (Regedt32.exe).
2. Go to the following key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TcpIp\Parameters
3. If you are running Windows 2000, follow these steps:
1. On the Edit menu, click Add Value.
2. In the Value name box, type DisableUserTOSSetting.
3. In the Data Type list, click REG_DWORD, and then click OK.
4. In the Data box, type a value of 0 (zero), and then click OK.

If you are running Windows XP or Windows Server 2003, follow these steps:

1. On the Edit menu, point to New, and then click DWORD Value.
2. Type DisableUserTOSSetting as the entry name, and then press ENTER.

When you add this entry, the value is set to 0 (zero). Do not change the value.

4. Quit Registry Editor, and then restart the computer.

This is not supported under Windows Vista

The Generic Quality of Service (GQoS) API

It is also possible to specify DSCP values using GQoS API. This API is part of Microsoft Windows Sockets v2. Because the first method can break the security rules it is recommended to use GQoS. This API can also be used to provide feedback to your application regarding the status of the network.

Good article on how to use this API --> http://msdn.microsoft.com/en-us/magazine/cc301862.aspx

Only IPv4 is supported

Quality Windows Audio/Video Experience (qWave)

As define here qWave is a collection of QoS-related software modules that run on devices in the home network. qWave supports multiple A/V streams (real-time flows requiring QoS) and data streams (best-effort flows, such as e-mail) simultaneously over the home network, while providing a high-quality A/V user experience. qWave is targeted for home A/V scenarios and is disabled in other environments, such as an enterprise.

Only under Windows Vista

Some references:

http://www.rfc-editor.org/rfc/rfc2474.txt
http://www.rfc-editor.org/rfc/rfc1349.txt
http://www.microsoft.com/whdc/archive/qWave.mspx
http://technet.microsoft.com/en-us/library/bb742475.aspx
http://support.microsoft.com/kb/248611

IMS Client for Windows Mobile

After the success of Mercuro IMS Client on Windows XP/Vista, Inexbee has launched Mercuro Pocket.

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.

Mercuro Pocket can be used as a normal SIP /VoIP client and is now available for download at http://www.mercuro.net.

Commercial version of Mercuro IMS Client is now available

	Inexbee’s Mercuro IMS Client is the result of more than four years of expertise in telecom and convergence software development. Today, the Mercuro IMS Client is the most complete and 3GPP/IMS/RCS compliant softphone available. After several months of live testing and thanks to the active contribution of many of you, the beta version is withdrawn to give birth to a Bronze, Silver and Gold edition on Windows and Windows Mobile.
	Mercuro Bronze Edition Inexbee is providing a free version of the Mercuro IMS Client. The Bronze edition is the entry level version that offers all of the most common features of IMS. It is perfect to begin IMS testing and deployment. The Mercuro Bronze edition is downloadable for free directly from our website: www.mercuro.net
	Mercuro Silver Edition + Mercuro Pocket (beta) The Mercuro IMS Client Silver edition is our most complete version of IMS Client. It includes all of the features of the Bronze edition. Additionaly, it is compliant with the latest security Networks and is carrying OMA XDMS support. It can be used in carrier-grade IMS environment. Be among the first to buy the Mercuro Silver Edition and get the beta Mercuro Pocket Silver edition (for Windows Mobile) for free. You can buy it directly from our website: www.mercuro.net
	Mercuro Gold Edition (On Request) Fully customizable, the Gold edition is available on request and is dedicated to large deployments and provides custom branding, QoS features and high quality codec. For further information please refer to: www.mercuro.net
	About Mercuro Inexbee is a worldwide leader in software development for multimedia convergence and interoperability. Mercuro team is part of a large community of companies and independent engineers setting up the standards of the next Rich Communication Suite and bringing to life the concept of Multimedia Convergence Service. For further information please refer to: www.mercuro.net
	Copyright 2008 © Inexbee - All Rights Reserved