TOC 
Network Working GroupP. Saint-Andre
Internet-DraftCisco
Intended status: InformationalS. Loreto
Expires: September 9, 2009Ericsson
 F. Forno
 Bluendo srl
 March 8, 2009


Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Multi-Party Text Chat
draft-saintandre-sip-xmpp-groupchat-01

Status of this Memo

This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on September 9, 2009.

Copyright Notice

Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.

Abstract

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



Table of Contents

1.  Introduction
    1.1.  Overview
    1.2.  Scope
    1.3.  Formal and Informal Sessions
    1.4.  Gateway Heuristics
    1.5.  Acknowledgements
    1.6.  Discussion Venue
2.  XMPP Group Chat to MSRP Multiparty Instant Message (IM) Session
    2.1.  Entering a Room
    2.2.  Setting up a nickname
    2.3.  Presence Broadcast
    2.4.  Exchanging Messages
        2.4.1.  Sending a Message to All Occupants
        2.4.2.  Sending a Private Message
    2.5.  Exiting a Room
    2.6.  Nickname Conflict
    2.7.  Changing Nickname
3.  MSRP Multiparty Instant Message (IM) Session to XMPP Group Chat
    3.1.  Entering a Room
    3.2.  Presence Broadcast
    3.3.  Exchanging Messages
        3.3.1.  Sending a Message to All Occupants
        3.3.2.  Sending a Private Message
    3.4.  Exiting a Room
    3.5.  Nickname Conflict
    3.6.  Changing Nickname
4.  Security Considerations
5.  References
    5.1.  Normative References
    5.2.  Informative References
§  Authors' Addresses




 TOC 

1.  Introduction



 TOC 

1.1.  Overview

Both the Session Initiation Protocol [SIP] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.) and the Extensible Messaging and Presence Protocol [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) 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 [SIP‑XMPP] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” March 2009.), including mapping of addresses and error conditions. Mappings for single instant messages (sometimes called "pager-mode" messaging) are provided in [SIP‑XMPP‑IM] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging,” March 2009.). Mappings for one-to-one text chat sessions are provided in [SIP‑XMPP‑CHAT] (Saint-Andre, P., Gavita, E., Hossain, N., and S. Loreto, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat,” March 2009.).

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 [MSRP] (Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” September 2007.).

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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [TERMS].



 TOC 

1.2.  Scope

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 [MUC] (Saint-Andre, P., “Multi-User Chat,” July 2008.). 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 [MSRP‑MULTI] (Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” October 2009.).

As in [SIP‑XMPP‑IM] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging,” March 2009.) 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:



 TOC 

1.3.  Formal and Informal Sessions

[TBD] Does XMPP use Formal and Informal session also for group-chat?



 TOC 

1.4.  Gateway Heuristics

[TBD]



 TOC 

1.5.  Acknowledgements

Some text in this document was borrowed from [SIP‑XMPP] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” March 2009.) and from [MUC] (Saint-Andre, P., “Multi-User Chat,” July 2008.).



 TOC 

1.6.  Discussion Venue

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 http://mail.jabber.org/mailman/listinfo/sip-xmpp.



 TOC 

2.  XMPP Group Chat to MSRP Multiparty Instant Message (IM) Session

This section describes how to map an XMPP Group Chat to a Multi-party Instant Message (IM) MSRP session.

                                                  MSRP conference
