Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Multi-Party Text ChatCiscopsaintan@cisco.comEricssonHirsalantie 1102420JorvasFinlandSalvatore.Loreto@ericsson.comBluendo srlVia Morosini 1010128TorinoItalyfabio@bluendo.com
RAI
Text ChatInstant MessagingSession Initiation ProtocolSIPMessage Sessions Relay ProtocolMSRPExtensible Messaging and Presence ProtocolXMPPThis document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a many-to-many chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).Both the Session Initiation Protocol and the Extensible Messaging and Presence Protocol can be used for the purpose of many-to-many text chat over the Internet. To ensure interworking between these technologies, it is important to define bi-directional protocol mappings.The architectural assumptions underlying such protocol mappings are provided in , including mapping of addresses and error conditions. Mappings for single instant messages (sometimes called "pager-mode" messaging) are provided in . Mappings for one-to-one text chat sessions are provided in . This document specifies mappings for many-to-many text chat sessions (sometimes called "groupchat"); in particular, this document specifies mappings between XMPP and the Message Session Relay Protocol .Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.Both XMPP and SIP/SIMPLE technologies enable multi-user text chat, whereby users can exchange messages in the context of a room. The term "room" usually is a synonym for a virtual environment where people enter and exchange messages.Groupchat messages are messages which are sent from a sender to multiple recipients (i.e., two or more) in the context of a "multi-user chat session", "text conference", or "chatroom". In XMPP a groupchat message is a <message/> stanza of type "groupchat" that is reflected from the sender to multiple recipients by a multi-user chat service, as defined in . In SIP/SIMPLE a groupchat message is reflected from the sender to multiple recipients by a conference server that uses MSRP to handle groupchat sessions, as defined in .As in and related documents, the approach taken here is to directly map syntax and semantics from one protocol to another. The mapping described herein depends on the protocols defined in the following specifications:XMPP chat sessions using message stanzas of type "groupchat" are specified in .SIP-based chat room sessions using the SIP INVITE and SEND request types are specified in .[TBD] Does XMPP use Formal and Informal session also for group-chat?[TBD]Some text in this document was borrowed from and from .The authors welcome discussion and comments related to the topics presented in this document. The preferred forum is the <sip-xmpp@xmpp.org> mailing list, for which archives and subscription information are available at .This section describes how to map an XMPP Group Chat to a Multi-party Instant Message (IM) MSRP session.When the XMPP user ("Juliet") wants to join a multi-user chat room ("Verona"), she sends a <presence/> stanza to the hostname hosting that chat room, she also specifies the "nick" she desires to use within the room ("juliet"). The Room Nickname is the resource identifier portion of a Room JID. The Juliet client SHOULD signal its ability to speak the multi-user chat protocol by including in the initial presence stanza an empty <x/> element qualified by the
'http://jabber.org/protocol/muc' namespace.Upon receiving such a presence stanza, the XMPP server to which Juliet has authenticated attempts to deliver the stanza to a local domain or attempts to route the presence stanza to the remote domain that services the hostname in the 'to' attribute. Naturally, in this document we assume that the hostname in the 'to' attribute is an Chat Room-aware SIP service hosted by a separate server.As specified in , the XMPP server needs to determine the identity of the remote domain, which it does by performing one or more lookups. For presence stanzas, the order of lookups recommended by is to first try the "_xmpp-server" service as specified in and to then try the "_im" service as specified in . Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.shakespeare.net", since we have already assumed that the shakespeare.net hostname is running a SIP instant messaging service. (Note: The XMPP server may have previously determined that the remote domain is a SIMPLE server, in which case it would not need to perform the SRV lookups; the caching of such information is a matter of implementation and local service policy, and is therefore out of scope for this document.)Once the XMPP server (example.com) has determined that the remote domain is serviced by a SIMPLE server, it hands the XMPP presence stanza off to its local XMPP-to-SIP gateway (x2s.example.com), which transforms the presence stanza into SIP syntax and routes it to the remote conference server (shakespeare.net).As a compliant multi-user chat services MUST accept the presence stanza containing an empty <x/> element qualified by the
'http://jabber.org/protocol/muc' namespace as a request to enter a room; the XMPP-to-SIP gateway MUST transform it in a SIP INVITE request.
Here the Session Description Protocol offer specifies the MSRP-aware XMPP-to-SIP gateway on the XMPP side as well as other particulars of the session.There is no direct mapping for the MSRP URIs. In fact MSRP URIs identify a session of instant messages at a particular device; they are ephemeral and have no meaning outside the scope of that session. The authority component of the MSRP URI MUST contain the XMPP-to-SIP gateway hostname or numeric IP address and an explicit port number.As specified in , the mapping of XMPP syntax elements to SIP and syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)Here we assume that the chat room server accepts the session establishment. It includes the 'isfocus' and other relevant feature tags in the Contact header field of the response. The chat room server also includes an answer session description that acknowledges the choice of media and contains the extensions specified in .Upon receiving such a response, the SIMPLE server or associated SIP-to-XMPP gateway MUST send a SIP ACK to the SIP user.If the chat room server accepted the session, the SIMPLE server or associated SIP-to-XMPP gateway MUST set up the nickname as received in the presence stanza. The nickname is set up using the extension specified in The chat room server analyzes the existing allocation of nicknames, accepts the nick name proposal and answers with a 200
response.If the multi-user chat service accepts the request to enter a room, the xmpp user expects to receive back presence
information from all the existing occupants' room. So the XMPP-to-SIP gateway MUST SUBSCRIBE to the Conference Event
package on the MSRP conference server. When the subscription is completed the MSRP conference
server send back to the XMPP-to-SIP gateway a NOTIFY with the presence information from all the existing occupants' room a full mapping of RFC 4575 will be defined later on. the <nickname-text/> attribute is an extension to the conference package
explained but not defined in the subject (if present in the NOTIFY) must be sent with a separate <message/> stanza;
so after F11 there should be another <message/> stanza from the gw to the joining party how to send to the room jid with the subject child set: do we need to send it in a different presence stanza
that the F11? Upon receiving such a response, the SIP-to-XMPP gateway MUST send a 200 OK to the MSRP conference server and
translate it in an xmpp presence stanza.As specified in ???, the mapping of SIP and SDP syntax elements to XMPP syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.) how to match the <roles/> SIP Conference attribute in the XMPP
<affiliation/> and <role/>. In XMPP roles are current privileges within the room while, affiliations
are kept permanently in different sessions (they are the default for a given user).Once the user has joined the chat room, the user can exchange an unbounded number of messages both public and private.The mapping of XMPP syntax elements to MSRP syntax elements SHOULD be as shown in the following table.
(Mappings for elements not mentioned are undefined.)When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to
<room@service> itself (i.e. <verona@chat.shakespeare.net> in our example).The following examples show an exchange of a public message.Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it in an MSRP SEND message.Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes"
or does not contain a Failure-Report header at all, MSRP conference server MUST immediately generate and send
a response.Since the XMPP room could be moderated and an XMPP User can not be sure whether his message has been accepted
or not, without an echo from the server, the states that the sender have to receive back the
same message it has generated. So in this scenario the XMPP-to-SIP gateway has to generate the echo message.Since each occupant has a unique JID, Juliet MAY send a "private message" to a selected occupant via the
service by sending a message to the occupant's room JID. The message type SHOULD be "chat" and MUST NOT be
"groupchat", but MAY be left unspecified.The following examples show an exchange of a private message.Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it in an MSRP SEND message.If Juliet decides to exit the multi-user chat room, her client sends a presence stanza of type "unavailable" to the <verona@chat.shakespeare.net/juliet> she is currently using in the room.Upon receiving such stanza exiting the multi-user chat room, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to MSRP conference server. The MSRP conference server then responds with a 200 OK.Juliet MAY include a custom exit message in the presence stanza of type "unavailable"Upon receiving such stanza exiting the multi-user chat room, the XMPP-to-SIP gateway MUST before delivering the message and then, after the message is successfully delivered, it terminates the SIP session by sending a SIP BYE to MSRP conference server. The MSRP conference server then responds with a 200 OK.The chat room server analyzes the existing allocation of nicknames, and detects that the nickname proposal
is already provided to another partecipant by the conference. In this case the MSRP conference server answers
with a 423 response. Upon receiving such a response, the SIP-to-XMPP gateway MUST translate it in an xmpp presence stanza of type "error"
specifying a <conflict/> error condition.If Juliet decides to changing her nickname within the room, she SHOULD send an update presence information to the room,
specifically she SHOULD send a new Nickname in the same room.This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP Group Chat.When the MSRP user ("Romeo") wants to join a multi-user chat room ("Verona"), he first has to start the SIP session by sending out
a SIP INVITE request containing an offered session description that includes an MSRP media line accompanied by a mandatory "path" and
"chatroom" attributes. The MSRP media line is also accompanied by an "accept-types" attribute specifing support for a Message/CPIM top
level wrapper for the MSRP message. does not say anything abouth the inclusion of the SDP "chatroom" attribute in the INVITE
however that is the only way for a GW to understand the the INVITE is establishing a group-chat sessionUpon receiving the INVITE, the SIP-to-XMPP gateway needs to determine the identity of the remote domain, which it does by
performing one or more DNS SRV lookups . The SIP-to-XMPP gateway SHOULD resolve the address present in the
To header of the INVITE to an im URI, then follow the rules in regarding the "_im" SRV service for the
target domain contained in the To header. If SRV address resolution fails for the "_im" service, the SIP-to-XMPP gateway MAY attempt
a lookup for the "_xmpp-server" service as specified in or MAY return an error to the sender (i.e. 502 Bad
Gateway).If SRV address resolution succeeds, the SIP-to-XMPP gateway SHOULD answer successfuly with a SIP 200 OK (F2), but it MUST not
yet translate the request into an XMPP presece stanza before the MSRP user set up the nickname.the GW could use a temporary nick name and translate directly the request into a XMPP presence stanza, entering the XMPP
chat roomUpon receiving the MSRP NICKNAME request, the SIP-to-XMPP gateway is responsible to generate an XMPP presence stanza and
sending it to the hostname hosting that chat room.If the room does not already contain another user with the nickname, the service accept the access. So if the GW does not
receive any stanza of type "error" specifying a <conflict/> error condition, it MUST answer the MSRP nickname proposal
with a 200 OK response (F6).If the multi-user chat service is able to add the user to the room, it sends presence from all the existing occupants' room
JIDs to the new occupants's full JID, including extended presence information about roles in an <x/> element. Upon receiving such a response, if the MSRP has already complited the subscription to the Conference Event package
, the XMPP-to-SIP gateway MUST translate it in a SIP NOTIFY request.Once the user has joined the chat room, the user can exchange an unbounded number of messages both public and private.The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be as shown in the following table.
(Mappings for elements not mentioned are undefined.)When Romeo wants to sends a message to all other occupants in the room, he sends a MSRP SEND request to
<room@service> itself (i.e. <verona@chat.shakespeare.net> in our example).Upon receiving the SEND request, if the request either contains a Failure-Report header field value of "yes"
or does not contain a Failure-Report header at all, the SIP-to-XMPP gateway MUST immediately translate in a xmpp message stanza (F13)
and then generate and send an MSRP response (F14).The following examples show an exchange of a public message.The SIP-to-XMPP gateway will receive back the echo message from the Chat room service. The SIP-to-XMPP gateway
has to translate it back to the MSRP user or no?Romeo MAY send a "private message" to a selected occupant via the chat room service by sending a message
to the occupant's room nick name.The following examples show an exchange of a private message.If Romeo decides to exit the multi-user chat room, his client sends SIP BYE to the <verona@chat.shakespeare.net>
chat room.Upon receiving the SIP BYE, the SIP-to-XMPP gateway translate it in a presence stanza (F19) and send it to the XMPP chat room
service. Then the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user.If Romeo decides to changing her nickname within the room, he SHOULD send a
new MSRP NICKNAME request. In fact modification of the nickname in MSRP is
not different from the initial reservation and usage of a nickname.Upon receiving such message, the SIP-to-XMPP gateway MUST translate it in a XMPP presence stanza.To follow.The Message Session Relay Protocol (MSRP)This document describes the Message Session Relay Protocol, a protocol for transmitting a series of related instant messages in the context of a session. Message sessions are treated like any other media stream when set up via a rendezvous or session creation protocol such as the Session Initiation Protocol. [STANDARDS TRACK]Address Resolution for Instant Messaging and PresencePresence and instant messaging are defined in RFC 2778. The Common Profiles for Presence and Instant Messaging define two Universal Resource Identifier (URI) schemes: 'im' for INSTANT INBOXes and 'pres' for PRESENTITIES. This document provides guidance for locating the resources associated with URIs that employ these schemes. [STANDARDS TRACK] SIP: Session Initiation ProtocolThis document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS TRACK] Multi-User Chatstpeter@jabber.orgKey words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
Extensible Messaging and Presence Protocol (XMPP): CoreJabber Software Foundationstpeter@jabber.org
Applications
XMPP Working GroupRFCRequest for CommentsI-DInternet-DraftXMPPExtensible Messaging and Presence ProtocolJabberIMInstant MessagingPresenceXMLExtensible Markup LanguageThis memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and PresenceJabber Software Foundationstpeter@jabber.org
Applications
XMPP Working GroupRFCRequest for CommentsI-DInternet-DraftXMPPExtensible Messaging and Presence ProtocolJabberIMInstant MessagingPresenceXMLExtensible Markup LanguageThis memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.A DNS RR for specifying the location of services (DNS SRV)Troll TechWaldemar Thranes gate 98BOsloN-0175NO+47 22 806390+47 22 806380arnt@troll.noInternet Software Consortium950 Charter StreetRedwood CityCA94063US+1 650 779 7001Microsoft CorporationOne Microsoft WayRedmondWA98052USlevone@microsoft.comThis document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)The Message Session Relay Protocol (MSRP) defines a mechanism for sending instant messages within a peer-to-peer session, negotiated using the Session Initiation Protocol (SIP) and the Session Description Protocol (SDP). This document defines the necessary tools for establishing multi-party instant messaging (IM) sessions, or chat rooms, with MSRP.SDP: Session Description ProtocolThis memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS TRACK]Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): CoreAs a foundation for the definition of application-specific, bi-directional protocol mappings between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP), this document specifies the architectural assumptions underlying such mappings as well as the mapping of addresses and error conditions.Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text ChatThis document defines a bi-directional protocol mapping for the exchange of instant messages in the context of a one-to-one chat session between a user of the Session Initiation Protocol (SIP) and a user of the Extensible Messaging and Presence Protocol (XMPP). Specifically for SIP text chat, this document specifies a mapping to the Message Session Relay Protocol (MSRP).Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant MessagingThis document defines a bi-directional protocol mapping for the exchange of single instant messages between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP).A Session Initiation Protocol (SIP) Event Package for Conference StateThis document defines a conference event package for tightly coupled conferences using the Session Initiation Protocol (SIP) events framework, along with a data format used in notifications for this package. The conference package allows users to subscribe to a conference Uniform Resource Identifier (URI). Notifications are sent about changes in the membership of this conference and optionally about changes in the state of additional conference components. [STANDARDS TRACK]