RFC 7702
Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
Pages: 43
Proposed Standard
Proposed Standard
Part 2 of 2 – Pages 25 to 43
6. MSRP Multi-party Messaging Session to XMPP MUC
This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP MUC session. As before, the following diagram outlines the overall protocol flow of a sample session, which includes some optional exchanges (such as sending messages, changing nickname, and inviting another user).
SIP SIP MSRP XMPP
User Proxy Switch Server
| + S2X GW + M2X GW +X2S GW
| | | +X2M GW
| | | |
| (F35) SIP | | |
| INVITE | | |
|****************>| | |
| (F36) SIP | | |
| 200 OK | | |
|<****************| | |
| (F37) SIP ACK | | |
|****************>| | |
| (F38) SIP | | |
| SUBSCRIBE | | |
| Event: | | |
| conference | | |
|****************>| | |
| (F39) SIP | | |
| 200 OK | | |
|<****************| | |
| | (F40) XMPP presence: enter room |
| |..................................>|
| | (F41) XMPP presence |
| |<..................................|
| (F42) SIP | | |
| NOTIFY | | |
|<****************| | |
| (F43) SIP | | |
| 200 OK | | |
|****************>| | |
. . . .
. . . .
| (F44) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F45) XMPP |
| | | groupchat |
| | | message |
| | |................>|
| | | (F46) XMPP |
| | | groupchat |
| | | message |
| | |<................|
| (F47) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (F48) MSRP SEND | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| (F49) MSRP 200 OK | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
| | | (F50) XMPP |
| | | message |
| | |................>|
. . . .
. . . .
| (F51) MSRP NICKNAME | |
|%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%>| |
| | | (F52) XMPP |
| | | presence |
| | |................>|
| | | (F53) XMPP |
| | | presence |
| | | error |
| | |<................|
| (F54) MSRP 425 Error | |
|<%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%| |
. . . .
. . . .
| (F55) SIP REFER | | |
|****************>| | |
| (F56) SIP | | |
| 200 OK | | |
|<****************| | |
| (F57) SIP | | |
| NOTIFY | | |
|<****************| | |
| | (F58) XMPP message invite |
| |..................................>|
. . . .
. . . .
| (F59) SIP BYE | | |
|****************>| | |
| | (F60) XMPP presence unavailable |
| |..................................>|
| | (F61) XMPP presence unavailable |
| |<..................................|
| (F62) SIP | | |
| 200 OK | | |
|<****************| | |
| | | |
If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the conference event, then the server SHOULD cache the participant list until the subscription is established and delivered in a SIP NOTIFY request.6.1. Enter Room
When the SIP user ("Romeo") wants to join a groupchat room ("capulet"), 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 mandatory 'path' and 'chatroom' attributes. Here we assume that Romeo's user agent has been configured to be aware of an MSRP switch (chat.example.org) it can use. The MSRP media line is also accompanied by an 'accept- types' attribute specifying support for a Message/CPIM [RFC3862] top- level wrapper for the MSRP message. Example 27: SIP User Starts Session (F35) | INVITE sip:capulet@rooms.example.com SIP/2.0 | From: "Romeo" <sip:romeo@example.org>;tag=43524545 | To: <sip:capulet@rooms.example.com> | Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 1 INVITE | Content-Type: application/sdp | Content-Length: ... | | c=IN IP4 s2x.example.org | m=message 7313 TCP/MSRP * | a=accept-types:message/cpim text/plain text/html | a=accept-wrapped-types:text/plain text/html | a=path:msrp://chat.example.org:7313/ansp71weztas;tcp | a=chatroom:nickname private-messages Upon receiving the INVITE, the SIP proxy needs to determine the identity of the domain portion of the Request-URI or To header, which it does by following the procedures discussed in [RFC7247]. Here we assume that the SIP proxy has determined that the domain is serviced by an XMPP server, that it contains or has available to it a SIP-to- XMPP gateway or connection manager (which enables it to speak natively to XMPP servers), and that it hands off the message to the gateway. Implementations MAY wait until the nickname is set with an MSRP NICKNAME chunk before joining the XMPP MUC or MAY choose a temporary nickname (such as the SIP From header display name) and use it to join the room. Here we assume the latter.
Example 28: SIP-to-XMPP Gateway ACKs Session (F36) | SIP/2.0 200 OK | From: "Romeo" <sip:romeo@example.org>;tag=43524545 | To: <sip:capulet@rooms.example.com>;tag=a3343df32 | Contact: <sip:rooms.example.com;transport=tcp>;isfocus | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 1 INVITE | Content-Type: application/sdp | | m=message 8763 TCP/MSRP * | a=accept-types:message/cpim text/plain text/html | a=accept-wrapped-types:text/plain text/html | a=path:msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp | a=chatroom:nickname private-messages The SIP/MSRP user agent subscribes to a conference event package at the destination groupchat service. Example 29: Gateway Subscribes to the Conference (F38) | SUBSCRIBE sip:capulet@rooms.example.com SIP/2.0 | To: <sip:capulet@rooms.example.com>;tag=a3343df32 | From: "Romeo" <sip:romeo@example.org>;tag=43524545 | Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 2 SUBSCRIBE | Event: conference | Expires: 600 | Accept: application/conference-info+xml | Allow-Events: conference | Content-Length: 0 After the conference subscription request is acknowledged, the SIP- to-XMPP gateway sends presence from Romeo to the MUC chat room. Example 30: Romeo Enters XMPP Chat Room (F40) | <presence from='romeo@example.org/dr4hcr0st3lup4c' | to='montague@chat.example.org/Romeo'> | <x xmlns='http://jabber.org/protocol/muc'/> | </presence>
6.2. Presence Broadcast
If the MUC service is able to add the SIP/MSRP user to the room, it sends presence from all the existing occupants' room JIDs to the new occupant's full JID, including extended presence information about roles in an <x/> element. Example 31: XMPP Service Sends Presence from Existing Occupants to New Occupant (F41) | <presence from='capulet@rooms.example.com/Romeo' | to='romeo@example.org/dr4hcr0st3lup4c'> | <x xmlns='http://jabber.org/protocol/muc#user'> | <item affiliation='none' role='participant'/> | <status code='110'/> | </x> | </presence> | | <presence from='capulet@rooms.example.com/Ben' | to='romeo@example.org/dr4hcr0st3lup4c'> | <x xmlns='http://jabber.org/protocol/muc#user'> | <item affiliation='none' role='participant'/> | </x> | </presence> | | <presence from='capulet@rooms.example.com/JuliC' | to='romeo@example.org/dr4hcr0st3lup4c'> | <x xmlns='http://jabber.org/protocol/muc#user'> | <item affiliation='none' role='participant'/> | </x> | </presence> Upon receiving these presence stanzas, if the conference focus has already completed the subscription to the conference event package [RFC4575], the XMPP-to-SIP gateway translates them into a SIP NOTIFY request containing the participant list (represented in the conference-info format specified in [RFC4575]).
Example 32: SIP Mapping of XMPP Participant Presence Stanzas (F42) | NOTIFY sip:romeo@example.org SIP/2.0 | To: <sip:romeo@example.org>;tag=43524545 | From: <sip:capulet@rooms.example.com>;tag=a3343df32 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 3 NOTIFY | Event: conference | Subscription-State: active;expires=3600 | Content-Type: application/conference-info+xml | Content-Length: ... | | <conference-info version="0" state="full" | entity="sip:capulet@rooms.example.com"> | <conference-description> | <subject>Today in Verona</subject> | <conf-uris> | <entry> | <uri>tel:+18882934234</uri> | <uri>sip:capulet@rooms.example.com</uri> | </entry> | </conf-uris> | </conference-description> | <users> | <user entity="sip:capulet@rooms.example.com;gr=JuliC" | state="full"> | <display-text>JuliC</display-text> | <roles> | <entry>participant</entry> | </roles> | <endpoint entity="sip:capulet@rooms.example.com;gr=JuliC" | state="full"> | <status>connected</status> | <media id="211835821"> | <type>message</type> | </media> | </endpoint> | </user> | <user entity="sip:capulet@rooms.example.com;gr=Ben" | state="full"> | <display-text>Ben</display-text> | <roles> | <entry>participant</entry> | </roles> | <endpoint entity="sip:capulet@rooms.example.com;gr=Ben" | state="full"> | <status>connected</status> | <media id="211835822">
| <type>message</type> | </media> | </endpoint> | </user> | </users> | </conference-info> Because the "room roster" is communicated in XMPP by means of multiple presence stanzas (one for each participant) whereas the participant list is communicated in SIP by means of a single conference information document, the SIP-to-XMPP gateway will need to keep track of the user's SIP URI and the mapping of that URI into an XMPP address; then, based on that mapping, it will need to determine when it has received a complete room roster from the MUC room, i.e., when it has received the in-room presence of the SIP user (which according to [XEP-0045] is the last presence stanza received in the initial batch sent after joining). Once that happens, the SIP-to- XMPP gateway can construct the conference information document containing the complete participant list and send that to the SIP user.6.3. Exchange 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 MUST be as shown in the following table. (Mappings for elements not mentioned are undefined.) Table 5: Message Syntax Mapping from MSRP Message to XMPP +-----------------------------+-----------------------------+ | CPIM Header |XMPP Element or Attribute | +-----------------------------+-----------------------------+ | To | to | | From | from | | body of the SEND request | <body/> | +-----------------------------+-----------------------------+6.3.1. Send a Message to All Occupants
When Romeo wants to send a message to all other occupants in the room, he sends an MSRP SEND request to <room@service> (<capulet@rooms.example.com> in our example).
The following examples show an exchange of a public message. Example 33: Romeo Sends a Message to the Chat Room (F44) | MSRP a786hjs2 SEND | To-Path: msrp://room.example.com:7313/ansp71weztas;tcp | From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp | Message-ID: 87652492 | Byte-Range: 1-*/* | Content-Type: message/cpim | | To: <sip:capulet@rooms.example.com> | From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c | 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 immediately translates it into an XMPP message stanza and then generates and sends an MSRP response. Example 34: XMPP Mapping of Message (F45) | <message from='romeo@example.org/dr4hcr0st3lup4c' | to='capulet@rooms.example.com' | type='groupchat' | id='8gbx1g4p'> | <body>Romeo is here!</body> | </message> Example 35: MSRP Response to Public Message (F47) | MSRP d93kswow 200 OK | To-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp | From-Path: msrp://chat.example.org:7313/ansp71weztas;tcp | -------d93kswow$ Note well that the XMPP MUC room will reflect the sender's message back to all users, including the sender. The MSRP-to-XMPP gateway SHOULD wait until receiving this reflected message before sending an MSRP 200 OK reply to the original sender.
6.3.2. Send a Private Message
Romeo can send a "private message" to a selected occupant via the chat room service by sending a message to the occupant's room nickname. The following examples show an exchange of a private message. Example 36: Romeo Sends a Private Message (F48) | MSRP a786hjs2 SEND | To-Path: msrp://rooms.example.com:7313/ansp71weztas;tcp | From-Path: msrp://chat.example.org:8763/lkjh37s2s20w2a;tcp | Message-ID: 87652492 | Byte-Range: 1-*/* | Content-Type: message/cpim | | To: <sip:capulet@rooms.example.com>;gr=JuliC | From: "Romeo" <sip:romeo@example.org>;gr=dr4hcr0st3lup4c | DateTime: 2008-10-15T15:02:31-03:00 | Content-Type: text/plain | | I am here!!! | -------a786hjs2$ The MSRP switch is responsible for transforming the 'From' address into an in-room address (not shown). Once the MSRP switch sends that message to the gateway, the gateway is responsible for translating it into XMPP syntax. Example 37: XMPP Mapping of Private Message (F50) | <message from='capulet@rooms.example.com/Romeo' | to='capulet@rooms.example.com/JuliC' | type='chat' | id='rg2ca9k7'> | <body>I am here!!!</body> | </message>6.4. Change Nickname
If Romeo decides to change his nickname within the room, he sends 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 38: MSRP User Changes Nickname (F51) | MSRP a786hjs2 NICKNAME | To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp | From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp | Use-Nickname: "montecchi" | -------a786hjs2 Upon receiving such a message, the MSRP-to-XMPP gateway translates it into an XMPP presence stanza. Example 39: XMPP Mapping of Nickname Change (F52) | <presence from='romeo@example.org/dr4hcr0st3lup4c' | to='capulet@rooms.example.com/montecchi'/> The XMPP server will analyze the nickname allocation and determine if the requested nickname is available. In case the nickname is not available or not usable, the server will generate a presence stanza of type "error" specifying a <conflict/> error condition. Example 40: XMPP Conflict Error for Nickname (F53) | <presence from='capulet@rooms.example.com/Romeo' | to='romeo@example.org/dr4hcr0st3lup4c' | type='error'> | <x xmlns='http://jabber.org/protocol/muc'/> | <error type='cancel' by='capulet@rooms.example.com'> | <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> | </error> | </presence> Upon receiving this stanza, the XMPP-to-MSRP gateway will reply to the NICKNAME request with code 425. Example 41: Gateway Translates XMPP Nickname Conflict to MSRP Error Code (F54) | MSRP a786hjs2 425 Nickname usage failed | To-Path: msrp://chat.example.org:7313/ansp71weztas;tcp | From-Path: msrp://rooms.example.com:8763/lkjh37s2s20w2a;tcp | -------a786hjs26.5. Invite Another User to a Room
If a SIP user wants to invite another user to join the conference he will send a REFER request indicating who needs to be invited in the Refer-To header, as per Section 5.5 of [RFC4579].
Example 42: SIP User Invites Another User (F55) | REFER sip:capulet@rooms.example.com SIP/2.0 | To: <sip:capulet@rooms.example.com>;tag=a3343df32 | From: "Romeo" <sip:romeo@example.org>;tag=5534562 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 4 REFER | Contact: <sip:romeo@example.org>;gr=dr4hcr0st3lup4c | Accept: message/sipfrag | Refer-To: <sip:benvolio@example.com> | Supported: replaces | Content-Length: 0 The SIP-to-XMPP gateway then acknowledges the SIP REFER request with a 200 OK response (step F56). The gateway will then send a NOTIFY request as per [RFC3515] indicating that the invitation is in progress. Since there is no way to know the progress of the invitation until the user has joined, implementations are advised to terminate the REFER dialog subscription upon receiving the first NOTIFY request, with a status code of 100 Trying. Example 43: Progress Notification for Invitation (F56) | NOTIFY sip:romeo@example.org SIP/2.0 | To: <sip:romeo@example.org>;tag=5534562 | From: <sip:capulet@rooms.example.com>;tag=a3343df32 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 5 NOTIFY | Event: refer | Subscription-State: terminated;reason=noresource | Contact: <sip:capulet@rooms.example.com;transport=tcp>;isfocus | Content-Type: message/sipfrag;version=2.0 | Content-Length: ... | | SIP/2.0 100 Trying6.6. Exit Room
If Romeo decides to exit the chat room, his client sends a SIP BYE to the <montague@chat.example.org> chat room.
Example 44: Romeo Terminates Session (F59) | BYE sip:capulet@rooms.example.com SIP/2.0 | Max-Forwards: 70 | From: "Romeo" <sip:romeo@example.org>;tag=5534562 | To: <sip:capulet@rooms.example.com>;tag=a3343df32 | Call-ID: 08CFDAA4-FAED-4E83-9317-253691908CD2 | CSeq: 6 BYE | Content-Length: 0 Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it into a presence stanza of type "unavailable" (F60) and sends it to the XMPP MUC room service. Then, the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user (F62). Example 45: Romeo Exits Chat Room (F60) | <presence from='romeo@example.org/dr4hcr0st3lup4c' | to='capulet@rooms.example.com/Romeo' | type='unavailable'/>7. Handling of Nicknames and Display Names
Fundamental rules for mapping addresses between XMPP and SIP are provided in [RFC7247]. However, chat rooms include a more specialized, unique identifier for each participant in a room, called a "nickname". Implementations SHOULD apply the rules for preparation and comparison of nicknames specified in [RFC7700]. In addition to nicknames, some groupchat implementations also include display names (which might or might not be different from users' nicknames). A display name need not be unique within the context of a room but instead simply provides a user-friendly name for a participant. In the SIP conference event package, the nickname is the value of the Centralized Conferencing (XCON) 'nickname' attribute of the <user/> element [RFC6501] and the display name is the XML character data of the conference-info <display-text/> element [RFC4575]. In XMPP, the nickname is the value of the resourcepart of the occupant JID [XEP-0045] and the display name is the XML character data of the <nick/> element [XEP-0172]. In practice, the <display-text/> element is treated as canonical in SIP implementations, and the <nick/> element is rarely used in XMPP implementations. Therefore, for display purposes, SIP implementations ought to use the <display-text/> element if the XCON
'nickname' attribute is not present, and XMPP implementations ought to use the resourcepart of the occupant JID if the <nick/> element is not present. If there is a conflict between the SIP nickname and the XMPP nickname, the SIP-to-XMPP or XMPP-to-SIP gateway is responsible for adjusting the nickname to avoid the conflict and for informing the SIP or XMPP client of the unique nickname used to join the chat room.8. Message Size
It is possible for MSRP messages to exceed the size allowed by an XMPP service on the far end of an MSRP-to-XMPP gateway; see [RFC7573] for a discussion of this issue.9. Security Considerations
The security considerations of [RFC3261], [RFC4975], [RFC6120], [RFC7247], [RFC7701], and [XEP-0045] apply. This document specifies methods for exchanging groupchat messages through a gateway that translates between SIP and XMPP. Such a gateway MUST be compliant with the minimum security requirements of the protocols for which it translates (i.e., MSRP/SIP and XMPP). The addition of gateways to the security models of MSRP, SIP, and XMPP introduces some new risks. In particular, end-to-end security properties (especially confidentiality and integrity) between user agents that interface through an MSRP-to-XMPP gateway can be provided only if common formats are supported; unfortunately, although [RFC3862] specifies such a format for one-to-one instant messages, the problem of end-to-end security for multi-party messaging has not been solved in a standardized way. Some of the features that are not addressed by the minimal interoperability baseline defined in this document are relevant to security, such as the ability to administer rooms, kick out and ban users, and enable room moderation. Users needing to take advantage of such features cannot do so through a gateway in a standardized manner and therefore will need to use native clients for the relevant protocol (MSRP or XMPP). As mentioned in [RFC7572], there are several possible methods for end-to-end encryption of one-to-one instant messages. Unfortunately, because there is no widely deployed method for end-to-end encryption of multi-party instant messages, this document cannot provide a recommendation in this regard.
10. References
10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, <http://www.rfc-editor.org/info/rfc3261>. [RFC4579] Johnston, A. and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006, <http://www.rfc-editor.org/info/rfc4579>. [RFC4975] Campbell, B., Ed., Mahy, R., Ed., and C. Jennings, Ed., "The Message Session Relay Protocol (MSRP)", RFC 4975, DOI 10.17487/RFC4975, September 2007, <http://www.rfc-editor.org/info/rfc4975>. [RFC5627] Rosenberg, J., "Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)", RFC 5627, DOI 10.17487/RFC5627, October 2009, <http://www.rfc-editor.org/info/rfc5627>. [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, March 2011, <http://www.rfc-editor.org/info/rfc6120>. [RFC6121] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 6121, DOI 10.17487/RFC6121, March 2011, <http://www.rfc-editor.org/info/rfc6121>. [RFC7247] Saint-Andre, P., Houri, A., and J. Hildebrand, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling", RFC 7247, DOI 10.17487/RFC7247, May 2014, <http://www.rfc-editor.org/info/rfc7247>.
[RFC7573] Saint-Andre, P. and S. Loreto, "Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): One-to-One Text Chat Sessions", RFC 7573, DOI 10.17487/RFC7573, June 2015, <http://www.rfc-editor.org/info/rfc7573>. [RFC7700] Saint-Andre, P., "Preparation, Enforcement, and Comparison of Internationalized Strings Representing Nicknames", RFC 7700, DOI 10.17487/RFC7700, December 2015, <http://www.rfc-editor.org/info/rfc7700>. [RFC7701] Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi- party Chat Using the Message Session Relay Protocol (MSRP)", RFC 7701, DOI 10.17487/RFC7701, December 2015, <http://www.rfc-editor.org/info/rfc7701>. [XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, February 2012, <http://www.xmpp.org/extensions/xep-0045.html>.10.2. Informative References
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3515, DOI 10.17487/RFC3515, April 2003, <http://www.rfc-editor.org/info/rfc3515>. [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, DOI 10.17487/RFC3862, August 2004, <http://www.rfc-editor.org/info/rfc3862>. [RFC4353] Rosenberg, J., "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006, <http://www.rfc-editor.org/info/rfc4353>. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006, <http://www.rfc-editor.org/info/rfc4566>. [RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, Ed., "A Session Initiation Protocol (SIP) Event Package for Conference State", RFC 4575, DOI 10.17487/RFC4575, August 2006, <http://www.rfc-editor.org/info/rfc4575>.
[RFC6501] Novo, O., Camarillo, G., Morgan, D., and J. Urpalainen, "Conference Information Data Model for Centralized Conferencing (XCON)", RFC 6501, DOI 10.17487/RFC6501, March 2012, <http://www.rfc-editor.org/info/rfc6501>. [RFC6502] Camarillo, G., Srinivasan, S., Even, R., and J. Urpalainen, "Conference Event Package Data Format Extension for Centralized Conferencing (XCON)", RFC 6502, DOI 10.17487/RFC6502, March 2012, <http://www.rfc-editor.org/info/rfc6502>. [RFC7572] 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", RFC 7572, DOI 10.17487/RFC7572, June 2015, <http://www.rfc-editor.org/info/rfc7572>. [RFC7614] Sparks, R., "Explicit Subscriptions for the REFER Method", RFC 7614, DOI 10.17487/RFC7614, August 2015, <http://www.rfc-editor.org/info/rfc7614>. [RFC7647] Sparks, R. and A. Roach, "Clarifications for the Use of REFER with RFC 6665", RFC 7647, DOI 10.17487/RFC7647, September 2015, <http://www.rfc-editor.org/info/rfc7647>. [XEP-0172] Saint-Andre, P. and V. Mercier, "User Nickname", XSF XEP 0172, March 2012, <http://xmpp.org/extensions/xep-0172.html>. [XEP-0249] Saint-Andre, P., "Direct MUC Invitations", XSF XEP 0249, September 2011, <http://xmpp.org/extensions/xep-0249.html>.
Acknowledgements
Special thanks to Fabio Forno for coauthoring an early draft version of this document and to Ben Campbell for his detailed and insightful reviews. Thanks also to Dave Crocker, Philipp Hancke, Olle Johansson, Paul Kyzivat, and Matt Ryan for their feedback. Leif Johansson reviewed the document on behalf of the Security Directorate. Stephen Farrell, Barry Leiba, Pete Resnick, and Martin Stiemerling provided helpful input during IESG review. The authors gratefully acknowledge the assistance of Markus Isomaki and Yana Stamcheva as the working group Chairs and Gonzalo Camarillo and Alissa Cooper as the sponsoring Area Directors. Peter Saint-Andre wishes to acknowledge Cisco Systems, Inc., for employing him during his work on earlier draft versions of this document.
Authors' Addresses
Peter Saint-Andre &yet Email: peter@andyet.com URI: https://andyet.com/ Saul Ibarra Corretge AG Projects Dr. Leijdsstraat 92 Haarlem 2021RK The Netherlands Email: saul@ag-projects.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland Email: Salvatore.Loreto@ericsson.com