XMPP User                      GW                       server
    |                          |                          |
    |(F1) (XMPP) Entering a room                          |
    |------------------------->|                          |
    |                          |(F2) (SIP) INVITE         |
    |                          |------------------------->|
    |                          |(F3) (SIP) 200 OK         |
    |                          |<-------------------------|
    |                          |(F4) (SIP) ACK            |
    |                          |------------------------->|
    |                          |                          |
    |                          |(F5) (MSRP) NICKNAME      |
    |                          |------------------------->|
    |                          |(F6) (MSRP) 200 OK        |
    |                          |<-------------------------|
    |                          |                          |
    |                          |(F7) (SIP)SUBSCRIBE       |
    |                          |------------------------->|
    |                          |     Event:conference     |
    |                          |                          |
    |                          |(F8) (SIP) 200 OK         |
    |                          |<-------------------------|
    |                          |                          |
    |                          |(F9) (SIP) NOTIFY         |
    |                          |<-------------------------|
    |                          |(F10) (SIP) 200 OK        |
    |                          |------------------------->|
    |(F11) (XMPP) Presence     |                          |
    |<-------------------------|                          |
    |                          |                          |
    |(F12) (XMPP) A chat message                          |
    |------------------------->|                          |
    |                          |(F13) (MSRP) SEND         |
    |                          |------------------------->|
    |                          |(F14) (MSRP) 200 OK       |
    |                          |<-------------------------|
    |                          |                          |
    |(F15) (XMPP) echo chat message                       |
    |--------------------------|                          |
    .                          .                          .
    .                          .                          .
    |(F16) (XMPP) Exiting a room                          |
    |------------------------->|                          |
    |                          |(F17) (SIP) BYE           |
    |                          |------------------------->|
    |                          |(F18) (SIP) 200 OK        |
    |                          |<-------------------------|


 TOC 

2.1.  Entering a Room

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.

Example: (F1) Juliet entering a chatroom

    <presence from='juliet@example.com'
             to='verona@chat.shakespeare.net/juliet'>
      <x xmlns='http='http://jabber.org/protocol/muc'/>
    </presence>

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 [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.), the XMPP server needs to determine the identity of the remote domain, which it does by performing one or more [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) lookups. For presence stanzas, the order of lookups recommended by [XMPP‑IM] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” October 2004.) is to first try the "_xmpp-server" service as specified in [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) and to then try the "_im" service as specified in [IMP‑SRV] (Peterson, J., “Address Resolution for Instant Messaging and Presence,” August 2004.). 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.

Example: (F2) Juliet entering a chatroom (SIP transformation)

    INVITE sip:verona@chat.shakespeare.net SIP/2.0
    To: <sip:verona@chat.shakespeare.net>
    From: <sip:juliet@example.com>;tag=786
    Call-ID: 711609sa
    Content-Type: application/sdp
    Content-Lenght: [length]

    c=IN IP4 x2s.shakespeare.net
    m=message 7654 TCP/MSRP *
    a=accept-types:text/cpim text/plain text/html
    a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
    a=chatroom:nickname private-message

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 [SIP‑XMPP] (Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” March 2009.), the mapping of XMPP syntax elements to SIP and [SDP] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) syntax elements SHOULD be as shown in the following table. (Mappings for elements not mentioned are undefined.)

Table 1: Message syntax mapping from XMPP to SIP/SDP

    +-----------------------------+-----------------------------+
    |  XMPP Element or Attribute  |  SIP Header or SDP Contents |
    +-----------------------------+-----------------------------+
    |  from                       |  From                       |
    |  to (without the /nick)     |  To                         |
    +-----------------------------+-----------------------------+

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 [MSRP‑MULTI] (Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” October 2009.).

Example: (F3) the chat room accepts the session establishment

  SIP/2.0 200 OK
  To: <sip:verona@chat.shakespeare.net>
  From: <sip:juliet@example.com>;tag=786
  Call-ID: 711609sa
  Contact: <sip:verona@chat.shakespeare.net;transport=tcp>\
           ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY"\
           ;automata;isfocus;message;event="conference"
  Content-Type: application/sdp
  Content-Lenght: [length]

  c=IN IP4 shakespeare.net
  m=message 12763 TCP/MSRP *
  a=accept-types:message/cpim
  a=accept-wrapped-types:text/plain text/html *
  a=path:msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp

Upon receiving such a response, the SIMPLE server or associated SIP-to-XMPP gateway MUST send a SIP ACK to the SIP user.

Example: (F4) the Gateway sends ACK to the chat room server

    ACK sip:verona@chat.shakespeare.net SIP/2.0
    To: <sip:verona@chat.shakespeare.net>;tag=087js
    From: <sip:juliet@example.com>;tag=786
    Call-ID: 711609sa


 TOC 

