Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
draft-saintandre-sip-xmpp-groupchat-03
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Replaced".
|
|
|---|---|---|---|
| Authors | Peter Saint-Andre , Salvatore Loreto , Saúl Ibarra Corretgé , Fabio Forno | ||
| Last updated | 2013-05-02 | ||
| Replaced by | draft-ietf-stox-groupchat, RFC 7702 | ||
| RFC stream | (None) | ||
| Formats | |||
| Additional resources | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-saintandre-sip-xmpp-groupchat-03
Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc.
Intended status: Standards Track S. Loreto
Expires: November 3, 2013 Ericsson
S. Ibarra
AG Projects
F. Forno
Bluendo srl
May 2, 2013
Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Groupchat
draft-saintandre-sip-xmpp-groupchat-03
Abstract
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).
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on November 3, 2013.
Copyright Notice
Copyright (c) 2013 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
Saint-Andre, et al. Expires November 3, 2013 [Page 1]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. XMPP MUC to MSRP Multi-party Messaging Session . . . . . . . . 3
3.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Setting up a Nickname . . . . . . . . . . . . . . . . . . 7
3.3. Nickname Conflict . . . . . . . . . . . . . . . . . . . . 8
3.4. Changing Nickname . . . . . . . . . . . . . . . . . . . . 9
3.5. Inviting Another User to a Room . . . . . . . . . . . . . 10
3.6. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 11
3.7. Exchanging Messages . . . . . . . . . . . . . . . . . . . 13
3.7.1. Sending a Message to All Occupants . . . . . . . . . . 14
3.7.2. Sending a Private Message . . . . . . . . . . . . . . 15
3.8. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 16
4. MSRP Multi-party Messaging Session to XMPP MUC . . . . . . . . 17
4.1. Enter Room . . . . . . . . . . . . . . . . . . . . . . . . 18
4.2. Nickname Conflict . . . . . . . . . . . . . . . . . . . . 20
4.3. Changing Nickname . . . . . . . . . . . . . . . . . . . . 20
4.4. Inviting Another User to a Room . . . . . . . . . . . . . 21
4.5. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 21
4.6. Exchanging Messages . . . . . . . . . . . . . . . . . . . 22
4.6.1. Sending a Message to All Occupants . . . . . . . . . . 23
4.6.2. Sending a Private Message . . . . . . . . . . . . . . 24
4.7. Exit Room . . . . . . . . . . . . . . . . . . . . . . . . 24
5. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
8.1. Normative References . . . . . . . . . . . . . . . . . . . 26
8.2. Informative References . . . . . . . . . . . . . . . . . . 26
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Saint-Andre, et al. Expires November 3, 2013 [Page 2]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
1. Introduction
Both the Session Initiation Protocol (SIP) [RFC3261] and the
Extensible Messaging and Presence Protocol (XMPP) [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.
The architectural assumptions underlying such protocol mappings are
provided in [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 [XEP-0045] and the SIP-based Message
Session Relay Protocol [RFC4975].
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.
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.
2. Terminology
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
[RFC2119].
3. XMPP MUC to MSRP Multi-party Messaging Session
This section describes how to map an XMPP MUC session to an MSRP
Multi-party Messaging session.
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Enter room | |
Saint-Andre, et al. Expires November 3, 2013 [Page 3]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
|------------------------->| |
| |(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 |
| |<-------------------------|
Saint-Andre, et al. Expires November 3, 2013 [Page 4]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Detailed protocol flows are provided in the following sections.
3.1. Enter Room
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.
Example: (F1) Juliet enters room
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'>
<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 (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.
As specified in [RFC6121], the XMPP server needs to determine the
identity of the remote domain, which it does by performing one or
more DNS SRV lookups [RFC2782]. For presence stanzas, the order of
lookups recommended by [RFC6121] is to first try the "_xmpp-server"
service as specified in [RFC6120] and to then try the "_im" service
as specified in [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.)
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
Saint-Andre, et al. Expires November 3, 2013 [Page 5]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
syntax and routes it to the remote conference server
(chat.example.org).
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.
Example: (F2) Juliet enters room (SIP conversion)
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
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 [I-D.saintandre-sip-xmpp-core], the mapping of XMPP
syntax elements to SIP and [RFC4566] syntax elements is 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 |
+-----------------------------+-----------------------------+
Saint-Andre, et al. Expires November 3, 2013 [Page 6]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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
[I-D.ietf-simple-chat].
Example: (F3) the chat room accepts the session establishment
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
Upon receiving such a response, the SIMPLE server or associated SIP-
to-XMPP gateway sends a SIP ACK to the SIP user.
Example: (F4) Gateway sends ACK to the chat room server
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
3.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 [I-D.ietf-simple-chat].
Saint-Andre, et al. Expires November 3, 2013 [Page 7]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: (F5) Gateway sets up the nickname
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
The chat room server analyzes the existing allocation of nicknames,
accepts the nickname proposal and answers with a 200 response.
Example: (F6) chat room accepts the nickname proposal
MSRP a786hjs2 200 OK
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.example.org:12763/kjhd37s2s20w2a;tcp
-------a786hjs2
3.3. Nickname Conflict
The foregoing section assumed that the requested nickname did not
conflict with any existing nicknames. This section describes the
handling of a nickname conflict.
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 |
| |<-------------------------|
Saint-Andre, et al. Expires November 3, 2013 [Page 8]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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.
Example: (F6) chat room does not accept the nickname proposal
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
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) conflict error for nickname
<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>
3.4. Changing Nickname
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Presence to change Nickname |
|------------------------->| |
| |(F2) (MSRP) NICKNAME |
| |------------------------->|
| |(F3) (MSRP) 200 OK |
| |<-------------------------|
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).
Saint-Andre, et al. Expires November 3, 2013 [Page 9]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: (F1) Juliet changing the nickname
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'>
</presence>
3.5. Inviting Another User to a Room
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Message stanza to invite participant |
|------------------------->| |
| |(F2) (SIP) REFER |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
. . .
| |(F4) (SIP) NOTIFY |
| |<-------------------------|
If Juliet decides to invite Hecate to the room, she sends a message
stanza to the room.
Example: (F1) Juliet inviting Hecate to the room
<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>
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)
Saint-Andre, et al. Expires November 3, 2013 [Page 10]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: (F2) Juliet inviting Hecate to the room
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
The progress of the invitation will be tracked by the reeived NOTIFY
requests as per RFC 3515.
Example: (F4) Progress notification for invitation
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
3.6. 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 of the room. So the XMPP-to-SIP gateway MUST
subscribe to the Conference Event package [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.
Saint-Andre, et al. Expires November 3, 2013 [Page 11]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: (F9) chat room sends presence information
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>
Table 2: Syntax mapping from RFC4575 payload to XMPP participants
list. (Mappings for elements not mentioned are undefined.)
+--------------------------------+-----------------------------+
| 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 |
+--------------------------------+-----------------------------+
If both nickname and display-text are present in the RFC 4575 payload
the nickname element takes precedence.
Saint-Andre, et al. Expires November 3, 2013 [Page 12]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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) chat room presence information translated in XMPP
<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>
If the NOTIFY included a subject, the gateway shall convert it into a
separate XMPP message.
Example: (F12) chat room subject translated in XMPP
<message from='verona@chat.example.com/mayor'
to='juliet@example.com/balcony'>
<subject>Today in Verona</subject>
</message>
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.)
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 |
+-----------------------------+-----------------------------+
3.7. 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 is as
shown in the following table. (Mappings for elements not mentioned
are undefined.)
Saint-Andre, et al. Expires November 3, 2013 [Page 13]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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 |
+-----------------------------+-----------------------------+
3.7.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 the <room@service>
itself (in our example, <verona@chat.example.org>).
The following examples show an exchange of a public message.
Example: (F13) Juliet sends a Message to all occupants
<message from='juliet@example.com/balcony'
to='verona@chat.example.org'
type='groupchat'>
<body>Who knows where Romeo is?</body>
</message>
Upon receiving such stanza message, the XMPP-to-SIP gateway MUST
translate it into an MSRP SEND message.
Example: (F14) Gateway transforms XMPP message to MSRP
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$
Upon receiving the SEND request, if the request either contains a
Failure-Report header field value of "yes" or does not contain a
Saint-Andre, et al. Expires November 3, 2013 [Page 14]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Failure-Report header at all, the 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.example.org:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
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), [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.
3.7.2. Sending a Private Message
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.
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 [I-D.ietf-simple-chat].
a=chatroom:nickname private-messages
The following examples show an exchange of a private message.
Example: Juliet sends private message
<message from='juliet@example.com'
to='verona@chat.example.org/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.
Saint-Andre, et al. Expires November 3, 2013 [Page 15]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: Gateway transforms private message from XMPP to MSRP
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$
3.8. Exit Room
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>).
Example: (F17) Juliet exits room
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'
type='unavailable'>
</presence>
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.
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.
Example: (F17) Juliet exiting a chatroom
<presence from='juliet@example.com/balcony'
to='verona@chat.example.org/JuliC'
type='unavailable'>
<status>Time to go!</status>
</presence>
Saint-Andre, et al. Expires November 3, 2013 [Page 16]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
4. 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 Group Chat.
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 | |
Saint-Andre, et al. Expires November 3, 2013 [Page 17]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
|<------------------------| |
|(F19)(MSRP) 200 OK | |
|------------------------>| |
. . .
. . .
| | |
|(F20)(SIP) BYE | |
|------------------------>| |
| |(F21)(XMPP) Exiting a room|
| |------------------------->|
|(F22)(SIP) 200 OK | |
|<------------------------| |
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.
4.1. Enter 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.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
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 [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 [RFC3861] regarding the "_im" SRV
Saint-Andre, et al. Expires November 3, 2013 [Page 18]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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 [RFC6120] 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.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
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.example.org/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
Saint-Andre, et al. Expires November 3, 2013 [Page 19]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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
4.2. Nickname Conflict
The foregoing section assumed that the requested nickname did not
conflict with any existing nicknames. This section describes the
handling of a 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) 425 Error | |
|<------------------------| |
| | |
4.3. Changing Nickname
XMPP conference
SIP User GW server
| | |
|(F1) (MSRP) NICKNAME | |
|------------------------->| |
| |(F2) (XMPP) Presence w/ Nickname
| |------------------------->|
|(F3) (MSRP) 200 OK | |
|<-------------------------| |
Saint-Andre, et al. Expires November 3, 2013 [Page 20]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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.
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.example.org/montecchi'>
</presence>
4.4. Inviting Another User to a Room
To follow.
4.5. 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) chat room presence information translated in XMPP
<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>
Upon receiving such a response, if the MSRP has already completed the
subscription to the Conference Event package [RFC4575], the XMPP-to-
SIP gateway MUST translate it in a SIP NOTIFY request.
Saint-Andre, et al. Expires November 3, 2013 [Page 21]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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.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>
4.6. 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.)
Saint-Andre, et al. Expires November 3, 2013 [Page 22]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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/> |
+-----------------------------+-----------------------------+
4.6.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.example.org> 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.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$
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).
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.example.org'
type='groupchat'>
<body>Romeo is here!</body>
</message>
Saint-Andre, et al. Expires November 3, 2013 [Page 23]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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$
4.6.2. Sending 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: (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.example.org>
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.example.org/JuliC'
type='chat'/>
<body>I am here!!!</body>
</message>
4.7. Exit Room
If Romeo decides to exit the multi-user chat room, his client sends
SIP BYE to the <verona@chat.example.org> chat room.
Saint-Andre, et al. Expires November 3, 2013 [Page 24]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Example: (F11) Romeo terminates the session
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
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.
Example: (F19) Juliet exiting a chatroom
<presence from='romeo@example.com'
to='verona@chat.example.org/romeo'
type='unavailable'>
</presence>
5. Open Issues
The following issues remain to be closed.
1. Define a full mapping between RFC 4575 and MUC.
2. 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?)
3. Specify how to deal with conflicts between SIP display name and
XMPP nickname (e.g., use only display-text?).
4. 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).
5. When joining via SIP, the gateway could use a temporary nickname
and directly translate the request into a XMPP presence stanza.
6. 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?
7. 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'?
8. 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).
Saint-Andre, et al. Expires November 3, 2013 [Page 25]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
6. Security Considerations
To follow.
7. IANA Considerations
This document requests no actions of the IANA.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] 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.
[RFC3861] Peterson, J., "Address Resolution for Instant Messaging
and Presence", RFC 3861, August 2004.
[RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, March 2011.
[RFC6121] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 6121, March 2011.
[XEP-0045]
Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
July 2008.
8.2. Informative References
[I-D.ietf-simple-chat]
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-18
(work in progress), January 2013.
[I-D.saintandre-sip-xmpp-core]
Saint-Andre, et al. Expires November 3, 2013 [Page 26]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
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-04 (work in
progress), April 2013.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
Appendix A. Acknowledgements
Some text in this document was borrowed from
[I-D.saintandre-sip-xmpp-core] and from [XEP-0045].
Authors' Addresses
Peter Saint-Andre
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver, CO 80202
USA
Phone: +1-303-308-3282
Email: psaintan@cisco.com
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Salvatore.Loreto@ericsson.com
Saint-Andre, et al. Expires November 3, 2013 [Page 27]
Internet-Draft SIP-XMPP Interworking: Groupchat May 2013
Saul Ibarra Corretge
AG Projects
Dr. Leijdsstraat 92
Haarlem 2021RK
The Netherlands
Email: saul@ag-projects.com
Fabio Forno
Bluendo srl
Via Morosini 10
Torino 10128
Italy
Email: fabio@bluendo.com
Saint-Andre, et al. Expires November 3, 2013 [Page 28]