draft-ietf-simple-message-sessions-00.txt   draft-ietf-simple-message-sessions-01.txt 
SIMPLE Working Group B. Campbell SIMPLE Working Group B. Campbell
Internet-Draft J. Rosenberg Internet-Draft J. Rosenberg
Expires: November 20, 2003 R. Sparks Expires: December 29, 2003 R. Sparks
dynamicsoft dynamicsoft
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
May 22, 2003 June 30, 2003
Instant Message Sessions in SIMPLE Instant Message Sessions in SIMPLE
draft-ietf-simple-message-sessions-00 draft-ietf-simple-message-sessions-01
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on November 20, 2003. This Internet-Draft will expire on December 29, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract Abstract
The SIP MESSAGE method is used to send instant messages, where each
message is independent of any other message. This is often called
pager-mode messaging, due to the fact that this model is similar to
that of most two-way pager devices. Another model is called
session-mode. In session-mode, the instant messages are part of a
media session that provides ordering, a security context, and other
functions. This media session is established using a SIP INVITE, just
as an audio or video session would be established.
This document describes the Message Session Relay Protocol (MSRP), a This document describes the Message Session Relay Protocol (MSRP), a
mechanism for transmitting session-mode messages with minimalist mechanism for transmitting a series of Instant Messages within a
relay support. Additionally, this document describes using the SDP session. MSRP sessions are managed using the SDP offer/answer model
offer/answer model to initiate such sessions. carried by a signaling protocol such as SIP.
MSRP supports end-to-end Instant Message Sessions, as well as
sessions traversing one or two relays.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Motivation for Session-mode Messaging . . . . . . . . . . 4 2. Motivation for Session-mode Messaging . . . . . . . . . . . 4
3. Scope of this Document . . . . . . . . . . . . . . . . . . 5 3. Scope of this Document . . . . . . . . . . . . . . . . . . . 5
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 5
5. SDP Offer-Answer Exchanges for MSRP Sessions. . . . . . . 8 5. Architectural Considerations . . . . . . . . . . . . . . . . 8
5.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . 8 5.1 Use of Relays . . . . . . . . . . . . . . . . . . . . . . . 8
5.2 The Direction Attribute . . . . . . . . . . . . . . . . . 9 5.2 Transferring Large Content . . . . . . . . . . . . . . . . . 9
5.3 URL Negotiations . . . . . . . . . . . . . . . . . . . . . 10 5.3 Connection Sharing . . . . . . . . . . . . . . . . . . . . . 9
5.4 Example SDP Exchange . . . . . . . . . . . . . . . . . . . 11 6. SDP Offer-Answer Exchanges for MSRP Sessions . . . . . . . . 10
6. The Message Session Relay Protocol . . . . . . . . . . . . 11 6.1 Use of the SDP M-line . . . . . . . . . . . . . . . . . . . 10
6.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2 The Direction Attribute . . . . . . . . . . . . . . . . . . 11
6.2 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . 12 6.3 MIME Wrappers . . . . . . . . . . . . . . . . . . . . . . . 13
6.3 Resolving MSRP Host Device . . . . . . . . . . . . . . . . 13 6.4 URL Negotiations . . . . . . . . . . . . . . . . . . . . . . 13
6.3.1 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . 14 6.5 Example SDP Exchange . . . . . . . . . . . . . . . . . . . . 14
6.4 MSRP messages . . . . . . . . . . . . . . . . . . . . . . 14 7. The Message Session Relay Protocol . . . . . . . . . . . . . 15
6.5 MSRP Transactions . . . . . . . . . . . . . . . . . . . . 15 7.1 MSRP URLs . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.6 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . 16 7.1.1 MSRP URL Comparison . . . . . . . . . . . . . . . . . . . . 16
6.6.1 Initiating an MSRP session . . . . . . . . . . . . . . . . 16 7.1.2 Resolving MSRP Host Device . . . . . . . . . . . . . . . . . 16
6.6.2 Handling VISIT requests . . . . . . . . . . . . . . . . . 19 7.1.3 The msrps URL Scheme . . . . . . . . . . . . . . . . . . . . 17
6.6.3 Sending Instant Messages on a Session . . . . . . . . . . 20 7.2 MSRP messages . . . . . . . . . . . . . . . . . . . . . . . 17
6.6.4 Managing Session State and Connections . . . . . . . . . . 21 7.3 MSRP Transactions . . . . . . . . . . . . . . . . . . . . . 18
6.7 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . 22 7.4 MSRP Sessions . . . . . . . . . . . . . . . . . . . . . . . 19
6.7.1 Establishing Session State at a Relay . . . . . . . . . . 22 7.4.1 Initiating an MSRP session . . . . . . . . . . . . . . . . . 19
6.7.2 Removing Session State from a relay . . . . . . . . . . . 24 7.4.2 Handling VISIT requests . . . . . . . . . . . . . . . . . . 23
6.7.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . 24 7.4.3 Sending Instant Messages on a Session . . . . . . . . . . . 23
6.7.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . 24 7.4.4 Ending a Session . . . . . . . . . . . . . . . . . . . . . . 24
6.8 Session State Expiration . . . . . . . . . . . . . . . . . 26 7.4.5 Session Inactivity Timer . . . . . . . . . . . . . . . . . . 24
6.9 Digest Authentication . . . . . . . . . . . . . . . . . . 26 7.4.6 Managing Session State and Connections . . . . . . . . . . . 25
6.9.1 The MD5 Algorithm . . . . . . . . . . . . . . . . . . . . 27 7.5 MSRP Relays . . . . . . . . . . . . . . . . . . . . . . . . 26
6.10 Method Descriptions . . . . . . . . . . . . . . . . . . . 28 7.5.1 Establishing Session State at a Relay . . . . . . . . . . . 26
6.10.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5.2 Removing Session State from a relay . . . . . . . . . . . . 28
6.10.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.5.3 Sending IMs across an MSRP relay . . . . . . . . . . . . . . 28
6.10.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.5.4 Relay Pairs . . . . . . . . . . . . . . . . . . . . . . . . 28
6.11 Response Code Descriptions . . . . . . . . . . . . . . . . 29 7.6 Digest Authentication . . . . . . . . . . . . . . . . . . . 30
6.11.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.6.1 The SHA1 Algorithm . . . . . . . . . . . . . . . . . . . . . 31
6.11.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.7 Method Descriptions . . . . . . . . . . . . . . . . . . . . 31
6.11.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 7.7.1 BIND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.11.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7.2 SEND . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.11.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.7.3 VISIT . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.11.6 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8 Response Code Descriptions . . . . . . . . . . . . . . . . . 32
6.11.7 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8.1 200 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6.11.8 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8.2 400 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12 Header Field Descriptions . . . . . . . . . . . . . . . . 30 7.8.3 401 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8.4 403 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 7.8.5 415 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.8.6 426 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.8.7 481 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . 32 7.8.8 500 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.12.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.8.9 506 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 32 7.9 Header Field Descriptions . . . . . . . . . . . . . . . . . 33
7.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . 33 7.9.1 TR-ID . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . 34 7.9.2 Exp . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
7.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . 37 7.9.3 CAuth . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
8. IANA Considerations . . . . . . . . . . . . . . . . . . . 40 7.9.4 SChal . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9. Security Considerations . . . . . . . . . . . . . . . . . 40 7.9.5 Content-Type . . . . . . . . . . . . . . . . . . . . . . . . 36
9.1 The MSRPS Scheme . . . . . . . . . . . . . . . . . . . . . 40 7.9.6 S-URL . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.2 Sensitivity of the Session URL . . . . . . . . . . . . . . 41 8. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3 End to End Protection of IMs . . . . . . . . . . . . . . . 41 8.1 No Relay . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . 42 8.2 Single Relay . . . . . . . . . . . . . . . . . . . . . . . . 39
10. Changes introduced in 8.3 Two Relays . . . . . . . . . . . . . . . . . . . . . . . . . 42
draft-ietf-simple-message-sessions-00 . . . . . . . . . . 42 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 46
11. Changes introduced in 9.1 MSRP Port . . . . . . . . . . . . . . . . . . . . . . . . . 46
draft-campbell-simple-im-sessions-01 . . . . . . . . . . . 43 9.2 MSRP URL Schemes . . . . . . . . . . . . . . . . . . . . . . 46
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . 43 9.2.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Normative References . . . . . . . . . . . . . . . . . . . 43 9.2.2 Character Encoding . . . . . . . . . . . . . . . . . . . . . 46
Informational References . . . . . . . . . . . . . . . . . 44 9.2.3 Intended Usage . . . . . . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 45 9.2.4 Protocols . . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . 46 9.2.5 Security Considerations . . . . . . . . . . . . . . . . . . 47
9.2.6 Relevant Publications . . . . . . . . . . . . . . . . . . . 47
9.3 SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.1 Direction . . . . . . . . . . . . . . . . . . . . . . . . . 47
9.3.2 Wrapped Types . . . . . . . . . . . . . . . . . . . . . . . 47
10. Security Considerations . . . . . . . . . . . . . . . . . . 48
10.1 TLS and the MSRPS Scheme . . . . . . . . . . . . . . . . . . 48
10.2 Sensitivity of the Session URL . . . . . . . . . . . . . . . 49
10.3 End to End Protection of IMs . . . . . . . . . . . . . . . . 49
10.4 CPIM compatibility . . . . . . . . . . . . . . . . . . . . . 50
10.5 PKI Considerations . . . . . . . . . . . . . . . . . . . . . 50
11. Changes from Previous Draft Versions . . . . . . . . . . . . 50
11.1 draft-ietf-simple-message-sessions-01 . . . . . . . . . . . 51
11.2 draft-ietf-simple-message-sessions-00 . . . . . . . . . . . 51
11.3 draft-campbell-simple-im-sessions-01 . . . . . . . . . . . . 52
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . . 53
Informational References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 54
Intellectual Property and Copyright Statements . . . . . . . 56
1. Introduction 1. Introduction
The MESSAGE [9] extension to SIP [2] allows SIP to be used to The MESSAGE [10] extension to SIP [2] allows SIP to be used to
transmit instant messages. Instant messages sent using the MESSAGE transmit instant messages. Instant messages sent using the MESSAGE
method are normally independent of each other. This approach is often method are normally independent of each other. This approach is often
called pager-mode messaging, since it follows a model similar to that called page-mode messaging, since it follows a model similar to that
used by many two-way pager devices. Pager-mode messaging makes sense used by many two-way pager devices. page-mode messaging makes sense
for instant message exchanges where a small number of messages occur. for instant message exchanges where a small number of messages occur.
There are also applications in which it is useful for instant There are also applications in which it is useful for instant
messages to be associated together in some way. For example, a user messages to be associated together in some way. For example, a user
may wish to join a text conference, participate in the conference for may wish to join a text conference, participate in the conference for
some period of time, then leave the conference. This usage is some period of time, then leave the conference. This usage is
analogous to regular media sessions that are typically initiated, analogous to regular media sessions that are typically initiated,
managed, and terminated using SIP. We commonly refer to this model as managed, and terminated using SIP. We commonly refer to this model as
session-mode messaging. session-mode messaging.
One of the primary purposes of SIP and SDP (Section 5) is the One of the primary purposes of SIP and SDP (Section 6) is the
management of media sessions. Session-mode messaging can be thought management of media sessions. Session-mode messaging can be thought
of as a media session like any other. This document describes the of as a media session like any other. This document describes the
motivations for session-mode messaging, the Message Session Relay motivations for session-mode messaging, the Message Session Relay
Protocol, and the use of the SDP offer/answer mechanism for managing Protocol, and the use of the SDP offer/answer mechanism for managing
MSRP session. MSRP session.
2. Motivation for Session-mode Messaging 2. Motivation for Session-mode Messaging
Message sessions offer several advantages over pager-mode messages. Message sessions offer several advantages over page-mode messages.
For message exchanges that include more than a small number of For message exchanges that include more than a small number of
message transactions, message sessions offer a way to remove message transactions, message sessions offer a way to remove
messaging load from intervening SIP proxies. For example, a minimal messaging load from intervening SIP proxies. For example, a minimal
session setup and tear-down requires one INVITE/ACK transaction, and session setup and tear-down requires one INVITE/ACK transaction, and
one BYE transaction, for a total of 5 SIP messages. Normal SIP one BYE transaction, for a total of 5 SIP messages. Normal SIP
request routing allows for all but the initial INVITE transaction to request routing allows for all but the initial INVITE transaction to
bypass any intervening proxies that do not specifically request to be bypass any intervening proxies that do not specifically request to be
in the path for future requests. Session-mode messages never cross in the path for future requests. Session-mode messages never cross
the SIP proxies themselves, unless proxies also act as message the SIP proxies themselves, unless proxies also act as message
relays. relays.
Each pager mode message involves a complete SIP transaction, that is, Each page-mode message involves a complete SIP transaction, that is,
a request and a response. Any pager-mode message exchange that a request and a response. Any page-mode message exchange that
involves more than 2 or 3 MESSAGE requests will generate more SIP involves more than 2 MESSAGE requests will generate more SIP requests
requests than a minimal session initiation sequence. Since MESSAGE is than a minimal session initiation sequence. Since MESSAGE is normally
normally used outside of a SIP dialog, these requests will typically used outside of a SIP dialog, these requests will typically traverse
traverse the entire proxy network between the endpoints. the entire proxy network between the endpoints.
Due to network congestion concerns, the MESSAGE method has Due to network congestion concerns, the MESSAGE method has
significant limitations in message size, a prohibition against significant limitations in message size, a prohibition against
overlapping requests, etc. Much of this has been required because of overlapping requests, etc. Much of this has been required because of
perceived limitations in the congestion-avoidance features of SIP perceived limitations in the congestion-avoidance features of SIP
itself. Work is in progress to mitigate these concerns. itself. Work is in progress to mitigate these concerns.
However, session-mode messages are always sent over reliable, However, session-mode messages are always sent over reliable,
congestion-safe transports. Therefore, there are no restrictions on congestion-safe transports. Therefore, there are no restrictions on
message sizes. There is no requirement to wait for acknowledgement, message sizes. There is no requirement to wait for acknowledgement,
skipping to change at page 5, line 27 skipping to change at page 5, line 27
of session initiation. This key can be used to protect each message of session initiation. This key can be used to protect each message
that is part of the session. This requires only symmetric key that is part of the session. This requires only symmetric key
operations for each subsequent IM, and no additional certificate operations for each subsequent IM, and no additional certificate
exchanges are required after the initial exchange. The establishment exchanges are required after the initial exchange. The establishment
of the session key can be done using standard techniques that apply of the session key can be done using standard techniques that apply
to voice and video, in addition to instant messaging. to voice and video, in addition to instant messaging.
Finally, SIP devices can treat message sessions like any other media Finally, SIP devices can treat message sessions like any other media
sessions. Any SIP feature that can be applied to other sorts of media sessions. Any SIP feature that can be applied to other sorts of media
sessions can equally apply to message sessions. For example, sessions can equally apply to message sessions. For example,
conferencing [11], third party call control [12], call transfer [13], conferencing [12], third party call control [13], call transfer [14],
QoS integration [14], and privacy [15] can all be applied to message QoS integration [15], and privacy [16] can all be applied to message
sessions. sessions.
Messaging sessions can also reduce the overhead in each individual Messaging sessions can also reduce the overhead in each individual
message. In pager-mode, each message needs to include all of the SIP message. In page-mode, each message needs to include all of the SIP
headers that are mandated by RFC 3261 [2]. However, many of these headers that are mandated by RFC 3261 [2]. However, many of these
headers are not needed once a context is established for exchanging headers are not needed once a context is established for exchanging
messages. As a result, messaging session mechanisms can be designed messages. As a result, messaging session mechanisms can be designed
with significantly less overhead. with significantly less overhead.
3. Scope of this Document 3. Scope of this Document
This document describes the use of MSRP between endpoints, or via one This document describes the use of MSRP between endpoints, or via one
or two relays, where endpoints have advance knowledge of the relays. or two relays, where endpoints have advance knowledge of the relays.
It does not provide a mechanism for endpoints to determine whether a It does not provide a mechanism for endpoints to determine whether a
skipping to change at page 6, line 15 skipping to change at page 6, line 15
transporting session-mode messages between endpoints. MSRP also transporting session-mode messages between endpoints. MSRP also
contains primitives to allow the use of one or two relay devices. contains primitives to allow the use of one or two relay devices.
MSRP uses connection oriented, reliable network transport protocols MSRP uses connection oriented, reliable network transport protocols
only. It is intrinsically NAT and firewall friendly, as it allows only. It is intrinsically NAT and firewall friendly, as it allows
participants to positively associate message sessions with specific participants to positively associate message sessions with specific
connections, and does not depend upon connection source address, connections, and does not depend upon connection source address,
which may be obscured by NATs. which may be obscured by NATs.
MSRP uses the following primitives: MSRP uses the following primitives:
SEND: Used to actually send message content from one endpoint to SEND: Used to send message content from one endpoint to another.
another.
VISIT: Used by an endpoint to establish a session association to the VISIT: Used by an endpoint to establish a session association to the
opposite endpoint, or to a relay that was selected by the opposite opposite endpoint, or to a relay that was selected by the opposite
endpoint. endpoint.
BIND: Used by an endpoint to establish a session at a relay, and BIND: Used by an endpoint to establish a session at a relay, and
allow the opposite endpoint to visit that relay. allow the opposite endpoint to visit that relay.
The simplest use case for MSRP is a session that goes directly The simplest use case for MSRP is a session that goes directly
between endpoints, with no intermediaries involved. Assume A is an between endpoints, with no intermediaries involved. Assume A is an
skipping to change at page 7, line 16 skipping to change at page 7, line 16
B->A (SDP): answer(msrp://A/123) B->A (SDP): answer(msrp://A/123)
A->B (MSRP): SEND A->B (MSRP): SEND
B->A (MSRP): 200 OK B->A (MSRP): 200 OK
B->A (MSRP): SEND B->A (MSRP): SEND
A->B (MSRP): 200 OK A->B (MSRP): 200 OK
The state associated with the session will expire over time, based on The session state has an associated inactivity timer. This timer is
an expiration time specified in the VISIT request. If the lifetime of initialized when a successful VISIT request occurs, and is reset each
the session is to exceed that expiration time, the visitor must time either endpoint sends a SEND request. If this timer expires
update the expiration with a new VISIT request prior to expiration. without being reset, the hosting device invalidates the session state
and terminates all associated connections. Endpoints that are
otherwise idle may keep a session active by periodically sending SEND
requests with no content.
A slightly more complicated case involves a single relay, known about A slightly more complicated case involves a single relay, known about
in advance by one of the parties. The endpoint that has the in advance by one of the parties. The endpoint that has the
preexisting relationship with the relay uses the BIND method to preexisting relationship with the relay uses the BIND method to
establish session state in the relay. The relay returns a temporary establish session state in the relay. The relay returns a temporary
URL, that identifies the session. For endpoints A and B, and relay R, URL, that identifies the session. For endpoints A and B, and relay R,
the flow would look like the following: the flow would look like the following:
A->R: MSRP: BIND(msrp://r) A->R: MSRP: BIND(msrp://r)
skipping to change at page 7, line 47 skipping to change at page 8, line 4
B->A (SDP): answer(msrp://r/4uye) B->A (SDP): answer(msrp://r/4uye)
A->R (MSRP): SEND A->R (MSRP): SEND
R->B (MSRP): SEND R->B (MSRP): SEND
B->R (MSRP): 200 OK B->R (MSRP): 200 OK
R->A (MSRP): 200 OK R->A (MSRP): 200 OK
B->R (MSRP): SEND B->R (MSRP): SEND
R->A (MSRP): SEND R->A (MSRP): SEND
A->R (MSRP): 200 OK A->R (MSRP): 200 OK
R->B (MSRP): 200 OK R->B (MSRP): 200 OK
The BIND request contains an expiration time much the same as in The BIND request contains an expiration time. If a successful VISIT
VISIT. If the life of a relay-hosted session is to exceed the request does not occur prior to the expiration, the relay will
expiration value in the BIND request, the host endpoint will refresh destroy the session. Additionally, when tearing down a session, the
the expiration time with a new BIND request prior to expiration. host endpoint invalidates the session state by issuing a BIND request
Additionally, when tearing down a session, the host endpoint with an expiration value of zero.
invalidates the session state by issuing a BIND request with an
expiration value of zero.
5. SDP Offer-Answer Exchanges for MSRP Sessions. 5. Architectural Considerations
There are a number of considerations that, if handled in a reasonable
fashion, will allow more effective use of the protocols described in
this document.
5.1 Use of Relays
The primary motivation for relay support in MSRP is to deal with
situations where, due to issues of network topologies, neither
endpoint is able to receive an inbound TCP connection from the other.
For example, both endpoints may be behind separate firewalls that
only allow outbound connections. Relays may also be needed for policy
enforcement. For example, parts of the financial industry require the
logging of all communication.
However, the use of such relays has a significant impact on the
scalability of MSRP. Each relay will require two TCP connections for
each session in use, as well as memory for local session state
storage. Most general purpose platforms on which one might implement
MSRP relays will have relatively low limits on the number of
simultaneous TCP connections they can handle.
Therefore relays SHOULD NOT be used indescrimantly. In the absence of
strong reasons to use relays, MSRP endpoints SHOULD be configured to
set up point-to-point sessions.
MSRP supports the use of two relays, where each endpoint has a relay
acting on its behalf. However, most of the network topology issues
mentioned above can work with a single relay, if that relay is
reachable by both endpoints. Dual relays are only needed for cases of
very strict firewall policy, such as when only specific hosts are
allowed to connect to the outside world; or situations requiring
strict policy enforcement at both endpoint domains. If a given usage
scenario can be solved with a single relay, then a second relay
SHOULD NOT be used.
In spite of these recommendations, relays serve a real purpose in
that the increase the likelihood of two arbitrary endpoints being
able to talk to one another. Therefore if a provider deploys MSRP
endpoints in a network configuration that prevents them from
receiving TCP connections from arbitrary peers, and does not wish to
explicitly prevent MSRP communication with the outside world, then
the provider SHOULD provide its endpoints with the use of an MSRP
relay that is reachable from arbitrary peers.
5.2 Transferring Large Content
MSRP endpoints may attempt to send very long messages on a session.
For example, most commercial instant messaging systems have a file
transfer feature. Since MSRP does not impose message size limits,
there is nothing to prevent endpoints from transferring files over
it.
An analysis of whether it makes sense to do this, rather than sending
such content over FTP, HTTP, or some other such protocol, is beyond
the scope of this document. However, implementers should be aware of
the impact of sending very large messages over MSRP. The primary
impact is, since MSRP is sent over TCP, is that any additional
messages that the sender wishes to send will be blocked until the
large transfer is complete. This includes responses to messages sent
by the peer. Therefore, any SEND transactions initiated by the peer
are likely to time out, even though they are received without
problems.
Further, there is no way to abort the sending of a very large message
before it is complete. For the sake of efficiency, the framing
mechanism in MSRP is very simple. There is no clean way to recover
framing if the complete message is not sent.
These issues can be mitigated greatly if the endpoint simply
establishes a separate session for the transfer. This allows the
transfer to be sent without interfering with any instant messages
being sent on other sessions. Further, the endpoint can abort the
transfer by simply tearing down the transfer session. Therefore, if a
peer wishes to send very large content, it SHOULD establish a
dedicated session for that purpose.
5.3 Connection Sharing
The SIMPLE working group spent quite a bit of effort in the
consideration of shared TCP connections. Connection sharing would
offer value whenever a large number of message sessions cross the
same two adjacent devices. This situation is likely to occur in the
two relay model. It may also occur in the point-to-point model if the
endpoints are multiuser devices, as is likely with web-hosted
messaging services.
Unfortunately, such connection sharing in TCP created significant
problems. The biggest problem is it introduced a head-of-line
blocking problem that spanned sessions. For example, if two different
pairs of users had sessions that crossed the same shared connection,
a large message sent on one session would block transfer of messages
on the other session. The working group considered this an
unacceptable property of shared connections. One possible solution
was to put limits on message size, and possibly add mechanisms to
allow breaking messages into many chunks. However, these solutions
promised to add a great deal of complexity to the protocol, so the
work group chose not to go that route.
It may be possible to relax this requirement using other transport
protocols, such as SCTP. The lack of connection sharing in this
document should not be construed to prohibit shared connections on
other such protocols. However, such specification is beyond the scope
of this document.
6. SDP Offer-Answer Exchanges for MSRP Sessions
MSRP sessions will typically be initiated using the Session MSRP sessions will typically be initiated using the Session
Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP Description Protocol (SDP) [1] offer-answer mechanism, carried in SIP
[2] or any other protocol supporting it. MSRP borrows the idea of the [2] or any other protocol supporting it. MSRP borrows the idea of the
direction attributes from COMEDIA [17], but does not depend on that direction attributes from COMEDIA [18], but does not depend on that
specification. specification.
5.1 Use of the SDP M-line 6.1 Use of the SDP M-line
The SDP m-line takes the following form: The SDP m-line takes the following form:
m=<media> <port> <protocol> <format list> m=<media> <port> <protocol> <format list>
For non-RTP media sessions, The media field specifies the top level For non-RTP media sessions, The media field specifies the top level
MIME media type for the session. For MSRP sessions, the media field MIME media type for the session. For MSRP sessions, the media field
MUST have the value of "message". The proto field MUST designate the MUST have the value of "message". The port field is normally not
message session mechanism and transport protocol, separated by a "/" used, and SHOULD be set to 9999. An exception is when the port field
character. For MSRP, left part of this value MUST be "msrp". For MSRP value is set to zero, according to normal SDP usage.
over TCP, the right part of this field MUST take the value "tcp". For
MSRP over other transport protocols, the field value MUST be defined The proto field MUST designate the message session mechanism and
by the specification for that protocol binding. The format list MUST transport protocol, separated by a "/" character. For MSRP, left part
indicate the MIME content-types that the endpoint is willing to of this value MUST be "msrp". For MSRP over TCP, the right part of
accept in the payload of SEND requests. If any of the allowed types this field MUST take the value "tcp". For MSRP over other transport
are compound in nature, that is, they allow one or more arbitrary protocols, the field value MUST be defined by the specification for
MIME body parts to be embedded within them, then the format list MUST that protocol binding.
include the content-types allowed for the embedded parts. If the
The format list MUST indicate the MIME content-types that the
endpoint is willing to accept in the payload of SEND requests. If the
final entry in the format list is a "*", this indicates that the final entry in the format list is a "*", this indicates that the
endpoint is may be willing to receive other types as well, but the endpoint is may be willing to receive other types as well, but the
types listed explicitly are preferred. The format list in the SDP types listed explicitly are preferred. The format list in the SDP
answer MUST be the same as, or a subset of, the list provided in the answer MUST be the same as, or a subset of, the list provided in the
offer. offer.
A "*" in the format list indicates that the sender may attempt to A "*" in the format list indicates that the sender may attempt to
send messages with other media types that have not been explicitly send messages with other media types that have not been explicitly
listed. If the receiver is able to process the media type, it does listed. If the receiver is able to process the media type, it does
so. If not, it will respond with a 415. Note that all explicit so. If not, it will respond with a 415. Note that all explicit
entries in the format list should be considered preferred over any entries in the format list should be considered preferred over any
non-listed types. This feature is needed as, otherwise, the format non-listed types. This feature is needed as, otherwise, the format
list for IM devices may be prohibitively large. list for IM devices may be prohibitively large.
The port field in the M-line is not used to determine the port to The m-line format list may include MIME wrapper types, that is,
which to connect. Rather, the actual port is determined by the mime formats that contain other types internally. The types listed
contents of the session URL. (Section 6.1). in the format field can be used both as the root payload, or may
be contained in container types. (Note that the container type
must also be listed in the format list.) A list of types that are
only allowed when wrapped in containers can be communicated in the
accept-wrapped-types (Section 6.3) attribute.
The following example illustrates an m-line for a CPIM message The port field in the M-line is not normally used to determine the
session, where the endpoint is willing to accept payloads of plain port to which to connect. Rather, the actual port is determined by
text or HTML, which may appear at the top level of the payload, or the contents of the session URL (Section 7.1). However, a port value
may be embedded inside a message/cpim body part. of zero has the normal SDP meaning.
m=message 49232 msrp/tcp message/cpim text/plain text/html The following example illustrates an m-line for a message session,
where the endpoint is willing to accept root payloads of message/
cpim, plain text or HTML. The second two types could either be
presented as the root body, or could be contained within message/cpim
bodies.
5.2 The Direction Attribute m=message 9999 msrp/tcp message/cpim text/plain text/html
6.2 The Direction Attribute
Since MSRP uses connection oriented transport protocols, one goal of Since MSRP uses connection oriented transport protocols, one goal of
the SDP negotiation is to determine which participant initiates the the SDP negotiation is to determine which participant initiates the
transport connection. The direction attribute advertises whether the transport connection. The direction attribute advertises whether the
offerer or answerer wishes to initiate the connection, wishes the offerer or answerer wishes to initiate the connection, wishes the
peer endpoint to initiate the connection, or doesn't care. peer endpoint to initiate the connection, or doesn't care.
The endpoint that accepts the connection, or has a relay accept the The endpoint that accepts the connection, or has a relay accept the
connection on its behalf, is said to "host" the session, and is known connection on its behalf, is said to "host" the session, and is known
as the hosting endpoint. The endpoint that initiates the connection as the hosting endpoint. The endpoint that initiates the connection
is said to "visit" the session, and is known as the visiting is said to "visit" the session, and is known as the visiting
endpoint. endpoint.
The direction attribute is included in an SDP a-line, with a value The direction attribute is included in an SDP a-line, with a value
taking the following syntax: taking the following syntax:
direction = direction-label ":" role direction = direction-label ":" role
direction-label = "direction" direction-label = "direction"
role = active / passive / both role = active / passive / both
active = "active" active = "active"
passive = "passive" passive = "passive" [sp timeout]
both = "both" both = "both"
timeout = 1*DIGIT ; timeout value in seconds
The values for the role field are as follows: The values for the role field are as follows:
passive The endpoint wishes to host the session passive The endpoint wishes to host the session
active The endpoint wishes the peer to host the session. active The endpoint wishes the peer to host the session.
both The endpoint is willing to act as either host or visitor. both The endpoint is willing to act as either host or visitor. If
"both" is selected, it may contain an optional timeout value. This
timeout specifies how much time the answerer should wait before
giving up on a connection and attempting to take over as host
device. If the timeout value is not specified, it defaults to 30
seconds.
The SDP offer for an MSRP session MUST contain a direction attribute, The SDP offer for an MSRP session MUST contain a direction attribute,
which MAY take any of the defined values. If the offerer is capable which MAY take any of the defined values. If the offerer is capable
of hosting the session, or can arrange for a relay to host the of hosting the session, or can arrange for a relay to host the
session on its behalf, then it SHOULD select "both". The endpoint session on its behalf, then it SHOULD select "both". The endpoint
SHOULD NOT select "active" unless it cannot host the session under SHOULD NOT select "active" unless it cannot host the session under
any circumstances. The endpoint SHOULD NOT select "passive" unless it any circumstances. The endpoint SHOULD NOT select "passive" unless it
has no option but to host the session. has no option but to host the session.
The SDP answer also MUST contain a direction attribute, but its value The SDP answer also MUST contain a direction attribute, but its value
choices are limited based on the value in the offer. If the offer choices are limited based on the value in the offer. If the offer
contained "active", then the answerer MUST either select "passive" or contained "active", then the answerer MUST either select "passive" or
reject the offer. Likewise, if the offer contained "passive", then reject the offer. Likewise, if the offer contained "passive", then
the answerer MUST select"active" or reject the offer. If the offer the answerer MUST select"active" or reject the offer. If the offer
contained "both", the answerer SHOULD select "active", but MAY select contained "both", the answerer SHOULD select "active", but MAY select
"passive" if local policy requires it to act as host. "passive" if it is unable to reach the host device, or if local
policy requires it to act as host.
5.3 URL Negotiations 6.3 MIME Wrappers
The MIME content-types in the M-line format list will often include
compound types; that is, types that contain other types. For example,
"message/cpim" or "multipart/mixed." Occasionally and endpoint will
need to specify a MIME body type that can only be used if wrapped
inside a listed container type.
Endpoints MAY specify MIME types that are only allowed to be wrapped
inside compound types using the "accept-wrapped-types" attribute in
an SDP a-line. This attribute has the following syntax:
accept-wrapped-types = wrapped-types-label ":" format-list
wrapped-types-label = "accept-wrapped-types"
The format-list element has the identical syntax as the format list
in the m-line. The semantics for this attribute are identical to
those of the m-line format list, with the exception that the
specified types may only be used when wrapped inside containers. The
container types would be specified on the m-line normally. Since any
type listed on the m-line may be used both as a root body, or wrapped
in other bodies, format entries from the m-line SHOULD NOT be
repeated in this attribute.
This approach does not allow for specifying distinct lists of
acceptable wrapped types for different types of containers. If an
endpoint understands a MIME type in the context of one wrapper, it is
assumed to understand it in the context of any other acceptable
wrappers, subject to any constraints defined by the wrapper types
themselves.
The approach of specifying types that are only allowed inside of
containers separately from the primary payload types allows an
endpoint to force the use of certain wrappers. For example, a CPIM
gateway device may require all messages to be wrapped inside
message/cpim bodies, but may allow several content types inside
the wrapper. If the gateway were to specify the wrapped types in
the m-line format list, its peer could choose to use those types
without the wrapper.
6.4 URL Negotiations
An MSRP session is identified by an MSRP URL, which is determined by An MSRP session is identified by an MSRP URL, which is determined by
the hosting endpoint, and negotiated in the SDP exchange. Any SDP the hosting endpoint, and negotiated in the SDP exchange. Any SDP
offer or answer that creates a possibility that the sender will host offer or answer that creates a possibility that the sender will host
the session, that is, contains a direction value of "passive" or the session, that is, contains a direction value of "passive" or
"both", MUST contain an MSRP URL in a session attribute. This "both", MUST contain an MSRP URL in a session attribute. This
attribute has the following syntax: attribute has the following syntax:
a=session:<MSRP_URL> a=session:<MSRP_URL>
where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 6.1. where <MSRP_URL> is an MSRP or MSRPS URL as defined in Section 7.1.
The visitor will use the session URL established by the host both to The visitor will use the session URL established by the host both to
resolve the host address and port, and to identify the session when resolve the host address and port, and to identify the session when
connecting. For MSRP sessions, the address field in the C-line and connecting. For MSRP sessions, the address field in the C-line is not
the port field in the M-line are not relevant, and MUST be ignored. relevant, and MUST be ignored. The port field in the M-line MUST be
ignored if non-zero. Zero values have the normal meeting for SDP.
The following example shows an SDP offer with a session URL of The following example shows an SDP offer with a session URL of
"msrp://example.com:7394/2s93i" "msrp://example.com:7394/2s93i"
c=IN IP4 useless.host.name c=IN IP4 useless.host.name
m=message 7394 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=direction:both a=direction:both
a=session:msrp://example.com:7394/2s93i a=session:msrp://example.com:7394/2s93i
The session URL MUST be a temporary URL assigned just for this The session URL MUST be a temporary URL assigned just for this
particular session. It MUST NOT duplicate any URL in use for any particular session. It MUST NOT duplicate any URL in use for any
other session hosted by the endpoint or relay. Further, since the other session hosted by the endpoint or relay. Further, since the
peer endpoint will use the session URL to identify itself when peer endpoint will use the session URL to identify itself when
connecting, it SHOULD be hard to guess, and protected from connecting, it SHOULD be hard to guess, and protected from
eavesdroppers. This will be discussed in more detail in the Security eavesdroppers. This will be discussed in more detail in Section 10.
Considerations section.
5.4 Example SDP Exchange 6.5 Example SDP Exchange
Endpoint A wishes to invite Endpoint B to a MSRP session. A offers Endpoint A wishes to invite Endpoint B to a MSRP session. A offers
the following session description containing the following lines: the following session description containing the following lines:
c=IN IP4 alice.example.com c=IN IP4 alice.example.com
m=message 7394 msrp/tcp message/cpim text/plain text/html m=message 9999 msrp/tcp message/cpim text/plain text/html
a=direction:both a=direction:both
a=session:msrp://alice.example.com:7394/2s93i9 a=session:msrp://alice.example.com:7394/2s93i9
Endpoint B chooses to participate in the role of visitor, opens a TCP Endpoint B chooses to participate in the role of visitor, opens a TCP
connection to alice.example.com:7394, and successfully performs a connection to alice.example.com:7394, and successfully performs a
VISIT transaction passing the URL of msrp://alice.example.com:7394/ VISIT transaction passing the URL of msrp://alice.example.com:7394/
2s93i9;. B indicates that it has accomplished this by answering with: 2s93i9;. B indicates that it has accomplished this by answering with:
c=IN IP4 dontlookhere c=IN IP4 dontlookhere
m=message 7394 msrp/tcp message/cpim text/plain m=message 9999 msrp/tcp message/cpim text/plain
a=direction:active a=direction:active
A may now send IMs to B by executing SEND transactions on the same A may now send IMs to B by executing SEND transactions on the same
connection on which B sent the VISIT request. connection on which B sent the VISIT request.
6. The Message Session Relay Protocol 7. The Message Session Relay Protocol
The Message Session Relay Protocol (MSRP) is a text based, message The Message Session Relay Protocol (MSRP) is a text based, message
oriented protocol for the transfer of instant messages in the context oriented protocol for the transfer of instant messages in the context
of a session. MSRP uses the UTF8 character set. of a session. MSRP uses the UTF8 character set.
MSRP messages MUST be sent over reliable, congestion-controlled, MSRP messages MUST be sent over reliable, congestion-controlled,
connection-oriented transport protocols, such as TCP. connection-oriented transport protocols, such as TCP.
6.1 MSRP URLs 7.1 MSRP URLs
MSRP sessions are identified by MSRP URLs. An MSRP URL follows a MSRP sessions are identified by MSRP URLs. An MSRP URL follows a
subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme subset of the URL syntax in Appendix A of RFC2396 [4], with a scheme
of "msrp": of "msrp":
msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource] msrp_url = "msrp" ":" "//" [userinfo] hostport ["/' resource]
resource = 1*unreserved resource = 1*unreserved
The constructions for "userinfo", "hostport", and "unreserved" are The constructions for "userinfo", "hostport", and "unreserved" are
detailed in RFC2396 [4]. detailed in RFC2396 [4].
An MSRP URL server part identifies the hosting device of an MSRP An MSRP URL server part identifies the hosting device of an MSRP
session. There is no default port for MSRP URLs. If the server part session. If the server part contains a numeric IP address, it MUST
contains a numeric IP address, it MUST also contain a port. The also contain a port. The resource part identifies a particular
resource part identifies a particular session at that host device. session at that host device. The absence of the resource part
The absence of the resource part indicates a reference to an MSRP indicates a reference to an MSRP host device, but does not
host device, but does not specifically refer to a particular session specifically refer to a particular session resource.
resource.
Open Issue: Do we need a default port? Cullen points out it would MSRP has an IANA registered recommended port defined in Section 9.1.
at least be useful for firewall configuration. However, this value should not be considered a default, as the URL
process described herein will always explicitly resolve a port
number. However, the URLs SHOULD be configured so that the
recommended port is used whenever appropriate. This makes life easier
for network administrators who need to manage firewall policy for
MSRP.
The server part will typically not contain a userinfo component, but The server part will typically not contain a userinfo component, but
MAY do so to indicate a user account for which the session is valid. MAY do so to indicate a user account for which the session is valid.
Note that this is not the same thing as identifying the session Note that this is not the same thing as identifying the session
itself. If a userinfo component exists, MUST be constructed only from itself. If a userinfo component exists, MUST be constructed only from
"unreserved" characters, to avoid a need for escape processing. "unreserved" characters, to avoid a need for escape processing.
Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo Escaping MUST NOT be used in an MSRP URL. Furthermore, a userinfo
part MUST NOT contain password information. part MUST NOT contain password information.
The following is an example of a typical MSRP URL: The following is an example of a typical MSRP URL:
msrp://host.example.com:8493/asfd34 msrp://host.example.com:8493/asfd34
6.2 MSRP URL Comparison 7.1.1 MSRP URL Comparison
MSRP URL comparisons MUST be performed according to the following MSRP URL comparisons MUST be performed according to the following
rules: rules:
The host part is compared as case insensitive. The host part is compared as case insensitive.
If the port exists explicitly in either URL, then it must match If the port exists explicitly in either URL, then it must match
exactly. Since there is no default port for MSRP, a URL with an exactly. An URL with an explicit port is never equivalent to
explicit port is never equivalent to another with no port another with no port specified.
specified.
The resource part is compared as case insensitive. A URL without a The resource part is compared as case insensitive. A URL without a
resource part is never equivalent to one that includes a resource resource part is never equivalent to one that includes a resource
part. part.
Userinfo parts are not considered for URL comparison. Userinfo parts are not considered for URL comparison.
Path normalization is not relevant for MSRP URLs. Escape Path normalization is not relevant for MSRP URLs. Escape
normalization is not required, since the relevant parts are limited normalization is not required, since the relevant parts are limited
to unreserved characters. to unreserved characters.
6.3 Resolving MSRP Host Device 7.1.2 Resolving MSRP Host Device
An MSRP host device is identified by the server part of an MSRP URL. An MSRP host device is identified by the server part of an MSRP URL.
If the server part contains a numeric IP address and port, they MUST If the server part contains a numeric IP address and port, they MUST
be used as listed.. be used as listed..
If the server part contains a host name and a port, the connecting If the server part contains a host name and a port, the connecting
device MUST determine a host address by doing an A or AAAA DNS query, device MUST determine a host address by doing an A or AAAA DNS query,
and use the port as listed. and use the port as listed.
skipping to change at page 13, line 41 skipping to change at page 17, line 16
entry SHOULD be chosen for the initial connection attempt. This entry SHOULD be chosen for the initial connection attempt. This
allows any ordering created in the DNS to be preserved. allows any ordering created in the DNS to be preserved.
5. If the connection attempt fails, the device SHOULD attempt to 5. If the connection attempt fails, the device SHOULD attempt to
connect to the addresses returned in any additional A or AAAA connect to the addresses returned in any additional A or AAAA
records, in the order the records were presented. If all of these records, in the order the records were presented. If all of these
fail, the device SHOULD attempt to use any additional SRV records fail, the device SHOULD attempt to use any additional SRV records
that may have been returned, following the normal rules for SRV that may have been returned, following the normal rules for SRV
record selection. record selection.
Open Issue: We need to carefully consider the rules about A RR
selection. I am sure there are others who understand this much
better than I do. Ted pointed us to RFC1794, which if I understand
correctly indicates that some systems may attempt to load balance
by controlling the order in which A RRs are presented. Attempts to
randomize selection by the client could distort any such control.
Note that in most cases, the transport protocol will be determined Note that in most cases, the transport protocol will be determined
separately from the resolution process. For example, if the MSRP URL separately from the resolution process. For example, if the MSRP URL
was communicated in an SDP offer or answer, the SDP M-line will was communicated in an SDP offer or answer, the SDP M-line will
contain the transport protocol. When an MSRP URL is communicated contain the transport protocol. When an MSRP URL is communicated
outside of SDP, the protocol SHOULD also be communicated. For outside of SDP, the protocol SHOULD also be communicated. For
example, a client may be configured to use a particular relay that is example, a client may be configured to use a particular relay that is
referenced with an MSRP URL. The client MUST also be told what referenced with an MSRP URL. The client MUST also be told what
protocol to use. If a device needs to resolve an MSRP URL and does protocol to use. If a device needs to resolve an MSRP URL and does
not know the protocol, it SHOULD assume TCP. not know the protocol, it SHOULD assume TCP.
Open Issue: Do we need to do an NAPTR query to determine the 7.1.3 The msrps URL Scheme
protocol?
6.3.1 The msrps URL Scheme
The "msrps" URL Scheme indicates that each hop MUST be secured with The "msrps" URL Scheme indicates that each hop MUST be secured with
TLS. Otherwise, it is used identically as an MSRP URL, except that a TLS. Otherwise, it is used identically as an MSRP URL, except that a
MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS MSRPS URL MUST NOT be considered equivalent to an MSRP URL. The MSRPS
scheme is further discussed in the Security Considerations section. scheme is further discussed in Section 10.
6.4 MSRP messages 7.2 MSRP messages
MSRP messages are either requests or responses. Requests and MSRP messages are either requests or responses. Requests and
responses are distinguished from one another by the first line. The responses are distinguished from one another by the first line. The
first line of a Request takes the form of the request-start entry first line of a Request takes the form of the request-start entry
below. Likewise, the first line of a response takes the form of below. Likewise, the first line of a response takes the form of
response-start. The syntax for an MSRP message is as follows: response-start. The syntax for an MSRP message is as follows:
msrp-message = request-start/response-start *(header CRLF) msrp-message = request-start/response-start *(header CRLF)
[CRLF body] [CRLF body]
request-start = "MSRP" SP length SP Method CRLF request-start = "MSRP" SP length SP Method CRLF
skipping to change at page 15, line 19 skipping to change at page 18, line 19
Reason CRLF Reason CRLF
length = 1*DIGIT ; the length of the message, exclusive of the start line. length = 1*DIGIT ; the length of the message, exclusive of the start line.
Method = SEND / BIND / VISIT Method = SEND / BIND / VISIT
header = Client-Authenticate / Server-Challenge / header = Client-Authenticate / Server-Challenge /
Transaction-ID / Session-URL/ Content-Type / Expires Transaction-ID / Session-URL/ Content-Type / Expires
Status-Code = 200 ;Success Status-Code = 200 ;Success
/ 400 ;Bad Request / 400 ;Bad Request
/ 401 ;Authentication Required / 401 ;Authentication Required
/ 403 ;Forbidden / 403 ;Forbidden
/ 415 ;Unsupported Content Type / 415 ;Unsupported Content Type
/ 426 ;Upgrade Required
/ 481 ;No session / 481 ;No session
/ 500 ;Cannot Deliver / 500 ;Cannot Deliver
/ 506 ;duplicate session / 506 ;duplicate session
Reason = token ; Human readable text describing status Reason = token ; Human readable text describing status
Client-Authenticate = "CAuth" credentials Client-Authenticate = "CAuth" credentials
Server-Challenge = "SChal" ":" challenge Server-Challenge = "SChal" ":" challenge
Transaction-ID = "Tr-ID" ":" token Transaction-ID = "Tr-ID" ":" token
Content-Type = "Content-Type" ":" quoted-string Content-Type = "Content-Type" ":" quoted-string
Session-URL = "S-URL" ":" msrp_url Session-URL = "S-URL" ":" msrp_url
Expires = "Exp"":" delta-seconds Expires = "Exp"":" delta-seconds
delta-seconds= 1*DIGIT ; Integer number of seconds delta-seconds= 1*DIGIT ; Integer number of seconds
All requests and responses MUST contain at least a TR-ID header All requests and responses MUST contain at least a TR-ID header
field. Messages MAY contain other fields, depending on the method or field. Messages MAY contain other fields, depending on the method or
response code. response code.
6.5 MSRP Transactions 7.3 MSRP Transactions
An MSRP transaction consists of exactly one request and one response. An MSRP transaction consists of exactly one request and one response.
A response matches a transaction if it share the same TR-ID value, A response matches a transaction if it share the same TR-ID value,
and arrives on the same connection on which the transaction was sent. and arrives on the same connection on which the transaction was sent.
BIND is always hop by hop. VISIT transactions are usually hop-by-hop, BIND is always hop by hop. VISIT transactions are usually hop-by-hop,
but may be relayed in situations where the visiting endpoint uses a but may be relayed in situations where the visiting endpoint uses a
relay. However, SEND transactions are end to end, meaning that under relay. However, SEND transactions are end-to-end, meaning that under
normal circumstances the response is sent by the peer endpoint, even normal circumstances the response is sent by the peer endpoint, even
if there are intervening relays. if there are intervening relays.
Endpoints MUST select TR-ID header field values in requests so that Endpoints MUST select TR-ID header field values in requests so that
they are not repeated by the same endpoint in scope of the given they are not repeated by the same endpoint in scope of the given
session. TR-ID values SHOULD be globally unique. The TR-ID space of session. TR-ID values SHOULD be globally unique. The TR-ID space of
each endpoint is independent of that of its peer. Endpoints MUST NOT each endpoint is independent of that of its peer. Endpoints MUST NOT
infer any semantics from the TR-ID header field beyond what is stated infer any semantics from the TR-ID header field beyond what is stated
above. In particular, TR-ID values are not required to follow any above. In particular, TR-ID values are not required to follow any
sequence. sequence.
MSRP Transactions complete when a response is received, or after a MSRP Transactions complete when a response is received, or after a
timeout interval expires with no response. Endpoints MUST treat such timeout interval expires with no response. Endpoints MUST treat such
timeouts in exactly the same way they would treat a 500 response. The timeouts in exactly the same way they would treat a 500 response. The
size of the timeout interval is a matter of local policy. size of the timeout interval is a matter of local policy, with a
default of 30 seconds after a request has been completely sent.
6.6 MSRP Sessions 7.4 MSRP Sessions
AN MSRP session is a context in which a series of instant messages AN MSRP session is a context in which a series of instant messages
are exchanged, using SEND requests. A session has two endpoints (a are exchanged, using SEND requests. A session has two endpoints (a
host and a visitor) and may have one or two relays. A session is host and a visitor) and may have one or two relays. A session is
identified by an MSRP URL. identified by an MSRP URL.
6.6.1 Initiating an MSRP session 7.4.1 Initiating an MSRP session
When an endpoint wishes to engage a peer endpoint in a message When an endpoint wishes to engage a peer endpoint in a message
session, it invites the peer to communicate using an SDP offer, session, it invites the peer to communicate using an SDP offer,
carried over SIP or some other protocol supporting the SDP offer/ carried over SIP or some other protocol supporting the SDP offer/
answer model. For the purpose of this document, we will refer to the answer model. For the purpose of this document, we will refer to the
endpoint choosing to initiate communication as the offerer, and the endpoint choosing to initiate communication as the offerer, and the
peer being invited as the answerer. peer being invited as the answerer.
The offerer SHOULD volunteer to act as the hosting endpoint if The offerer SHOULD volunteer to act as the hosting endpoint if
allowed by policy and network topology. An endpoint is said to host a allowed by policy and network topology. An endpoint is said to host a
skipping to change at page 16, line 49 skipping to change at page 19, line 50
If the offerer wishes to host the session directly, that is without If the offerer wishes to host the session directly, that is without
using a relay, it MUST perform the following steps: using a relay, it MUST perform the following steps:
1. Construct a session MSRP URL . This URL MUST be resolvable to the 1. Construct a session MSRP URL . This URL MUST be resolvable to the
offerer. The URL SHOULD be temporary, SHOULD be hard to guess, offerer. The URL SHOULD be temporary, SHOULD be hard to guess,
and MUST not duplicate the URL of any other session currently and MUST not duplicate the URL of any other session currently
hosted by the offerer. hosted by the offerer.
2. Listen for a connection from the peer. 2. Listen for a connection from the peer.
3. Construct an SDP offer as described in Section 5, including the 3. Construct an SDP offer as described in Section 6, including the
list of allowed IM payload formats in the format list. The list of allowed IM payload formats in the format list. The
offerer maps the session URL to the session attribute, as offerer maps the session URL to the session attribute, as
described in Section 5.3. described in Section 6.4.
4. Insert a direction attribute. This value SHOULD be "both", 4. Insert a direction attribute. This value SHOULD be "both",
indicating that the offerer will allow the answerer to override indicating that the offerer will allow the answerer to override
the offerer's decision to host. The value MAY be "passive" if the the offerer's decision to host. If "both" is selected, the
offerer is prevented from allowing the answerer override this offerer SHOULD leave the timeout at the default value (by leaving
choice. out the value entirely." However, the offerer MAY select a
different timeout if circumstances warrant it. The direction
value MAY be "passive" if the offerer is prevented from allowing
the answerer override this choice.
5. Send the SDP offer using the normal processing for the signaling 5. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
If the offerer chooses to force the answerer to host the session, it If the offerer chooses to force the answerer to host the session, it
MUST perform the following steps instead: MUST perform the following steps instead:
1. Construct an SDP offer as described above, but with no session 1. Construct an SDP offer as described above, but with no session
attribute. attribute.
skipping to change at page 17, line 38 skipping to change at page 20, line 42
visitor. A direction attribute value of "both" in the offer indicates visitor. A direction attribute value of "both" in the offer indicates
that the offerer wishes to host, but will allow the answerer to host, that the offerer wishes to host, but will allow the answerer to host,
in which case the answerer SHOULD act as the visitor, but MAY choose in which case the answerer SHOULD act as the visitor, but MAY choose
to host. A value of "passive" means the offerer insists upon hosting, to host. A value of "passive" means the offerer insists upon hosting,
in which case the answerer MUST act as visitor or decline the offer. in which case the answerer MUST act as visitor or decline the offer.
If the answerer chooses to participate as a visitor, it MUST perform If the answerer chooses to participate as a visitor, it MUST perform
the following steps: the following steps:
1. Determine the host address and port from the session URL, 1. Determine the host address and port from the session URL,
following the procedures in section Section 6.1 following the procedures in section Section 7.1
2. Connect to the host address and port, using the transport 2. Connect to the host address and port, using the transport
protocol from the M-line. protocol from the M-line.
3. Construct a VISIT request, which MUST contain the following 3. Construct a VISIT request, which MUST contain the following
information: information:
1. An S-URL header field containing the session URL. 1. An S-URL header field containing the session URL.
2. A TR-ID header field containing a unique transaction ID. 2. A TR-ID header field containing a unique transaction ID.
3. An Exp header field containing the expiration time for the 3. A size field containing size of the message subsequent to the
VISIT request.
4. A size field containing size of the message subsequent to the
start-line. start-line.
4. Send the request and wait for a response 4. Send the request and wait for a response
5. If the transaction succeeds, set the actual expiration time to 5. If the transaction succeeds, send a SDP answer via the signaling
the value in the Exp header field in the response, and send a SDP protocol, according to the following rules:
answer via the signaling protocol, according to the following
rules:
1. The C-line is copied unmodified from the offer. 1. The C-line is copied unmodified from the offer.
2. The M-Line contains a dummy port value, the protocol field 2. The M-Line contains a dummy port value, the protocol field
from the original offer, and a format list describing the from the original offer, and a format list describing the
SEND payload media types that the answerer is willing to SEND payload media types that the answerer is willing to
accept. The format list in the answer MUST be either the same accept. The format list in the answer MUST be either the same
as the format list in the offer, or a subset. as the format list in the offer, or a subset.
3. A direction attribute containing the value "active". 3. A direction attribute containing the value "active".
6. If the transaction fails, the answerer MAY choose to act as host, 6. If the transaction fails, the answerer MAY choose to act as host,
if allowed by the direction attribute of the answer. If the if allowed by the direction attribute of the answer. If the
answerer is unable or unwilling to host, then it should return an answerer is unable or unwilling to host, then it should return an
error response as appropriate for the signaling protocol. error response as appropriate for the signaling protocol.
Some TCP connection failure conditions may ordinarily take some time
to notice. For example, if the offerer is unable to open a TCP
connection to the host device, this connection attempt may take a
fairly large number of seconds to timeout. This length of time will
not be acceptable for many call flow scenarios. Therefore, the
devices SHOULD limit the time they wait for the TCP connection to a
shorter timeout value, which will default to 30 seconds. However, the
offerer MAY supply a different time in the timeout parameter of the
"both" direction value. If the offerer supplies a value, the answerer
SHOULD use that value for the TCP connection timeout, interpreted as
an integer number of seconds.
If the answerer chooses to host the session, it MUST perform the If the answerer chooses to host the session, it MUST perform the
following steps: following steps:
1. Construct a new session URL . This MUST be a MSRP URL, MUST 1. Construct a new session URL . This MUST be a MSRP or MSRPS URL,
resolve to the answerer, and MUST not be the same as the session MUST resolve to the answerer, and MUST not be the same as the
URL in the offer. The URL SHOULD be temporary, SHOULD be hard to session URL in the offer. The URL SHOULD be temporary, SHOULD be
guess, and MUST not duplicate URLs currently identifying any hard to guess, and MUST not duplicate URLs currently identifying
active sessions hosted by the answerer. any active sessions hosted by the answerer.
2. Listen for a connection from the peer. 2. Listen for a connection from the peer.
3. Construct an SDP answer as described in Section 5, mapping the 3. Construct an SDP answer as described in Section 6, mapping the
new session URL to the session attribute, and inserting a new session URL to the session attribute, and inserting a
direction attribute with the value of "passive". direction attribute with the value of "passive".
4. Send the SDP offer using the normal processing for the signaling 4. Send the SDP offer using the normal processing for the signaling
protocol. protocol.
When the offerer receives the SDP answer, it must determine who will When the offerer receives the SDP answer, it must determine who will
continue to host the session. If the answer contained a direction continue to host the session. If the answer contained a direction
attribute value of "active", the offerer MUST continue as host. If attribute value of "active", the offerer MUST continue as host. If
the offer contained "active" or "both" and the answer contains the offer contained "active" or "both" and the answer contains
"passive", then the offerer MUST allow the answerer to host the "passive", then the offerer MUST allow the answerer to host the
session. session.
If the offerer chooses not to continue as host, it MUST perform the If the offerer chooses not to continue as host, it MUST perform the
following steps: following steps:
1. Release resources it acquired in expectation of hosting the 1. Release resources it acquired in expectation of hosting the
session, if any. session, if any.
2. Determine the host address and port from the session URL of the 2. Determine the host address and port from the session URL of the
answer, following the procedures in section Section 6.1 answer, following the procedures in section Section 7.1
3. Connect to the host address and port, using the transport 3. Connect to the host address and port, using the transport
protocol from the M-line. protocol from the M-line.
4. Construct a VISIT request, which MUST contain the following 4. Construct a VISIT request, which MUST contain the following
information: information:
1. A S-URL header field containing the session URL. 1. A S-URL header field containing the session URL.
2. A TR-ID header field containing a unique transaction ID. 2. A TR-ID header field containing a unique transaction ID.
3. An Exp header field containing the expiration time for the 3. A size field containing size of the message subsequent to the
VISIT request.
4. A size field containing size of the message subsequent to the
start-line. start-line.
5. Send the request and wait for a response 5. Send the request and wait for a response
6. If the transaction succeeds, set the actual expiration time to 6. If the transaction succeeds, set the actual expiration time to
the value in the Exp header field in the response, and the value in the Exp header field in the response, and
acknowledge the answer via the signaling protocol. If either the acknowledge the answer via the signaling protocol. If either the
connection attempt or the VISIT transaction fail, acknowledge the connection attempt or the VISIT transaction fail, acknowledge the
answer, then initiate the tear-down of the session using the answer, then initiate the tear-down of the session using the
signaling protocol. signaling protocol.
6.6.2 Handling VISIT requests 7.4.2 Handling VISIT requests
An MSRP endpoint that is hosting a session will receive a VISIT An MSRP endpoint that is hosting a session will receive a VISIT
request from the visiting endpoint. When an endpoint receives a VISIT request from the visiting endpoint. When an endpoint receives a VISIT
request, it MUST perform the following procedures: request, it MUST perform the following procedures:
1. Check if state exists for a session with a URL that matches the 1. Check if state exists for a session with a URL that matches the
S-URL of the VISIT request. If so, and if no visitor connection S-URL of the VISIT request. If so, and if no visitor connection
has been associated with the session, determine the expiration has been associated with the session, then return a 200 response,
time according to the procedures in Section 6.8, then return a and save state designating the connection on which the request
200 response, and save state designating the connection on which was received as the visitor leg of the session.
the request was received as the visitor leg of the session.
2. If the session exists, and the visitor connection has already 2. If the session exists, and the visitor connection has already
been established, and the request arrived on the existing visitor been established, return a 506 response and do not change session
connection, treat the request as a refresh, as described in state in any way.
Section 6.8. If the request arrived on a different connection,
return a 506 response and do not change session state in any way.
3. If no matching session exists, return a 481 request, and do not 3. If no matching session exists, return a 481 request, and do not
change session state in any way. change session state in any way.
6.6.3 Sending Instant Messages on a Session 7.4.3 Sending Instant Messages on a Session
Once a MSRP session has been established, either endpoint may send Once a MSRP session has been established, either endpoint may send
instant messages to its peer using the SEND method. When an endpoint instant messages to its peer using the SEND method. When an endpoint
wishes to do so, it MUST construct a SEND request according to the wishes to do so, it MUST construct a SEND request according to the
following process: following process:
1. Insert the message payload in the body, and the media type in the 1. Insert the message payload in the body, and the media type in the
Content-Type header field. The media type MUST match one of the Content-Type header field. The media type MUST match one of the
types in the format list negotiated in the SDP exchange. If a "*" types in the format list negotiated in the SDP exchange. If a "*"
is present in the format list, then the media type SHOULD match is present in the format list, then the media type SHOULD match
skipping to change at page 21, line 16 skipping to change at page 24, line 24
following steps. following steps.
1. Determine that it understands the media type in the body, if any 1. Determine that it understands the media type in the body, if any
exists. exists.
2. If it does, return a 200 response and render the message to the 2. If it does, return a 200 response and render the message to the
user. The method of rendering is a matter of local policy. user. The method of rendering is a matter of local policy.
3. If it does not understand the media type, return a 415 response. 3. If it does not understand the media type, return a 415 response.
6.6.3.1 Ending a Session 7.4.4 Ending a Session
When either endpoint in an MSRP session wishes to end the session, it When either endpoint in an MSRP session wishes to end the session, it
first signals its intent using the normal processing for the first signals its intent using the normal processing for the
signaling protocol. For example, in SIP, it would send a BYE request signaling protocol. For example, in SIP, it would send a BYE request
to the peer. After agreeing to end the session, the host endpoint to the peer. After agreeing to end the session, the host endpoint
MUST release any resources acquired as part of the session. The MUST release any resources acquired as part of the session. The
process for this differs depending on whether the session is hosted process for this differs depending on whether the session is hosted
directly by the host, or an a relay. directly by the host, or an a relay.
The host MUST destroy local state for the session. This involves The host MUST destroy local state for the session. This involves
completely removing the state entry for this session and invalidating completely removing the state entry for this session and invalidating
session URL. If the host is using an MSRP relay, it MUST send a BIND session URL. If the host is using an MSRP relay, it MUST send a BIND
containing an expires value of zero. This request MUST be sent host containing an expires value of zero. This request MUST be sent host
connection established by the original BIND request. This BIND connection established by the original BIND request. This BIND
request MUST include the session URL in the S-URL header field. request MUST include the session URL in the S-URL header field.
Since these host actions completely destroy the session state at Since these host actions completely destroy the session state at
the hosting device, the visitor is not required to take further the hosting device, the visitor is not required to take further
action beyond cleaning up any local state. If for some reason the action beyond cleaning up any local state. If for some reason the
host fails to destroy session state, the state will be invalidated host fails to destroy session state, the state will be invalidated
anyway when either of the original BIND or VISIT requests expire. anyway when the inactivity timer expires.
6.6.4 Managing Session State and Connections 7.4.5 Session Inactivity Timer
State associated with MSRP sessions, either at the host endpoint, or
a hosting or visiting relay, is soft-state; that is, it expires over
time if no message activity occurs. Each such device maintains a pair
of inactivity timer, each with an initial value of 1 minute. One of
these timers is assigned for each endpoint.
All devices use the same, predetermined timer expiration value.
While there might be some utility in negotiating this timer on a
per device basis, such negotiation would add a great deal of
complexity to MSRP.
When a hosting device or visiting relay returns a successful response
to a VISIT request, it MUST initialize both timers. The device MUST
reset a timer anytime the associated endpoint sends a SEND request.
If either timer expires without being reset, the device MUST
invalidate the session, using normal procedures depending on the
device's role in the session.
Each endpoint MUST keep a similar timer, which it initializes when
the session is created from its perspective. For the host endpoint,
this is when it receives a successful response to a BIND request. For
a visiting endpoint, this is when it sees a successful response to a
VISIT request. Each endpoint resets its timer whenever it sends a
SEND request. If an endpoint inactivity timer approaches expiration,
and the endpoint wishes to continue participating in the session, it
MUST send a SEND request. This request MAY be sent without a body if
there is no user data to send. Endpoints MUST select the timer value
so that there is sufficient time for the SEND request to traverse to
the opposite endpoint. If the endpoint waits to the last moment,
there is a danger that it will not be received by all relevant
devices in time to prevent session destruction.
7.4.6 Managing Session State and Connections
A MSRP session is represented by state at the host device. As mention A MSRP session is represented by state at the host device. As mention
previously, session state is identified by an MSRP URL. An active previously, session state is identified by an MSRP URL. An active
session also has two associated network connections. The connection session also has two associated network connections. The connection
hosting device and the host endpoint is known as the host connection. hosting device and the host endpoint is known as the host connection.
The connection with the visiting endpoint is the visiting connection. The connection with the visiting endpoint is the visiting connection.
Note that when the session state is hosted directly by an endpoint, Note that when the session state is hosted directly by an endpoint,
the host connection may not involve a physical network connection; the host connection may not involve a physical network connection;
rather it is a logical connection the device maintains with itself. rather it is a logical connection the device maintains with itself.
skipping to change at page 22, line 28 skipping to change at page 26, line 22
approach creates a race condition between the time that the approach creates a race condition between the time that the
hosting device notices the failed connection, and the time that hosting device notices the failed connection, and the time that
the endpoint tries to recover the session. If the endpoint the endpoint tries to recover the session. If the endpoint
attempts to reconnect prior to the hosting device noticing the attempts to reconnect prior to the hosting device noticing the
failure, the hosting device will interpret the recovery attempt as failure, the hosting device will interpret the recovery attempt as
a conflict. The only way around this would be to force the hosting a conflict. The only way around this would be to force the hosting
device to do a liveness check on the original connection, which device to do a liveness check on the original connection, which
would create a lot of complexity and overhead that do not seem to would create a lot of complexity and overhead that do not seem to
be worth the trouble. be worth the trouble.
6.7 MSRP Relays 7.5 MSRP Relays
6.7.1 Establishing Session State at a Relay 7.5.1 Establishing Session State at a Relay
An endpoint that wishes to host a MSRP session MAY do so by An endpoint that wishes to host a MSRP session MAY do so by
initiating session state at a MSRP relay, rather than hosting initiating session state at a MSRP relay, rather than hosting
directly. An endpoint may wish to do this because network topology or directly. An endpoint may wish to do this because network topology or
local policy prevents a peer from connecting directly to the local policy prevents a peer from connecting directly to the
endpoint. The use of a relay should not be the default case, that is, endpoint. The use of a relay should not be the default case, that is,
a hosting endpoint that is not prevented from doing so by topology or a hosting endpoint that is not prevented from doing so by topology or
policy SHOULD host the session directly. In order to use a relay, an policy SHOULD host the session directly. In order to use a relay, an
MSRP endpoint MUST have knowledge of that relay's existence and MSRP endpoint MUST have knowledge of that relay's existence and
location.. location..
We previously mentioned how an endpoint wishing to host a MSRP We previously mentioned how an endpoint wishing to host a MSRP
session constructs session URL. When using a relay, the endpoint session constructs session URL. When using a relay, the endpoint
delegates that responsibility to the relay. delegates that responsibility to the relay.
To establish session state at a relay, the endpoint MUST perform the To establish session state at a relay, the endpoint MUST perform the
following steps: following steps:
1. Open a network connection to the relay at the relays address and 1. Open a network connection to the relay at the relays address and
the well-known port for MSRP relays, or at another port if so port. Normally, this information will be resolved from an MSRP
configured. URL representing the relay, although the relay MAY be configured
with an explicit address and port, rather than a URL.
2. Construct a BIND request with a S-URL that refers to the relay. 2. Construct a BIND request with a S-URL that refers to the relay.
3. Set the Expire header field to a desired value. 3. Set the Expire header field to a desired value.
4. Send the BIND request on the connection. 4. Send the BIND request on the connection.
5. Respond to any authentication request from the relay. 5. Respond to any authentication request from the relay.
6. If the response has a 2xx status code, use the URL in the S-URL 6. If the response has a 2xx status code, use the URL in the S-URL
header field as the session URL. The endpoint uses this URL in header field as the session URL. The endpoint uses this URL in
exactly the same manner as it had constructed it itself. exactly the same manner as it had constructed it itself.
Additionally, accept the expires value in the response as session Additionally, accept the expires value in the response as
expiration time. pre-visit expiration time.
A MSRP relay listens for connections to its well-known port at all A MSRP relay listens for connections at all times. When it receives a
times. When it receives a BIND request, it SHOULD authenticate the BIND request, it SHOULD authenticate the request, either using
request, either using digest-authentication, TLS authentication, or digest-authentication, TLS authentication, or some other
some other authentication mechanism. If authentication succeeds, the authentication mechanism. If authentication succeeds, the relay
relay performs the following steps: performs the following steps:
1. Verify the client is authorized to BIND to this relay. If not, 1. Verify the client is authorized to BIND to this relay. If not,
return a 403 response and make no state change. return a 403 response and make no state change.
2. If the client is authorized, construct a session MSRP URL. The 2. If the client is authorized, construct a session MSRP URL. The
URL MUST resolve to the relay. It SHOULD be temporary, and hard URL MUST resolve to the relay. It SHOULD be temporary, and hard
to guess. It MUST not duplicate URL used in any active sessions to guess. It MUST not duplicate URL used in any active sessions
hosted by the relay. If the relay wishes the visiting endpoint to hosted by the relay. If the relay wishes the visiting endpoint to
connect over a point other than the MSRP relay well-know port, it connect over a point other than the MSRP relay well-know port, it
MUST explicitly add the port number to visitor URL. MUST explicitly add the port number to visitor URL.
3. Establish the expiration time for the session according to 3. Establish the pre-visit expiration time for the session according
section Section 6.8. to section Section 7.4.5.
4. Create state for the session. The relay MUST associate the 4. Create state for the session. The relay MUST associate the
connection on which the BIND request arrived as the host connection on which the BIND request arrived as the host
connection for the session. connection for the session.
5. Return a 200 response, with the session URL in the S-URL header 5. Return a 200 response, with the session URL in the S-URL header
field, and the session expiration time in the Exp header field.. field, and the pre-visit session expiration time in the Exp
header field.
When an MSRP relay receives a VISIT request, it MUST perform the When an MSRP relay receives a VISIT request, it MUST perform the
following steps: following steps:
1. Check the S-URL header field value to see it matches the URL for 1. Check the S-URL header field value to see it matches the URL for
an existing session state entry. an existing session state entry.
2. If not, return a 481 response and make no state changes 2. If not, return a 481 response and make no state changes
3. If it matches, but another connection has already been associated 3. If it matches, but another connection has already been associated
with the session URL, return a 506 response and make no state with the session URL, return a 506 response and make no state
changes. If the session has been previously associated with this changes. If the session has been previously associated with this
connection, treate the request as a refresh. connection, treat the request as a refresh.
4. If it matches, and no visiting connection has been previously 4. If it matches, and no visiting connection has been previously
associated with the session, then the VISIT succeeds. The relay associated with the session, then the VISIT succeeds. The relay
assigns the connection on which it received the VISIT request as assigns the connection on which it received the VISIT request as
the visiting connection for the session, and returns a 200 the visiting connection for the session, and returns a 200
response. The visit expiration time is established as described response.
in Section 6.8 and returned in the response.
6.7.2 Removing Session State from a relay 7.5.2 Removing Session State from a relay
An MSRP relay SHOULD remove state for a session when any of the An MSRP relay SHOULD remove state for a session when any of the
following conditions occur: following conditions occur:
o The expiration time for either the BIND or VISIT is reached o The session inactivity timer expires.
without a respective refresh request.
o The pre-visit timer expires before a VISIT request has occurred.
o The host sends a BIND refresh request matching with an expiration o The host sends a BIND refresh request matching with an expiration
value of zero. value of zero.
o Either the host or visitor network connection fails for any o Either the host or visitor network connection fails for any
reason. reason.
6.7.3 Sending IMs across an MSRP relay 7.5.3 Sending IMs across an MSRP relay
Once a session is established at a relay, the host and visitor may Once a session is established at a relay, the host and visitor may
exchange IMs by sending SEND requests. Under normal circumstances, exchange IMs by sending SEND requests. Under normal circumstances,
the relay does not respond to SEND requests in any way. Rather, the the relay does not respond to SEND requests in any way. Rather, the
relay MUST forward the request to the peer connection unchanged. relay MUST forward the request to the peer connection unchanged.
Likewise, if the relay receives a response it MUST forward the Likewise, if the relay receives a response it MUST forward the
request unchanged on the peer connection. request unchanged on the peer connection.
If a SEND request arrives on a connection that is not associated with If a SEND request arrives on a connection that is not associated with
a session, the relay MUST return a 481 response. a session, the relay MUST return a 481 response.
6.7.4 Relay Pairs 7.5.4 Relay Pairs
In rare circumstances, two relays may be required in a session. For In rare circumstances, two relays may be required in a session. For
example, two endpoints may exist in separate administrative domains, example, two endpoints may exist in separate administrative domains,
where each domain's policy insist that all sessions must cross that where each domain's policy insist that all sessions must cross that
domain's relay. A relay operating on behalf of the visiting endpoint domain's relay. A relay operating on behalf of the visiting endpoint
is known as a visiting relay. An MSRP relay MAY be capable of acting is known as a visiting relay. An MSRP relay MAY be capable of acting
as a visiting relay. as a visiting relay.
This document does not describe a mechanism for an endpoint to
discover that it needs to use a visiting relay. We assume that an
endpoint is globally configured to use or not use such a relay,
and does not make this decision on a session-by-session basis.
This, of course, does not preclude using some other mechanism to
make such a decision.
In a two relay scenario, the visitor connects to a relay operating on In a two relay scenario, the visitor connects to a relay operating on
its behalf, rather than connecting directly to the hosting device. its behalf, rather than connecting directly to the hosting device.
The visitor sends a VISIT request as it would if it had connected The visitor sends a VISIT request as it would if it had connected
directly to the hosting device. The visiting relay then connect to directly to the hosting device. The visiting relay then connects to
the hosting device and performs a VISIT request on behalf of the the hosting device and performs a VISIT request on behalf of the
visitor. visitor.
When a relay that is capable of acting as a visiting relay receives a When a relay that is capable of acting as a visiting relay receives a
VISIT request, it MUST check to see if the S-URL of the request VISIT request, it MUST check to see if the S-URL of the request
matches a domain that the relay hosts. If the URL matches, then the matches a domain that the relay hosts. If the URL matches, then the
visitor is not requesting the relay act as a visiting relay, and it visitor is not requesting the relay act as a visiting relay, and it
SHOULD operate normally. If the URL does not match, then the relay SHOULD operate normally. If the URL does not match, then the relay
SHOULD perform the following steps: SHOULD perform the following steps:
skipping to change at page 25, line 40 skipping to change at page 29, line 42
visiting endpoint connecting directly. If this connection is visiting endpoint connecting directly. If this connection is
successful, continue with the remaining steps. Otherwise, return successful, continue with the remaining steps. Otherwise, return
a 500 response. a 500 response.
4. Create local state to associate the connection to the host device 4. Create local state to associate the connection to the host device
with the connection to the visiting device. with the connection to the visiting device.
5. Relay the VISIT request unchanged to the hosting device. 5. Relay the VISIT request unchanged to the hosting device.
6. Relay the response to the VISIT request unchanged to the visiting 6. Relay the response to the VISIT request unchanged to the visiting
endpoint. If the response is a 200, set the expiration time for endpoint.
the local session state to the value in the Exp header in the
response.
7. Relay all subsequent arriving on one of the associated 7. Relay all subsequent arriving on one of the associated
connections to the peer connection. connections to the peer connection.
The preceding steps result in local session state that expires based
on the expiration time negotiated between the visiting endpoint and
the hosting device. The visiting endpoint will send VISIT requests on
the same connection from time to time to refresh the session state
expiration time. A visiting relay MUST refresh the local expiration
time based on the Exp header field value in a successful response to
such a VISIT request. If the local expiration time passes without a
refresh, the visiting relay SHOULD invalidate the session state and
SHOULD drop the associated connections.
If either associated connection fails for any reason, the visiting If either associated connection fails for any reason, the visiting
relay SHOULD invalidate the session state, and SHOULD drop the peer relay MUST invalidate the session state, and MUST drop the peer
connection. connection.
6.8 Session State Expiration 7.6 Digest Authentication
State associated with MSRP sessions, either at the host endpoint or a
host relay, is soft-state; that is, it expires over time unless
refreshed. The expiration time is determined by the Expires header
field in VISIT and BIND requests. All VISIT and BIND requests MUST
contain an Expires header field. This field is defined as an integer
number of seconds from the time that the request is received.
When a hosting device (endpoint or relay) creates session state due
to a successful VISIT request, it SHOULD accept the Expires value
from the request, although it MAY choose a smaller value. It MUST NOT
choose a larger value. The device MUST communicate the actual chosen
value back to the opposite endpoint by placing the value in an
expires header field in the response.
Likewise, when a relay creates session state due to a successful BIND
request, it SHOULD accept the expires value from the request,
although it MAY choose a smaller value. It MUST NOT choose a larger
value. The device MUST communicate the actual chosen value back to
the opposite endpoint by placing the value in an Expires header field
in the response.
A visiting relay does not normally respond to a VISIT request.
Rather, it relays the request to the hosting device, and relays the
resulting response back to the visiting endpoint. This prevents it
from being able to negotiate the expiration time in the same way as
hosting devices. Therefore, a visiting relay MUST determine session
expiration time from the Exp header field in any 200 response
returned by the hosting device.
6.9 Digest Authentication
MSRP relays may use the digest authentication scheme to authenticate MSRP relays may use the digest authentication scheme to authenticate
users. MSRP digest authentication is a simplified version of HTTP users. MSRP digest authentication is a simplified version of HTTP
digest authentication [18], but this specification does not digest authentication [19], but this specification does not
normatively depend on that document. MSRP digest authentication does normatively depend on that document. MSRP digest authentication does
not support the concept of a protection domain, nor does it support not support the concept of a protection domain, nor does it support
integrity protection. Since a user of a relay is expected to have integrity protection. Since a user of a relay is expected to have
credentials for that particular relay, it does not support the realm credentials for that particular relay, it does not support the realm
concept. Finally, since digest authentication is only expected for concept. Finally, since digest authentication is only expected for
the initial BIND or VISIT request, MSRP does not support HTTP digest the initial BIND or VISIT request, MSRP does not support HTTP digest
optimizations such as MD5-sess and preemptive credential loading by optimizations such as MD5-sess and preemptive credential loading by
the client. the client.
Typically, a hosting user that uses a relay will have a preexisting Typically, a hosting user that uses a relay will have a preexisting
relationship with that relay. This relationship SHOULD include relationship with that relay. This relationship SHOULD include
authentication credentials. An MSRP relay SHOULD authenticate initial authentication credentials. An MSRP relay SHOULD authenticate initial
BIND requests. BIND requests.
It is less likely that the visiting user will have an account at the It is less likely that the visiting user will have an account at the
hosting relay, so in many cases the authentication of VISIT requests hosting relay, so in most cases the authentication of VISIT requests
is not useful. However a relay MAY authenticate initial VISIT is not useful. However a relay MAY authenticate initial VISIT
requests. A visiting relay SHOULD authenticate initial VISIT requests. A visiting relay SHOULD authenticate initial VISIT
requests, as it is much more likely to share credentials with the requests, as it is much more likely to share credentials with the
visiting user. visiting user.
There has been some discussion that a hosting relay SHOULD also There has been some discussion that a hosting relay SHOULD also
authenticate VISIT requests. However, it will be very common for authenticate VISIT requests. However, it will be common for
visiting users to have no preexisting relationship with the host visiting users to have no preexisting relationship with the host
relay. Using authentication here would require the host endpoint relay. Using authentication here would require the host endpoint
to send temporary credentials in the SDP exchange, perhaps as part to send temporary credentials in the SDP exchange, perhaps as part
of the session URL. However, these temporary credentials would of the session URL. However, these temporary credentials would
necessarily be transferred via the same channels as the session necessarily be transferred via the same channels as the session
URL itself. If the credentials are sufficiently protected in URL itself. If the credentials are sufficiently protected in
transfer, then so is the session URL. Further, since the session transfer, then so is the session URL. Further, since the session
URL is intended for a one time use, and is expected to be hard to URL is intended for a one time use, and is expected to be hard to
guess, that URL itself may be sufficient for this purpose. guess, that URL itself should be sufficient for this purpose. Any
situation where this is not adequate can be covered by the use of
the MSRPS scheme.
MSRP relays MUST NOT request authentication for any method other than MSRP relays MUST NOT request authentication for any method other than
BIND and VISIT. BIND and VISIT.
If a relay wishes to authenticate a request using digest If a relay wishes to authenticate a request using digest
authentication, it MAY challenge the request by responding with a authentication, it MAY challenge the request by responding with a
401 response, which MUST include a SChal header field. 401 response, which MUST include a SChal header field.
If an endpoint wishes to respond to a digest authentication challenge If an endpoint wishes to respond to a digest authentication challenge
received in a 401 response, it MAY do so by sending a new VISIT or received in a 401 response, it MAY do so by sending a new VISIT or
BIND request, identical to the previous request, but with a CAuth BIND request, identical to the previous request, but with a CAuth
header field containing the response to the challenge. header field containing the response to the challenge.
6.9.1 The MD5 Algorithm 7.6.1 The SHA1 Algorithm
The only digest authentication algorithm defined in this The only digest authentication algorithm defined in this
specification is MD5. [8] Other algorithms can be added as specification is SHA1. [9] Other algorithms can be added as
extensions. MD5 is the default algorithm if no algorithm directive is extensions. SHA1 is the default algorithm if no algorithm directive
present in the challenge. is present in the challenge.
The MD5 algorithm is defined as follows: The SHA1 digest is defined as follows:
Let KD(secret, data) denote the string obtained by performing the Let KD(secret, data) denote the string obtained by performing the
digest algorithm to the data "data" with the secret "secret". Let digest algorithm to the data "data" with the secret "secret". Let
H(data) denote the string obtained by performing the checksum H(data) denote the string obtained by performing the checksum
algorithm on the data "data". algorithm on the data "data".
For the "MD5" algorithm, H(data) = MD5(data), and KD(secret,data) = For the "SHA1" algorithm, H(data) = SHA1(data), and KD(secret,data) =
H(concat(secret, ":", data) H(concat(secret, ":", data)
The request-digest value in a CAuth header field takes the following The request-digest value in a CAuth header field takes the following
format. Note that unq(quoted-string) denotes the value of the string format. Note that unq(quoted-string) denotes the value of the string
with the quotes removed. with the quotes removed.
request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <"> request-digest = <"> < KD ( H(A1), unq(nonce-value) ":" H(A2) ) > <">
A1 = unq(username-value) ":" shared-secret A1 = unq(username-value) ":" shared-secret
A2 = Method A2 = concat(Method,TR-ID,S-URI)
When the relay receives a CAuth header, it SHOULD check its validity When the relay receives a CAuth header, it SHOULD check its validity
by looking up the shared secret, or H(A1), performing the same digest by looking up the shared secret, or H(A1), performing the same digest
operation as performed by the client, and comparing the results to operation as performed by the client, and comparing the results to
the request-digest value. the request-digest value.
6.10 Method Descriptions 7.7 Method Descriptions
This section summarizes the purpose of each MSRP method. All MSRP This section summarizes the purpose of each MSRP method. All MSRP
messages MUST contain the TR-ID header fields. All messages MUST messages MUST contain the TR-ID header fields. All messages MUST
contain a length field in the start line that indicates the overall contain a length field in the start line that indicates the overall
length of the request, including any body, but not including the length of the request, including any body, but not including the
start line itself. Additional requirements exist depending on the start line itself. Additional requirements exist depending on the
individual method. Except where otherwise noted, all requests are hop individual method. Except where otherwise noted, all requests are hop
by hop. by hop.
6.10.1 BIND 7.7.1 BIND
The BIND method is used by a host endpoint to establish or refresh The BIND method is used by a host endpoint to establish or refresh
session state at a hosting relay. BIND requests SHOULD be session state at a hosting relay. BIND requests SHOULD be
authenticated. BIND requests MUST contain the S-URL and Exp header authenticated. BIND requests MUST contain the S-URL and Exp header
fields and MAY contain the CAuth header fields. fields and MAY contain the CAuth header fields.
A successful response to a BIND request MUST contain the S-URL and A successful response to a BIND request MUST contain the S-URL and
Exp header fields. Exp header fields.
6.10.2 SEND 7.7.2 SEND
The SEND method is used by both the host and visitor endpoints to The SEND method is used by both the host and visitor endpoints to
send instant messages to its peer endpoint. SEND requests SHOULD send instant messages to its peer endpoint. SEND requests SHOULD
contain a MIME body part. The body MUST be of a media type included contain a MIME body part. The body MUST be of a media type included
in the format list negotiated in the SDP exchange. If a body is in the format list negotiated in the SDP exchange. If a body is
present, the request MUST contain a Content-Type header field present, the request MUST contain a Content-Type header field
identifying the media type of the body. identifying the media type of the body.
Unlike other methods, SEND requests are end to end in nature. This Unlike other methods, SEND requests are end to end in nature. This
means the request is consumed only by the opposite endpoint. Under means the request is consumed only by the opposite endpoint. Under
normal conditions, any intervening relays merely forward the request normal conditions, any intervening relays merely forward the request
on towards the peer endpoint. on towards the peer endpoint.
6.10.3 VISIT 7.7.3 VISIT
The visiting endpoint uses the VISIT method to associate a network The visiting endpoint uses the VISIT method to associate a network
connection with the session state at the hosting device, which could connection with the session state at the hosting device, which could
be either the host endpoint or a relay operating on behalf of the be either the host endpoint or a relay operating on behalf of the
host endpoint. VISIT is also used to refresh the expiration time for host endpoint. The request MUST contain a S-URL header matching the
the visiting connection. The request MUST contain a S-URL header session URL.
matching the session URL. A VISIT request MUST contain the Expires
header field.
Successful responses to a VISIT request MUST contain the Expires
header.
There is normally no authentication operation for the VISIT There is normally no authentication operation for the VISIT
request. This is because the session URL acts as a shared secret request. This is because the session URL acts as a shared secret
between host and the visitor. This puts certain requirements on between host and the visitor. This puts certain requirements on
the handling of the session URLs that are discussed in Section 9. the handling of the session URLs that are discussed in Section 10.
However, if a visiting relay is used, it SHOULD authenticate However, if a visiting relay is used, it SHOULD authenticate VISIT
initial VISIT requests, and MAY authenticate subsequent VISIT requests.
refresh requests.
6.11 Response Code Descriptions 7.8 Response Code Descriptions
This section summarizes the various response codes. Except where This section summarizes the various response codes. Except where
noted, all responses MUST contain a TR-ID header field matching the noted, all responses MUST contain a TR-ID header field matching the
TR-ID header field of the associated request. Responses are never TR-ID header field of the associated request. Responses are never
consumed by relays. consumed by relays.
6.11.1 200 7.8.1 200
The 200 response code indicates a successful transaction. The 200 response code indicates a successful transaction.
6.11.2 400 7.8.2 400
A 400 response indicates a request was unintelligible. A 400 response indicates a request was unintelligible.
6.11.3 401 7.8.3 401
A 401 response indicates authentication is required. 401 responses A 401 response indicates authentication is required. 401 responses
MUST NOT be used in response to any method other than BIND and VISIT. MUST NOT be used in response to any method other than BIND and VISIT.
A 401 response MUST contain a SChal header field. A 401 response MUST contain a SChal header field.
6.11.4 403 7.8.4 403
A 403 response indicates the user is not authorized to perform the A 403 response indicates the user is not authorized to perform the
action. action.
6.11.5 415 7.8.5 415
A 415 response indicates the SEND request contained a MIME A 415 response indicates the SEND request contained a MIME
content-type that is not understood by the receiver. content-type that is not understood by the receiver.
6.11.6 481 7.8.6 426
A 426 response indicates that the request is only allowed over TLS
protected connections.
Open Issue: Do we need to make 426 extensible to support other
types of protection?
7.8.7 481
A 481 response indicates that no session exists for the connection. A 481 response indicates that no session exists for the connection.
6.11.7 500 7.8.8 500
A 500 response indicates that a relay was unable to deliver a SEND A 500 response indicates that a relay was unable to deliver a SEND
request to the target. request to the target.
6.11.8 506 7.8.9 506
A 506 response indicates that a VISIT request occurred in which the A 506 response indicates that a VISIT request occurred in which the
S-URL indicates a session that is already associated with another S-URL indicates a session that is already associated with another
connection. A 506 response MUST NOT be returned in response to any connection. A 506 response MUST NOT be returned in response to any
method other than VISIT. method other than VISIT.
6.12 Header Field Descriptions 7.9 Header Field Descriptions
This section summarizes the various header fields. MSRP header fields This section summarizes the various header fields. MSRP header fields
are single valued; that is, they MUST NOT occur more than once in a are single valued; that is, they MUST NOT occur more than once in a
particular request or response. particular request or response.
6.12.1 TR-ID 7.9.1 TR-ID
The TR-ID header field contains a transaction identifier used to map The TR-ID header field contains a transaction identifier used to map
a response to the corresponding request. A TR-ID value MUST be unique a response to the corresponding request. A TR-ID value MUST be unique
among all values used by a given endpoint inside a given session. among all values used by a given endpoint inside a given session.
MSRP elements MUST NOT assume any additional semantics for TR-ID. MSRP elements MUST NOT assume any additional semantics for TR-ID.
6.12.2 Exp 7.9.2 Exp
The Exp header field specifies when the state associated with a BIND The Exp header field specifies when the state associated with a BIND
or VISIT request will expire. The value is specified as an integer request will expire, if no successful VISIT request has been
number of seconds from the time the request is received. BIND and received.. The value is specified as an integer number of seconds
VISIT requests MUST contain this header field. Furthermore, from the time the request is received. BIND requests MUST contain
successful responses to BIND or VISIT requests must also contain the this header field. Furthermore, successful responses to BIND requests
Exp header. MUST also contain the Exp header.
The maximum value for the Exp header field is (2**32)-1 seconds. The maximum value for the Exp header field is (2**32)-1 seconds.
Exp has no meaning if it occurs in MSRP messages other than BIND and Exp has no meaning if it occurs in MSRP messages other than BIND
VISIT requests, and responses to those requests. MSRP compliant requests, and responses to those requests. MSRP compliant devices
devices SHOULD NOT use Exp in other requests or responses, unless SHOULD NOT use Exp in other requests or responses, unless that usage
that usage is defined in an extension to this specification. is defined in an extension to this specification.
6.12.3 CAuth 7.9.3 CAuth
The CAuth header field is used by a host endpoint to respond to offer The CAuth header field is used by a host endpoint to respond to offer
digest authentication credentials to a relay, usually in response to digest authentication credentials to a relay, usually in response to
a digest authentication challenge. CAuth SHOULD NOT be present in a a digest authentication challenge. CAuth SHOULD NOT be present in a
request of any method other than BIND and VISIT. request of any method other than BIND and VISIT.
The CAuth credentials adhere to the following syntax: The CAuth credentials adhere to the following syntax:
credentials = "Digest" digest-response credentials = "Digest" digest-response
digest-response = 1#( username | nonce | digest-response = 1#( username | nonce |
skipping to change at page 32, line 5 skipping to change at page 35, line 17
nonce: The nonce value copied from the challenge. nonce: The nonce value copied from the challenge.
response: A 32 hex digit string that proves user knowledge of the response: A 32 hex digit string that proves user knowledge of the
shared secret. shared secret.
algorithm: The algorithm value copied from the challenge. algorithm: The algorithm value copied from the challenge.
auth-param: Additional parameters for the sake of extensibility. auth-param: Additional parameters for the sake of extensibility.
6.12.4 SChal 7.9.4 SChal
The SChal header field is used by a relay to carry the challenge in a The SChal header field is used by a relay to carry the challenge in a
digest authentication attempt. Exactly one SChal header field MUST digest authentication attempt. Exactly one SChal header field MUST
exist in a 401 response. The SChal header MUST NOT be used in any exist in a 401 response. The SChal header MUST NOT be used in any
message except for a 401 response. The SChal header field value is message except for a 401 response. The SChal header field value is
made up of a challenge according to the following syntax: made up of a challenge according to the following syntax:
challenge= digest-scheme SP digest-challenge challenge= digest-scheme SP digest-challenge
digest-scheme = "Digest" digest-scheme = "Digest"
digest-challenge = 1#( nonce | [ algorithm ] | digest-challenge = 1#( nonce | [ algorithm ] |
[auth-param] ) [auth-param] )
nonce = "nonce" "=" nonce-value nonce = "nonce" "=" nonce-value
nonce-value = quoted-string nonce-value = quoted-string
algorithm = "algorithm" "=" ( "MD5" | token ) algorithm = "algorithm" "=" ( "SHA1" | token )
The meaning of each value is as follows: The meaning of each value is as follows:
digest scheme: A token to identify the particular authentication digest scheme: A token to identify the particular authentication
scheme. For digest, the value MUST be "Digest." This token is scheme. For digest, the value MUST be "Digest." This token is
present for the sake of extensibility. present for the sake of extensibility.
nonce: A server-specified string, which the relay SHOULD uniquely nonce: A server-specified string, which the relay SHOULD uniquely
generate each time it sends a 401 response. This string SHOULD generate each time it sends a 401 response. This string SHOULD
take the form of base64 or hexadecimal data, to avoid the presence take the form of base64 or hexadecimal data, to avoid the presence
of a double-quote character, which is not allowed. of a double-quote character, which is not allowed.
algorithm: A token indicating the algorithms to be used to generate algorithm: A token indicating the algorithms to be used to generate
the digest and checksum. This directive exists for the sake of the digest and checksum. This directive exists for the sake of
extensibility; the only value defined by this document is "MD5". extensibility; the only value defined by this document is "SHA1".
absence of this directive indicates a value of "MD5." Absence of this directive indicates a value of "SHA1".
6.12.5 Content-Type 7.9.5 Content-Type
The Content-Type header field is used to indicate the MIME media type The Content-Type header field is used to indicate the MIME media type
of the body. Content-Type MUST be present if a body is present. of the body. Content-Type MUST be present if a body is present.
6.12.6 S-URL 7.9.6 S-URL
The S-URL header field is used to identify the session. The S-URI The S-URL header field is used to identify the session. The S-URI
header field MUST be present in a BIND request, a successful response header field MUST be present in a BIND request, a successful response
to a BIND request, or a VISIT request. to a BIND request, or a VISIT request.
7. Examples 8. Examples
This section shows some example message flows for various common This section shows some example message flows for various common
scenarios. The examples assume SIP is used to transport the SDP scenarios. The examples assume SIP is used to transport the SDP
exchange. Details of the SIP messages and SIP proxy infrastructure exchange. Details of the SIP messages and SIP proxy infrastructure
are omitted for the sake of brevity. In the examples, assume the are omitted for the sake of brevity. In the examples, assume the
offerer is sip:alice@atlanta.com and the answerer is offerer is sip:alice@atlanta.com and the answerer is
sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length sip:bob@biloxi.com. In any given MSRP message, an "xx" in the length
field indicates the actual length of the rest of the message. field indicates the actual length of the rest of the message.
7.1 No Relay 8.1 No Relay
In this scenario, the session goes directly between endpoints with no
MSRP relays involved.
Alice Bob
| |
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (MSRP) VISIT |
|<-----------------------|
|(3) (MSRP) 200 OK |
|----------------------->|
|(4) (SIP) 200 OK |
|<-----------------------|
|(5) (SIP) ACK |
|----------------------->|
|(6) (MSRP) SEND |
|----------------------->|
|(7) (MSRP) 200 OK |
|<-----------------------|
|(8) (MSRP) SEND |
|<-----------------------|
|(9) (MSRP) 200 OK |
|----------------------->|
|(10) (SIP) BYE |
|----------------------->|
|(11) (SIP) 200 OK |
|<-----------------------|
| |
| |
1. Alice constructs a session URL of msrp://alicepc.atlanta.com/ 1. Alice constructs a session URL of msrp://alicepc.atlanta.com/
iau39 and listens for a connection on TCP port 7777. iau39 and listens for a connection on TCP port 7777.
2. Alice->Bob (SIP): INVITE sip:bob@biloxi.com Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 fillername c=IN IP4 fillername
m=message 7777 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=direction:both a=session:msrp://alicepc.atlanta.com/iau39:7777 a=direction:both
a=session:msrp://alicepc.atlanta.com/iau39:7777
3. Bob->Alice: Open TCP connection to alicepc.atlanta.com:7777. 2. Bob opens a TCP connection to alicepc.atlanta.com:7777:
4. Bob->Alice (MSRP): Bob->Alice (MSRP):
MSRP xx VISIT MSRP xx VISIT
S-URL: msrp://alicepc.atlanta.com/iau39:7777 S-URL: msrp://alicepc.atlanta.com/iau39:7777
Tr-ID: sie09s Tr-ID: sie09s
Exp:600 3. Alice->Bob (MSRP):
5. Alice->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
Tr-ID: sie09s Tr-ID: sie09s
Exp:300 Exp:300
6. Bob->Alice (SIP): 200 OK 4. Bob->Alice (SIP): 200 OK
c=IN IP4 ignorefield c=IN IP4 ignorefield
m=message 7777 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=direction:active a=direction:active
7. Alice->Bob (SIP): ACK 5. Alice->Bob (SIP): ACK
8. Alice->Bob (MSRP): 6. Alice->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
9. Bob->Alice (MSRP): 7. Bob->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
10. Bob->Alice (MSRP): 8. Bob->Alice (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 456 TR-ID: 456
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
11. Alice->Bob (MSRP): 9. Alice->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 456 TR-ID: 456
12. Alice->Bob (SIP): BYE 10. Alice->Bob (SIP): BYE
13. Alice invalidates session and drops connection. Alice invalidates session and drops connection.
14. Bob invalidates local state for the session. 11. Bob invalidates local state for the session.
15. Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
7.2 Single Relay 8.2 Single Relay
This scenario introduces an MSRP relay at relay.atlanta.com. This scenario introduces an MSRP relay at relay.atlanta.com.
Alice Relay Bob
| | |
| | |
|(1) (MSRP) BIND | |
|----------------------->| |
|(2) (MSRP) 200 OK | |
|<-----------------------| |
|(3) (SIP) INVITE | |
|------------------------------------------------>|
| |(4) (MSRP) VISIT |
| |<-----------------------|
| |(5) (MSRP) 200 OK |
| |----------------------->|
|(6) (SIP) 200 OK | |
|<------------------------------------------------|
|(7) (SIP) ACK | |
|------------------------------------------------>|
|(8) (MSRP) SEND | |
|----------------------->| |
| |(9) (MSRP) SEND |
| |----------------------->|
| |(10) (MSRP) 200 OK |
| |<-----------------------|
|(11) (MSRP) 200 OK | |
|<-----------------------| |
| |(12) (MSRP) SEND |
| |<-----------------------|
|(13) (MSRP) SEND | |
|<-----------------------| |
|(14) (MSRP) 200 OK | |
|----------------------->| |
| |(15) (MSRP) 200 OK |
| |----------------------->|
|(16) (SIP) BYE | |
|------------------------------------------------>|
|(17) (MSRP) BIND | |
|----------------------->| |
|(18) (MSRP) 200 OK | |
|<-----------------------| |
|(19) (SIP) 200 OK | |
|<------------------------------------------------|
| | |
| | |
1. Alice->Relay (MSRP): Alice opens a connection to the relay, and 1. Alice->Relay (MSRP): Alice opens a connection to the relay, and
sends the following: sends the following:
MSRP xx BIND MSRP xx BIND
S-URL: msrp://relay.atlanta.com S-URL: msrp://relay.atlanta.com
TR-ID: 321 TR-ID: 321
Exp:600 Exp:600
2. Relay->Alice (MSRP): 2. Relay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 321 TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:300 Exp:300
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 dummyvalue c=IN IP4 dummyvalue
skipping to change at page 35, line 14 skipping to change at page 40, line 26
2. Relay->Alice (MSRP): 2. Relay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 321 TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:300 Exp:300
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 dummyvalue c=IN IP4 dummyvalue
m=message 7777 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=direction:passive a=direction:passive
a=session:msrp://relay.atlanta.com:7777/iau39 a=session:msrp://relay.atlanta.com:7777/iau39
4. Bob->Alice: Open connection to relay.atlanta.com:7777. 4. Bob->Alice: Open connection to relay.atlanta.com:7777.
5. Bob->Relay (MSRP): Bob->Relay (MSRP):
MSRP xx VISIT MSRP xx VISIT
S-URL:msrp://relay.atlanta.com:7777/iau39 S-URL:msrp://relay.atlanta.com:7777/iau39
TR-ID: msrp:sie09s TR-ID: msrp:sie09s
Exp:500
6. Relay->Bob (MSRP): 5. Relay->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: sie09s TR-ID: sie09s
Exp:300 Exp:300
7. Bob->Alice (SIP): 200 OK 6. Bob->Alice (SIP): 200 OK
c=IN IP4 nobodybutuschickens
c=IN IP4 nobodybutchickens m=message 9999 msrp/tcp text/plain
m=message 7777 msrp/tcp text/plain
a=direction:active a=direction:active
8. Alice->Bob (SIP): ACK 7. Alice->Bob (SIP): ACK
9. Alice->Relay (MSRP): 8. Alice->Relay (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
10. Relay->Bob (MSRP):
9. Relay->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
11. Bob->Relay (MSRP): 10. Bob->Relay (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
12. Relay->Alice (MSRP): 11. Relay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
13. Bob->Relay (MSRP): 12. Bob->Relay (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 456 TR-ID: 456
Content-Type:"text/plain" Content-Type:"text/plain"
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
14. Relay->Alice (MSRP): 13. Relay->Alice (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 456 TR-ID: 456
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, Alice! I'm Bob! Hi, Alice! I'm Bob!
15. Alice->relay (MSRP): 14. Alice->relay (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 456 TR-ID: 456
16. Relay->Bob (MSRP): 15. Relay->Bob (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 456 TR-ID: 456
17. Alice->Bob (SIP): BYE
18. Alice->Relay (MSRP): 16. Alice->Bob (SIP): BYE
17. Alice->Relay (MSRP):
MSRP xx BIND MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42 TR-ID: 42
Exp:0 Exp:0
19. Relay->Alice (MSRP): (relay invalidates session state) 18. Relay->Alice (MSRP): Relay invalidates session state.
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 42 TR-ID: 42
Exp:0 Exp:0
20. Bob invalidates local state for the session. 19. Bob invalidates local state for the session.
21. Bob->Alice (SIP): 200 OK Bob->Alice (SIP): 200 OK
7.3 Two Relays 8.3 Two Relays
In this scenario, both Alice and Bob are each required by local In this scenario, both Alice and Bob are each required by local
policy to route all sessions through a different local relay. policy to route all sessions through a different local relay.
1. Alice->AtlantaRelay (MSRP): Alice opens a connection to the Alice AtlantaRelay BiloxiRelay Bob
| | | |
| | | |
|(1) (MSRP) BIND | |
|------------->| | |
|(2) (MSRP) 200 OK | |
|<-------------| | |
|(3) (SIP) INVITE | |
|------------------------------------------->|
| | |(4) (MSRP) VISIT
| | |<-------------|
| |(5) (MSRP) VISIT |
| |<-------------| |
| |(6) (MSRP) 200 OK |
| |------------->| |
| | |(7) (MSRP) 200 OK
| | |------------->|
|(8) (SIP) 200 OK | |
|<-------------------------------------------|
|(9) (SIP) ACK | | |
|------------------------------------------->|
|(10) (MSRP) SEND | |
|------------->| | |
| |(11) (MSRP) SEND |
| |------------->| |
| | |(12) (MSRP) SEND
| | |------------->|
| | |(13) (MSRP) 200 OK
| | |<-------------|
| |(14) (MSRP) 200 OK |
| |<-------------| |
|(15) (MSRP) SEND | |
|<-------------| | |
|(16) (SIP) BYE| | |
|------------------------------------------->|
|(17) (MSRP) BIND | |
|------------->| | |
|(18) (MSRP) 200 OK | |
|<-------------| | |
|(19) (SIP) 200 OK | |
|<-------------------------------------------|
| | | |
| | | |
1. Alice->AtlantaRelay (MSRP): Alice opens a connection to her
relay, and sends the following: relay, and sends the following:
MSRP xx BIND MSRP xx BIND
S-URL: msrp://relay.atlanta.com S-URL: msrp://relay.atlanta.com
TR-ID: 321 TR-ID: 321
Exp:600 Exp:600
2. AtlantaRelay->Alice (MSRP): 2. AtlantaRelay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 321 TR-ID: 321
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
Exp:600 Exp:600
3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com 3. Alice->Bob (SIP): INVITE sip:bob@biloxi.com
c=IN IP4 blahblahblah c=IN IP4 blahblahblah
m=message 7777 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=session:msrp://relay.atlanta.com:7777/iau39 a=session:msrp://relay.atlanta.com:7777/iau39
a=direction:passive a=direction:passive
4. Bob determines that, due to local policy, he must connect 4. Bob determines that, due to local policy, he must connect
through his own proxy. through his own relay.
5. Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay, Bob->BiloxiRelay (MSRP): Bob opens a connection to his relay,
and sends the following: and sends the following:
MSRP xx VISIT MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934 TR-ID: 934
Exp:600
6. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL, 5. BiloxiRelay->AtlantaRelay (MSRP): BiloxiRelay resolves the URL,
opens a connection to relay.atlanta.com:7777, and sends the opens a connection to relay.atlanta.com:7777, and sends the
following: following:
MSRP xx VISIT MSRP xx VISIT
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 934 TR-ID: 934
Exp:600
7. AtlantaRelay->BiloxiRelay(MSRP): 6. AtlantaRelay->BiloxiRelay(MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 934 TR-ID: 934
Exp:600
8. BiloxiRelay->Bob(MSRP): 7. BiloxiRelay->Bob(MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 934 TR-ID: 934
Exp:600
9. Bob->Alice (SIP): 200 OK 8. Bob->Alice (SIP): 200 OK
c=IN IP4 stuff c=IN IP4 stuff
m=message 7777 msrp/tcp text/plain m=message 9999 msrp/tcp text/plain
a=direction: active a=direction: active
10. Alice->Bob (SIP): ACK 9. Alice->Bob (SIP): ACK
11. Alice->AtlantaRelay (MSRP):
10. Alice->AtlantaRelay (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
12. AtlantaRelay ->BiloxiRelay (MSRP): 11. AtlantaRelay ->BiloxiRelay (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
13. BiloxiRelay->Bob (MSRP): 12. BiloxiRelay->Bob (MSRP):
MSRP xx SEND MSRP xx SEND
TR-ID: 123 TR-ID: 123
Content-Type: "text/plain" Content-Type: "text/plain"
Hi, I'm Alice! Hi, I'm Alice!
14. Bob->BiloxiRelay (MSRP): 13. Bob->BiloxiRelay (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
15. BiloxiRelay->AtlantaRelay (MSRP): 14. BiloxiRelay->AtlantaRelay (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
15. AtlantaRelay->Alice (MSRP):
16. AtlantaRelay->Alice (MSRP):
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 123 TR-ID: 123
17. Alice->Bob (SIP): BYE 16. Alice->Bob (SIP): BYE
18. Alice->AtlantaRelay (MSRP): 17. Alice->AtlantaRelay (MSRP):
MSRP xx BIND MSRP xx BIND
S-URL: msrp://relay.atlanta.com:7777/iau39 S-URL: msrp://relay.atlanta.com:7777/iau39
TR-ID: 42 TR-ID: 42
Exp:0 Exp:0
19. Relay->Alice (MSRP): (relay invalidates session state) 18. Relay->Alice (MSRP): Relay invalidates session state.
MSRP xx 200 OK MSRP xx 200 OK
TR-ID: 42 TR-ID: 42
Exp:0 Exp:0
20. Bob->Alice (SIP): 200 OK 19. Bob->Alice (SIP): 200 OK
8. IANA Considerations 9. IANA Considerations
To Do. 9.1 MSRP Port
Do we need to register URL schemes or SDP a-line attributes? MSRP uses TCP port XYX, to be determined by IANA after this document
is approved for publication. Usage of this value is described in
Section 7.1
9. Security Considerations 9.2 MSRP URL Schemes
This document defines the URL schemes of "msrp" and "msrps".
9.2.1 Syntax
See Section 7.1.
9.2.2 Character Encoding
See Section 7.1.
9.2.3 Intended Usage
See Section 7.1.
9.2.4 Protocols
The Message Session Relay Protocol (MSRP).
9.2.5 Security Considerations
See Section 10.
9.2.6 Relevant Publications
RFCXXXX
[Note to RFC Editor: Please replace RFCXXXX in the above paragraph
with the actual number assigned to this document.
9.3 SDP Parameters
This document registers the following SDP parameters in the
sdp-parameters registry:
9.3.1 Direction
Attribute-name: direction
Long-form Attribute Name Direction
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.2.
9.3.2 Wrapped Types
Attribute-name: accept-wrapped-types
Long-form Attribute Name Acceptable MIME Types Inside Wrappers
Type: Media level
Subject to Charset Attribute No
Purpose and Appropriate Values See Section 6.3.
10. Security Considerations
There are a number of security considerations for MSRP, some of which There are a number of security considerations for MSRP, some of which
are mentioned elsewhere in this document. This section discusses are mentioned elsewhere in this document. This section discusses
those further, and introduces some new ones. those further, and introduces some new ones.
9.1 The MSRPS Scheme 10.1 TLS and the MSRPS Scheme
The MSRPS scheme indicates that all hops in an MSRP session MUST be All MSRP devices must support TLS, with at least the
protected with TLS. Ensuring this implies some additional rules. An TLS_RSA_WITH_AES_128_CBC_SHA [8] cipher suite. Other cipher suites
MSRP relay MUST NOT return an MSRPS URL in the S-URL header field in MAY be supported.
a response to a BIND request unless the BIND request itself was
received over a TLS protected session. A VISIT request for an MSRPS
URL MUST be sent over a TLS protected connection. If a visiting relay
receives a VISIT request for an MSRPS URL, the connection to the
hosting device MUST also be protected.
There has been controversy on whether an MSRPS scheme is really MSRP does not define a separate TCP port for TLS connections. This
needed, since there is a small limit to the total number of hops means that all MSRP server devices, that is, all devices that listen
in an MSRP session. However, a mechanism is required to inform the for TCP connections, MUST be prepared to handle both TLS and plain
visitor to use TLS in the first place. We could have used an SDP text connections on the same port. When a device accepts a TCP
a-line attribute for this. However, there also needs to be a connection, it MUST watch for the TLS handshake messages to determine
mechanism for a hosting relay to tell the host endpoint to request if a particular connection uses TLS. If the first data received is
the visitor use TLS. The MSRPS scheme seems to best fit all of not part of a TLS handshake request, the device ceases to watch for
these requirements. the TLS handshake and begins normal MSRP processing.
Open Issue: There is also some controversy over how TLS should be An MSRP device MAY refuse to accept a given request over a non-TLS
used with MSRP. The changes in this draft version make it possible connection by returning a 426 response, after which it MUST either
for relays to act as tunnels, where the TLS handshake is immediately close the connection, or begin watching for a TLS
end-to-end. This is much the same way that TLS is handled by HTTPS handshake request as it would if it had just accepted a connection.
proxies. However, this usage requires at least one endpoint to
have a TLS server certificate, which may not be likely. Another
approach is to make TLS usage hop-by-hop. When at least one relay
is used, only the relays would need server certificates. Even if
we support end-to-end TLS, we may still need a way to specify
hop-by-hop TLS, because since end-to-end TLS would delay the TLS
handshake until _after_ the BIND and VISIT requests, these
requests would not be protected.
9.2 Sensitivity of the Session URL MSRP devices acting in the role of TCP client MAY perform a TLS
handshake either immediately upon connection, or immediately after
receiving a 426 response. They MUST NOT attempt to upgrade to TLS at
any other time.
Allowing clients to upgrade at any time would require the server
device to check every single request to determine if it is an MSRP
request or a TLS handshake request. The specified approach only
requires this check on the initial data received on a connection,
or on data received immediately after a 426 response. In both
cases, the receiver will have to peek ahead in the received data
stream to look for the TLS, then read again from the start once
the presence or absence of TLS has been determined.
The MSRPS URI scheme indicates that all hops in an MSRP session MUST
be protected with TLS. Ensuring this implies some additional rules. A
relay MUST return an MSRPS URL to a BIND request if the request
arrived over TLS and included a MSRPS URI in the S-URI header field.
The relay MAY return an MSRPS URI to any BIND request that arrives
over TLS, but MUST NOT return an MSRP URI to a BIND request that does
not arrive over TLS. If a relay receives a BIND request with an MSRPS
S-URI, over a non-TLS connection, it MUST reject the request with a
426 response. A relay may insist on always using MSRPS by returning a
426 to any bind received over an unprotected connection, and always
returning MSRPS URLs to BIND requests over protected connections.
A VISIT request for an MSRPS URL MUST be sent over a TLS protected
connection. If a visiting relay receives a VISIT request for an MSRPS
URL over an unprotected connection, it MUST reject the request with a
426 response.
10.2 Sensitivity of the Session URL
The URL of a MSRP session is used by the visiting endpoint to The URL of a MSRP session is used by the visiting endpoint to
identify itself to the hosting device, regardless of whether the identify itself to the hosting device, regardless of whether the
session is directly hosted by the host endpoint, or is hosted by a session is directly hosted by the host endpoint, or is hosted by a
relay. If an attacker were able to acquire session URL, either by relay. If an attacker were able to acquire session URL, either by
guessing it or by eavesdropping, there is a window of opportunity in guessing it or by eavesdropping, there is a window of opportunity in
which the attacker could hijack the session by sending a VISIT which the attacker could hijack the session by sending a VISIT
request to the host device before the true visiting endpoint. Because request to the host device before the true visiting endpoint. Because
of this sensitivity, the session URL SHOULD be constructed in a way of this sensitivity, the session URL SHOULD be constructed in a way
to make it difficult to guess, and should be sufficiently random so to make it difficult to guess, and should be sufficiently random so
skipping to change at page 41, line 39 skipping to change at page 49, line 40
Therefore an MSRP device MUST support the use of TLS for at least the Therefore an MSRP device MUST support the use of TLS for at least the
VISIT request, which by extension indicates the endpoint MUST support VISIT request, which by extension indicates the endpoint MUST support
the use of TLS for all MSRP messages. Further, MSRP connections the use of TLS for all MSRP messages. Further, MSRP connections
SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST SHOULD actually be protected with TLS. Further, an MSRP endpoint MUST
be capable of using the security features of the signaling protocol be capable of using the security features of the signaling protocol
in order to protect the SDP exchange and SHOULD actually use them on in order to protect the SDP exchange and SHOULD actually use them on
all such exchanges. End-to-end protection schemes SHOULD be preferred all such exchanges. End-to-end protection schemes SHOULD be preferred
over hop-by-hop schemes for protection of the SDP exchange. over hop-by-hop schemes for protection of the SDP exchange.
9.3 End to End Protection of IMs 10.3 End to End Protection of IMs
Instant messages can contain very sensitive information. As a result, Instant messages can contain very sensitive information. As a result,
as specified in RFC 2779 [3], instant messaging protocols need to as specified in RFC 2779 [3], instant messaging protocols need to
provide for encryption, integrity and authentication of instant provide for encryption, integrity and authentication of instant
messages. Therefore MSRP endpoints MUST support the end-to-end messages. Therefore MSRP endpoints MUST support the end-to-end
encryption and integrity of bodies sent via SEND requests using CMS encryption and integrity of bodies sent via SEND requests using
[7]. Secure MIME (S/MIME) [7].
Note that while each protected body could use separate keying Note that while each protected body could use separate keying
material, this is inefficient in that it requires an independent material, this is inefficient in that it requires an independent
public key operation for each message. Endpoints wishing to invoke public key operation for each message. Endpoints wishing to invoke
end-to-end protection of message sessions SHOULD exchange symmetric end-to-end protection of message sessions SHOULD exchange symmetric
keys in SDP k-lines, and use secret key encryption on for each MSRP keys in SDP k-lines, and use secret key encryption on for each MSRP
message. When symmetric keys are present in the SDP, the offer-answer message. When symmetric keys are present in the SDP, the offer-answer
exchange MUST be protected from eavesdropping and tampering using the exchange MUST be protected from eavesdropping and tampering using the
appropriate facilities of the signaling protocol. For example, if the appropriate facilities of the signaling protocol. For example, if the
signaling protocol is SIP, the SDP exchange MUST be protected using signaling protocol is SIP, the SDP exchange MUST be protected using
S/MIME. S/MIME.
Open Issue: This subsection needs very close scrutiny for accuracy 10.4 CPIM compatibility
and security. In particular, do we need to say more about using
secret key operations in CMS?
9.4 CPIM compatibility
MSRP sessions may be gatewayed to other CPIM [16]compatible MSRP sessions may be gatewayed to other CPIM [17]compatible
protocols. If this occurs, the gateway MUST maintain session state, protocols. If this occurs, the gateway MUST maintain session state,
and MUST translate between the MSRP session semantics and CPIM and MUST translate between the MSRP session semantics and CPIM
semantics that do not include a concept of sessions. Furthermore, semantics that do not include a concept of sessions. Furthermore,
when one endpoint of the session is a CPIM gateway, instant messages when one endpoint of the session is a CPIM gateway, instant messages
SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST SHOULD be wrapped in "message/cpim" [5] bodies. Such a gateway MUST
include "message/cpim" as the first entry in its SDP format list. include "message/cpim" as the first entry in its SDP format list.
MSRP endpoints sending instant messages to a peer that has included MSRP endpoints sending instant messages to a peer that has included
'message/cpim" as the first entry in the format list SHOULD 'message/cpim" as the first entry in the format list SHOULD
encapsulate all instant message bodies in "message/cpim" wrappers. encapsulate all instant message bodies in "message/cpim" wrappers.
All MSRP endpoints SHOULD support the S/MIME features of that format. All MSRP endpoints SHOULD support the S/MIME features of that format.
10. Changes introduced in draft-ietf-simple-message-sessions-00 10.5 PKI Considerations
Several aspects of MSRP will benefit from being used in the context
of a public key infrastructure. For example, the MSRPS scheme allows,
and even encourages, TLS connections between endpoint devices. And
while MSRP allows for a symmetric session key to protect all messages
in a session, it is most likely that session key itself would be
exchanged in a signaling protocol such as SIP. Since that key is
extremely sensitive, its exchange would also need to be protected. In
SIP, the preferred mechanism for this would be S/MIME, which would
also benefit from a PKI.
However, all of these features may be used without PKI. Each endpoint
could instead use self signed certificates. This will, of course, be
less convenient than with a PKI, in that there would be no
certificate authority to act as a trusted introducer. Peers would be
required to exchange certificates prior to securely communicating.
Since, at least for the immediate future, any given MSRP
implementation is likely to communicate with at least some peers that
do not have a PKI available, MSRP implementations SHOULD support the
use of self-signed certificates, and SHOULD support the ability to
configure lists of trusted certificates.
11. Changes from Previous Draft Versions
This section to be deleted prior to publication as an RFC
11.1 draft-ietf-simple-message-sessions-01
Abstract rewritten.
Added architectural considerations section.
The m-line format list now only describes the root body part for a
request. Contained body part types may be described in the
"accept-wrapped-types" a-line attribute.
Added a standard dummy value for the m-line port field. Clarified
that a zero in this field has normal SDP meaning.
Clarified that an endpoint is globally configured as to whether or
not to use a relay. There is no relay discovery mechanism
intrinsic to MSRP.
Changed digest algorithm to SHA1. Added TR-ID and S-URI to the
hash for digest authentication.
CMS usage replaced with S/MIME.
TLS and MSRPS usage clarified.
Session state timeout is now based on SEND activity, rather than
BIND and VISIT refreshes.
Default port added.
Added sequence diagrams to the example message flows.
Added discussion of self-signed certificates in the security
considerations section.
11.2 draft-ietf-simple-message-sessions-00
Name changed to reflect status as a work group item. Name changed to reflect status as a work group item.
This version no longer supports the use of multiple sessions This version no longer supports the use of multiple sessions
across a single TCP session. This has several related changes: across a single TCP session. This has several related changes:
There is now a single session URI, rather than a separate one for There is now a single session URI, rather than a separate one for
each endpoint. The session URI is not required to be in requests each endpoint. The session URI is not required to be in requests
other than BIND and VISIT, as the session can be determined based other than BIND and VISIT, as the session can be determined based
on the connection on which it arrives. on the connection on which it arrives.
skipping to change at page 43, line 19 skipping to change at page 52, line 29
Clarified signaling associated with session failure due to dropped Clarified signaling associated with session failure due to dropped
connections. connections.
Clarified security related motivations for MSRP. Clarified security related motivations for MSRP.
Removed MIKEY dependency for session key exchange. Simple usage of Removed MIKEY dependency for session key exchange. Simple usage of
k-lines in SDP, where the SDP exchange is protected end-to-end k-lines in SDP, where the SDP exchange is protected end-to-end
seems sufficient. seems sufficient.
11. Changes introduced in draft-campbell-simple-im-sessions-01 11.3 draft-campbell-simple-im-sessions-01
Version 01 is a significant re-write. References to COMEDIA were Version 01 is a significant re-write. References to COMEDIA were
removed, as it was determined that COMEDIA would not allow removed, as it was determined that COMEDIA would not allow
connections to be used bidirectionally in the presence of NATs. connections to be used bidirectionally in the presence of NATs.
Significantly more discussion of a concrete mechanism has been added Significantly more discussion of a concrete mechanism has been added
to make up for no longer using COMEDIA. Additionally, this draft and to make up for no longer using COMEDIA. Additionally, this draft and
draft-campbell-cpimmsg-sessions (which would have also changed draft-campbell-cpimmsg-sessions (which would have also changed
drastically) have now been combined into this single draft. drastically) have now been combined into this single draft.
12. Contributors 12. Contributors
skipping to change at page 44, line 17 skipping to change at page 53, line 28
Identifiers (URL): Generic Syntax", RFC 2396, August 1998. Identifiers (URL): Generic Syntax", RFC 2396, August 1998.
[5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging [5] Atkins, D. and G. Klyne, "Common Presence and Instant Messaging
Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in Message Format", draft-ietf-impp-cpim-msgfmt-08 (work in
progress), January 2003. progress), January 2003.
[6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for [6] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[7] Housley, R., "Cryptographic Message Syntax (CMS)", RFC 3369, [7] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC
August 2002. 2633, June 1999.
[8] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April [8] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for
1992. Transport Layer Security (TLS)", RFC 3268, June 2002.
[9] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
Informational References Informational References
[9] Campbell, B. and J. Rosenberg, "Session Initiation Protocol [10] Campbell, B. and J. Rosenberg, "Session Initiation Protocol
Extension for Instant Messaging", RFC 3428, September 2002. Extension for Instant Messaging", RFC 3428, September 2002.
[10] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, [11] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC "RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996. 1889, January 1996.
[11] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D. [12] Mahy, R., Campbell, B., Sparks, R., Rosenberg, J., Petrie, D.
and A. Johnston, "A Multi-party Application Framework for SIP", and A. Johnston, "A Multi-party Application Framework for SIP",
draft-ietf-sipping-cc-framework-02 (work in progress), May draft-ietf-sipping-cc-framework-02 (work in progress), May
2003. 2003.
[12] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo, [13] Rosenberg, J., Peterson, J., Schulzrinne, H. and G. Camarillo,
"Best Current Practices for Third Party Call Control in the "Best Current Practices for Third Party Call Control in the
Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work Session Initiation Protocol", draft-ietf-sipping-3pcc-03 (work
in progress), March 2003. in progress), March 2003.
[13] Sparks, R. and A. Johnston, "Session Initiation Protocol Call [14] Sparks, R. and A. Johnston, "Session Initiation Protocol Call
Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in Control - Transfer", draft-ietf-sipping-cc-transfer-01 (work in
progress), February 2003. progress), February 2003.
[14] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of [15] Camarillo, G., Marshall, W. and J. Rosenberg, "Integration of
Resource Management and Session Initiation Protocol (SIP)", RFC Resource Management and Session Initiation Protocol (SIP)", RFC
3312, October 2002. 3312, October 2002.
[15] Peterson, J., "A Privacy Mechanism for the Session Initiation [16] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323 , November 2002. Protocol (SIP)", RFC 3323 , November 2002.
[16] Peterson, J., "A Common Profile for Instant Messaging (CPIM)", [17] Peterson, J., "A Common Profile for Instant Messaging (CPIM)",
draft-ietf-impp-im-03 (work in progress), May 2003. draft-ietf-impp-im-03 (work in progress), May 2003.
[17] Yon, D., "Connection-Oriented Media Transport in SDP", [18] Yon, D., "Connection-Oriented Media Transport in SDP",
draft-ietf-mmusic-sdp-comedia-05 (work in progress), March draft-ietf-mmusic-sdp-comedia-05 (work in progress), March
2003. 2003.
[18] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [19] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999. Basic and Digest Access Authentication", RFC 2617, June 1999.
Authors' Addresses Authors' Addresses
Ben Campbell Ben Campbell
dynamicsoft dynamicsoft
5100 Tennyson Parkway 5100 Tennyson Parkway
Suite 1200 Suite 1200
Plano, TX 75024 Plano, TX 75024
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/