2.2.  Setting up a nickname

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 [MSRP‑MULTI] (Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” October 2009.)

Example: (F5) the Gateway set up the nickname

    MSRP a786hjs2 NICKNAME
    To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    Use-Nickname: "juliet"
    -------a786hjs2

The chat room server analyzes the existing allocation of nicknames, accepts the nick name proposal and answers with a 200 response.

Example: (F6) the chat room accepts the nickname proposal

    MSRP a786hjs2 200 OK
    To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    -------a786hjs2


 TOC 

2.3.  Presence Broadcast

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 [RFC4575] (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.) 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

Example: (F9) the chat room notifies the presence information

    NOTIFY sip:verona@chat.shakespeare.net SIP/2.0
    To: Juliet <sip:juliet@example.com>;tag=43524545
    From: <sip:verona@chat.shakespeare.net>;tag=a3343df32
    Call-ID: k3l43id034ksereree
    Event: conference
    Subscription-State: active;expires=3600
    Content-Type: application/conference-info+xml
    Content-Length: ...


    <conference-info version="0" state="full"
     entity="sip:3402934234@conf.example.com">
     <conference-description>
      <subject>Today in Verona</subject>
      <conf-uris>
       <entry>
        <uri>tel:+18882934234</uri>
       </entry>
      </conf-uris>
     </conference-description>
     <users>
      <user entity="sip:romeo@example.com" state="full">
       <nickname-text>romeo</nickname-text>
        <roles>
         <entry>participant</entry>
        </roles>
      </user>
     </users>
    </conference-info>

[NOTE: 1]
a full mapping of RFC 4575 will be defined later on.
[NOTE: 2]
the <nickname-text/> attribute is an extension to the conference package explained but not defined in [MSRP‑MULTI] (Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” October 2009.)
[NOTE: 3]
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

[OPEN ISSUE: 1]
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.

Example: (F11) the chat room presence information translated in XMPP

    <presence from='romeo@example.com/romeo'
     to='verona@chat.shakespeare.net/juliet'>
     <x xmlns='http://jabber.org/protocol/muc#user'>
      <item affiliation='none' role='participant'/>
     </x>
    </presence>

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

Table 2: Message syntax mapping from SIP/SDP to XMPP

    +-----------------------------+-----------------------------+
    | SIP Header or SDP Contents  | XMPP Element or Attribute   |
    +-----------------------------+-----------------------------+
    |  <user entity=...>          |  From                       |
    |  To + / <nickname-text>     |  To                         |
    |  roles                      |  role                       |
    |  'none'                     |  affiliation                |
    +-----------------------------+-----------------------------+

[OPEN ISSUE: 1]
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).


 TOC 

2.4.  Exchanging Messages

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

Table 3: Message syntax mapping from XMPP Message to MSRP

    +-----------------------------+-----------------------------+
    |  XMPP Element or Attribute  |  CPIM Header                |
    +-----------------------------+-----------------------------+
    |  to                         |  To                         |
    |  from                       |  From                       |
    |  <body/>                    |  body of the SEND request   |
    +-----------------------------+-----------------------------+


 TOC 

2.4.1.  Sending a Message to All Occupants

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.

Example: (F12) Juliet sends a Message to all occupants

    <message from='juliet@example.com'
              to='verona@chat.shakespeare.net'
              type='groupchat'>
          <body>Who knows where Romeo is?</body>
    </message>

Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it in an MSRP SEND message.

