Network Working Group P. Saint-Andre
Internet-Draft XSF
Intended status: Informational S. Loreto
Expires: April 30, 2009 Ericsson
F. Forno
Bluendo srl
Oct 27, 2008
Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Many-to-Many Text
Chat
draft-saintandre-sip-xmpp-groupchat-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 30, 2009.
Abstract
This document defines a bi-directional protocol mapping for the
exchange of instant messages in the context of a many-to-many chat
session among users of the Session Initiation Protocol (SIP) and
users of the Extensible Messaging and Presence Protocol (XMPP).
Specifically for SIP text chat, this document specifies a mapping to
the Message Session Relay Protocol (MSRP).
Saint-Andre, et al. Expires April 30, 2009 [Page 1]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3. Formal and Informal Sessions . . . . . . . . . . . . . . . 4
1.4. Gateway Heuristics . . . . . . . . . . . . . . . . . . . . 4
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 4
1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 4
2. XMPP Group Chat to MSRP Multiparty Instant Message (IM)
Session . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. Entering a Room . . . . . . . . . . . . . . . . . . . . . 6
2.2. Setting up a nickname . . . . . . . . . . . . . . . . . . 8
2.3. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 9
2.4. Exchanging Messages . . . . . . . . . . . . . . . . . . . 11
2.4.1. Sending a Message to All Occupants . . . . . . . . . . 11
2.4.2. Sending a Private Message . . . . . . . . . . . . . . 12
2.5. Exiting a Room . . . . . . . . . . . . . . . . . . . . . . 13
2.6. Nickname Conflict . . . . . . . . . . . . . . . . . . . . 14
2.7. Changing Nickname . . . . . . . . . . . . . . . . . . . . 15
3. MSRP Multiparty Instant Message (IM) Session to XMPP Group
Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Entering a Room . . . . . . . . . . . . . . . . . . . . . 17
3.2. Presence Broadcast . . . . . . . . . . . . . . . . . . . . 19
3.3. Exchanging Messages . . . . . . . . . . . . . . . . . . . 20
3.3.1. Sending a Message to All Occupants . . . . . . . . . . 21
3.3.2. Sending a Private Message . . . . . . . . . . . . . . 22
3.4. Exiting a Room . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Nickname Conflict . . . . . . . . . . . . . . . . . . . . 23
3.6. Changing Nickname . . . . . . . . . . . . . . . . . . . . 24
4. Security Considerations . . . . . . . . . . . . . . . . . . . 24
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
5.1. Normative References . . . . . . . . . . . . . . . . . . . 24
5.2. Informative References . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Saint-Andre, et al. Expires April 30, 2009 [Page 2]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
1. Introduction
1.1. Overview
Both the Session Initiation Protocol [SIP] and the Extensible
Messaging and Presence Protocol [XMPP] can be used for the purpose of
many-to-many text chat over the Internet. To ensure interworking
between these technologies, it is important to define bi-directional
protocol mappings.
The architectural assumptions underlying such protocol mappings are
provided in [SIP-XMPP], including mapping of addresses and error
conditions. Mappings for single instant messages (sometimes called
"pager-mode" messaging) are provided in [SIP-XMPP-IM]. Mappings for
one-to-one text chat sessions are provided in
[I-D.saintandre-sip-xmpp-chat].
This document specifies mappings for many-to-many text chat sessions
(sometimes called "groupchat"); in particular, this document
specifies mappings between XMPP and the Message Session Relay
Protocol [MSRP].
Note: The capitalized key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be
interpreted as described in RFC 2119 [TERMS].
1.2. Scope
Both XMPP and SIP/SIMPLE technologies enable multi-user text chat,
whereby users can exchange messages in the context of a room. The
term "room" usually is a synonym for a virtual environment where
people enter and exchange messages.
Groupchat messages are messages which are sent from a sender to
multiple recipients (i.e., two or more) in the context of a "multi-
user chat session", "text conference", or "chatroom". In XMPP a
groupchat message is a <message/> stanza of type "groupchat" that is
reflected from the sender to multiple recipients by a multi-user chat
service, as defined in [MUC]. In SIP/SIMPLE a groupchat message is
reflected from the sender to multiple recipients by a conference
server that uses MSRP to handle groupchat sessions, as defined in
[MSRP-MULTI].
As in [SIP-XMPP-IM] and related documents, the approach taken here is
to directly map syntax and semantics from one protocol to another.
The mapping described herein depends on the protocols defined in the
following specifications:
Saint-Andre, et al. Expires April 30, 2009 [Page 3]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
o XMPP chat sessions using message stanzas of type "groupchat" are
specified in [MUC].
o SIP-based chat room sessions using the SIP INVITE and SEND request
types are specified in [MSRP-MULTI].
1.3. Formal and Informal Sessions
[TBD] Does XMPP use Formal and Informal session also for group-chat?
1.4. Gateway Heuristics
[TBD]
1.5. Acknowledgements
Some text in this document was borrowed from [SIP-XMPP] and from
[MUC].
1.6. Discussion Venue
The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the
<sip-xmpp@xmpp.org> mailing list, for which archives and subscription
information are available at
<http://mail.jabber.org/mailman/listinfo/sip-xmpp>.
2. XMPP Group Chat to MSRP Multiparty Instant Message (IM) Session
This section describes how to map an XMPP Group Chat to a Multi-party
Instant Message (IM) MSRP session.
Saint-Andre, et al. Expires April 30, 2009 [Page 4]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Entering a room |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| | |
| |(F5) (MSRP) NICKNAME |
| |------------------------->|
| |(F6) (MSRP) 200 OK |
| |<-------------------------|
| | |
| |(F7) (SIP)SUBSCRIBE |
| |------------------------->|
| | Event:conference |
| | |
| |(F8) (SIP) 200 OK |
| |<-------------------------|
| | |
| |(F9) (SIP) NOTIFY |
| |<-------------------------|
| |(F10) (SIP) 200 OK |
| |------------------------->|
|(F11) (XMPP) Presence | |
|<-------------------------| |
| | |
|(F12) (XMPP) A chat message |
|------------------------->| |
| |(F13) (MSRP) SEND |
| |------------------------->|
| |(F14) (MSRP) 200 OK |
| |<-------------------------|
| | |
|(F15) (XMPP) echo chat message |
|--------------------------| |
. . .
. . .
|(F16) (XMPP) Exiting a room |
|------------------------->| |
| |(F17) (SIP) BYE |
| |------------------------->|
| |(F18) (SIP) 200 OK |
| |<-------------------------|
Saint-Andre, et al. Expires April 30, 2009 [Page 5]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
2.1. Entering a Room
When the XMPP user ("Juliet") wants to join a multi-user chat room
("Verona"), she sends a <presence/> stanza to the hostname hosting
that chat room, she also specifies the "nick" she desires to use
within the room ("juliet"). The Room Nickname is the resource
identifier portion of a Room JID. The Juliet client SHOULD signal
its ability to speak the multi-user chat protocol by including in the
initial presence stanza an empty <x/> element qualified by the
'http://jabber.org/protocol/muc' namespace.
Example: (F1) Juliet entering a chatroom
<presence from='juliet@example.com'
to='verona@chat.shakespeare.net/juliet'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
</presence>
Upon receiving such a presence stanza, the XMPP server to which
Juliet has authenticated attempts to deliver the stanza to a local
domain or attempts to route the presence stanza to the remote domain
that services the hostname in the 'to' attribute. Naturally, in this
document we assume that the hostname in the 'to' attribute is an Chat
Room-aware SIP service hosted by a separate server.
As specified in [XMPP-IM], the XMPP server needs to determine the
identity of the remote domain, which it does by performing one or
more [DNS-SRV] lookups. For presence stanzas, the order of lookups
recommended by [XMPP-IM] is to first try the "_xmpp-server" service
as specified in [XMPP] and to then try the "_im" service as specified
in [IMP-SRV]. Here we assume that the first lookup will fail but
that the second lookup will succeed and return a resolution
"_im._simple.shakespeare.net", since we have already assumed that the
shakespeare.net hostname is running a SIP instant messaging service.
(Note: The XMPP server may have previously determined that the remote
domain is a SIMPLE server, in which case it would not need to perform
the SRV lookups; the caching of such information is a matter of
implementation and local service policy, and is therefore out of
scope for this document.)
Once the XMPP server (example.com) has determined that the remote
domain is serviced by a SIMPLE server, it hands the XMPP presence
stanza off to its local XMPP-to-SIP gateway (x2s.example.com), which
transforms the presence stanza into SIP syntax and routes it to the
remote conference server (shakespeare.net).
As a compliant multi-user chat services MUST accept the presence
Saint-Andre, et al. Expires April 30, 2009 [Page 6]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
stanza containing an empty <x/> element qualified by the
'http://jabber.org/protocol/muc' namespace as a request to enter a
room; the XMPP-to-SIP gateway MUST transform it in a SIP INVITE
request.
Example: (F2) Juliet entering a chatroom (SIP transformation)
INVITE sip:verona@chat.shakespeare.net SIP/2.0
To: <sip:verona@chat.shakespeare.net>
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
Content-Type: application/sdp
Content-Lenght: [length]
c=IN IP4 x2s.shakespeare.net
m=message 7654 TCP/MSRP *
a=accept-types:text/cpim text/plain text/html
a=path:msrp://x2s.example.com:7654/jshA7weztas;tcp
a=chatroom:nickname private-message
Here the Session Description Protocol offer specifies the MSRP-aware
XMPP-to-SIP gateway on the XMPP side as well as other particulars of
the session.
There is no direct mapping for the MSRP URIs. In fact MSRP URIs
identify a session of instant messages at a particular device;
they are ephemeral and have no meaning outside the scope of that
session. The authority component of the MSRP URI MUST contain the
XMPP-to-SIP gateway hostname or numeric IP address and an explicit
port number.
As specified in [SIP-XMPP], the mapping of XMPP syntax elements to
SIP and SDP syntax elements SHOULD be as shown in the following
table. (Mappings for elements not mentioned are undefined.)
Table 1: Message syntax mapping from XMPP to SIP/SDP
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | SIP Header or SDP Contents |
+-----------------------------+-----------------------------+
| from | From |
| to (without the /nick) | To |
+-----------------------------+-----------------------------+
Here we assume that the chat room server accepts the session
establishment. It includes the 'isfocus' and other relevant feature
tags in the Contact header field of the response. The chat room
server also includes an answer session description that acknowledges
Saint-Andre, et al. Expires April 30, 2009 [Page 7]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
the choice of media and contains the extensions specified in
[MSRP-MULTI].
Example: (F3) the chat room accepts the session establishment
SIP/2.0 200 OK
To: <sip:verona@chat.shakespeare.net>
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
Contact: <sip:verona@chat.shakespeare.net;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Lenght: [length]
c=IN IP4 shakespeare.net
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
Upon receiving such a response, the SIMPLE server or associated SIP-
to-XMPP gateway MUST send a SIP ACK to the SIP user.
Example: (F4) the Gateway sends ACK to the chat room server
ACK sip:verona@chat.shakespeare.net SIP/2.0
To: <sip:verona@chat.shakespeare.net>;tag=087js
From: <sip:juliet@example.com>;tag=786
Call-ID: 711609sa
2.2. Setting up a nickname
If the chat room server accepted the session, the SIMPLE server or
associated SIP-to-XMPP gateway MUST set up the nickname as received
in the presence stanza. The nickname is set up using the extension
specified in [MSRP-MULTI]
Example: (F5) the Gateway set up the nickname
MSRP a786hjs2 NICKNAME
To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
Use-Nickname: "juliet"
-------a786hjs2
The chat room server analyzes the existing allocation of nicknames,
accepts the nick name proposal and answers with a 200 response.
Saint-Andre, et al. Expires April 30, 2009 [Page 8]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F6) the chat room accepts the nickname proposal
MSRP a786hjs2 200 OK
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
-------a786hjs2
2.3. Presence Broadcast
If the multi-user chat service accepts the request to enter a room,
the xmpp user expects to receive back presence information from all
the existing occupants' room. So the XMPP-to-SIP gateway MUST
SUBSCRIBE to the Conference Event package [RFC4575] on the MSRP
conference server. When the subscription is completed the MSRP
conference server send back to the XMPP-to-SIP gateway a NOTIFY with
the presence information from all the existing occupants' room
Example: (F9) the chat room notifies the presence information
NOTIFY sip:verona@chat.shakespeare.net SIP/2.0
To: Juliet <sip:juliet@example.com>;tag=43524545
From: <sip:verona@chat.shakespeare.net>;tag=a3343df32
Call-ID: k3l43id034ksereree
Event: conference
Subscription-State: active;expires=3600
Content-Type: application/conference-info+xml
Content-Length: ...
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<subject>Today in Verona</subject>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:romeo@example.com" state="full">
<nickname-text>romeo</nickname-text>
<roles>
<entry>participant</entry>
</roles>
</user>
</users>
</conference-info>
Saint-Andre, et al. Expires April 30, 2009 [Page 9]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
[NOTE: 1] a full mapping of RFC 4575 will be defined later on.
[NOTE: 2] the <nickname-text/> attribute is an extension to the
conference package explained but not defined in
[MSRP-MULTI]
[NOTE: 3] the subject (if present in the NOTIFY) must be sent with a
separate <message/> stanza; so after F11 there should be
another <message/> stanza from the gw to the joining party
[OPEN ISSUE: 1] how to send to the room jid with the subject child
set: do we need to send it in a different presence
stanza that the F11?
Upon receiving such a response, the SIP-to-XMPP gateway MUST send a
200 OK to the MSRP conference server and translate it in an xmpp
presence stanza.
Example: (F11) the chat room presence information translated in XMPP
<presence from='romeo@example.com/romeo'
to='verona@chat.shakespeare.net/juliet'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
As specified in ???, the mapping of SIP and SDP syntax elements to
XMPP syntax elements SHOULD be as shown in the following table.
(Mappings for elements not mentioned are undefined.)
Table 2: Message syntax mapping from SIP/SDP to XMPP
+-----------------------------+-----------------------------+
| SIP Header or SDP Contents | XMPP Element or Attribute |
+-----------------------------+-----------------------------+
| <user entity=...> | From |
| To + / <nickname-text> | To |
| roles | role |
| 'none' | affiliation |
+-----------------------------+-----------------------------+
[OPEN ISSUE: 1] how to match the <roles/> SIP Conference attribute
in the XMPP <affiliation/> and <role/>. In XMPP
roles are current privileges within the room while,
affiliations are kept permanently in different
sessions (they are the default for a given user).
Saint-Andre, et al. Expires April 30, 2009 [Page 10]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
2.4. Exchanging Messages
Once the user has joined the chat room, the user can exchange an
unbounded number of messages both public and private.
The mapping of XMPP syntax elements to MSRP syntax elements SHOULD be
as shown in the following table. (Mappings for elements not
mentioned are undefined.)
Table 3: Message syntax mapping from XMPP Message to MSRP
+-----------------------------+-----------------------------+
| XMPP Element or Attribute | CPIM Header |
+-----------------------------+-----------------------------+
| to | To |
| from | From |
| <body/> | body of the SEND request |
+-----------------------------+-----------------------------+
2.4.1. Sending a Message to All Occupants
When Juliet wants to sends a message to all other occupants in the
room, she sends a message of type "groupchat" to <room@service>
itself (i.e. <verona@chat.shakespeare.net> in our example).
The following examples show an exchange of a public message.
Example: (F12) Juliet sends a Message to all occupants
<message from='juliet@example.com'
to='verona@chat.shakespeare.net'
type='groupchat'>
<body>Who knows where Romeo is?</body>
</message>
Upon receiving such stanza message, the XMPP-to-SIP gateway MUST
translate it in an MSRP SEND message.
Saint-Andre, et al. Expires April 30, 2009 [Page 11]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F13) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND
To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:verona@chat.shakespeare.net;transport=tcp>
From: <sip:juliet@example.com>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
Who knows where Romeo is?
-------a786hjs2$
Upon receiving the SEND request, if the request either contains a
Failure-Report header field value of "yes" or does not contain a
Failure-Report header at all, MSRP conference server MUST immediately
generate and send a response.
MSRP d93kswow 200 OK
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
Since the XMPP room could be moderated and an XMPP User can not be
sure whether his message has been accepted or not, without an echo
from the server, the [MUC] states that the sender have to receive
back the same message it has generated. So in this scenario the
XMPP-to-SIP gateway has to generate the echo message.
2.4.2. Sending a Private Message
Since each occupant has a unique JID, Juliet MAY send a "private
message" to a selected occupant via the service by sending a message
to the occupant's room JID. The message type SHOULD be "chat" and
MUST NOT be "groupchat", but MAY be left unspecified.
The following examples show an exchange of a private message.
Saint-Andre, et al. Expires April 30, 2009 [Page 12]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F12) Juliet sends a private message
<message from='juliet@example.com'
to='verona@chat.shakespeare.net/romeo'
type='chat'/>
<body>O Romeo, Romeo! wherefore art thou Romeo?</body>
</message>
Upon receiving such stanza message, the XMPP-to-SIP gateway MUST
translate it in an MSRP SEND message.
Example: (F13) Gateway transforms XMPP message to MSRP
MSRP a786hjs2 SEND
To-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
Message-ID: 87652491
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:romeo@chat.shakespeare.net>
From: <sip:juliet@chat.shakespeare.net>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
O Romeo, Romeo! wherefore art thou Romeo?
-------a786hjs2$
2.5. Exiting a Room
If Juliet decides to exit the multi-user chat room, her client sends
a presence stanza of type "unavailable" to the
<verona@chat.shakespeare.net/juliet> she is currently using in the
room.
Example: (F16) Juliet exiting a chatroom
<presence from='juliet@example.com'
to='verona@chat.shakespeare.net/juliet'
type='unavailable'>
</presence>
Upon receiving such stanza exiting the multi-user chat room, the
XMPP-to-SIP gateway terminates the SIP session by sending a SIP BYE
to MSRP conference server. The MSRP conference server then responds
with a 200 OK.
Juliet MAY include a custom exit message in the presence stanza of
Saint-Andre, et al. Expires April 30, 2009 [Page 13]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
type "unavailable"
Example: (F16) Juliet exiting a chatroom
<presence from='juliet@example.com'
to='verona@chat.shakespeare.net/juliet'
type='unavailable'>
<status>I can not chat now!</status>
</presence>
Upon receiving such stanza exiting the multi-user chat room, the
XMPP-to-SIP gateway MUST before delivering the message and then,
after the message is successfully delivered, it terminates the SIP
session by sending a SIP BYE to MSRP conference server. The MSRP
conference server then responds with a 200 OK.
2.6. Nickname Conflict
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Entering a room |
|------------------------->| |
| |(F2) (SIP) INVITE |
| |------------------------->|
| |(F3) (SIP) 200 OK |
| |<-------------------------|
| |(F4) (SIP) ACK |
| |------------------------->|
| | |
| |(F5) (MSRP) NICKNAME |
| |------------------------->|
| |(F6) (MSRP) 423 OK |
| |<-------------------------|
| | |
|(F7) (XMPP) Presence Error
|<-------------------------| |
. . .
| |(F8) (SIP) BYE |
| |------------------------->|
| |(F9) (SIP) 200 OK |
| |<-------------------------|
The chat room server analyzes the existing allocation of nicknames,
and detects that the nickname proposal is already provided to another
partecipant by the conference. In this case the MSRP conference
server answers with a 423 response.
Saint-Andre, et al. Expires April 30, 2009 [Page 14]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F6) the chat room does not accept the nickname proposal
MSRP a786hjs2 423 Nickname usage failed
To-Path: msrp://x2s.example.com:7654/jshA7weztas;tcp
From-Path: msrp://s2x.shakespeare.net:12763/kjhd37s2s20w2a;tcp
-------a786hjs2
Upon receiving such a response, the SIP-to-XMPP gateway MUST
translate it in an xmpp presence stanza of type "error" specifying a
<conflict/> error condition.
Example: (F7) Juliet sends a Message to all occupants
<presence from='verona@chat.shakespeare.net'
to='juliet@example.com'
type='error'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
2.7. Changing Nickname
MSRP conference
XMPP User GW server
| | |
|(F1) (XMPP) Presence changing Nickname |
|------------------------->| |
| |(F2) (MSRP) NICKNAME |
| |------------------------->|
| |(F3) (MSRP) 200 OK |
| |<-------------------------|
If Juliet decides to changing her nickname within the room, she
SHOULD send an update presence information to the room, specifically
she SHOULD send a new Nickname in the same room.
Example: (F1) Juliet changing the nickname
<presence from='juliet@example.com'
to='verona@chat.shakespeare.net/July'>
</presence>
Saint-Andre, et al. Expires April 30, 2009 [Page 15]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
3. MSRP Multiparty Instant Message (IM) Session to XMPP Group Chat
This section describes how to map a Multi-party Instant Message (IM)
MSRP session to an XMPP Group Chat.
XMPP Chat
SIP User GW room
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
|(F2) (SIP) 200 OK | |
|<------------------------| |
|(F3) (SIP) ACK | |
|------------------------>| |
| | |
|(F4) (MSRP) NICKNAME | |
|------------------------>| |
| |(F5)(XMPP) Entering a room|
| |------------------------->|
|(F6) (MSRP) 200 OK | |
|<------------------------| |
| |(F7)(XMPP) (XMPP) Presence|
| |<-------------------------|
|(ISSUE)how to handle F7 | |
| if the user has not | |
| yet SUBSCRIBE to | |
| Event: conference | |
| | |
|(F8)(SIP) SUBSCRIBE | |
|------------------------>| |
| Event:conference | |
| | |
|(F9) (SIP) 200 OK | |
|<------------------------| |
| | |
|(F10) (SIP) NOTIFY | |
|<------------------------| |
|(F11) (SIP) 200 OK | |
|------------------------>| |
| | |
|(F12)(MSRP) SEND | |
|------------------------>| |
| |(F13)(XMPP) A chat message|
|(F14)(MSRP) 200 OK |------------------------->|
|<------------------------|(F15)(XMPP) A chat message|
| |<-------------------------|
|(F16)(MSRP) SEND | |
|<------------------------| |
Saint-Andre, et al. Expires April 30, 2009 [Page 16]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
|(F17)(MSRP) 200 OK | |
|------------------------>| |
. . .
. . .
| | |
|(F18)(SIP) BYE | |
|------------------------>| |
| |(F19)(XMPP) Exiting a room|
| |------------------------->|
|(F20)(SIP) 200 OK | |
|<------------------------| |
3.1. Entering a Room
When the MSRP user ("Romeo") wants to join a multi-user chat room
("Verona"), he first has to start the SIP session by sending out a
SIP INVITE request containing an offered session description that
includes an MSRP media line accompanied by a mandatory "path" and
"chatroom" attributes. The MSRP media line is also accompanied by an
"accept-types" attribute specifing support for a Message/CPIM top
level wrapper for the MSRP message.
Example: (F1) SIP user starts the session
INVITE sip:verona@chat.shakespeare.net SIP/2.0
To: <sip:verona@chat.shakespeare.net>
From: <sip:romeo@example.com>;tag=786
Call-ID: 742510no
Content-Type: application/sdp
Content-Lenght: [length]
c=IN IP4 s2x.example.net
m=message 7313 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://s2x.example.net:7313/ansp71weztas;tcp
a=chatroom:nickname private-message
[OPEN ISSUE: 1] [MSRP-MULTI] does not say anything abouth the
inclusion of the SDP "chatroom" attribute in the
INVITE however that is the only way for a GW to
understand the the INVITE is establishing a group-
chat session
Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine
the identity of the remote domain, which it does by performing one or
more DNS SRV lookups [DNS-SRV]. The SIP-to-XMPP gateway SHOULD
resolve the address present in the To header of the INVITE to an im
URI, then follow the rules in [IMP-SRV] regarding the "_im" SRV
Saint-Andre, et al. Expires April 30, 2009 [Page 17]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
service for the target domain contained in the To header. If SRV
address resolution fails for the "_im" service, the SIP-to-XMPP
gateway MAY attempt a lookup for the "_xmpp-server" service as
specified in [XMPP] or MAY return an error to the sender (i.e. 502
Bad Gateway).
If SRV address resolution succeeds, the SIP-to-XMPP gateway SHOULD
answer successfuly with a SIP 200 OK (F2), but it MUST not yet
translate the request into an XMPP presece stanza before the MSRP
user set up the nickname.
SIP/2.0 200 OK
To: <sip:verona@chat.shakespeare.net>
From: <sip:romeo@example.com>;tag=786
Contact: <sip:x2s.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Call-ID: 742510no
Content-Type: application/sdp
c=IN IP4 x2s.example.com
m=message 8763 TCP/MSRP *
a=accept-types:message/cpim text/plain text/html
a=path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
[OPEN ISSUE: 1] the GW could use a temporary nick name and translate
directly the request into a XMPP presence stanza,
entering the XMPP chat room
Example: (F4) the MSRP user set up the nickname
MSRP a786hjs2 NICKNAME
To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Use-Nickname: "romeo"
-------a786hjs2
Upon receiving the MSRP NICKNAME request, the SIP-to-XMPP gateway is
responsible to generate an XMPP presence stanza and sending it to the
hostname hosting that chat room.
Example: (F5) Romeo entering a chatroom
<presence from='romeo@example.com'
to='verona@chat.shakespeare.net/romeo'>
<x xmlns='http='http://jabber.org/protocol/muc'/>
</presence>
Saint-Andre, et al. Expires April 30, 2009 [Page 18]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
If the room does not already contain another user with the nickname,
the service accept the access. So if the GW does not receive any
stanza of type "error" specifying a <conflict/> error condition, it
MUST answer the MSRP nickname proposal with a 200 OK response (F6).
Example: (F6)
MSRP a786hjs2 200 OK
To-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
From-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
-------a786hjs2
3.2. Presence Broadcast
If the multi-user chat service is able to add the user to the room,
it sends presence from all the existing occupants' room JIDs to the
new occupants's full JID, including extended presence information
about roles in an <x/> element.
Example: (F7) the chat room presence information translated in XMPP
<presence from='verona@chat.shakespeare.net/juliet'
to='juliet@example.com'>
<x xmlns='http://jabber.org/protocol/muc#user'>
<item affiliation='none' role='participant'/>
</x>
</presence>
Upon receiving such a response, if the MSRP has already complited the
subscription to the Conference Event package [RFC4575], the XMPP-to-
SIP gateway MUST translate it in a SIP NOTIFY request.
Saint-Andre, et al. Expires April 30, 2009 [Page 19]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F10) the XMPP-to-SIP notifies the presence information
NOTIFY sip:romeo@example.com SIP/2.0
To: Juliet <sip:romeo@example.com>;tag=43524545
From: <sip:verona@chat.shakespeare.net>;tag=a3343df32
Call-ID: k3l43id034ksererff
Event: conference
Subscription-State: active;expires=3600
Content-Type: application/conference-info+xml
Content-Length: ...
<conference-info version="0" state="full"
entity="sip:3402934234@conf.example.com">
<conference-description>
<subject>Today in Verona</subject>
<conf-uris>
<entry>
<uri>tel:+18882934234</uri>
</entry>
</conf-uris>
</conference-description>
<users>
<user entity="sip:juliet@example.com" state="full">
<nickname-text>juliet</nickname-text>
<roles>
<entry>participant</entry>
</roles>
</user>
</users>
</conference-info>
3.3. Exchanging Messages
Once the user has joined the chat room, the user can exchange an
unbounded number of messages both public and private.
The mapping of MSRP syntax elements to XMPP syntax elements SHOULD be
as shown in the following table. (Mappings for elements not
mentioned are undefined.)
Saint-Andre, et al. Expires April 30, 2009 [Page 20]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
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/> |
+-----------------------------+-----------------------------+
3.3.1. Sending a Message to All Occupants
When Romeo wants to sends a message to all other occupants in the
room, he sends a MSRP SEND request to <room@service> itself (i.e.
<verona@chat.shakespeare.net> in our example).
Example: (F12) ROMEO sends a message to the chat room
MSRP a786hjs2 SEND
To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Message-ID: 87652492
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:verona@chat.shakespeare.net;transport=tcp>
From: <sip:juliet@example.com>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
Romeo is here!
-------a786hjs2$
Upon receiving the SEND request, if the request either contains a
Failure-Report header field value of "yes" or does not contain a
Failure-Report header at all, the SIP-to-XMPP gateway MUST
immediately translate in a xmpp message stanza (F13) and then
generate and send an MSRP response (F14).
The following examples show an exchange of a public message.
Example: (F13) Romeo sends a Message to all occupants
<message from='romeo@example.com'
to='verona@chat.shakespeare.net'
type='groupchat'>
<body>Romeo is here!</body>
</message>
Saint-Andre, et al. Expires April 30, 2009 [Page 21]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Example: (F14) the SIP-to-XMPP send the MSRP response
MSRP d93kswow 200 OK
To-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
From-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
-------d93kswow$
[OPEN ISSUE: 1] The SIP-to-XMPP gateway will receive back the echo
message from the Chat room service. The SIP-to-XMPP
gateway has to translate it back to the MSRP user or
no?
3.3.2. Sending a Private Message
Romeo MAY send a "private message" to a selected occupant via the
chat room service by sending a message to the occupant's room nick
name.
The following examples show an exchange of a private message.
Example: (F12) Romeo sends a private message
MSRP a786hjs2 SEND
To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Message-ID: 87652492
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:juliet@chat.shakespeare.net>
From: <sip:romeo@example.com>
DateTime: 2008-10-15T15:02:31-03:00
Content-Type: text/plain
I am here!!!
-------a786hjs2$
Example: (F13) Juliet sends a private message
<message from='romeo@example.com'
to='verona@chat.shakespeare.net/juliet'
type='chat'/>
<body>I am here!!!</body>
</message>
Saint-Andre, et al. Expires April 30, 2009 [Page 22]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
3.4. Exiting a Room
If Romeo decides to exit the multi-user chat room, his client sends
SIP BYE to the <verona@chat.shakespeare.net> chat room.
Example: (F11) Romeo terminates the session
BYE sip:verona@chat.shakespeare.net SIP/2.0
Max-Forwards: 70
From: <sip:romeo@example.net>;tag=786
To: <sip:verona@chat.shakespeare.net>;tag=534
Call-ID: 742510no
Cseq: 1 BYE
Content-Length: 0
Upon receiving the SIP BYE, the SIP-to-XMPP gateway translate it in a
presence stanza (F19) and send it to the XMPP chat room service.
Then the SIP-to-XMPP gateway responds with a 200 OK to the MSRP user.
Example: (F19) Juliet exiting a chatroom
<presence from='romeo@example.com'
to='verona@chat.shakespeare.net/romeo'
type='unavailable'>
</presence>
3.5. Nickname Conflict
XMPP conference
SIP User GW server
| | |
|(F1)(SIP) INVITE | |
|------------------------>| |
|(F2) (SIP) 200 OK | |
|<------------------------| |
|(F3) (SIP) ACK | |
|------------------------>| |
| | |
|(F4) (MSRP) NICKNAME | |
|------------------------>| |
| |(F5)(XMPP) Entering a room|
| |------------------------->|
| |(F7) (XMPP) Presence Error|
| |<-------------------------|
|(F6) (MSRP) 423 OK | |
|<------------------------| |
| | |
Saint-Andre, et al. Expires April 30, 2009 [Page 23]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
3.6. Changing Nickname
XMPP conference
SIP User GW server
| | |
|(F1) (MSRP) NICKNAME | |
|------------------------->| |
| |(F2) (XMPP) Presence changing Nickname
| |------------------------->|
|(F3) (MSRP) 200 OK | |
|<-------------------------| |
If Romeo decides to changing her nickname within the room, he SHOULD
send a new MSRP NICKNAME request. In fact modification of the
nickname in MSRP is not different from the initial reservation and
usage of a nickname.
Example: (F1) the MSRP user changes the nickname
MSRP a786hjs2 NICKNAME
To-Path: path:msrp://s2x.example.net:7313/ansp71weztas;tcp
From-Path: path:msrp://x2s.example.com:8763/lkjh37s2s20w2a;tcp
Use-Nickname: "montecchi"
-------a786hjs2
Upon receiving such message, the SIP-to-XMPP gateway MUST translate
it in a XMPP presence stanza.
Example: (F2) Juliet changing the nickname
<presence from='juliet@example.com'
to='verona@chat.shakespeare.net/montecchi'>
</presence>
4. Security Considerations
To follow.
5. References
5.1. Normative References
[IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging
and Presence", RFC 3861, August 2004.
Saint-Andre, et al. Expires April 30, 2009 [Page 24]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
[MSRP] Campbell, B., Mahy, R., and C. Jennings, "The Message
Session Relay Protocol (MSRP)", RFC 4975, September 2007.
[MUC] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045,
April 2007.
[OFFER] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264,
June 2002.
[SIP] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-IM] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004.
5.2. Informative References
[BOSH] Paterson, I., Smith, D., and P. Saint-Andre,
"Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
XEP 0124, February 2007.
[BOSH-XMPP]
Paterson, I., "XMPP Over BOSH", XSF XEP 0206, June 2007.
[CAPS] Hildebrand, J., Saint-Andre, P., Troncon, R., and J.
Konieczny, "Entity Capabilities", XSF XEP 0115,
February 2008.
[DISCO] Hildebrand, J., Millard, P., Eatmon, R., and P. Saint-
Andre, "Service Discovery", XSF XEP 0030, June 2008.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[I-D.saintandre-sip-xmpp-chat]
Saint-Andre, P., Gavita, E., Hossain, N., and S. Loreto,
"Interworking between the Session Initiation Protocol
Saint-Andre, et al. Expires April 30, 2009 [Page 25]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
(SIP) and the Extensible Messaging and Presence Protocol
(XMPP): One-to-One Text Chat",
draft-saintandre-sip-xmpp-chat-02 (work in progress),
July 2008.
[MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message
Bodies", RFC 2045, November 1996.
[MSRP-MULTI]
Niemi, A., Garcia-Martin, M., and G. Sandbakken, "Multi-
party Instant Message (IM) Sessions Using the Message
Session Relay Protocol (MSRP)", draft-ietf-simple-chat-02
(work in progress), February 2008.
[RECEIPTS]
Saint-Andre, P. and J. Hildebrand, "Message Receipts", XSF
XEP 0184, September 2007.
[RFC4575] Rosenberg, J., Schulzrinne, H., and O. Levin, "A Session
Initiation Protocol (SIP) Event Package for Conference
State", RFC 4575, August 2006.
[SDP] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
[SIP-MSG] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[SIP-XMPP]
Saint-Andre, P., Houri, A., and J. Hildebrand,
"Interworking between the Session Initiation Protocol
(SIP) and the Extensible Messaging and Presence Protocol
(XMPP): Core", draft-saintandre-sip-xmpp-core-00 (work in
progress), January 2008.
[SIP-XMPP-IM]
Saint-Andre, P., Houri, A., and J. Hildebrand,
"Interworking between the Session Initiation Protocol
(SIP) and the Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging",
draft-saintandre-sip-xmpp-im-00 (work in progress),
January 2008.
[XHTML-IM]
Saint-Andre, P., "XHTML-IM", XSF XEP 0071, August 2007.
Saint-Andre, et al. Expires April 30, 2009 [Page 26]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Authors' Addresses
Peter Saint-Andre
XMPP Standards Foundation
P.O. Box 1641
Denver, CO 80201
USA
Email: stpeter@jabber.org
URI: https://stpeter.im/
Salvatore Loreto
Ericsson
Hirsalantie 11
Jorvas 02420
Finland
Email: Salvatore.Loreto@ericsson.com
Fabio Forno
Bluendo srl
Via Morosini 10
Torino 10128
Italy
Email: fabio@bluendo.com
Saint-Andre, et al. Expires April 30, 2009 [Page 27]
Internet-Draft SIP-XMPP Interworking: Chat Oct 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Saint-Andre, et al. Expires April 30, 2009 [Page 28]