One document matched: draft-saintandre-sip-xmpp-groupchat-03.xml
<?xml version="1.0" encoding="us-ascii"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc sortrefs="yes"?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<rfc category="std" docName="draft-saintandre-sip-xmpp-groupchat-03" ipr="trust200902">
<front>
<title abbrev="SIP-XMPP Interworking: Groupchat">Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>1899 Wynkoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<author initials="S." surname="Loreto" fullname="Salvatore Loreto">
<organization>Ericsson</organization>
<address>
<postal>
<street>Hirsalantie 11</street>
<code>02420</code>
<city>Jorvas</city>
<country>Finland</country>
</postal>
<email>Salvatore.Loreto@ericsson.com</email>
</address>
</author>
<author initials="S." surname="Ibarra" fullname="Saul Ibarra Corretge">
<organization>AG Projects</organization>
<address>
<postal>
<street>Dr. Leijdsstraat 92</street>
<code>2021RK</code>
<city>Haarlem</city>
<country>The Netherlands</country>
</postal>
<email>saul@ag-projects.com</email>
</address>
</author>
<author initials="F." surname="Forno" fullname="Fabio Forno">
<organization>Bluendo srl</organization>
<address>
<postal>
<street>Via Morosini 10</street>
<code>10128</code>
<city>Torino</city>
<country>Italy</country>
</postal>
<email>fabio@bluendo.com</email>
</address>
</author>
<date/>
<area>RAI</area>
<keyword>Text Chat</keyword>
<keyword>Groupchat</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Session Initiation Protocol</keyword>
<keyword>SIP</keyword>
<keyword>Message Sessions Relay Protocol</keyword>
<keyword>MSRP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>This document defines a bidirectional protocol mapping for the exchange of instant messages in the context of a multiparty chat session among users of the Session Initiation Protocol (SIP) and users of the Extensible Messaging and Presence Protocol (XMPP). Specifically, this document defines a mapping between the XMPP Multi-User Chat (MUC) extension and the SIP-based Message Session Relay Protocol (MSRP).</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>Both the Session Initiation Protocol (SIP) <xref target="RFC3261"/> and the Extensible Messaging and Presence Protocol (XMPP) <xref target="RFC6120"/> can be used for the purpose of multiparty text chat over the Internet. To ensure interworking between these technologies, it is important to define bidirectional protocol mappings.</t>
<t>The architectural assumptions underlying such protocol mappings are provided in <xref target="I-D.saintandre-sip-xmpp-core"/>, including mapping of addresses and error conditions. This document specifies mappings for multiparty text chat sessions (often called "groupchat"); specifically, this document defines a mapping between the XMPP Multi-User Chat (MUC) extension <xref target='XEP-0045'/> and the SIP-based Message Session Relay Protocol <xref target="RFC4975"/>.</t>
<t>Both MUC and MSRP contain a large set of features, such as the ability to administer rooms, kick and ban users, reserve a room nickname, change room subject, enable room moderation, and destroy the room. This document covers only a basic subset of groupchat features: joining the room, establishing or changing a room nickname, modifying presence information within the room, sending a message to all participants, sending a private message to a single participant, and leaving the room. Future documents might define mapping of additional features beyond this core.</t>
<t>The discussion venue for this document is the mailing list of the DISPATCH WG; visit https://www.ietf.org/mailman/listinfo/dispatch for subscription information and discussion archives.</t>
</section>
<section title="Terminology" anchor="terms">
<t>The 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 <xref target='RFC2119'/>.</t>
</section>
<section title="XMPP MUC to MSRP Multi-party Messaging Session" anchor="muc2msrp">
<t>This section describes how to map an XMPP MUC session to an MSRP Multi-party Messaging session.</t>
<figure>
<artwork><![CDATA[
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Enter 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) Subject | |
|<-------------------------| |
| | |
|(F13) (XMPP) Chat message | |
|------------------------->| |
| |(F14) (MSRP) SEND |
| |------------------------->|
| |(F15) (MSRP) 200 OK |
| |<-------------------------|
| | |
|(F16) (XMPP) Chat message | |
|<-------------------------| |
. . .
. . .
|(F17) (XMPP) Exit room | |
|------------------------->| |
| |(F18) (SIP) BYE |
| |------------------------->|
| |(F19) (SIP) 200 OK |
| |<-------------------------|
]]></artwork>
</figure>
<t>Detailed protocol flows are provided in the following sections.</t>
<section title="Enter Room" anchor="muc2msrp-enter">
<t>When the XMPP user (say, juliet@example.com) wants to join a multi-user chat room (say, "verona@chat.example.org"), she sends a <presence/> stanza to that chat room. In her request she also specifies the nickname she wants to use within the room (say, "JuliC"); in XMPP this Room Nickname is the resourcepart of an Occupant JID (thus "verona@chat.example.org/JuliC"). The joining client signals 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.</t>
<figure>
<preamble>Example: (F1) Juliet enters room</preamble>
<artwork><![CDATA[
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
</presence>
]]></artwork>
</figure>
<t>Upon receiving such a presence stanza, the XMPP server to which Juliet has authenticated attempts to (a) deliver the stanza to a local domain or (b) 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 a groupchat-aware SIP/MSRP service hosted by a separate server.</t>
<t>As specified in <xref target="RFC6121"/>, the XMPP server needs to determine the identity of the remote domain, which it does by performing one or more DNS SRV lookups <xref target="RFC2782"/>. For presence stanzas, the order of lookups recommended by <xref target="RFC6121"/> is to first try the "_xmpp-server" service as specified in <xref target="RFC6120"/> and to then try the "_im" service as specified in <xref target="RFC3861"/>. Here we assume that the first lookup will fail but that the second lookup will succeed and return a resolution "_im._simple.example.org", since we have already assumed that the example.org hostname is running a SIP instant messaging service. (Note: The XMPP server might 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.)</t>
<t>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 code (this might be a connection manager or a dedicated component at, say, x2s.example.com), which transforms the presence stanza into SIP syntax and routes it to the remote conference server (chat.example.org).</t>
<t>Because a multi-user chat service accepts the presence stanza shown above as a request to enter a room, the XMPP-to-SIP gateway transforms it in a SIP INVITE request.</t>
<figure>
<preamble>Example: (F2) Juliet enters room (SIP conversion)</preamble>
<artwork><![CDATA[
INVITE sip:verona@chat.example.org SIP/2.0
To: <sip:verona@chat.example.org>
From: <sip:juliet@example.com>;gr=balcony
Call-ID: 711609sa
Content-Type: application/sdp
Content-Length: [length]
c=IN IP4 x2s.example.org
m=message 7654 TCP/MSRP *
a=accept-types:text/cpim
a=accept-wrapped-types:text/plain text/html
a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-messages
]]></artwork>
</figure>
<t>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.</t>
<t><list style="empty"><t>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.</t></list></t>
<t>As specified in <xref target="I-D.saintandre-sip-xmpp-core"/>, the mapping of XMPP syntax elements to SIP and <xref target='RFC4566'/> syntax elements is as shown in the following table. (Mappings for elements not mentioned are undefined.)</t>
<figure>
<preamble>Table 1: Message syntax mapping from XMPP to SIP/SDP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | SIP Header or SDP Contents |
+-----------------------------+-----------------------------+
| from | From |
| to (without the /nick) | To |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
<t>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 <xref target="I-D.ietf-simple-chat"/>.</t>
<figure>
<preamble>Example: (F3) the chat room accepts the session establishment</preamble>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:verona@chat.example.org>
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
Contact: <sip:verona@chat.example.org;transport=tcp>\
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY"\
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: [length]
c=IN IP4 example.org
m=message 12763 TCP/MSRP *
a=chatroom:nickname private-messages
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
]]></artwork>
</figure>
<t>Upon receiving such a response, the SIMPLE server or associated SIP-to-XMPP gateway sends a SIP ACK to the SIP user.</t>
<figure>
<preamble>Example: (F4) Gateway sends ACK to the chat room server</preamble>
<artwork><![CDATA[
ACK sip:verona@chat.example.org SIP/2.0
To: <sip:verona@chat.example.org>;tag=087js
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
]]></artwork>
</figure>
</section>
<section title="Setting up a Nickname" anchor="muc2msrp-nicksetup">
<t>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 <xref target="I-D.ietf-simple-chat"/>.</t>
<figure>
<preamble>Example: (F5) Gateway sets up the nickname</preamble>
<artwork><![CDATA[
MSRP a786hjs2 NICKNAME
To-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
Use-Nickname: "JuliC"
-------a786hjs2
]]></artwork>
</figure>
<t>The chat room server analyzes the existing allocation of nicknames, accepts the nickname proposal and answers with a 200 response.</t>
<figure>
<preamble>Example: (F6) chat room accepts the nickname proposal</preamble>
<artwork><![CDATA[
MSRP a786hjs2 200 OK
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
-------a786hjs2
]]></artwork>
</figure>
</section>
<section title="Nickname Conflict" anchor="muc2msrp-nickConflict">
<t>The foregoing section assumed that the requested nickname did not conflict with any existing nicknames. This section describes the handling of a nickname conflict.</t>
<figure>
<artwork><![CDATA[
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Enter room | |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| | |
| |(F5) (MSRP) NICKNAME |
| |------------------------->|
| |(F6) (MSRP) 425 Error |
| |<-------------------------|
| | |
|(F7) (XMPP) Presence Error
|<-------------------------| |
. . .
| |(F8) (SIP) BYE |
| |------------------------->|
| |(F9) (SIP) 200 OK |
| |<-------------------------|
]]></artwork>
</figure>
<t>The chat room server analyzes the existing allocation of nicknames, and detects that the nickname proposal is already provided to another participant by the conference. In this case the MSRP conference server answers with a 425 response.</t>
<figure>
<preamble>Example: (F6) chat room does not accept the nickname proposal</preamble>
<artwork><![CDATA[
MSRP a786hjs2 425 Nickname usage failed
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
-------a786hjs2
]]></artwork>
</figure>
<t>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.</t>
<figure>
<preamble>Example: (F7) conflict error for nickname</preamble>
<artwork><![CDATA[
<presence from='verona@chat.example.org'
to='juliet@example.com/balcony'
type='error'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
]]></artwork>
</figure>
</section>
<section title="Changing Nickname" anchor="muc2msrp-nickChanging">
<figure>
<artwork><![CDATA[
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Presence to change Nickname |
|------------------------->| |
| |(F2) (MSRP) NICKNAME |
| |------------------------->|
| |(F3) (MSRP) 200 OK |
| |<-------------------------|
]]></artwork>
</figure>
<t>If Juliet decides to change her nickname within the room, she sends an update presence information to the room (specifically she SHOULD send a new Nickname in the same room).</t>
<figure>
<preamble>Example: (F1) Juliet changing the nickname</preamble>
<artwork><![CDATA[
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'>
</presence>
]]></artwork>
</figure>
</section>
<section title="Inviting Another User to a Room" anchor="muc2msrp-inviting">
<figure>
<artwork><![CDATA[
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Message stanza to invite participant |
|------------------------->| |
| |(F2) (SIP) REFER |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
. . .
| |(F4) (SIP) NOTIFY |
| |<-------------------------|
]]></artwork>
</figure>
<t>If Juliet decides to invite Hecate to the room, she sends a message stanza to the room.</t>
<figure>
<preamble>Example: (F1) Juliet inviting Hecate to the room</preamble>
<artwork><![CDATA[
<message
from='juliet@example.com/balcony'
id='nzd143v8'
to='verona@chat.example.org'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<invite to='hecate@example.com'>
<reason>
Hey Hecate, this is the place for all good witches!
</reason>
</invite>
</x>
</message>
]]></artwork>
</figure>
<t>The SIP - XMPP gateway then sends a SIP REFER request to the MSRP conference server indicating who needs to be invited
in the Refer-To header, as per RFC 4579 (sec 5.5)</t>
<figure>
<preamble>Example: (F2) Juliet inviting Hecate to the room</preamble>
<artwork><![CDATA[
REFER sip:verona@chat.example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bKg4534
Max-Forwards: 70
To: <sip:verona@chat.example.com>
From: <sip:juliet@example.com>;tag=5534562
Call-ID: 849392fklgl43
CSeq: 476 REFER
Contact: <sip:juliet@juliet.example.com>
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Accept: message/sipfrag
Refer-To: <sip:hecate@example.com>
Supported: replaces
Content-Length: 0
]]></artwork>
</figure>
<t>The progress of the invitation will be tracked by the reeived NOTIFY requests as per RFC 3515.</t>
<figure>
<preamble>Example: (F4) Progress notification for invitation</preamble>
<artwork><![CDATA[
NOTIFY sip:juliet@example.com SIP/2.0
Via: SIP/2.0/UDP client.example.com;branch=z9hG4bK9922ef992-25
To: <sip:juliet@example.com>;tag=5534562
From: <sip:verona@chat.example.com>;tag=18747389
Call-ID: 849392fklgl43
CSeq: 1993402 NOTIFY
Max-Forwards: 70
Event: refer
Subscription-State: active;expires=60
Contact: sip:verona@verona.chat.example.com
Content-Type: message/sipfrag;version=2.0
Content-Length: ...
SIP/2.0 200 OK
]]></artwork>
</figure>
</section>
<section title="Presence Broadcast" anchor="muc2msrp-presence">
<t>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 of the room. So the XMPP-to-SIP gateway MUST subscribe to the Conference Event package <xref target="RFC4575"/> on the MSRP conference server. When the subscription is completed the MSRP conference server sends a NOTIFY with the presence information from all the existing occupants of the room back to the XMPP-to-SIP gateway.</t>
<figure>
<preamble>Example: (F9) chat room sends presence information</preamble>
<artwork><![CDATA[
NOTIFY sip:verona@chat.example.org SIP/2.0
To: Juliet <sip:juliet@example.com>;gr=balcony
From: <sip:verona@chat.example.org>;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@chat.example.org">
<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">
<display-text>romeo</display-text>
<roles>
<entry>participant</entry>
</roles>
</user>
</users>
</conference-info>
]]></artwork>
</figure>
<figure>
<preamble>Table 2: Syntax mapping from RFC4575 payload to XMPP participants list. (Mappings for elements not mentioned are undefined.)</preamble>
<artwork><![CDATA[
+--------------------------------+-----------------------------+
| RFC 4575 Element | XMPP Element or Attribute |
+--------------------------------+-----------------------------+
| conference-info entity | room JID |
| conference subject | room subject |
| user entity | participant bare JID |
| user display-text / nickname | participant nickname |
| endpoint entity | participant full JID |
+--------------------------------+-----------------------------+
]]></artwork>
</figure>
<t>If both nickname and display-text are present in the RFC 4575 payload the nickname element takes precedence.</t>
<t>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.</t>
<figure>
<preamble>Example: (F11) chat room presence information translated in XMPP</preamble>
<artwork><![CDATA[
<presence from='romeo@example.com/romeo'
to='verona@chat.example.org/JuliC'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
]]></artwork>
</figure>
<t>If the NOTIFY included a subject, the gateway shall convert it into a separate XMPP message.</t>
<figure>
<preamble>Example: (F12) chat room subject translated in XMPP</preamble>
<artwork><![CDATA[
<message from='verona@chat.example.com/mayor'
to='juliet@example.com/balcony'>
<subject>Today in Verona</subject>
</message>
]]></artwork>
</figure>
<t>The mapping of SIP and SDP syntax elements to XMPP syntax elements is as shown in the following table. (Mappings for elements not mentioned are undefined.)</t>
<figure>
<preamble>Table 2: Message syntax mapping from SIP/SDP to XMPP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| SIP Header or SDP Contents | XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| <user entity=...> | From |
| To + / <nickname-text> | To |
| roles | role |
| 'none' | affiliation |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
</section>
<section title="Exchanging Messages" anchor="muc2msrp-message">
<t>Once the user has joined the chat room, the user can exchange an unbounded number of messages both public and private.</t>
<t>The mapping of XMPP syntax elements to MSRP syntax elements is as shown in the following table. (Mappings for elements not mentioned are undefined.)</t>
<figure>
<preamble>Table 3: Message syntax mapping from XMPP Message to MSRP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | CPIM Header |
+-----------------------------+-----------------------------+
| to | To |
| from | From |
| <body/> | body of the SEND request |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
<section title="Sending a Message to All Occupants" anchor="muc2msrp-message-all">
<t>When Juliet wants to sends a message to all other occupants in the room, she sends a message of type "groupchat" to the <room@service> itself (in our example, <verona@chat.example.org>).</t>
<t>The following examples show an exchange of a public message.</t>
<figure>
<preamble>Example: (F13) Juliet sends a Message to all occupants</preamble>
<artwork><![CDATA[
<message from='juliet@example.com/balcony'
to='verona@chat.example.org'
type='groupchat'>
<body>Who knows where Romeo is?</body>
</message>
]]></artwork>
</figure>
<t>Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it into an MSRP SEND message.</t>
<figure>
<preamble>Example: (F14) Gateway transforms XMPP message to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://s2x.example.org: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.example.org;transport=tcp>
From: <sip:juliet@example.com;gr=balcony>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
Who knows where Romeo is?
-------a786hjs2$
]]></artwork>
</figure>
<t>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 MSRP conference server MUST immediately generate and send a response.</t>
<figure>
<artwork><![CDATA[
MSRP d93kswow 200 OK
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
]]></artwork>
</figure>
<t>Since the XMPP room could be moderated and an XMPP user cannot be sure whether his message has been accepted or not (without receiving it back from the server), <xref target="XEP-0045"/> states that the sender needs to receive back the same message it has generated. So in this scenario the XMPP-to-SIP gateway has to reflect the message back to the sender.</t>
</section>
<section title="Sending a Private Message" anchor="muc2msrp-message-private">
<t>Since each occupant has a unique JID, Juliet can send a "private message" to a selected occupant through the service by sending a message to the user's occupant JID. The XMPP message type SHOULD be "chat" and MUST NOT be "groupchat", but MAY be left unspecified.</t>
<t>If the XMPP-to-SIP gateway has support for private messaging it MUST advertise that fact by adding a "private-messages" value to the a=chatroom SDP attribute as stated by <xref target="I-D.ietf-simple-chat"/>.</t>
<figure>
<artwork><![CDATA[
a=chatroom:nickname private-messages
]]></artwork>
</figure>
<t>The following examples show an exchange of a private message.</t>
<figure>
<preamble>Example: Juliet sends private message</preamble>
<artwork><![CDATA[
<message from='juliet@example.com'
to='verona@chat.example.org/romeo'
type='chat'/>
<body>O Romeo, Romeo! wherefore art thou Romeo?</body>
</message>
]]></artwork>
</figure>
<t>Upon receiving such stanza message, the XMPP-to-SIP gateway MUST translate it in an MSRP SEND message.</t>
<figure>
<preamble>Example: Gateway transforms private message from XMPP to MSRP</preamble>
<artwork><![CDATA[
MSRP a786hjs2 SEND
To-Path: msrp://s2x.example.org: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.example.org>
From: <sip:juliet@chat.example.org;gr=balcony>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
O Romeo, Romeo! wherefore art thou Romeo?
-------a786hjs2$
]]></artwork>
</figure>
</section>
</section>
<section title="Exit Room" anchor="muc2msrp-exit">
<t>If Juliet decides to exit the multi-user chat room, her client sends a presence stanza of type "unavailable" to the occupant JID she is currently using in the room (here <verona@chat.example.org/JuliC>).</t>
<figure>
<preamble>Example: (F17) Juliet exits room</preamble>
<artwork><![CDATA[
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'
type='unavailable'>
</presence>
]]></artwork>
</figure>
<t>Upon receiving such a stanza, the XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE to the MSRP conference server. The MSRP conference server then responds with a 200 OK.</t>
<t>Juliet MAY include a custom exit message in the presence stanza of type "unavailable", in which case it SHOULD be broadcasted to other participants using the methods described above.</t>
<figure>
<preamble>Example: (F17) Juliet exiting a chatroom</preamble>
<artwork><![CDATA[
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'
type='unavailable'>
<status>Time to go!</status>
</presence>
]]></artwork>
</figure>
</section>
</section>
<section title="MSRP Multi-party Messaging Session to XMPP MUC" anchor="msrp2muc">
<t>This section describes how to map a Multi-party Instant Message (IM) MSRP session to an XMPP Group Chat.</t>
<figure>
<artwork><![CDATA[
XMPP Chat
SIP User GW room
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
|(F2) (SIP) 200 OK | |
|<------------------------| |
|(F3) (SIP) ACK | |
|------------------------>| |
| | |
|(F4) (MSRP) NICKNAME | |
|------------------------>| |
| |(F5)(XMPP) Enter a room |
| |------------------------->|
|(F6) (MSRP) 200 OK | |
|<------------------------| |
| |(F7)(XMPP) (XMPP) Presence|
| |<-------------------------|
| | |
|(F8)(SIP) SUBSCRIBE | |
|------------------------>| |
| Event:conference | |
| | |
|(F9) (SIP) 200 OK | |
|<------------------------| |
| | |
|(F10) (SIP) NOTIFY | |
|<------------------------| |
|(F11) (SIP) 200 OK | |
|------------------------>| |
| |(F12)(XMPP) (XMPP) Subject|
| |<-------------------------|
| | |
|(F13)(MSRP) SEND | |
|------------------------>| |
| | |
|(F14)(MSRP) SEND | |
|------------------------>| |
| |(F15)(XMPP) Chat message |
|(F16)(MSRP) 200 OK |------------------------->|
|<------------------------|(F17)(XMPP) Chat message |
| |<-------------------------|
|(F18)(MSRP) SEND | |
|<------------------------| |
|(F19)(MSRP) 200 OK | |
|------------------------>| |
. . .
. . .
| | |
|(F20)(SIP) BYE | |
|------------------------>| |
| |(F21)(XMPP) Exiting a room|
| |------------------------->|
|(F22)(SIP) 200 OK | |
|<------------------------| |
]]></artwork>
</figure>
<t>If the XMPP presence stanza is received before the SIP SUBSCRIBE dialog is established for the "conference" event the server SHOULD cache the participants list until the subscription is established and it's delivered in a SIP NOTIFY request.</t>
<section title="Enter Room" anchor="mrsp2muc-enter">
<t>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.</t>
<figure>
<preamble>Example: (F1) SIP user starts the session</preamble>
<artwork><![CDATA[
INVITE sip:verona@chat.example.org SIP/2.0
To: <sip:verona@chat.example.org>
From: <sip:romeo@example.com>;tag=786
Call-ID: 742510no
Content-Type: application/sdp
Content-Length: [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
]]></artwork>
</figure>
<t>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 <xref target="RFC2782"/>. 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 <xref target="RFC3861"/> 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 <xref target="RFC6120"/> or MAY return an error to the sender (i.e. 502 Bad Gateway).</t>
<t>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.</t>
<figure>
<artwork><![CDATA[
SIP/2.0 200 OK
To: <sip:verona@chat.example.org>
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
a=chatroom:nickname private-messages
]]></artwork>
</figure>
<figure>
<preamble>Example: (F4) the MSRP user set up the nickname</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>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.</t>
<figure>
<preamble>Example: (F5) Romeo entering a chatroom</preamble>
<artwork><![CDATA[
<presence from='romeo@example.com'
to='verona@chat.example.org/romeo'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
</presence>
]]></artwork>
</figure>
<t>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).</t>
<figure>
<preamble>Example: (F6) </preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
</section>
<section title="Nickname Conflict" anchor="msrp2muc-nickConflict">
<t>The foregoing section assumed that the requested nickname did not conflict with any existing nicknames. This section describes the handling of a nickname conflict.</t>
<figure>
<artwork><![CDATA[
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) 425 Error | |
|<------------------------| |
| | |
]]></artwork>
</figure>
</section>
<section title="Changing Nickname" anchor="msrp2muc-nickChanging">
<figure>
<artwork><![CDATA[
XMPP conference
SIP User GW server
| | |
|(F1) (MSRP) NICKNAME | |
|------------------------->| |
| |(F2) (XMPP) Presence w/ Nickname
| |------------------------->|
|(F3) (MSRP) 200 OK | |
|<-------------------------| |
]]></artwork>
</figure>
<t>If Romeo decides to changing her nickname within the room, he MUST 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.</t>
<figure>
<preamble>Example: (F1) the MSRP user changes the nickname</preamble>
<artwork><![CDATA[
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
]]></artwork>
</figure>
<t>Upon receiving such message, the SIP-to-XMPP gateway MUST translate it in a XMPP presence stanza.</t>
<figure>
<preamble>Example: (F2) Juliet changing the nickname</preamble>
<artwork><![CDATA[
<presence from='juliet@example.com'
to='verona@chat.example.org/montecchi'>
</presence>
]]></artwork>
</figure>
</section>
<section title="Inviting Another User to a Room" anchor="msrp2muc-inviting">
<t>To follow.</t>
</section>
<section title="Presence Broadcast" anchor="msrp2muc-presence">
<t>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.</t>
<figure>
<preamble>Example: (F7) chat room presence information translated in XMPP</preamble>
<artwork><![CDATA[
<presence from='verona@chat.example.org/JuliC'
to='juliet@example.com'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
]]></artwork>
</figure>
<t> Upon receiving such a response, if the MSRP has already completed the subscription to the Conference Event package <xref target="RFC4575"/>, the XMPP-to-SIP gateway MUST translate it in a SIP NOTIFY request.</t>
<figure>
<preamble>Example: (F10) the XMPP-to-SIP notifies the presence information</preamble>
<artwork><![CDATA[
NOTIFY sip:romeo@example.com SIP/2.0
To: Juliet <sip:romeo@example.com>;tag=43524545
From: <sip:verona@chat.example.org>;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:verona@chat.example.org">
<conference-description>
<subject>Today in Verona</subject>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
<uri>sip:verona@chat.example.org</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:juliet@example.com" state="full">
<display-text>juliet</display-text>
<roles>
<entry>participant</entry>
</roles>
</user>
</users>
</conference-info>
]]></artwork>
</figure>
</section>
<section title="Exchanging Messages" anchor="mrsp-exchange">
<t>Once the user has joined the chat room, the user can exchange an unbounded number of messages both public and private.</t>
<t>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.)</t>
<figure>
<preamble>Table 4: Message syntax mapping from MSRP Message to XMPP</preamble>
<artwork><![CDATA[
+-----------------------------+-----------------------------+
| CPIM Header |XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| To | to |
| From | from |
| body of the SEND request | <body/> |
+-----------------------------+-----------------------------+
]]></artwork>
</figure>
<section title="Sending a Message to All Occupants" anchor="msrp2muc-messageToAll">
<t>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.example.org> in our example).</t>
<figure>
<preamble>Example: (F12) Romeo sends a message to the chat room</preamble>
<artwork><![CDATA[
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.example.org;transport=tcp>
From: <sip:juliet@example.com>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
Romeo is here!
-------a786hjs2$
]]></artwork>
</figure>
<t>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 it in a XMPP message stanza (F13) and then generate and send an MSRP response (F14).</t>
<t>The following examples show an exchange of a public message.</t>
<figure>
<preamble>Example: (F13) Romeo sends a Message to all occupants</preamble>
<artwork><![CDATA[
<message from='romeo@example.com'
to='verona@chat.example.org'
type='groupchat'>
<body>Romeo is here!</body>
</message>
]]></artwork>
</figure>
<figure>
<preamble>Example: (F14) the SIP-to-XMPP send the MSRP response</preamble>
<artwork><![CDATA[
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$
]]></artwork>
</figure>
</section>
<section title="Sending a Private Message" anchor="msrp2muc-privatemessage">
<t>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.</t>
<t>The following examples show an exchange of a private message.</t>
<figure>
<preamble>Example: (F12) Romeo sends a private message</preamble>
<artwork><![CDATA[
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.example.org>
From: <sip:romeo@example.com>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
I am here!!!
-------a786hjs2$
]]></artwork>
</figure>
<figure>
<preamble>Example: (F13) Juliet sends a private message</preamble>
<artwork><![CDATA[
<message from='romeo@example.com'
to='verona@chat.example.org/JuliC'
type='chat'/>
<body>I am here!!!</body>
</message>
]]></artwork>
</figure>
</section>
</section>
<section title="Exit Room" anchor="msrp2muc-exit">
<t>If Romeo decides to exit the multi-user chat room, his client sends SIP BYE to the <verona@chat.example.org> chat room.</t>
<figure>
<preamble>Example: (F11) Romeo terminates the session</preamble>
<artwork><![CDATA[
BYE sip:verona@chat.example.org SIP/2.0
Max-Forwards: 70
From: <sip:romeo@example.net>;tag=786
To: <sip:verona@chat.example.org>;tag=534
Call-ID: 742510no
Cseq: 1 BYE
Content-Length: 0
]]></artwork>
</figure>
<t>Upon receiving the SIP BYE, the SIP-to-XMPP gateway translates it in a presence stanza (F19) and sends it to the XMPP chat room service. Then the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user.</t>
<figure>
<preamble>Example: (F19) Juliet exiting a chatroom</preamble>
<artwork><![CDATA[
<presence from='romeo@example.com'
to='verona@chat.example.org/romeo'
type='unavailable'>
</presence>
]]></artwork>
</figure>
</section>
</section>
<section title="Open Issues" anchor="issues">
<t>The following issues remain to be closed.</t>
<t>
<list style="numbers">
<t>Define a full mapping between RFC 4575 and MUC.</t>
<t>Define how to send to the room jid with the subject child set (e.g., do we need to send it in a different presence stanza than step F11?)</t>
<t>Specify how to deal with conflicts between SIP display name and XMPP nickname (e.g., use only display-text?).</t>
<t>Specify how to map the <roles/> conference-info attribute to 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).</t>
<t>When joining via SIP, the gateway could use a temporary nickname and directly translate the request into a XMPP presence stanza.</t>
<t>The SIP-to-XMPP gateway will receive back the reflected message from the Chat room service. Does the SIP-to-XMPP gateway need to translate it back to the MSRP user or not?</t>
<t>If the room is semi-anonymous, publish the occupant JID instead? Always set the occupant JID as the 'user' and the real JID as an 'endpoint'?</t>
<t>Should a private message be addressed to the occupant JID? If so, it would need to be translated to a GRUU (e.g., sip:verona@chat.example.org;gr=JuliC).</t>
</list>
</t>
</section>
<section title="Security Considerations" anchor="security">
<t>To follow.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document requests no actions of the IANA.</t>
</section>
</middle>
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<street>Cambridge</street>
<street>MA 02138</street></postal>
<phone>- +1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year="1997" month="March"/>
<area>General</area>
<keyword>keyword</keyword>
<abstract>
<t>
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:
<list>
<t>
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.
</t></list></t>
<t>
Note that the force of these words is modified by the requirement
level of the document in which they are used.
</t></abstract></front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
<format type="HTML" octets="17491" target="http://xml.resource.org/public/rfc/html/rfc2119.html"/>
<format type="XML" octets="5777" target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"/>
</reference>
<reference anchor="RFC3261">
<front>
<title>SIP: Session Initiation Protocol</title>
<author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
<organization/></author>
<author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
<organization/></author>
<author initials="G." surname="Camarillo" fullname="G. Camarillo">
<organization/></author>
<author initials="A." surname="Johnston" fullname="A. Johnston">
<organization/></author>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization/></author>
<author initials="R." surname="Sparks" fullname="R. Sparks">
<organization/></author>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="E." surname="Schooler" fullname="E. Schooler">
<organization/></author>
<date year="2002" month="June"/>
<abstract>
<t>This 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] </t></abstract></front>
<seriesInfo name="RFC" value="3261"/>
<format type="TXT" octets="647976" target="ftp://ftp.isi.edu/in-notes/rfc3261.txt"/>
</reference>
<reference anchor="RFC3861">
<front>
<title>Address Resolution for Instant Messaging and Presence</title>
<author initials="J." surname="Peterson" fullname="J. Peterson">
<organization/></author>
<date year="2004" month="August"/>
<abstract>
<t>Presence 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] </t></abstract></front>
<seriesInfo name="RFC" value="3861"/>
<format type="TXT" octets="15764" target="ftp://ftp.isi.edu/in-notes/rfc3861.txt"/>
</reference>
<reference anchor="RFC4975">
<front>
<title>The Message Session Relay Protocol (MSRP)</title>
<author initials="B." surname="Campbell" fullname="B. Campbell">
<organization/></author>
<author initials="R." surname="Mahy" fullname="R. Mahy">
<organization/></author>
<author initials="C." surname="Jennings" fullname="C. Jennings">
<organization/></author>
<date year="2007" month="September"/>
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name="RFC" value="4975"/>
<format type="TXT" octets="144254" target="ftp://ftp.isi.edu/in-notes/rfc4975.txt"/>
</reference>
<reference anchor='RFC6120'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6120' />
<format type='TXT' octets='451942' target='http://www.rfc-editor.org/rfc/rfc6120.txt' />
</reference>
<reference anchor='RFC6121'>
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2011' month='March' />
<abstract>
<t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='6121' />
<format type='TXT' octets='244800' target='http://www.rfc-editor.org/rfc/rfc6121.txt' />
</reference>
<reference anchor="XEP-0045">
<front>
<title>Multi-User Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="16" month="July" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0045"/>
<format type="HTML" target="http://www.xmpp.org/extensions/xep-0045.html"/>
</reference>
</references>
<references title="Informative References">
<reference anchor="I-D.ietf-simple-chat">
<front>
<title>Multi-party Instant Message (IM) Sessions Using the Message Session Relay Protocol (MSRP)</title>
<author initials="A" surname="Niemi" fullname="Aki Niemi">
<organization/>
</author>
<author initials="M" surname="Garcia-Martin" fullname="Miguel Garcia-Martin">
<organization/>
</author>
<author initials="G" surname="Sandbakken" fullname="Geir Arne Sandbakken">
<organization/>
</author>
<date month="January" day="11" year="2013"/>
<abstract><t>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.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-simple-chat-18"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-ietf-simple-chat-18.txt"/>
</reference>
<reference anchor="I-D.saintandre-sip-xmpp-core">
<front>
<title>Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
</author>
<author initials="A" surname="Houri" fullname="Avshalom Houri">
<organization/>
</author>
<author initials="J" surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
</author>
<date month="April" day="2" year="2013"/>
<abstract><t>As 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.</t></abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-saintandre-sip-xmpp-core-04"/>
<format type="TXT" target="http://www.ietf.org/internet-drafts/draft-saintandre-sip-xmpp-core-04.txt"/>
</reference>
<reference anchor='RFC2782'>
<front>
<title abbrev='DNS SRV RR'>A DNS RR for specifying the location of services (DNS SRV)</title>
<author initials='A.' surname='Gulbrandsen' fullname='Arnt Gulbrandsen'>
<organization>Troll Tech</organization>
<address>
<postal>
<street>Waldemar Thranes gate 98B</street>
<city>Oslo</city>
<region />
<code>N-0175</code>
<country>NO</country></postal>
<phone>+47 22 806390</phone>
<facsimile>+47 22 806380</facsimile>
<email>arnt@troll.no</email></address></author>
<author initials='P.' surname='Vixie' fullname='Paul Vixie'>
<organization>Internet Software Consortium</organization>
<address>
<postal>
<street>950 Charter Street</street>
<city>Redwood City</city>
<region>CA</region>
<code>94063</code>
<country>US</country></postal>
<phone>+1 650 779 7001</phone></address></author>
<author initials='L.' surname='Esibov' fullname='Levon Esibov'>
<organization>Microsoft Corporation</organization>
<address>
<postal>
<street>One Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<email>levone@microsoft.com</email></address></author>
<date month='February' year='2000' />
<abstract>
<t>This document describes a DNS RR which specifies the location of the
server(s) for a specific protocol and domain.</t></abstract></front>
<seriesInfo name='RFC' value='2782' />
<format type='TXT' octets='24013' target='ftp://ftp.isi.edu/in-notes/rfc2782.txt' />
</reference>
<reference anchor="RFC4566">
<front>
<title>SDP: Session Description Protocol</title>
<author initials="M." surname="Handley" fullname="M. Handley">
<organization/></author>
<author initials="V." surname="Jacobson" fullname="V. Jacobson">
<organization/></author>
<author initials="C." surname="Perkins" fullname="C. Perkins">
<organization/></author>
<date year="2006" month="July"/>
<abstract>
<t>This 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]</t></abstract></front>
<seriesInfo name="RFC" value="4566"/>
<format type="TXT" octets="108820" target="ftp://ftp.isi.edu/in-notes/rfc4566.txt"/>
</reference>
<reference anchor='RFC4575'>
<front>
<title>A Session Initiation Protocol (SIP) Event Package for Conference State</title>
<author initials='J.' surname='Rosenberg' fullname='J. Rosenberg'>
<organization /></author>
<author initials='H.' surname='Schulzrinne' fullname='H. Schulzrinne'>
<organization /></author>
<author initials='O.' surname='Levin' fullname='O. Levin'>
<organization /></author>
<date year='2006' month='August' />
<abstract>
<t>This 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]</t></abstract></front>
<seriesInfo name='RFC' value='4575' />
<format type='TXT' octets='97484' target='ftp://ftp.isi.edu/in-notes/rfc4575.txt' />
</reference>
</references>
<section title="Acknowledgements" anchor="acks">
<t>Some text in this document was borrowed from <xref target="I-D.saintandre-sip-xmpp-core"/> and from <xref target="XEP-0045"/>.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:40:51 |