Example: (F13) Gateway transforms XMPP message to MSRP

    MSRP a786hjs2 SEND
    To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    Message-ID: 87652491
    Byte-Range: 1-*/*
    Content-Type: message/cpim

    To: <sip:verona@chat.shakespeare.net;transport=tcp>
    From: <sip:juliet@example.com>
    DateTime: 2008-10-15T15:02:31-03:00
    Content-Type: text/plain

    Who knows where Romeo is?
    -------a786hjs2$

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.

    MSRP d93kswow 200 OK
    To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    -------d93kswow$

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 [MUC] (Saint-Andre, P., “Multi-User Chat,” July 2008.) 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.



 TOC 

2.4.2.  Sending a Private 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.

Example: (F12) Juliet sends a private message

    <message from='juliet@example.com'
              to='verona@chat.shakespeare.net/romeo'
              type='chat'/>
          <body>O Romeo, Romeo! wherefore art thou Romeo?</body>
    </message>

Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it in an MSRP SEND message.

Example: (F13) Gateway transforms XMPP message to MSRP

    MSRP a786hjs2 SEND
    To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    Message-ID: 87652491
    Byte-Range: 1-*/*
    Content-Type: message/cpim

    To: <sip:romeo@chat.shakespeare.net>
    From: <sip:juliet@chat.shakespeare.net>
    DateTime: 2008-10-15T15:02:31-03:00
    Content-Type: text/plain

    O Romeo, Romeo! wherefore art thou Romeo?
    -------a786hjs2$


 TOC 

2.5.  Exiting a Room

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.

Example: (F16) Juliet exiting a chatroom

    <presence from='juliet@example.com'
             to='verona@chat.shakespeare.net/juliet'
             type='unavailable'>
    </presence>

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"

Example: (F16) Juliet exiting a chatroom

    <presence from='juliet@example.com'
             to='verona@chat.shakespeare.net/juliet'
             type='unavailable'>
      <status>I can not chat now!</status>
    </presence>

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.



 TOC 

2.6.  Nickname Conflict

                                                  MSRP conference
XMPP User                      GW                       server
    |                          |                          |
    |(F1) (XMPP) Entering a room                          |
    |------------------------->|                          |
    |                          |(F2) (SIP) INVITE         |
    |                          |------------------------->|
    |                          |(F3) (SIP) 200 OK         |
    |                          |<-------------------------|
    |                          |(F4) (SIP) ACK            |
    |                          |------------------------->|
    |                          |                          |
    |                          |(F5) (MSRP) NICKNAME      |
    |                          |------------------------->|
    |                          |(F6) (MSRP) 423 OK        |
    |                          |<-------------------------|
    |                          |                          |
    |(F7) (XMPP) Presence Error
    |<-------------------------|                          |
    .                          .                          .
    |                          |(F8) (SIP) BYE            |
    |                          |------------------------->|
    |                          |(F9) (SIP) 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.

Example: (F6) the chat room does not accept the nickname proposal

    MSRP a786hjs2 423 Nickname usage failed
    To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
    From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
    -------a786hjs2

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.

Example: (F7) Juliet sends a Message to all occupants

    <presence from='verona@chat.shakespeare.net'
              to='juliet@example.com'
              type='error'>
      <x xmlns='http='http://jabber.org/protocol/muc'/>
      <error type='cancel'>
        <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
      </error>
    </presence>


 TOC 

2.7.  Changing Nickname

                                                  MSRP conference
XMPP User                      GW                       server
    |                          |                          |
    |(F1) (XMPP) Presence changing Nickname               |
    |------------------------->|                          |
    |                          |(F2) (MSRP) NICKNAME      |
    |                          |------------------------->|
    |                          |(F3) (MSRP) 200 OK        |
    |                          |<-------------------------|

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.

Example: (F1) Juliet changing the nickname

    <presence from='juliet@example.com'
             to='verona@chat.shakespeare.net/July'>
    </presence>



 TOC 

3.  MSRP Multiparty Instant Message (IM) Session to XMPP Group Chat

This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP Group Chat.

                                                    XMPP Chat
