| Network Working Group | A. Niemi |
| Internet-Draft | Nokia |
| Intended status: Standards Track | M. Garcia-Martin |
| Expires: September 01, 2012 | Ericsson |
| G.A. Sandbakken, Ed. | |
| Cisco Systems | |
| March 2, 2012 |
Multi-party Chat Using the Message Session Relay Protocol (MSRP)
draft-ietf-simple-chat-14
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 chat sessions, or chat rooms, using MSRP.
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 September 01, 2012.
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (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.
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
The Message Session Relay Protocol (MSRP) [RFC4975] defines a mechanism for sending a series of instant messages within a session. The Session Initiation Protocol (SIP) [RFC3261] in combination with the Session Description Protocol (SDP) [RFC4566] allows for two peers to establish and manage such sessions.
In another application of SIP, a user agent can join in a multi-party conversation called a conference that is hosted by a specialized user agent called a focus [RFC4353]. Such a conference can naturally involve MSRP sessions. It is the responsibility of an entity handling the media to relay instant messages received from one participant to the rest of the participants in the conference.
Several such systems already exist in the Internet. Participants in a chat room can be identified with a pseudonym or nickname, and decide whether their real identifier is disclosed to other participants. Participants can also use a rich set of features such as the ability to send private instant messages to other participants.
Similar conferences supporting chat rooms are already available today. For example, Internet Relay Chat (IRC) [RFC2810], Extensible Messaging and Presence Protocol (XMPP): Core [RFC6120] based chat rooms, and many other proprietary systems provide chat room functionality. Specifying equivalent functionality for MSRP-based systems provides competitive features and enables interworking between the systems.
This document defines requirements, conventions, and extensions for providing private messages and nickname management in centralized chat rooms with MSRP. Participants in a chat room can be identified by a pseudonym, and decide if their real identifier is disclosed to other participants. This memo uses the SIP Conferencing Framework [RFC4353] as a design basis. It also aims to be compatible with the A Framework for Centralized Conferencing [RFC5239]. Should requirements arise, future mechanisms for providing similar functionality in generic conferences might be developed, for example, where the media is not only restricted to MSRP. The mechanisms described in this document provide a future compatible short-term solution for MSRP centralized chat rooms.
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, BCP 14 [RFC2119], and indicate requirement levels for compliant implementations.
This memo deals with tightly coupled SIP conferences defined in SIP Conferencing Framework [RFC4353] and adopts the terminology from that document. In addition to that terminology, we introduce some new terms:
Although conference frameworks describing many types of conferencing applications already exist, such as the Framework for Centralized Conferencing [RFC5239] and the SIP Conferencing Framework [RFC4353], the exact details of session-based instant messaging conferences (chat rooms) are not well-defined at the moment.
To allow interoperable chat implementations, for both conference-aware, and conference-unaware user agents, certain conventions for MSRP chat rooms need to be defined. It also seems beneficial to provide a set of features that enhance the baseline multi-party MSRP in order to be able to create systems that have functionality on par with existing chat systems, as well as enable building interworking gateways to these existing chat systems.
We define the following requirements:
In order to enter a chat room, one must first be created. Users wishing to host a chat room themselves can of course do just that; their User Agent (UA) simply morphs from an ordinary UA into a special purpose one called a Focus UA. Another, commonly used setup is one where a dedicated node in the network functions as a Focus UA.
Each chat room has an identifier of its own: a SIP URI that participants use to join the chat room, e.g. by sending an INVITE request to it. The conference focus processes the invitations, and as such, maintains SIP dialogs with each participant. In a multi-party chat, or chat room, MSRP is one of the established media streams. Each chat room participant establishes an MSRP session with the MSRP switch, which is a special purpose MSRP application. The MSRP sessions can be relayed by one or more MSRP relays, which are specified in RFC 4976 [RFC4976]. This is illustrated in Figure 1
MSRP Sessions
+---------------------------+
| +-----------+ |
+---+--+ +---+--+ | |
| SIP | | SIP | | |
| MSRP | | MSRP | +--+---+----+
|Client| |Client| | MSRP |
+---+--+ ++-----+ | Relay |
| | +-----+-----+
SIP Dialogs | / |
| | | MSRP Sessions
+----+------+--+ |
| Conference | +-------+-----+
| Focus UA | | MSRP |
| |........| Switch |
| | | |
+---+--------+-+ +-------+-----+
| \ |
SIP Dialogs | | | MSRP Sessions
| \ |
+--+---+ +-+----+ +-----+------+
| SIP | | SIP | | MSRP |
| MSRP | | MSRP | | Relay |
|Client| |Client| +-+-------+--+
+---+--+ +--+---+ | |
| +-----------+ |
+------------------------------+
MSRP sessions
The MSRP switch is similar to a conference mixer in that it handles media sessions with each of the participants and bridges these streams together. However, unlike a conference mixer, the MSRP switch merely forwards messages between participants but doesn't actually mix the streams in any way. The system is illustrated in Figure 2.
+------+
| MSRP |
|Client|
+------+ +--.---+ +------+
| MSRP | | | MSRP |
|Client| | _|Client|
+------._ | ,' +------+
`._ | ,'
`.. +----------+ ,'
`| |'
| MSRP |
| Switch |
,| |_
_,-'' +----------+ ``-._
+------.-' | `--+------+
| MSRP | | | MSRP |
|Client| | |Client|
+------+ | +------+
+---'--+
| MSRP |
|Client|
+------+
Typically chat room participants also subscribe to a conference event package to gather information about the conference roster in the form of conference state notifications. For example, participants can learn about other participants' identifiers, including their nicknames.
All messages in the chat room use the 'Message/CPIM' wrapper content type [RFC3862], so that it is possible to distinguish between private and regular messages. When a participant wants to send an instant message to the chat room, it constructs an MSRP SEND request and submits it to the MSRP switch including a regular payload (e.g. a Message/CPIM message that contains a text, HTML, an image, etc.). The Message/CPIM To header is set to the chat room URI. The switch then fans out the SEND request to all of the other participants using their existing MSRP sessions.
A participant can also send a private instant message addressed to a participant whose identifier has been learned, e.g. via a conference event package. In this case the sender creates an MSRP SEND request with a Message/CPIM wrapper whose To header contains not the chat room URI but the recipient's URI. The MSRP switch then forwards the SEND request to that recipient. This specification supports the sending of private messages to one and only one recipient. However, if the recipient is logged from different endpoints, the MSRP switch will distribute the private message to each endpoint the recipient is logged.
We extend the current MSRP negotiation that takes place in SDP [RFC4566] to allow participants to learn whether the chat room supports and is willing to accept (e.g. due to local policy restrictions) certain MSRP functions defined in this memo, such as nicknames or private messaging.
Naturally, when a participant wishes to leave a chat room, it sends a SIP BYE request to the Focus UA and terminates the SIP dialog with the focus and MSRP sessions with the MSRP switch.
This document assumes that each chat room is allocated its own SIP URI. A user joining a chat room sends an INVITE request to that SIP URI, and as a result, a new MSRP session is established between the user and the MSRP switch. It is assumed that an MSRP session is mapped to a chat room. If a user wants to join a second chat room, he creates a different INVITE request, through a different SIP dialog, which leads to the creation of a second MSRP session between the user and the MSRP switch. Notice that these two MSRP sessions can still be multiplexed over the same TCP connection as per regular MSRP procedures. However, each chat room is associated to a unique MSRP session and a unique SIP dialog.
Since we consider a chat room a particular type of conference having MSRP media, the methods defined by the SIP Conference Framework [RFC4353] for creating conferences are directly applicable to a chat room.
Once a chat room is created, it is identified by a SIP URI, like any other conference.
Participants usually join the chat room by sending an INVITE request to the chat room URI. As long as the chat room policy allows, the INVITE request is accepted by the focus and the user is brought into the actual chat room.
The MSRP switch needs to be aware of the URIs of the participant (SIP, Tel, or IM URIs) in order to validate messages sent from this participant prior to their forwarding. This information is known to the focus of the conference. Therefore an interface between the focus and the MSRP switch is assumed. However, the interface between the focus and the MSRP switch is outside the scope of this document.
Conference-aware participants will detect that the peer is a focus due to the presence of the "isfocus" feature tag [RFC3840] in the Contact header field of the 200-class response to the INVITE request. Conference-unaware participants will not notice it is a focus, and can not apply the additional mechanisms defined in this document. Participants are also aware that the mixer is an MSRP switch due to the presence of a 'message' media type and either TCP/MSRP or TCP/TLS/MSRP as the protocol field in the media line of SDP [RFC4566].
The conference focus of a chat room MUST include support for a Message/CPIM [RFC3862] top-level wrapper for the MSRP messages by setting the 'accept-types' MSRP media line attribute in the SDP offer or answer [RFC3264] to include 'Message/CPIM'.
If a participant wants to remain anonymous to the rest of the participants in the chat room, the participant's UA must provide an anonymous URI to the conference focus. The URI will be used in the From and To headers in the 'Message/CPIM' wrapper, and can be learned by the other participants of the chat room. Notice that in order for the anonymity mechanism to work, the anonymous URI must not reveal the participant's SIP AOR. The mechanism for acquiring an anonymous URI is outside the scope of this specification.
The conference focus of a chat room MUST learn the chat room capabilities of each participant that joins the chat room. The conference focus MUST inform the MSRP switch of such support in order to prevent the MSRP switch from distributing private messages to participants who do not support private messaging. The recipient would not be able to render the message as private, and any potential reply would be sent to the whole chat room.
As with creating a conference, the methods defined by the SIP Conference Framework [RFC4353] for deleting a conference are directly applicable to a chat room. The MSRP switch will terminate the MSRP sessions with all the participants.
Deleting a chat room is an action that heavily depends on the policy of the chat room. The policy can determine that the chat room is deleted when the creator leaves the chat room, or with any out of band mechanism.
This section describes the conventions used to send and receive instant messages that are addressed to all the participants in the chat room. These are sent over a regular MSRP SEND request that contains a Message/CPIM wrapper [RFC3862] that in turn contains the desired payload (e.g. text, image, video-clip, etc.).
When a chat room participant wishes to send an instant message to all the other participants in the chat room, it constructs an MSRP SEND request according to the procedures specified in RFC 4975 [RFC4975]. The sender MAY choose the desired MSRP report model (e.g., populate the Success-Report and Failure-Report MSRP header fields).
The SEND request MUST contain a top-level wrapper of type 'Message/CPIM' according to RFC 3862 [RFC3862]. The actual instant message payload MUST be included as payload of the 'Message/CPIM' wrapper and MAY be of any type negotiated in the SDP 'accept-types' attribute according to the MSRP rules.
On sending a regular message the sender MUST populate the To header of the Message/CPIM wrapper with the URI of the chat room. The sender SHOULD populate the From header of the Message/CPIM wrapper with a proper identifier by which the user is recognized in the chat room. Identifiers that can be used (among others) are:
An MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI of a participant. This imposes a requirement for the focus of the conference to inform the MSRP switch of the URIs by which the participant is known, in order for the MSRP switch to validate messages. Section 6.3 provides further information with the actions to be taken in case this validation fails.
Then the MSRP switch should inspect the To header field of the Message/CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then, if the To header field of the Message/CPIM wrapper contains the chat room URI and there are no other To header fields, the MSRP switch can generate a copy of the SEND request to each of the participants in the chat room except the sender. The MSRP switch MUST NOT modify the content received in the SEND request. However, the MSRP switch MAY re-chunk any of the outbound MSRP SEND requests.
Note that the MSRP switch does not need to wait for the reception of the complete MSRP chunk or MSRP message before it starts the distribution to the rest of the participants. Instead, once the MSRP switch has received the headers of the Message/CPIM wrapper it SHOULD start the distribution process.
When forwarding chunked messages as soon as they are received, the Message/CPIM wrapper is only present at the beginning of the message, typically within the first chunk. Subsequent chunks will contain the rest of the message, but not the Message/CPIM headers. Therefore, an MSRP switch that receives a subsequent message may face challenges in determining the correct list of recipients of the message. An MSRP switch that uses this fast forwarding procedure MUST temporarily store the Message-Id of the MSRP message to correlate the different chunks, as well as it MUST temporarily store the list of recipients to which the initial chunks were delivered. The MSRP switch SHOULD forward subsequent chunks only to those recipients who were sent the initial chunks, except if the MSRP switch has knowledge that one of the recipients of the initial chunks has dropped from the chat room. This behavior also avoids new participants who joined the chat room when the first chunk has been distributed to receive subsequent chunks that would otherwise need to be discarded.
An MSRP endpoint that receives a SEND request from the MSRP switch containing a Message/CPIM wrapper SHOULD first inspect the To header field of the Message/CPIM wrapper. If the To header field is set to the chat room URI, it should render it as a regular message that has been distributed to all the participants in the chat room. Then the MSRP endpoint SHOULD inspect the From header field of the Message/CPIM wrapper to identify the sender. The From header field will include a URI that identifies the sender. The endpoint might have also received further identifier information through a subscription to a conference event package.
This section describes the conventions used to send and receive private instant messages, i.e., instant messages that are addressed to one participant of the chat room rather to all of them. A chat room can signal support for private messages using the 'chatroom' attribute in SDP (see Section 8 for details).
When a chat room participant wishes to send a private instant message to a participant in the chat room, it follows the same procedures for creating a SEND request as for regular messages [regular]. The only difference is that the MSRP endpoint MUST populate a single To header of the Message/CPIM wrapper with the identifier of the intended recipient. The identifier can be SIP, TEL, and IM URIs typically learned from the information received in notifications of a conference event package.
As for regular messages, an MSRP switch that receives a SEND request from a participant SHOULD first verify that the From header field of the Message/CPIM wrapper is correctly populated with a valid URI (i.e., the URI is a participant of this chat room). Section 6.3 provides further information with the actions to be taken in case this validation fails.
Then the MSRP switch MUST inspect the To header field of the Message/CPIM wrapper. If the MSRP switch receives a message containing several To header fields in the Message/CPIM wrapper the MSRP switch MUST reject the MSRP SEND request with a 403 response, as per procedures in RFC 4975 [RFC4975]. Then the MSRP switch MUST verify that the To header of the Message/CPIM wrapper matches the URI of a participant of the chat room. If this To header field does not contain the URI of a participant of the chat room or if the To header field cannot be resolved (e.g., caused by a mistyped URI), the MSRP switch MUST reject the request with a 404 response. This new 404 status code indicates a failure to resolve the recipient URI in the To header field of the Message/CPIM wrapper.
Finally, the MSRP switch MUST verify that the recipient supports private messages. If the recipient does not support private messages, the MSRP switch MUST reject the request with a 428 response. This new response 428 indicates that the recipient does not support private messages. Any potential REPORT request that the MSRP switch sends to the sender MUST include a Message/CPIM wrapper containing the original From header field included in the SEND request and the To header field of the original Message/CPIM wrapper. The MSRP switch MUST NOT forward private messages to a recipient that does not support private messaging.
If successful, the MSRP switch should search its mapping table to find the MSRP sessions established towards the recipient. If a match is found the MSRP switch MUST create a SEND request and MUST copy the contents of the sender's message to it.
An MSRP endpoint that receives a SEND request from the MSRP switch does the same validations as for regular messages [regular]. If the To header field is different from the chat room URI, the MSRP endpoints knows that this is a private message. The endpoint should render who it is from based on the value of the From header of the Message/CPIM wrapper. The endpoint can also use the sender’s nickname, possibly learned via a conference event package, to render such nickname rather than the sender’s actual URI.
It is possible that a participant, identified by a SIP Address of Record or other valid URI, joins a chat room from two or more different SIP UAs. It is RECOMMENDED that the MSRP switch can map a URI to two or more MSRP sessions. If the policy of the server allows for this, the MSRP switch MUST copy all messages intended to the recipient through each MSRP session mapped to the recipient's URI.
This section discusses the common procedures for regular and private messages with respect to MSRP reports and responses. Any particular procedure affecting only regular messages or only private messages is discussed in the previous Section 6.1 or Section 6.2, respectively.
MSRP switches MUST follow the success report and failure report handling described in section 7 of RFC 4975 [RFC4975], complemented with the procedures described in this section. The MSRP switch MUST act as an MSRP endpoint receiver of the request according to section 5.3 of RFC 4975 [RFC4975].
If the MSRP switch receives an MSRP SEND request that does not contain a Message/CPIM wrapper, the MSRP switch MUST reject the request with a 415 response (specified in RFC 4975 [RFC4975]).
If the MSRP switch receives an MSRP SEND request where the URI included in the From header field of the Message/CPIM wrapper is not valid, (e.g, because it does not "belong" to the sender of the message or is not a valid participant of the chat room), the MSRP switch MUST reject the request with a 403 response. In non-error cases, the MSRP switch MUST construct responses according to section 7.2 of RFC 4975 [RFC4975].
When the MSRP switch forwards a SEND request, it MAY use any report model in the copies intended for the recipients. The receiver reports from the recipients MUST NOT be forwarded to the originator of the original SEND request. This could lead to having the sender receiving multiple reports for a single MSRP request.
Congestion can occur when multiple heterogeneous interfaces are used by a diversity of users who are participating in a chat room. Some of these users might have fast path capable of high throughputs while other users might be slow paths with constrained throughputs. It is therefore possible that a subset of the participants of the chat room are able to send and receive messages at a high rate or with large contents (e.g., pictures), whereas others are not able to keep the pace.
Additionally, since MSRP uses a connection-oriented transport protocol such as TCP, it is expected that the TCP congestion avoidance mechanisms will also be activated should congestion occur.
While this document does not mandate a particular MSRP-specific mechanism to avoid congestion in any of the paths, something that is deemed outside the scope of this document, this document provides some recommendations for implementors to consider.
It is RECOMMENDED that MSRP switches implement one or more MSRP-specific strategies to detect and avoid congestion. Possible strategies (but definitely not a comprehensive list) include:
A common characteristic of existing chat room services is that participants have the ability to present themselves with a nickname to the rest of the participants of the chat room. It is used for easy reference of participants in the chat room, and can also provide anonymous participants with a meaningful descriptive name.
A nickname is a useful construct in many use cases, of which MSRP chat is but one example. It is associated with a URI of which the participant is known to the focus. Therefore, if a user joins the chat room under the same URI from multiple devices, he or she may request the same nickname across all these devices.
A nickname is a user selectable appearance of which the participant wants to be known to the other participants. It is not a 'display-name', but it is used somewhat like a display name. A main difference is that a nickname is unique inside a chat room to allow an unambiguous reference to a participant in the chat. Nicknames may be long lived, or may be temporary. Users also need to reserve a nickname prior to its utilization.
This memo specifies the nickname as a string. The nickname string MUST be unambiguous within the scope of the chat room (conference instance). This scope is similar to having a nickname unique inside a chat room from Extensible Messaging and Presence Protocol [RFC6120]. The chat room may have policies associated with nicknames. It may not accept nickname strings at all, or a it may provide a wider unambiguous scope like a domain or server, similar to Internet Relay Chat (IRC) [RFC2810].
This memo provides a mechanism to reserve a nickname for a participant for as long as the participant is logged into the chat room. The mechanism is based on a NICKNAME MSRP method (see below) and a new "Use-Nickname" header. Note that other mechanisms may exist (for example, a web page reservation system), although they are outside the scope of this document.
A chat room participant who has established an MSRP session with the MSRP switch, where the MSRP switch has indicated the support and availability of nicknames with the 'nicknames' token in the 'chatroom' SDP attribute, MAY send a NICKNAME request to the MSRP switch. The NICKNAME request MUST include a new Use‑Nickname header that contains the nickname string that the participant wants to reserve. MSRP NICKNAME requests MUST NOT include Success-Report or Failure-Report header fields.
An MSRP switch that receives a NICKNAME request containing a Use‑Nickname header field SHOULD first verify whether the policy of the chat room allows the nickname functionality. If not allowed, the MSRP switch MUST reject the request with a 403 response, as per RFC 4975 [RFC4975].
If the policy of the chat room allows the usage of nicknames, the MSRP switch SHOULD validate that the SIP AOR identifying the user is entitled to reserve the nickname. This may include, e.g., allowing that the participant's URI may use the same nickname when the participant has joined the chat room from different devices under the same URI. The participant's authenticated identifier can be derived after a successful SIP Digest Authentication [RFC3261], be included in a trusted SIP P-Asserted-Identity header field [RFC3325], be included in a valid SIP Identity header field [RFC4474], or be derived from any other present or future SIP authentication mechanism. Once the MSRP switch has validated that the participant is entitled to reserve the requested nickname, the MSRP switch verifies if the suggested nickname can be accepted (see below).
The reservation of a nickname can fail in several cases. If the NICKNAME request contains a malformed value in the Use‑Nickname header field, the MSRP switch MUST answer the NICKNAME request with a 424 response code. This can be the case when the value of the Use‑Nickname header field does not conform to the syntax.
The reservation of a nickname can also fail if the value of the Use‑Nickname header field of the NICKNAME request is a reserved word (not to be used as a nickname by any user) or that particular value is already in use by another user. In this case the MSRP switch MUST answer the NICKNAME request wihta 425 response code.
In both error conditions (receiving a 424 or 425 respose code), the nickname usage is considered failed; the nickname is not allocated to this user. The user can select a different nickname and retry another NICKNAME request. nickname is not allocated to this user".
If the MSRP switch is able to accept the suggested nickname to be used by this user, the MSRP switch MUST answer the NICKNAME request with a 200 response as per regular MSRP procedures.
As indicated earlier, this specification defines a new MSRP header field: "Use-Nickname". The Use‑Nickname header field carries a nickname string. This specification defines the usage of the Use‑Nickname header field in NICKNAME requests. If need arises, usages of the Use‑Nickname header field in other MSRP methods should be specified separately.
The syntax of the NICKNAME method and the "Use-Nickname" header field is built upon the MSRP formal syntax [RFC4975]
ext-method =/ NICKNAMEm
NICKNAMEm = %x4E.49.43.4B.4E.41.4D.45 ; NICKNAME in caps
ext-header =/ Use-Nickname
; ext-header defined in RFC 4975
Use-Nickname = "Use-Nickname:" SP nickname
nickname = quoted-string
; quoted-string defined in RFC 4975
Note that, according to RFC 4975 [RFC4975], "quoted-string" admits a subset of UTF-8 characters [RFC3629]. Please refer to Section 9 of RFC 4975 [RFC4975] for more details.
Once the MSRP switch has reserved a nickname and has bound it to a URI (e.g., a SIP Address-of-Record), the MSRP server MAY allow the usage of the same nickname by the same user (identified by the same URI, such as a SIP AoR) over a second MSRP session. This might be the case if the user joins the same chat room from a different SIP User Agent. In this case, the user MAY request the same or a different nickname than that used in conjunction with the first MSRP session; the MSRP server MAY accept the usage of the same nickname by the same user. The MSRP switch MUST NOT automatically assign the same nickname to more than one MSRP session established from the same URI, because this can create confusion to the user as whether the same nickname is bound to the second MSRP session.
Typically a participant will reserve a nickname as soon as the participant joins the chat room. But it is also possible for a participant to modify his/her own nickname and replace it with a new one at any time during the duration of the MSRP session. Modification of the nickname is not different from the initial reservation and usage of a nickname, thus the NICKNAME method is used as described in Section 7.1.
If a NICKNAME request that attempts to modify the current nickname of the user for some reason fails, the current nickname stays in effect. A new nickname comes into effect and the old one is released only after a NICKNAME request is accepted with a 200 response.
If the participant no longer wants to be known by a nickname in the chat room, the participant can follow the method described in Section 7.2. The nickname element of the Use‑Nickname header MUST be set to an empty quoted string.
Typically the conference focus acts as a notifier of the conference event package. To notify subscribers of the nickname reserved for a given participant, it is RECOMMENDED that conference focus and endpoints support Conference Event Package Data Format Extension for Centralized Conferencing [I-D.ietf-xcon-event-package]. The Conference Information Data Model for Centralized Conferencing [I-D.ietf-xcon-common-data-model] extends the user element from RFC 4575 [RFC4575] with a 'nickname' attribute.
There are a handful of use cases where a participant would like to learn the chat room capabilities supported by the MSRP switch and the chat room. For example, a participant would like to learn if the MSRP switch supports private messaging, otherwise, the participant may send what he believes is a private instant message addressed to a participant, but since the MSRP switch does not support the functions specified in this memo, the message gets eventually distributed to all the participants of the chat room.
The reverse case also exists. A participant, say Alice, whose user agent does not support the extensions defined by this document joins the chat room. The MSRP switch learns that Alice's application does not support private messaging nor nicknames. If another participant, say Bob, sends a private message to Alice, the MSRP switch does not distribute it to Alice, because Alice is not able to differentiate it from a regular message sent to the whole roster. Furthermore, if Alice replied to this message, she would do it to the whole roster. Because of this, the MSRP switch also keeps track of users who do not support the extensions defined in this document.
In another scenario, the policy of a chat room may indicate that certain functions are not allowed. For example, the policy may indicate that nicknames or private messages are not allowed.
In order to provide the user with a good chat room experience, we define a new 'chatroom' SDP attribute. The 'chatroom' attribute is a media-level value attribute [RFC4566] that MAY be included in conjunction with an MSRP media stream (i.e., when an m= line in SDP indicates "TCP/MSRP" or "TCP/TLS/MSRP"). The 'chatroom' attribute without further modifiers (e.g., chat-tokens) indicates that the endpoint supports the procedures described in this document for transferring MSRP messages to/from a chat room. The 'chatroom' attribute can be complemented with additional modifiers that further indicate the intersection of support and local policy allowance for a number of functions specified in this document. Specifically, we provide the means for indicating support to use nicknames and private messaging.
The 'chatroom' attribute merely indicates the capabilities supported and allowed by the local policy. This attribute is not a negotiation subject to the SDP offer/answer model [RFC3264], but instead a declaration. Therefore, a 'chatroom' attribute included in an SDP answer does not need to be a subset of the values included in the 'chatroom' attribute of its corresponding SDP offer. Consequently, an SDP answer MAY contain a 'chatroom' attribute even if its corresponding SDP offer did not include it.
On doing subsequent SDP offer/answer [RFC3264] exchanges pertaining to the same session, the 'chatroom' attribute MAY be modified with respect an earlier SDP offer/answer exchange. The new value of this attribute indicate the current support and local policy, meaning that some restrictions can apply now or might have been removed. If the 'chatroom' attribute is not included in a subsequent SDP offer/answer, but is corresponding MSRP stream is still in place, it indicates that support for the procedures indicated in this document are disabled.
The 'chatroom' SDP attribute has the following Augmented BNF (ABNF) [RFC5234] syntax:
attribute =/ chatroom-attr
; attribute defined in RFC 4566
chatroom-attr = chatroom-label [":" chat-token
*(SP chat-token)]
chatroom-label = "chatroom"
chat-token = (nicknames-token / private-msg-token /
ext-token)
nicknames-token = "nickname"
private-msg-token = "private-messages"
ext-token = private-token / standard-token
private-token = toplabel "." *(domainlabel ".") token
; toplabel defined in RFC 3261
; domainlabel defined in RFC 3261
; token defined in RFC 3261
standard-token = token
A given 'chat-token' value MUST NOT appear more than once in a 'chatroom' attribute.
A conference focus that includes the 'nicknames' token in the session description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 7. A conference focus that includes the 'private-messages' in the SDP description is signaling that the MSRP switch supports and the chat room allows to use the procedures specified in Section 6.2.
Example of the 'chatroom' attribute for an MSRP media stream that indicates the acceptance of nicknames and private messages:
a=chatroom:nickname private-messages
An example of a 'chatroom' attribute for an MSRP media stream where the endpoint, e.g., an MSRP switch, does not allow either nicknames nor private messages.
a=chatroom
The 'chatroom' attribute allows extensibility with the addition of new tokens. No IANA registry is provided at this time, since no extensions are expected at the time of this writing. Extensions to the 'chatroom' attribute can be defined in IETF documents or as private vendor extensions.
Extensions defined in IETF document MUST follow the 'standard-token' ABNF previously defined. In this type of extensions, are must be taken in the selection of the token to avoid a clash with any of the tokens previously defined.
Private extensions MUST follow the 'private-token' ABNF previously defined. The 'private-token' MUST include the DNS name of the vendor in reverse order in the token, in order to avoid clashes of tokens. The following is an example of a "chat.foo" extension by vendor "example.com"
a=chatroom:nickname private-messages com.example.chat.foo
Figure 8 presents a flow diagram where Alice joins a chat room by sending an INVITE request. This INVITE request contains a session description that includes the chatroom extensions defined in this document.
Alice Conference focus | | |F1: (SIP) INVITE | |----------------------->| |F2: (SIP) 200 OK | |<-----------------------| |F3: (SIP) ACK | |----------------------->| | |
F1: Alice constructs an SDP description that includes an MSRP media stream. She also indicates her support for the chatroom extensions defined in this document. She sends the INVITE request to the chat room server.
INVITE sip:chatroom22@chat.example.com SIP/2.0 Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9 Max-Forwards: 70 From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl To: Chatroom 22 <sip:chatroom22@chat.example.com> Call-ID: 3848276298220188511@atlanta.example.com CSeq: 1 INVITE Contact: <sip:alice@client.atlanta.example.com;transport=tcp> Content-Type: application/sdp Content-Length: 290 v=0 o=alice 2890844526 2890844526 IN IP4 client.atlanta.example.com s=- c=IN IP4 client.atlanta.example.com m=message 7654 TCP/MSRP * a=accept-types:message/cpim text/plain text/html a=path:msrp://client.atlanta.example.com:7654/jshA7weztas;tcp a=chatroom:nickname private-messages
F2: 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 builds an SDP answer that forces the reception of messages wrapped in Message/CPIM wrappers. It also includes the 'chatroom' attribute with the allowed extensions.
SIP/2.0 200 OK
Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74bf9
;received=192.0.2.101
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Chatroom 22 <sip:chatroom22@chat.example.com>;tag=8321234356
Call-ID: 3848276298220188511@atlanta.example.com
CSeq: 1 INVITE
Contact: <sip:chatroom22@chat.example.com;transport=tcp> \
;methods="INVITE,BYE,OPTIONS,ACK,CANCEL,SUBSCRIBE,NOTIFY" \
;automata;isfocus;message;event="conference"
Content-Type: application/sdp
Content-Length: 290
v=0
o=chat 2890844527 2890844527 IN IP4 chat.example.com
s=-
c=IN IP4 chat.example.com
m=message 12763 TCP/MSRP *
a=accept-types:message/cpim
a=accept-wrapped-types:text/plain text/html *
a=path:msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
a=chatroom:nickname private-messages
F3: The session established is acknowledged (details not shown).
Figure 11 shows an example of Alice setting up a nickname using the chat room as provider. Her first proposal is not accepted because that proposed nickname is already in use. Then, she makes a second proposal with a new nickname. This second proposal is accepted.
Alice MSRP switch
| |
|F1: (MSRP) NICKNAME |
|----------------------->|
|F2: (MSRP) 423 |
|<-----------------------|
|F3: (MSRP) NICKNAME |
|----------------------->|
|F4: (MSRP) 200 |
|<-----------------------|
| |
F1: Alice sends an MSRP NICKNAME request that contains her proposed nicknames in the Use-Nickname header field.
MSRP d93kswow NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice the great"
-------d93kswow$
F2: The MSRP switch analyzes the existing allocation of nicknames and detects that the nickname "Alice the great" is already provided to another participant in the chat room. The MSRP switch answers with a 423 response.
MSRP d93kswow 423 Nickname usage failed
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------d93kswow$
F3: Alice receives the response. She proposes a new nickname in a second NICKNAME request.
MSRP 09swk2d NICKNAME
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Use-Nickname: "Alice in Wonderland"
-------09swk2d$
F4: The MSRP switch accepts the nickname proposal and answers with a 200 response.
MSRP 09swk2d 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
-------09swk2d$
Figure 16 depicts a flow diagram where Alice is sending a regular message addressed to the chat room. The MSRP switch distributes the message to the rest of the participants.
Alice MSRP switch Bob Charlie
| | | |
| F1: (MSRP) SEND | | |
|--------------------->| F3: (MSRP) SEND | |
| F2: (MSRP) 200 |----------------------->| |
|<---------------------| F4: (MSRP) SEND | |
| |------------------------------->|
| | F5: (MSRP) 200 OK | |
| |<-----------------------| |
| | F6: (MSRP) 200 OK | |
| |<------------------------------ |
| | | |
| | | |
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to the chat room. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
MSRP 3490visdm SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: 99s9s2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------3490visdm$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
MSRP 3490visdm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: 99s9s2
-------3490visdm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it to Bob.
MSRP 490ej23 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: 304sse2
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:chatroom22@chat.example.com;transport=tcp>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello guys, how are you today?
-------490ej23$
Since the received message is addressed to the chat room URI in the From header of the Message/CPIM header, Bob knows that this is a regular message distributed all participants in the chat room, rather that a private message addressed to him.
The rest of the message flows are analogous to the previous. They are not shown here.
Figure 20 depicts a flow diagram where Alice is sending a private message addressed to Bob's SIP AOR. The MSRP switch distributes the message only to Bob.
Alice MSRP switch Bob
| | |
| F1: (MSRP) SEND | |
|--------------------->| F3: (MSRP) SEND |
| F2: (MSRP) 200 |----------------------->|
|<---------------------| F4: (MSRP) 200 |
| |<-----------------------|
| | |
F1: Alice builds a text message and wraps it in a Message/CPIM wrapper. She addresses the message to Bob's URI, which she learned from a notification in the conference event package. She encloses the resulting Message/CPIM wrapper in an MSRP SEND request and sends it to the MSRP switch via the existing TCP connection.
MSRP 6959ssdf SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: okj3kw
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------6959ssdf$
F2: The MSRP switch acknowledges the reception of the SEND request with a 200 (OK) response.
MSRP 6959ssdfm 200 OK
To-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
From-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
Message-ID: okj3kw
-------6959ssdfm$
F3: The MSRP switch creates a new MSRP SEND request that contains the received Message/CPIM wrapper and sends it only to Bob. Bob can distinguish the sender in the From header of the Message/CPIM wrapper. He also identifies this as a private message due to the presence of his own SIP AOR in the To header field of the Message/CPIM wrapper.
MSRP 9v9s2 SEND
To-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
From-Path: msrp://chat.example.com:5678/jofofo3;tcp
Message-ID: d9fghe982
Byte-Range: 1-*/*
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@atlanta.example.com>
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob.
-------9v9s2$
F4: Bob acknowledges the reception of the SEND request with a 200 (OK) response.
MSRP 9v9s2 200 OK
To-Path: msrp://chat.example.com:5678/jofofo3;tcp
From-Path: msrp://client.biloxi.example.com:4923/49dufdje2;tcp
Message-ID: d9fghe982
-------9v9s2$
The MSRP message below depicts the example of the same private message described in Section 9.4, but now the message is split in two chunks. The MSRP switch must wait for the complete set of Message/CPIM headers before distributing the messages.
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 1-*/174
Content-Type: message/cpim
To: <sip:bob@example.com>
From: <sip:alice@example.com>
-------7443ruls$
MSRP 7443ruls SEND
To-Path: msrp://chat.example.com:12763/kjhd37s2s20w2a;tcp
From-Path: msrp://client.atlanta.example.com:7654/jshA7weztas;tcp
Message-ID: aft4to
Byte-Range: 68-174/174
Content-Type: message/cpim
DateTime: 2009-03-02T15:02:31-03:00
Content-Type: text/plain
Hello Bob
-------7443ruls$
Figure 26 depicts two user elements in a conference information document both having the nickname element with a nickname string.
<?xml version="1.0" encoding="UTF-8"?>
<conference-info
xmlns="urn:ietf:params:xml:ns:conference-info"
entity="sip:chatroom22@chat.example.com"
state="full" version="1">
<!--
CONFERENCE INFO
-->
<conference-description>
<subject>MSRP nickname example</subject>
</conference-description>
<!--
CONFERENCE STATE
-->
<conference-state>
<user-count>2</user-count>
</conference-state>
<!--
USERS
-->
<users>
<user entity="sip:bob@example.com" state="full">
<nickname>Dopey Donkey</nickname>
</user>
<!--
USER
-->
<user entity="sip:alice@atlanta.example.com" state="full">
<nickname>Alice the great</nickname>
</user>
</users>
</conference-info>
This specification defines a new MSRP method to be added to the Methods sub-registry of the Message Session Relay Protocol (MSRP) Parameters registry:
See section Section 7 for details.
This specification defines a new MSRP header to be added to the Header Field sub-registry of the Message Session Relay Protocol (MSRP) Parameters registry:
See Section 7 for details.
This specification defines three new MSRP status codes to be added to the Status-Code sub-registry of the Message Session Relay Protocol (MSRP) parameters registry.
The 404 status code indicates the failure to resolve the recipient's URI in the To header field of the Message/CPIM wrapper in the SEND request, e.g, due to an unknown recipient. See Section 6.2 for details.
The 424 status code indicates a failure in allocating the requested nickname due to a malformed nickname in the Use‑Nickname header field. See Section 7 for details.
The 425 status code indicates a failure in allocating the requested nickname becuase the requested nickname in the Use‑Nickname header field is reserved or is already in use by another user. See Section 7 for details.
The 428 status code indicates that the recipient of a SEND request does not support private messages. See Section 6.2 for details.
Table 1 summarizes the IANA registration data with respect to new MSRP status codes:
| Value | Description | Reference |
|---|---|---|
| 404 | Failure to resolve recipient's URI | RFC XXXX |
| 424 | Malformed nickname | RFC XXXX |
| 425 | Nickname reserved or already in use | RFC XXXX |
| 428 | Private messages not supported | RFC XXXX |
This specification defines a new media-level attribute in the Session Description Protocol (SDP) Parameters registry. The registration data is as follows:
See section Section 8 for details.
This document proposes extensions to the Message Session Relay Protocol [RFC4975]. Therefore, the security considerations of that document apply to this document as well.
If the participant's SIP user agent doesn't understand the "isfocus" feature tag [RFC3840], it will not know that it is connected to a conference instance. The participant might not be notified that the participant's MSRP client will try to send messages to the MSRP switch having potentially multiple recipients. If the participant's MSRP client doesn't support the extensions of this specification, it is unlikely that it will try to send a message using 'Message/CPIM' wrapper content type [RFC3862], and the MSRP switch will reject the request with a 415 response [RFC4975]. Still if a participant's MSRP client does create a message with a valid 'Message/CPIM' wrapper content type [RFC3862] having the To header set to the URI of the chat room and the From header set to the URI of which the participant is known to the chat room, the participant might be unaware that the message can be forwarded to multiple recipients. Equally if the To header is set to a valid URI of a recipient known to the chat room, the message can be forwarded as a private message without the participant knowing.
If a participant wants to avoid eavesdropping, the participant's MSRP client can send the messages over a TLS [RFC5246] transport connection, as allowed by MSRP. It's up to the policy of the MSRP switch if the messages are forwarded to the other participant's in the chat room using TLS [RFC5246] transport.
Nicknames are used to show the appearance of the participants of the chat room. A successful take over of a nickname from a participant might lead to private messages to be sent to the wrong destination. The recipient's URI will be different from the URI associated to the original owner of the nickname, but the sender might not notice this. To avoid takeovers the MSRP switch MUST make sure that a nickname is unique inside a chat room. Also the security consideration for any authenticated identity mechanisms used to validate the SIP AOR will apply to this document as well. If a nickname can be reserved if it previously has been used by another participant in the chat room, is up to the policy of the chat room.
This work would have never been possible without the fruitful discussions in the SIMPLE WG mailing list, specially with Brian Rosen (Neustar) and Paul Kyzivat (Cisco), who provided extensive review and improvements throughout the document.
The authors want to thank Eva Leppanen, Adamu Haruna, Adam Roach, Matt Lepinski, Mary Barnes, Ben Campbell, Paul Kyzivat, Adrian Georgescu, Nancy Greene, Cullen Jennings, Flemming Andreasen, Suresh Krishnan, Christer Holmberg, Saul Ibarra, Enrico Marocco, Alexey Melnikov, and Peter Saint-Andre for providing comments.
| [RFC2810] | Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000. |
| [RFC3325] | Jennings, C., Peterson, J. and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. |
| [RFC3966] | Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. |
| [RFC4474] | Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. |
| [RFC6120] | Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011. |