|WP8: Dialer||WP8: Incoming call||WP8: In Call|
|WP8: In Progress||WP8: Credentials||WP8: Network|
|Windows Vista: Enhanced Address Book||Windows Vista: Chat + File Transfer + Video Sharing|
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/our-work/mobile_lifestyle/rcs/gsma_rcs_project.htm)
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)
|fully compliant||under dev|
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 is 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).
Boghe could be seen as a XDM Client (XDMC) and the server (XDMS) as a HTTP origin server. Boghe 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. We are working to add support for NAB synchronization in the coming releases.
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 information specific to Boghe will be stored in separate documents.
This feature is mainly based on OMA SIMPLE Presence 1.1 which partially uses IETF presence data model (RFC 4479).
Boghe 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 to have 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 (XCAP RLS Service).
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.
Boghe IMS Client can publish or 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 Boghe 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”.
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.
Boghe 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 2.
Boghe 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 the coming releases.
SMS service over broadband access
To send SMS over broadband access, Boghe follow the procedures of 3GPP SMS over IP transport level interworking described in 3GPP TS 23.204.
In our case we specifically support the procedures of 3GPP TS 23.204 chapter 6.3 and the procedures of 3GPP TS 24.341 chapter 22.214.171.124 (Client), chapter 126.96.36.199.1 and 188.8.131.52 (IP-SM-GW). Boghe acts as a “SM-over-IP sender”.
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 all these specifications do not apply. This means 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.
This feature will be supported in the coming releases.
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.
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 2 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 2 use cases.
© 2011-2015 Doubango Telecom
Inspiring the future