SIP User                     GW                       room
   |                         |                          |
   |(F1)(SIP) INVITE         |                          |
   |------------------------>|                          |
   |(F2) (SIP) 200 OK        |                          |
   |<------------------------|                          |
   |(F3) (SIP) ACK           |                          |
   |------------------------>|                          |
   |                         |                          |
   |(F4) (MSRP) NICKNAME     |                          |
   |------------------------>|                          |
   |                         |(F5)(XMPP) Entering a room|
   |                         |------------------------->|
   |(F6) (MSRP) 200 OK       |                          |
   |<------------------------|                          |
   |                         |(F7)(XMPP) (XMPP) Presence|
   |                         |<-------------------------|
   |(ISSUE)how to handle F7  |                          |
   |    if the user has not  |                          |
   |    yet SUBSCRIBE to     |                          |
   |    Event: conference    |                          |
   |                         |                          |
   |(F8)(SIP) SUBSCRIBE      |                          |
   |------------------------>|                          |
   |     Event:conference    |                          |
   |                         |                          |
   |(F9) (SIP) 200 OK        |                          |
   |<------------------------|                          |
   |                         |                          |
   |(F10) (SIP) NOTIFY       |                          |
   |<------------------------|                          |
   |(F11) (SIP) 200 OK       |                          |
   |------------------------>|                          |
   |                         |                          |
   |(F12)(MSRP) SEND         |                          |
   |------------------------>|                          |
   |                         |(F13)(XMPP) A chat message|
   |(F14)(MSRP) 200 OK       |------------------------->|
   |<------------------------|(F15)(XMPP) A chat message|
   |                         |<-------------------------|
   |(F16)(MSRP) SEND         |                          |
   |<------------------------|                          |
   |(F17)(MSRP) 200 OK       |                          |
   |------------------------>|                          |
   .                         .                          .
   .                         .                          .
   |                         |                          |
   |(F18)(SIP) BYE           |                          |
   |------------------------>|                          |
   |                         |(F19)(XMPP) Exiting a room|
   |                         |------------------------->|
   |(F20)(SIP) 200 OK        |                          |
   |<------------------------|                          |


 TOC 

3.1.  Entering a Room

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.

Example: (F1) SIP user starts the session

    INVITE sip:verona@chat.shakespeare.net SIP/2.0
    To: <sip:verona@chat.shakespeare.net>
    From: <sip:romeo@example.com>;tag=786
    Call-ID: 742510no
    Content-Type: application/sdp
    Content-Lenght: [length]

    c=IN IP4 s2x.example.net
    m=message 7313 TCP/MSRP *
    a=accept-types:message/cpim text/plain text/html
    a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    a=chatroom:nickname private-message

[OPEN ISSUE: 1]
[MSRP‑MULTI] (Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” October 2009.) 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 session

Upon 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 [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.). 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 [IMP‑SRV] (Peterson, J., “Address Resolution for Instant Messaging and Presence,” August 2004.) 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 [XMPP] (Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) 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.

  SIP/2.0 200 OK
  To: <sip:verona@chat.shakespeare.net>
  From: <sip:romeo@example.com>;tag=786
  Contact: <sip:x2s.example.com;transport=tcp> \
           ;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY"\
           ;automata;isfocus;message;event="conference"
  Call-ID: 742510no
  Content-Type: application/sdp

  c=IN IP4 x2s.example.com
  m=message 8763 TCP/MSRP *
  a=accept-types:message/cpim text/plain text/html
  a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp

[OPEN ISSUE: 1]
the GW could use a temporary nick name and translate directly the request into a XMPP presence stanza, entering the XMPP chat room

Example: (F4) the MSRP user set up the nickname

    MSRP a786hjs2 NICKNAME
    To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    Use-Nickname: "romeo"
        -------a786hjs2

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

Example: (F5) Romeo entering a chatroom

    <presence from='romeo@example.com'
             to='verona@chat.shakespeare.net/romeo'>
      <x xmlns='http='http://jabber.org/protocol/muc'/>
    </presence>

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

Example: (F6)

    MSRP a786hjs2 200 OK
    To-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    From-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
        -------a786hjs2


 TOC 

3.2.  Presence Broadcast

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.

Example: (F7) the chat room presence information translated in XMPP

    <presence from='verona@chat.shakespeare.net/juliet'
     to='juliet@example.com'>
     <x xmlns='http://jabber.org/protocol/muc#user'>
      <item affiliation='none' role='participant'/>
     </x>
    </presence>

Upon receiving such a response, if the MSRP has already complited the subscription to the Conference Event package [RFC4575] (Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” August 2006.), the XMPP-to-SIP gateway MUST translate it in a SIP NOTIFY request.

Example: (F10) the XMPP-to-SIP notifies the presence information

    NOTIFY sip:romeo@example.com SIP/2.0
    To: Juliet <sip:romeo@example.com>;tag=43524545
    From: <sip:verona@chat.shakespeare.net>;tag=a3343df32
    Call-ID: k3l43id034ksererff
    Event: conference
    Subscription-State: active;expires=3600
    Content-Type: application/conference-info+xml
    Content-Length: ...


    <conference-info version="0" state="full"
     entity="sip:3402934234@conf.example.com">
     <conference-description>
      <subject>Today in Verona</subject>
      <conf-uris>
       <entry>
        <uri>tel:+18882934234</uri>
       </entry>
      </conf-uris>
     </conference-description>
     <users>
      <user entity="sip:juliet@example.com" state="full">
       <nickname-text>juliet</nickname-text>
        <roles>
         <entry>participant</entry>
        </roles>
      </user>
     </users>
    </conference-info>



 TOC 

3.3.  Exchanging Messages

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

Table 4: Message syntax mapping from MSRP Message to XMPP

    +-----------------------------+-----------------------------+
    |  CPIM Header                |XMPP Element or Attribute    |
    +-----------------------------+-----------------------------+
    |  To                         |  to                         |
    |  From                       |  from                       |
    |  body of the SEND request   |  <body/>                    |
    +-----------------------------+-----------------------------+


 TOC 

3.3.1.  Sending a Message to All Occupants

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

Example: (F12) ROMEO sends a message to the chat room

    MSRP a786hjs2 SEND
    To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    Message-ID: 87652492
    Byte-Range: 1-*/*
    Content-Type: message/cpim

    To: <sip:verona@chat.shakespeare.net;transport=tcp>
    From: <sip:juliet@example.com>
    DateTime: 2008-10-15T15:02:31-03:00
    Content-Type: text/plain

    Romeo is here!
    -------a786hjs2$

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.

Example: (F13) Romeo sends a Message to all occupants

    <message from='romeo@example.com'
              to='verona@chat.shakespeare.net'
              type='groupchat'>
          <body>Romeo is here!</body>
    </message>

Example: (F14) the SIP-to-XMPP send the MSRP response

    MSRP d93kswow 200 OK
    To-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    From-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    -------d93kswow$

[OPEN ISSUE: 1]
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?


 TOC 

3.3.2.  Sending a Private Message

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.

Example: (F12) Romeo sends a private message

    MSRP a786hjs2 SEND
    To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    Message-ID: 87652492
    Byte-Range: 1-*/*
    Content-Type: message/cpim

    To: <sip:juliet@chat.shakespeare.net>
    From: <sip:romeo@example.com>
    DateTime: 2008-10-15T15:02:31-03:00
    Content-Type: text/plain

    I am here!!!
    -------a786hjs2$

Example: (F13) Juliet sends a private message

    <message from='romeo@example.com'
              to='verona@chat.shakespeare.net/juliet'
              type='chat'/>
          <body>I am here!!!</body>
    </message>


 TOC 

3.4.  Exiting a Room

If Romeo decides to exit the multi-user chat room, his client sends SIP BYE to the <verona@chat.shakespeare.net> chat room.

Example: (F11) Romeo terminates the session

    BYE sip:verona@chat.shakespeare.net SIP/2.0
    Max-Forwards: 70
    From: <sip:romeo@example.net>;tag=786
    To: <sip:verona@chat.shakespeare.net>;tag=534
    Call-ID: 742510no
    Cseq: 1 BYE
    Content-Length: 0

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.

Example: (F19) Juliet exiting a chatroom

    <presence from='romeo@example.com'
             to='verona@chat.shakespeare.net/romeo'
             type='unavailable'>
    </presence>


 TOC 

3.5.  Nickname Conflict

                                                  XMPP conference
SIP User                      GW                       server
   |                         |                          |
   |(F1)(SIP) INVITE         |                          |
   |------------------------>|                          |
   |(F2) (SIP) 200 OK        |                          |
   |<------------------------|                          |
   |(F3) (SIP) ACK           |                          |
   |------------------------>|                          |
   |                         |                          |
   |(F4) (MSRP) NICKNAME     |                          |
   |------------------------>|                          |
   |                         |(F5)(XMPP) Entering a room|
   |                         |------------------------->|
   |                         |(F7) (XMPP) Presence Error|
   |                         |<-------------------------|
   |(F6) (MSRP) 423 OK       |                          |
   |<------------------------|                          |
   |                         |                          |



 TOC 

3.6.  Changing Nickname

                                                  XMPP conference
SIP User                      GW                       server
    |                          |                          |
    |(F1) (MSRP) NICKNAME      |                          |
    |------------------------->|                          |
    |                          |(F2) (XMPP) Presence w/ Nickname
    |                          |------------------------->|
    |(F3) (MSRP) 200 OK        |                          |
    |<-------------------------|                          |

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.

Example: (F1) the MSRP user changes the nickname

    MSRP a786hjs2 NICKNAME
    To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
    From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
    Use-Nickname: "montecchi"
        -------a786hjs2

Upon receiving such message, the SIP-to-XMPP gateway MUST translate it in a XMPP presence stanza.

Example: (F2) Juliet changing the nickname

    <presence from='juliet@example.com'
             to='verona@chat.shakespeare.net/montecchi'>
    </presence>



 TOC 

4.  Security Considerations

To follow.



 TOC 

5.  References



 TOC 

5.1. Normative References

[IMP-SRV] Peterson, J., “Address Resolution for Instant Messaging and Presence,” RFC 3861, August 2004 (TXT).
[MSRP] Campbell, B., Mahy, R., and C. Jennings, “The Message Session Relay Protocol (MSRP),” RFC 4975, September 2007 (TXT).
[MUC] Saint-Andre, P., “Multi-User Chat,” XSF XEP 0045, July 2008.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” RFC 3261, June 2002 (TXT).
[TERMS] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML).
[XMPP] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Core,” RFC 3920, October 2004 (TXT, HTML, XML).
[XMPP-IM] Saint-Andre, P., Ed., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” RFC 3921, October 2004 (TXT, HTML, XML).


 TOC 

5.2. Informative References

[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” RFC 2782, February 2000 (TXT).
[MSRP-MULTI] Niemi, A., Garcia-Martin, M., and G. Sandbakken, “Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP),” draft-ietf-simple-chat-03 (work in progress), October 2009 (TXT).
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, “A Session Initiation Protocol (SIP) Event Package for Conference State,” RFC 4575, August 2006 (TXT).
[SDP] Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” RFC 4566, July 2006 (TXT).
[SIP-XMPP] Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core,” draft-saintandre-sip-xmpp-core-01 (work in progress), March 2009 (TXT).
[SIP-XMPP-CHAT] Saint-Andre, P., Gavita, E., Hossain, N., and S. Loreto, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat,” draft-saintandre-sip-xmpp-chat-03 (work in progress), March 2009 (TXT).
[SIP-XMPP-IM] Saint-Andre, P., Houri, A., and J. Hildebrand, “Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging,” draft-saintandre-sip-xmpp-im-01 (work in progress), March 2009 (TXT).


 TOC 

Authors' Addresses

  Peter Saint-Andre
  Cisco
Email:  psaintan@cisco.com
  
  Salvatore Loreto
  Ericsson
  Hirsalantie 11
  Jorvas 02420
  Finland
Email:  Salvatore.Loreto@ericsson.com
  
  Fabio Forno
  Bluendo srl
  Via Morosini 10
  Torino 10128
  Italy
Email:  fabio@bluendo.com