draft-ietf-mmusic-file-transfer-mech-07.txt   draft-ietf-mmusic-file-transfer-mech-08.txt 
MMUSIC Working Group M. Garcia-Martin MMUSIC Working Group M. Garcia-Martin
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Standards Track M. Isomaki Intended status: Standards Track M. Isomaki
Expires: September 28, 2008 Nokia Expires: November 21, 2008 Nokia
G. Camarillo G. Camarillo
S. Loreto S. Loreto
Ericsson Ericsson
P. Kyzivat P. Kyzivat
Cisco Systems Cisco Systems
March 27, 2008 May 20, 2008
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable
File Transfer File Transfer
draft-ietf-mmusic-file-transfer-mech-07.txt draft-ietf-mmusic-file-transfer-mech-08.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 September 28, 2008. This Internet-Draft will expire on November 21, 2008.
Abstract Abstract
This document provides a mechanism to negotiate the transfer of one This document provides a mechanism to negotiate the transfer of one
or more files between two endpoints by using the Session Description or more files between two endpoints by using the Session Description
Protocol (SDP) offer/answer model specified in RFC 3264. SDP is Protocol (SDP) offer/answer model specified in RFC 3264. SDP is
extended to describe the attributes of the files to be transferred. extended to describe the attributes of the files to be transferred.
The offerer can either describe the files it wants to send, or the The offerer can either describe the files it wants to send, or the
files it would like to receive. The answerer can either accept or files it would like to receive. The answerer can either accept or
reject the offer separately for each individual file. The transfer reject the offer separately for each individual file. The transfer
skipping to change at page 3, line 19 skipping to change at page 3, line 19
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5 4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7 5. File selector . . . . . . . . . . . . . . . . . . . . . . . . 7
6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 6. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8
7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13 7. File Disposition Types . . . . . . . . . . . . . . . . . . . . 13
8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14 8. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14 8.1. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 14
8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15 8.1.1. The Offerer is a File Sender . . . . . . . . . . . . . 15
8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 15 8.1.2. The Offerer is a File Receiver . . . . . . . . . . . . 15
8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16 8.1.3. SDP Offer for Several Files . . . . . . . . . . . . . 16
8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 16 8.2. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 17
8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17 8.2.1. The Answerer is a File Receiver . . . . . . . . . . . 17
8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18 8.2.2. The Answerer is a File Sender . . . . . . . . . . . . 18
8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19 8.3. The 'file-transfer-id' attribute . . . . . . . . . . . . . 19
8.4. Aborting an ongoing file transfer operation . . . . . . . 21 8.4. Aborting an ongoing file transfer operation . . . . . . . 21
8.5. Indicating File Transfer Offer/Answer Capability . . . . . 22 8.5. Indicating File Transfer Offer/Answer Capability . . . . . 24
8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 22 8.6. Re-usage of Existing "m=" Lines in SDP . . . . . . . . . . 25
8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 23 8.7. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 25
8.8. Considerations about the 'file-icon' attribute . . . . . . 24 8.8. Considerations about the 'file-icon' attribute . . . . . . 27
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 25 9.1. Offerer sends a file to the Answerer . . . . . . . . . . . 27
9.2. Offerer requests a file from the Answerer and second 9.2. Offerer requests a file from the Answerer and second
file transfer . . . . . . . . . . . . . . . . . . . . . . 30 file transfer . . . . . . . . . . . . . . . . . . . . . . 32
9.3. Example of a capability indication . . . . . . . . . . . . 37 9.3. Example of a capability indication . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 38 10. Security Considerations . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. Registration of new SDP attributes . . . . . . . . . . . . 39 11.1. Registration of new SDP attributes . . . . . . . . . . . . 41
11.1.1. Registration of the file-selector attribute . . . . . 39 11.1.1. Registration of the file-selector attribute . . . . . 41
11.1.2. Registration of the file-transfer-id attribute . . . . 40 11.1.2. Registration of the file-transfer-id attribute . . . . 42
11.1.3. Registration of the file-disposition attribute . . . . 40 11.1.3. Registration of the file-disposition attribute . . . . 42
11.1.4. Registration of the file-date attribute . . . . . . . 40 11.1.4. Registration of the file-date attribute . . . . . . . 42
11.1.5. Registration of the file-icon attribute . . . . . . . 41 11.1.5. Registration of the file-icon attribute . . . . . . . 43
11.1.6. Registration of the file-range attribute . . . . . . . 41 11.1.6. Registration of the file-range attribute . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 41 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . . 41 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43
13.2. Informational References . . . . . . . . . . . . . . . . . 42 13.2. Informational References . . . . . . . . . . . . . . . . . 44
Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 43 Appendix A. Alternatives Considered . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 46 Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
The Session Description Protocol (SDP) Offer/Answer [RFC3264] The Session Description Protocol (SDP) Offer/Answer [RFC3264]
provides a mechanism for two endpoints to arrive at a common view of provides a mechanism for two endpoints to arrive at a common view of
a multimedia session between them. These sessions often contain a multimedia session between them. These sessions often contain
real-time media streams such as voice and video, but are not limited real-time media streams such as voice and video, but are not limited
to that. Basically, any media component type can be supported, as to that. Basically, any media component type can be supported, as
long as there is a specification how to negotiate it within the SDP long as there is a specification how to negotiate it within the SDP
offer/answer exchange. offer/answer exchange.
skipping to change at page 6, line 6 skipping to change at page 6, line 6
of the file receiver. of the file receiver.
Pull operation: A file transfer operation where the SDP offerer Pull operation: A file transfer operation where the SDP offerer
takes the role of the file receiver and the SDP answerer takes the takes the role of the file receiver and the SDP answerer takes the
role of the file sender. role of the file sender.
4. Overview of Operation 4. Overview of Operation
An SDP offerer creates an SDP body that contains the description of An SDP offerer creates an SDP body that contains the description of
one or more files that the offerer wants to send or receive. The one or more files that the offerer wants to send or receive. The
offerer sends the SDP offer to the remote endpoint. The SDP answerer offerer sends the SDP offer to the remote endpoint. The SDP answerer
can accept or reject the transfer of each of those files. can accept or reject the transfer of each of those files separately.
The actual file transfer is carried out using the Message Session The actual file transfer is carried out using the Message Session
Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes an Relay Protocol (MSRP) [RFC4975]. Each SDP "m=" line describes an
MSRP media stream used to transfer a single file at a time. That is, MSRP media stream used to transfer a single file at a time. That is,
the transfer of multiple simultaneous files requires multiple "m=" the transfer of multiple simultaneous files requires multiple "m="
lines and corresponding MSRP media streams. It should be noted that lines and corresponding MSRP media streams. It should be noted that
multiple MSRP media streams can share a single transport layer multiple MSRP media streams can share a single transport layer
connection, so this mechanism will not lead to excessive use of connection, so this mechanism will not lead to excessive use of
transport resources. transport resources.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
the SDP answerer and the file receiver. The regular MSRP endpoint the SDP answerer and the file receiver. The regular MSRP endpoint
answers the offer as it would answer any ordinary MSRP offer answers the offer as it would answer any ordinary MSRP offer
without paying attention to the extension attributes. In such a without paying attention to the extension attributes. In such a
scenario the user experience would, however, be reduced, since the scenario the user experience would, however, be reduced, since the
recipient would not know (by any protocol means) the reason for recipient would not know (by any protocol means) the reason for
the session and would not be able to accept/reject it based on the the session and would not be able to accept/reject it based on the
file attributes. file attributes.
5. File selector 5. File selector
When the SDP offerer is the file the offer needs to unambiguously When the file receiver generates the SDP offer, this SDP offer needs
identify the requested file. For this purpose we introduce the to unambiguously identify the requested file at the file sender. For
notion of a file selector, which is a tuple composed of one or more this purpose we introduce the notion of a file selector, which is a
of the following individual selectors: the name, size, type, and hash tuple composed of one or more of the following individual selectors:
of the file. The file selector can include any number of selectors, the name, size, type, and hash of the file. The file selector can
so all four of them do not always need to be present. include any number of selectors, so all four of them do not always
need to be present.
The purpose of the file selector is to provide enough information The purpose of the file selector is to provide enough information
about the file to the remote entity, so that both the local and the about the file to the remote entity, so that both the local and the
remote entity can refer to the same file. The file selector is remote entity can refer to the same file. The file selector is
encoded in a 'file-selector' media attribute in SDP. The formal encoded in a 'file-selector' media attribute in SDP. The formal
syntax of the 'file-selector' media attribute is described in syntax of the 'file-selector' media attribute is described in
Figure 1. Figure 1.
The file selection process is applied to all the available files at The file selection process is applied to all the available files at
the host. The process selects those file that match each of the the host. The process selects those file that match each of the
skipping to change at page 13, line 42 skipping to change at page 13, line 42
The SDP Offer/Answer for file transfer allows the file sender to The SDP Offer/Answer for file transfer allows the file sender to
indicate a preferred disposition of the file to be transferred in a indicate a preferred disposition of the file to be transferred in a
new 'file-disposition' attribute. In principle, any value listed in new 'file-disposition' attribute. In principle, any value listed in
the IANA registry for Mail Content Disposition Values [3] is the IANA registry for Mail Content Disposition Values [3] is
acceptable, however, most of them may not be applicable. acceptable, however, most of them may not be applicable.
There are two content dispositions of interest for file transfer There are two content dispositions of interest for file transfer
operations. On one hand, the file sender may just want the file to operations. On one hand, the file sender may just want the file to
be rendered immediately in the file receiver's device. On the other be rendered immediately in the file receiver's device. On the other
hand, the file sender may just want to indicate the file recipient hand, the file sender may just want to indicate to the file receiver
that the file should not be rendered at the reception of the file. that the file should not be rendered at the reception of the file.
The recipient's user agent may want to interact with the user The recipient's user agent may want to interact with the user
regarding the file disposition or it may save the file until the user regarding the file disposition or it may save the file until the user
takes an action. In any case, the exact actions are implementation takes an action. In any case, the exact actions are implementation
dependent. dependent.
To indicate that a file should be automatically rendered, this memo To indicate that a file should be automatically rendered, this memo
uses the existing 'render' value of the Content Disposition type in uses the existing 'render' value of the Content Disposition type in
the new 'file-disposition' attribute in SDP. To indicate that a file the new 'file-disposition' attribute in SDP. To indicate that a file
should not be automatically rendered, this memo users the existing should not be automatically rendered, this memo users the existing
skipping to change at page 16, line 17 skipping to change at page 16, line 17
selector. However, specially in cases where the hash of the file is selector. However, specially in cases where the hash of the file is
unknown, the file name, size, and type can provide a description of unknown, the file name, size, and type can provide a description of
the file to be fetched. If the file receiver wishes to start a new the file to be fetched. If the file receiver wishes to start a new
file transfer it MUST add a 'file-transfer-id' attribute containing a file transfer it MUST add a 'file-transfer-id' attribute containing a
new globally unique random value. The file receiver MAY also add a new globally unique random value. The file receiver MAY also add a
'file-range' attribute indicating the start and stop offsets of the 'file-range' attribute indicating the start and stop offsets of the
file. There is no need to for the file receiver to include further file. There is no need to for the file receiver to include further
file attributes in the SDP offer, thus it is RECOMMENDED that SDP file attributes in the SDP offer, thus it is RECOMMENDED that SDP
offerers do not include any other file attribute defined by this offerers do not include any other file attribute defined by this
specification (other than the mandatory ones). Additionally, the specification (other than the mandatory ones). Additionally, the
file receiver MUST create an SDP offer that contains a session or file receiver MUST add a session or media 'recvonly' attribute in the
media 'recvonly' attribute. SDP offer. Then file receiver sends the SDP offer to the file
sender.
When the file receiver receives the SDP answer, if the port number of When the file receiver receives the SDP answer, if the port number of
the answer for a file request is non-zero, then the file receiver the answer for a file request is non-zero, then the file receiver
should receive the file using the protocol indicated in the "m=" should receive the file using the protocol indicated in the "m="
line. If the SDP answer contains a supported hashing algorithm in line. If the SDP answer contains a supported hashing algorithm in
the 'hash' selectors of the 'file-selector' attribute, then the file the 'hash' selectors of the 'file-selector' attribute, then the file
receiver SHOULD compute the hash of the file after its reception and receiver SHOULD compute the hash of the file after its reception and
check it against the hash received in the answer. In case the check it against the hash received in the answer. In case the
computed hash does not match the one contained in the SDP answer, the computed hash does not match the one contained in the SDP answer, the
file receiver SHOULD consider that the file transfer failed and file receiver SHOULD consider that the file transfer failed and
SHOULD inform the user. SHOULD inform the user.
8.1.3. SDP Offer for Several Files 8.1.3. SDP Offer for Several Files
An offerer that wishes to send or receive more than one file An offerer that wishes to send or receive more than one file
generates an "m=" line per file along with the file attributes generates an "m=" line per file along with the file attributes
described in this specification. This way, the answerer can reject described in this specification. This way, the answerer can reject
individual files by setting the port number of their associated "m=" individual files by setting the port number of their associated "m="
lines to zero, as per regular SDP [RFC4566] procedures. Each file lines to zero, as per regular SDP [RFC4566] procedures. Similarly,
has its own file transfer identifier, which uniquely identifies each the answerer can accept each individual file separately by setting
file transfer. the port number of their associated "m=" lines to non-zero value.
Each file has its own file transfer identifier, which uniquely
identifies each file transfer.
Using an "m=" line per file implies that different files are Using an "m=" line per file implies that different files are
transferred using different MSRP sessions. However, all those MSRP transferred using different MSRP sessions. However, all those MSRP
sessions can be set up to run over a single TCP connection, as sessions can be set up to run over a single TCP connection, as
described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP described in Section 8.1 of RFC 4975 [RFC4975]. The same TCP
connection can also be re-used for sequential file transfers. connection can also be re-used for sequential file transfers.
8.2. Answerer's Behavior 8.2. Answerer's Behavior
If the answerer wishes to reject a file offered by the offerer, it If the answerer wishes to reject a file offered by the offerer, it
skipping to change at page 18, line 8 skipping to change at page 18, line 15
If the SDP offer contains a 'file-range' attribute and the file If the SDP offer contains a 'file-range' attribute and the file
receiver accepts to receive the range of bytes declared in there, the receiver accepts to receive the range of bytes declared in there, the
file receiver MUST include a 'file-range' attribute in the SDP answer file receiver MUST include a 'file-range' attribute in the SDP answer
with the same range of values. If the file receiver does not accept with the same range of values. If the file receiver does not accept
the reception of that range of bytes, it SHOULD reject the transfer the reception of that range of bytes, it SHOULD reject the transfer
of the file. of the file.
8.2.2. The Answerer is a File Sender 8.2.2. The Answerer is a File Sender
In a pull operation the answerer is the file sender. In this case, In a pull operation the answerer is the file sender. In this case,
the file sender MUST first inspect the value of the the SDP answerer MUST first inspect the value of the
'file-transfer-id' attribute. If the has not been previously been 'file-transfer-id' attribute. If it has not been previously been
used throughout the session, then acceptance of the file MUST provoke used throughout the session, then acceptance of the file MUST provoke
the transfer of the file over the negotiated protocol. However, if the transfer of the file over the negotiated protocol. However, if
the value has been previously used by another file transfer operation the value has been previously used by another file transfer operation
within the session, then the file sender MUST NOT alert the user and within the session, then the file sender MUST NOT alert the user and
MUST NOT start a new transfer of the file. No matter whether an MUST NOT start a new transfer of the file. No matter whether an
actual file transfer is initiated or not, the file sender MUST create actual file transfer is initiated or not, the file sender MUST create
a proper SDP answer that contains the 'file-transfer-id' attribute a proper SDP answer that contains the 'file-transfer-id' attribute
with the same value received in the SDP offer, and then it MUST with the same value received in the SDP offer, and then it MUST
continue processing the SDP answer. continue processing the SDP answer.
The file sender MUST always create an SDP answer according to the SDP The file sender MUST always create an SDP answer according to the SDP
offer/answer procedures specified in RFC 3264 [RFC3264]. The file offer/answer procedures specified in RFC 3264 [RFC3264]. The file
sender inspects the file selector of the received SDP offer, which is sender inspects the file selector of the received SDP offer, which is
encoded in the 'file-selector' media attribute line. Then the file encoded in the 'file-selector' media attribute line. Then the file
sender applies the file selector, which implies selecting those files sender applies the file selector, which implies selecting those files
that match one by one with the 'name', 'type', 'size', and 'hash' that match one by one with the 'name', 'type', 'size', and 'hash'
selectors of the 'file-selector' attribute line (if they are selectors of the 'file-selector' attribute line (if they are
present). The file selector identifies zero or more candidate files present). The file selector identifies zero or more candidate files
to be sent. If the file selector is unable to identify any file, to be sent. If the file selector is unable to identify any file,
then the answerer MUST reject the MSRP stream for file transfer by then the answerer MUST reject the MSRP stream for file transfer by
setting the port number to zero, and then the file sender SHOULD also setting the port number to zero, and then the answerer SHOULD also
reject the SDP as per procedures in RFC 3264 [RFC3264], if this is reject the SDP as per procedures in RFC 3264 [RFC3264], if this is
the only stream described in the SDP offer. the only stream described in the SDP offer.
If the file selector points to a single file and the file sender If the file selector points to a single file and the file sender
decides to accept the file transfer, the file sender MUST create an decides to accept the file transfer, the file sender MUST create an
SDP answer that contains a 'sendonly' attribute, according to the SDP answer that contains a 'sendonly' attribute, according to the
procedures described RFC 3264 [RFC3264]. The file sender SHOULD add procedures described RFC 3264 [RFC3264]. The file sender SHOULD add
a 'hash' selector in the answer with the locally computed SHA-1 hash a 'hash' selector in the answer with the locally computed SHA-1 hash
over the complete file. If a hash value computed by the file sender over the complete file. If a hash value computed by the file sender
differs from that specified by the file receiver, the file sender can differs from that specified by the file receiver, the file sender can
skipping to change at page 20, line 25 skipping to change at page 20, line 31
identifier allocated to the file transfer operation. The file identifier allocated to the file transfer operation. The file
transfer identifier helps both endpoints to determine whether the SDP transfer identifier helps both endpoints to determine whether the SDP
offer is requesting a new file transfer or it is a repetition of the offer is requesting a new file transfer or it is a repetition of the
SDP. A new file transfer is one that, in case of acceptance, will SDP. A new file transfer is one that, in case of acceptance, will
provoke the actual transfer of a file. This is typically the case of provoke the actual transfer of a file. This is typically the case of
new offer/answer exchanges, or in cases where an endpoint wants to new offer/answer exchanges, or in cases where an endpoint wants to
abort the existing file transfer and re-start the file transfer once abort the existing file transfer and re-start the file transfer once
more. On the other hand, the repetition of the SDP does not lead to more. On the other hand, the repetition of the SDP does not lead to
any actual file to be transferred, potentially because the file any actual file to be transferred, potentially because the file
transfer is still going on or because it has already finished. This transfer is still going on or because it has already finished. This
is the case of a repeated offer/answer exchanges, which can be due to is the case of repeated offer/answer exchanges, which can be due to a
a number of reasons (session timer, addition/removal of other media number of reasons (session timer, addition/removal of other media
types in the SDP, update in SDP due to changes in other session types in the SDP, update in SDP due to changes in other session
parameters, etc.). parameters, etc.).
Implementations according to this specification MUST include a 'file- Implementations according to this specification MUST include a 'file-
transfer-id' attribute in SDP offers and answers. The SDP offerer transfer-id' attribute in SDP offers and answers. The SDP offerer
MUST select a file transfer identifier according to the syntax and MUST select a file transfer identifier according to the syntax and
add it to the 'file-transfer-id' attribute. The SDP answerer MUST add it to the 'file-transfer-id' attribute. The SDP answerer MUST
copy the value of the 'file-transfer-id' attribute in the SDP answer. copy the value of the 'file-transfer-id' attribute in the SDP answer.
The file transfer identifier MUST be unique within the current The file transfer identifier MUST be unique within the current
skipping to change at page 21, line 33 skipping to change at page 21, line 38
In another scenario, an endpoint that has successfully transferred a In another scenario, an endpoint that has successfully transferred a
file wants to send an SDP due to other reasons than the transfer of a file wants to send an SDP due to other reasons than the transfer of a
file. The SDP offerer creates an SDP file description that maintains file. The SDP offerer creates an SDP file description that maintains
the media description line corresponding to the file transfer. The the media description line corresponding to the file transfer. The
SDP offerer MUST then set the port number to zero and MUST keep the SDP offerer MUST then set the port number to zero and MUST keep the
same value of the 'file-transfer-id' attribute that the initial file same value of the 'file-transfer-id' attribute that the initial file
transfer got. transfer got.
8.4. Aborting an ongoing file transfer operation 8.4. Aborting an ongoing file transfer operation
A file sender that wishes to abort an ongoing file transfer operation Either the file sender or the file receiver can abort an ongoing file
without initiating an alternative file transfer, if an ongoing MSRP transfer at any time. Unless otherwise noted, the entity that aborts
SEND request is being transmitted, aborts the MSRP message by an ongoing file transfer operation MUST follow the procedures at the
including the '#' character in the continuation field of the end-line media level (e.g., MSRP) and at the signaling level (SDP Offer/
of a SEND request, according to the MSRP procedures (see Section 7.1 answer), as described below.
of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
message, aborting the MSRP message effectively aborts the file Assume the scenario depicted in Figure 3 where a file sender wishes
transfer. Then the file sender SHOULD close the MSRP session. This to abort an ongoing file transfer without initiating an alternative
is done by sending a new SDP offer that sets the port number to zero file transfer. Assume that an ongoing MSRP SEND request is being
in the related "m=" line that describes the file transfer (see transmitted. The file sender aborts the MSRP message by including
Section 8.2 of RFC 3264 [RFC3264]). This SDP offer MUST conform with the '#' character in the continuation field of the end-line of a SEND
the requirements of Section 8.1.1. The 'file-transfer-id' attribute request, according to the MSRP procedures (see Section 7.1 of RFC
MUST be the same that identifies the ongoing transfer. Then the file 4975 [RFC4975]). Since a file is transmitted as one MSRP message,
sender sends the SDP offer to the file recipient. aborting the MSRP message effectively aborts the file transfer. The
file receiver acknowledges the MSRP SEND request with a 200 response.
Then the file sender SHOULD close the MSRP session by creating a new
SDP offer that sets the port number to zero in the related "m=" line
that describes the file transfer (see Section 8.2 of RFC 3264
[RFC3264]). This SDP offer MUST conform with the requirements of
Section 8.1.1. The 'file-transfer-id' attribute MUST be the same
that identifies the ongoing transfer. Then the file sender sends
this SDP offer to the file receiver.
A file receiver that receives the above SDP offer creates an SDP A file receiver that receives the above SDP offer creates an SDP
answer according to the procedures of the SDP offer/answer (RFC 3264 answer according to the procedures of the SDP offer/answer (RFC 3264
[RFC3264]). This SDP answer MUST conform with the requirements of [RFC3264]). This SDP answer MUST conform with the requirements of
Section 8.2.1. Then the file recipient sends this SDP answer to the Section 8.2.1. Then the file receiver sends this SDP answer to the
file sender. file sender.
A file receiver that wishes to abort an ongoing transfer first must File sender File receiver
determine if the MSRP sender wishes to receive failure reports. If | |
the current MSRP SEND request sets the Failure-Report header to a |\ |
value different than "no", then the file receiver generates an MSRP | \ |
413 response to the current MSRP SEND request (see Section 10.5 of | \ |
RFC 4975 [RFC4975]). Then the file receiver SHOULD close the MSRP | \ |
session. This is done by sending a new SDP offer that sets the port | \ |
number to zero in the related "m=" line that describes the file | \ |
abort->| \ MSRP SEND (#) |
| +--------------->|
| MSRP 200 |
|<-----------------------|
| re-INVITE (SDP offer) |
|----------------------->|
| SIP 200 OK (SDP answer)|
|<-----------------------|
| SIP ACK |
|----------------------->|
| |
Figure 3: File sender aborts an ongoing file transfer
When the file receiver wants to abort the file transfer, there are
two possible scenarios, depending on the value of the Failure-Report
header in the ongoing MSRP SEND request. Assume now the scenario
depicted in Figure 4 where the MSRP SEND request includes a Failure-
Report header set to a value different than "no". When the file
receiver wishes to abort the ongoing file transfer, the file receiver
generates an MSRP 413 response to the current MSRP SEND request (see
Section 10.5 of RFC 4975 [RFC4975]). Then the file receiver MUST
close the MSRP session by generating a new SDP offer that sets the
port number to zero in the related "m=" line that describes the file
transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer transfer (see Section 8.2 of RFC 3264 [RFC3264]). This SDP offer
MUST conform with the requirements expressed in Section 8.1.2. The MUST conform with the requirements expressed in Section 8.1.2. The
'file-transfer-id' attribute MUST be the same that identifies the 'file-transfer-id' attribute MUST be the same that identifies the
ongoing transfer. Then the file sender sends the SDP offer to the ongoing transfer. Then the file receiver sends this SDP offer to the
file receiver. file sender.
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: yes |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| MSRP 413 |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| re-INVITE (SDP offer) |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
Figure 4: File receiver aborts an ongoing file transfer. Failure-
Report set to a value different than "no" in MSRP
In another scenario, depicted in Figure 5, an ongoing file transfer
is taking place, where the MSRP SEND request contains a Failure-
Report header set to the value "no". When the file receiver wants to
abort the ongoing transfer, it MUST close MSRP session by generating
a new SDP offer that sets the port number to zero in the related "m="
line that describes the file transfer (see Section 8.2 of RFC 3264
[RFC3264]). This SDP offer MUST conform with the requirements
expressed in Section 8.1.2. The 'file-transfer-id' attribute MUST be
the same that identifies the ongoing transfer. Then the file
receiver sends this SDP offer to the file sender.
File sender File receiver
| |
|\ |
| \ MSRP SEND |
| \ Failure-Report: no |
| \ |
| \ |
| \ |
| \ |
| \ |
| \ |
| re-INVITE (SDP offer) |<-abort
|<-----------------------|
| \ (#) |
| +----------->|
| MSRP 200 |
|<-----------------------|
| SIP 200 OK (SDP answer)|
|----------------------->|
| SIP ACK |
|<-----------------------|
| |
Figure 5: File receiver aborts an ongoing file transfer. Failure-
Report set to "no" in MSRP
A file sender that receives an SDP offer setting the port number to A file sender that receives an SDP offer setting the port number to
zero in the related "m=" line for file transfer, first, if an ongoing zero in the related "m=" line for file transfer, first, if an ongoing
MSRP SEND request is being transmitted, it aborts the MSRP message by MSRP SEND request is being transmitted, it aborts the MSRP message by
including the '#' character in the continuation field of the end-line including the '#' character in the continuation field of the end-line
of a SEND request, according to the MSRP procedures (see Section 7.1 of a SEND request, according to the MSRP procedures (see Section 7.1
of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP of RFC 4975 [RFC4975]). Since a file is transmitted as one MSRP
message, aborting the MSRP message effectively aborts the file message, aborting the MSRP message effectively aborts the file
transfer. Then the file sender creates an SDP answer according to transfer. Then the file sender creates an SDP answer according to
the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This the procedures of the SDP offer/answer (RFC 3264 [RFC3264]). This
SDP answer MUST conform with the requirements of Section 8.2.2. Then SDP answer MUST conform with the requirements of Section 8.2.2. Then
the file sender sends this SDP answer to the file receiver. the file sender sends this SDP answer to the file receiver.
8.5. Indicating File Transfer Offer/Answer Capability 8.5. Indicating File Transfer Offer/Answer Capability
The SDP Offer/Answer Model [RFC3264] provides provisions for The SDP Offer/Answer Model [RFC3264] provides provisions for
indicating a capability to another endpoint (see Section 9 of RFC indicating a capability to another endpoint (see Section 9 of RFC
3264 [RFC3264]). The mechanism assumes a high-level protocol, such 3264 [RFC3264]). The mechanism assumes a high-level protocol, such
as SIP [RFC3261], that provides a capability query (such as a SIP as SIP [RFC3261], that provides a capability query (such as a SIP
OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP OPTIONS request). RFC 3264 [RFC3264] indicates how to build the SDP
that is included in the response to such request. As such, RFC 3264 that is included in the response to such capability query. As such,
indicates that and endpoint builds an SDP body that contains an "m=" RFC 3264 indicates that an endpoint builds an SDP body that contains
line that contains the media type (message, for MSRP). An endpoint an "m=" line containing the media type (message, for MSRP). An
that implements the procedures specified in this document SHOULD also endpoint that implements the procedures specified in this document
add a 'file-selector' media attribute for the "m=message" line. The SHOULD also add a 'file-selector' media attribute for the "m=message"
'file-selector' media attribute MUST be empty, i.e., it MUST NOT line. The 'file-selector' media attribute MUST be empty, i.e., it
contain any selector. The endpoint MUST NOT add any of the other MUST NOT contain any selector. The endpoint MUST NOT add any of the
file attributes defined in this specification. other file attributes defined in this specification.
8.6. Re-usage of Existing "m=" Lines in SDP 8.6. Re-usage of Existing "m=" Lines in SDP
The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP The SDP Offer/Answer Model [RFC3264] provides rules that allow SDP
offerers and answerers to modify an existing media line, i.e., re-use offerers and answerers to modify an existing media line, i.e., re-use
an existing media line with different attributes. The same is also an existing media line with different attributes. The same is also
possible when SDP signals a file transfer operation according to the possible when SDP signals a file transfer operation according to the
rules of this memo. Therefore, the procedures defined in RFC 3264 rules of this memo. Therefore, the procedures defined in RFC 3264
[RFC3264], in particular those defined in Section 8.3, MUST apply for [RFC3264], in particular those defined in Section 8.3, MUST apply for
file transfer operations. An endpoint that wants to re-use an file transfer operations. An endpoint that wants to re-use an
skipping to change at page 23, line 23 skipping to change at page 25, line 34
If the file offerer re-sends an SDP offer with a port different than If the file offerer re-sends an SDP offer with a port different than
zero, then the 'file-transfer-id' attribute determines whether a new zero, then the 'file-transfer-id' attribute determines whether a new
file transfer will start or whether the file transfer does not need file transfer will start or whether the file transfer does not need
to start. If the SDP answerer accepts the SDP, then file transfer to start. If the SDP answerer accepts the SDP, then file transfer
starts from the indicated byte (if a 'file-range' attribute is starts from the indicated byte (if a 'file-range' attribute is
present). present).
8.7. MSRP Usage 8.7. MSRP Usage
The file transfer service specified in this document uses "m=" lines The file transfer service specified in this document uses "m=" lines
to describe the unidirectional transfer of a file. Consequently, in SDP to describe the unidirectional transfer of a file.
each MSRP session established following the procedures in Section 8.1 Consequently, each MSRP session established following the procedures
and Section 8.2 is only used to transfer a single file. So, senders in Section 8.1 and Section 8.2 is only used to transfer a single
MUST only use the dedicated MSRP session to send the file described file. So, senders MUST only use the dedicated MSRP session to send
in the SDP offer or answer. That is, senders MUST NOT send the file described in the SDP offer or answer. That is, senders MUST
additional files over the same MSRP session. NOT send additional files over the same MSRP session.
File transfer may be accomplished using a new multimedia session File transfer may be accomplished using a new multimedia session
established for the purpose. Alternatively a file transfer may be established for the purpose. Alternatively a file transfer may be
conducted within an existing multimedia session, without regard for conducted within an existing multimedia session, without regard for
the media in use within that session. Of particular note, file the media in use within that session. Of particular note, file
transfer may be done within a multimedia session containing an MSRP transfer may be done within a multimedia session containing an MSRP
session used for regular instant messaging. If file transfer is session used for regular instant messaging. If file transfer is
initiated within an existing multimedia session, the SDP offerer MUST initiated within an existing multimedia session, the SDP offerer MUST
NOT reuse an existing "m=" line that is still being used by MSRP NOT reuse an existing "m=" line that is still being used by MSRP
(either regular MSRP for instant messaging or an ongoing file (either regular MSRP for instant messaging or an ongoing file
transfer). Rather it MUST add an addtional "m=" line or else reuse transfer). Rather it MUST add an addtional "m=" line or else reuse
an "m=" line that is no longer being used. an "m=" line that is no longer being used.
Additionally, implementations according to this specification MUST Additionally, implementations according to this specification MUST
include a single file in a single MSRP message. Notice that the MSRP include a single file in a single MSRP message. Notice that the MSRP
specification defines "MSRP message" as a complete unit of MIME or specification defines "MSRP message" as a complete unit of MIME or
text content, which can be split and delivered in more than one MSRP text content, which can be split and delivered in more than one MSRP
request; each of these portions of the complete message is called a request; each of these portions of the complete message is called a
"chunk". So, it is still valid to send a file in several chunks, but "chunk". So, it is still valid to send a file in several chunks, but
from the MSRP point of view, all the chunks together form an MSRP from the MSRP point of view, all the chunks together form an MSRP
message: the CPIM message that wraps the file. When chunking, notice message: the CPIM message that wraps the file. When chunking is
that MSRP does not require to wait for a 200-class response for a used, it should be noticed that MSRP does not require to wait for a
chunk before sending the following one. Therefore, it is valid to 200-class response for a chunk before sending the following one.
send pipelined MSRP SEND requests containing chunks of the same MSRP Therefore, it is valid to send pipelined MSRP SEND requests
message (the file). Section 9.1 contains an example of a file containing chunks of the same MSRP message (the file). Section 9.1
transfer using pipelined MSRP requests. contains an example of a file transfer using pipelined MSRP requests.
The MSRP specification [RFC4975] defines a 'max-size' SDP attribute. The MSRP specification [RFC4975] defines a 'max-size' SDP attribute.
This attribute specifies the maximum number of octets of an MSRP This attribute specifies the maximum number of octets of an MSRP
message that the creator of the SDP is willing to receive (notice message that the creator of the SDP is willing to receive (notice
once more the definition of "MSRP message"). File receivers MAY add once more the definition of "MSRP message"). File receivers MAY add
a 'max-size' attribute to the MSRP "m=" line that specifies the file, a 'max-size' attribute to the MSRP "m=" line that specifies the file,
indicating the maximum number of octets of an MSRP message. File indicating the maximum number of octets of an MSRP message. File
senders MUST NOT exceed the 'max-size' limit for any message sent in senders MUST NOT exceed the 'max-size' limit for any message sent in
the resulting session. the resulting session.
skipping to change at page 24, line 37 skipping to change at page 26, line 48
to MSRP for transportation. MSRP will consider the delivered content to MSRP for transportation. MSRP will consider the delivered content
as a whole message, and will start numbering bytes with the number 1. as a whole message, and will start numbering bytes with the number 1.
Note that the default content disposition of MSRP bodies is 'render'. Note that the default content disposition of MSRP bodies is 'render'.
When MSRP is used to transfer files, the MSRP Content-Disposition When MSRP is used to transfer files, the MSRP Content-Disposition
header can also take the value 'attachment' as indicated in header can also take the value 'attachment' as indicated in
Section 7. Section 7.
Once the file transfer is completed, the file sender SHOULD close the Once the file transfer is completed, the file sender SHOULD close the
MSRP session and MUST behave according to the MSRP [RFC4975] MSRP session and MUST behave according to the MSRP [RFC4975]
procedures with respect closing MSRP sessions. Note that MSRP procedures with respect to closing MSRP sessions. Note that MSRP
session management is not related to TCP connection management. As a session management is not related to TCP connection management. As a
matter of fact, MSRP allows multiple MSRP sessions to share the same matter of fact, MSRP allows multiple MSRP sessions to share the same
TCP connection. TCP connection.
8.8. Considerations about the 'file-icon' attribute 8.8. Considerations about the 'file-icon' attribute
This specification allows a file sender to include a small preview of This specification allows a file sender to include a small preview of
an image file: an icon. A 'file-icon' attribute contains a CID URL an image file: an icon. A 'file-icon' attribute contains a CID URL
[RFC2392] that points to an additional body that contains the actual [RFC2392] pointing to an additional body that contains the actual
icon. Since the icon is sent as a separate body along the SDP body, icon. Since the icon is sent as a separate body along the SDP body,
the file sender MUST wrap the SDP body and the icon bodies in a MIME the file sender MUST wrap the SDP body and the icon bodies in a MIME
multipart/related body. Therefore, implementations according to this multipart/related body. Therefore, implementations according to this
specification MUST implement the multipart/related MIME type specification MUST implement the multipart/related MIME type
[RFC2387]. When creating a multipart/related MIME wrapper, the SDP [RFC2387]. When creating a multipart/related MIME wrapper, the SDP
body MUST be the root body, which according to RFC 2387 [RFC2387] is body MUST be the root body, which according to RFC 2387 [RFC2387] is
identified as the first body in the multipart/related MIME wrapper or identified as the first body in the multipart/related MIME wrapper or
explicitly identified by the 'start' parameter. According to RFC explicitly identified by the 'start' parameter. According to RFC
2387 [RFC2387], the 'type' parameter MUST be present and point to the 2387 [RFC2387], the 'type' parameter MUST be present and point to the
root body, i.e., the SDP body. root body, i.e., the SDP body.
Assume that an endpoint behaving according to this specification Assume that an endpoint behaving according to this specification
tries to send a file to a remote endpoint that neither implements tries to send a file to a remote endpoint that neither implements
this specification nor implements multipart MIME bodies. The file this specification nor implements multipart MIME bodies. The file
sender sends an SDP offer that contains a multipart/related MIME body sender sends an SDP offer that contains a multipart/related MIME body
that includes an SDP body part and an icon body part. The file that includes an SDP body part and an icon body part. The file
receiver, not supporting multipart MIME types, will reject the SDP receiver, not supporting multipart MIME types, will reject the SDP
offer, via a higher protocol mechanism (e.g., SIP). In this case, it offer via a higher protocol mechanism (e.g., SIP). In this case, it
is RECOMMENDED that the file sender removes the icon body part, is RECOMMENDED that the file sender removes the icon body part,
creates a single SDP body (i.e., without multipart MIME) and re-sends creates a single SDP body (i.e., without multipart MIME) and re-sends
the SDP offer again. This provides some backwards compatibility with the SDP offer again. This provides some backwards compatibility with
file receives that do not implement this specification and increases file receives that do not implement this specification and increases
the chances of getting the SDP accepted at the file receiver. the chances of getting the SDP accepted at the file receiver.
Since the icon is sent as part of the signaling, it is recommended to Since the icon is sent as part of the signaling, it is RECOMMENDED to
keep icons restricted to the minimum number of bytes that provide keep the size of icons restricted to the minimum number of bytes that
significance. provide significance.
9. Examples 9. Examples
9.1. Offerer sends a file to the Answerer 9.1. Offerer sends a file to the Answerer
This section shows an example flow for a file transfer scenario. The This section shows an example flow for a file transfer scenario. The
example assumes that SIP [RFC3261] is used to transport the SDP example assumes that SIP [RFC3261] is used to transport the SDP
offer/answer exchange, although the SIP details are briefly shown in offer/answer exchange, although the SIP details are briefly shown for
the sake of brevity. the sake of brevity.
Alice, the SDP offerer, wishes to send an image file to Bob (the Alice, the SDP offerer, wishes to send an image file to Bob (the
answerer). Alice's User Agent Client (UAC) creates a unidirectional answerer). Alice's User Agent Client (UAC) creates a unidirectional
SDP offer that contains the description of the file that she wants to SDP offer that contains the description of the file that she wants to
send to Bob's User Agent Server (UAS). The description also includes send to Bob's User Agent Server (UAS). The description also includes
an icon representing the contents of the file to be transferred. The an icon representing the contents of the file to be transferred. The
sequence flow is shown in Figure 3. sequence flow is shown in Figure 6.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(3) (SIP) ACK | |(3) (SIP) ACK |
|----------------------->| |----------------------->|
| | | |
skipping to change at page 26, line 30 skipping to change at page 28, line 31
|(7) (MSRP) 200 OK | |(7) (MSRP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
|(8) (SIP) BYE | |(8) (SIP) BYE |
|----------------------->| |----------------------->|
|(9) (SIP) 200 OK | |(9) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
| | | |
Figure 3: Flow diagram of an offerer sending a file to an answerer Figure 6: Flow diagram of an offerer sending a file to an answerer
F1: Alice constructs an SDP description of the file to be sent and F1: Alice constructs an SDP description of the file to be sent and
attaches it to a SIP INVITE request addressed to Bob. attaches it to a SIP INVITE request addressed to Bob.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
CSeq: 1 INVITE CSeq: 1 INVITE
Max-Forwards: 70 Max-Forwards: 70
skipping to change at page 27, line 51 skipping to change at page 29, line 51
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com> Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
[...small preview icon of the file...] [...small preview icon of the file...]
--boundary71-- --boundary71--
Figure 4: INVITE request containing an SDP offer for file transfer Figure 7: INVITE request containing an SDP offer for file transfer
NOTE: The Content-Type header field and the 'file-selector' NOTE: The Content-Type header field and the 'file-selector'
attribute in the above figure are split in several lines for attribute in the above figure are split in several lines for
formatting purposes. Real implementations will encode it in a formatting purposes. Real implementations will encode it in a
single line. single line.
From now on we omit the SIP details for the sake of brevity. From now on we omit the SIP details for the sake of brevity.
F2: Bob receives the INVITE request, inspects the SDP offer and F2: Bob receives the INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following decides to accept the file transfer. So Bob creates the following
skipping to change at page 28, line 31 skipping to change at page 30, line 31
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg a=file-selector:name:"My cool picture.jpg" type:image/jpeg
size:4092 hash:sha-1: size:4092 hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
Figure 5: SDP answer accepting the SDP offer for file transfer Figure 8: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split NOTE: The 'file-selector' attribute in the above figure is split
in three lines for formatting purposes. Real implementations will in three lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
request. This SEND request contains the first chunk of the file. request. This SEND request contains the first chunk of the file.
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
skipping to change at page 29, line 23 skipping to change at page 31, line 23
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
DateTime: 2006-05-15T15:02:31-03:00 DateTime: 2006-05-15T15:02:31-03:00
Content-Disposition: render; filename="My cool picture.jpg"; Content-Disposition: render; filename="My cool picture.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300"; creation-date="Mon, 15 May 2006 15:01:31 +0300";
size=4092 size=4092
Content-Type: image/jpeg Content-Type: image/jpeg
... first set of bytes of the JPEG image ... ... first set of bytes of the JPEG image ...
-------d93kswow+ -------d93kswow+
Figure 6: MSRP SEND request containing the first chunk of actual file Figure 9: MSRP SEND request containing the first chunk of actual file
F5: Alice sends the second and last chunk. Note that MSRP allows to F5: Alice sends the second and last chunk. Note that MSRP allows to
send pipelined chunks, so there is no need to wait for the 200 (OK) send pipelined chunks, so there is no need to wait for the 200 (OK)
response from the previous chunk. response from the previous chunk.
MSRP op2nc9a SEND MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp
Message-ID: 12339sdqwer Message-ID: 12339sdqwer
Byte-Range: 2049-4385/4385 Byte-Range: 2049-4385/4385
Content-Type: message/cpim Content-Type: message/cpim
... second set of bytes of the JPEG image ... ... second set of bytes of the JPEG image ...
-------op2nc9a$ -------op2nc9a$
Figure 7: MSRP SEND request containing the second chunk of actual Figure 10: MSRP SEND request containing the second chunk of actual
file file
F6: Bob acknowledges the reception of the first chunk. F6: Bob acknowledges the reception of the first chunk.
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4385 Byte-Range: 1-2048/4385
-------d93kswow$ -------d93kswow$
Figure 8: MSRP 200 OK response Figure 11: MSRP 200 OK response
F7: Bob acknowledges the reception of the second chunk. F7: Bob acknowledges the reception of the second chunk.
MSRP op2nc9a 200 OK MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4385/4385 Byte-Range: 2049-4385/4385
-------op2nc9a$ -------op2nc9a$
Figure 9: MSRP 200 OK response Figure 12: MSRP 200 OK response
F8: Alice terminates the SIP session by sending a SIP BYE request. F8: Alice terminates the SIP session by sending a SIP BYE request.
F9: Bob acknowledges the reception of the BYE request and sends a 200 F9: Bob acknowledges the reception of the BYE request and sends a 200
(OK) response. (OK) response.
9.2. Offerer requests a file from the Answerer and second file transfer 9.2. Offerer requests a file from the Answerer and second file transfer
In this example Alice, the SDP offerer, first wishes to fetch a file In this example Alice, the SDP offerer, first wishes to fetch a file
from Bob, the SDP answerer. Alice knows that Bob has a specific file from Bob, the SDP answerer. Alice knows that Bob has a specific file
she wants to download. She has learned the hash of the file by some she wants to download. She has learned the hash of the file by some
out-of-band mechanism. The hash selector is enough to produce a file out-of-band mechanism. The hash selector is enough to produce a file
selector that points to the specific file. So, Alice creates an SDP selector that points to the specific file. So, Alice creates an SDP
offer that contains the file descriptor. Bob accepts the offer that contains the file descriptor. Bob accepts the file
transmission and sends the file to Alice. When Alice has completely transfer and sends the file to Alice. When Alice has completely
received Bob's file, she intends to send a new image file to Bob. received Bob's file, she intends to send a new image file to Bob.
Therefore Alice re-uses the existing SDP media line with different Therefore Alice re-uses the existing SDP media line with different
attributes and updates the description of the new file she wants to attributes and updates the description of the new file she wants to
send to Bob's User Agent Server (UAS). In particular, Alice creates send to Bob's User Agent Server (UAS). In particular, Alice creates
a new file transfer identifier since this is a new file transfer a new file transfer identifier since this is a new file transfer
operation. Figure 10 shows the sequence flow. operation. Figure 13 shows the sequence flow.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) INVITE | |(1) (SIP) INVITE |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
|<-----------------------| |<-----------------------|
|(3) (SIP) ACK | |(3) (SIP) ACK |
|----------------------->| |----------------------->|
| | | |
skipping to change at page 31, line 38 skipping to change at page 33, line 38
|(10) (MSRP) 200 OK | |(10) (MSRP) 200 OK |
|<-----------------------| |<-----------------------|
| | | |
|(11) (SIP) BYE | |(11) (SIP) BYE |
|<-----------------------| |<-----------------------|
|(12) (SIP) 200 OK | |(12) (SIP) 200 OK |
|----------------------->| |----------------------->|
| | | |
| | | |
Figure 10: Flow diagram of an offerer requesting a file from the Figure 13: Flow diagram of an offerer requesting a file from the
answerer and then sending a file to the answer answerer and then sending a file to the answer
F1: Alice constructs an SDP description of the file she wants to F1: Alice constructs an SDP description of the file she wants to
receive and attaches the SDP offer to a SIP INVITE request addressed receive and attaches the SDP offer to a SIP INVITE request addressed
to Bob. to Bob.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com> To: Bob <sip:bob@example.com>
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
Call-ID: a84b4c76e66710 Call-ID: a84b4c76e66710
skipping to change at page 32, line 30 skipping to change at page 34, line 30
t=0 0 t=0 0
m=message 7654 TCP/MSRP * m=message 7654 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=file-selector:hash:sha-1: a=file-selector:hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2 a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
Figure 11: INVITE request containing an SDP offer for file transfer Figure 14: INVITE request containing an SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split NOTE: The 'file-selector' attribute in the above figure is split
in two lines for formatting purposes. Real implementations will in two lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
From now on we omit the SIP details for the sake of brevity. From now on we omit the SIP details for the sake of brevity.
F2: Bob receives the INVITE request, inspects the SDP offer, computes F2: Bob receives the INVITE request, inspects the SDP offer, computes
the file descriptor and finds a local file whose hash equals the one the file descriptor and finds a local file whose hash equals the one
indicated in the SDP. Bob accepts the file transmission and creates indicated in the SDP. Bob accepts the file transfer and creates an
an SDP answer as follows: SDP answer as follows:
v=0 v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=sendonly a=sendonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:type:image/jpeg hash:sha-1: a=file-selector:type:image/jpeg hash:sha-1:
72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E 72:24:5F:E8:65:3D:DA:F3:71:36:2F:86:D4:71:91:3E:E4:A2:CE:2E
a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2 a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2
Figure 12: SDP answer accepting the SDP offer for file transfer Figure 15: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split NOTE: The 'file-selector' attribute in the above figure is split
in two lines for formatting purposes. Real implementations will in two lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP
SEND request that contains the file. SEND request that contains the file.
MSRP d93kswow SEND MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
skipping to change at page 33, line 48 skipping to change at page 35, line 48
Content-Disposition: render; filename="My cool photo.jpg"; Content-Disposition: render; filename="My cool photo.jpg";
creation-date="Mon, 15 May 2006 15:01:31 +0300"; creation-date="Mon, 15 May 2006 15:01:31 +0300";
modification-date="Mon, 15 May 2006 16:04:53 +0300"; modification-date="Mon, 15 May 2006 16:04:53 +0300";
read-date="Mon, 16 May 2006 09:12:27 +0300"; read-date="Mon, 16 May 2006 09:12:27 +0300";
size=1931 size=1931
Content-Type: image/jpeg Content-Type: image/jpeg
...binary JPEG image... ...binary JPEG image...
-------d93kswow$ -------d93kswow$
Figure 13: MSRP SEND request containing the actual file Figure 16: MSRP SEND request containing the actual file
F5: Alice acknowledges the reception of the SEND request. F5: Alice acknowledges the reception of the SEND request.
MSRP d93kswow 200 OK MSRP d93kswow 200 OK
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
-------d93kswow$ -------d93kswow$
Figure 14: MSRP 200 OK response Figure 17: MSRP 200 OK response
F6: Alice re-uses the existing SDP media line inserting the F6: Alice re-uses the existing SDP media line inserting the
description of the file to be sent and attaches it to a SIP re-INVITE description of the file to be sent and attaches it to a SIP re-INVITE
request addressed to Bob. Alice reuses the TCP port number for the request addressed to Bob. Alice reuses the TCP port number for the
MSRP stream, but changes the MSRP session and the 'file-transfer-id' MSRP stream, but changes the MSRP session and the 'file-transfer-id'
value according to this specification. value according to this specification.
INVITE sip:bob@example.com SIP/2.0 INVITE sip:bob@example.com SIP/2.0
To: Bob <sip:bob@example.com>;tag=1928323431 To: Bob <sip:bob@example.com>;tag=1928323431
From: Alice <sip:alice@example.com>;tag=1928301774 From: Alice <sip:alice@example.com>;tag=1928301774
skipping to change at page 35, line 51 skipping to change at page 37, line 51
Content-Type: image/jpeg Content-Type: image/jpeg
Content-Transfer-Encoding: binary Content-Transfer-Encoding: binary
Content-ID: <id3@alicepc.example.com> Content-ID: <id3@alicepc.example.com>
Content-Length: [length of image] Content-Length: [length of image]
Content-Disposition: icon Content-Disposition: icon
[..small preview icon...] [..small preview icon...]
--boundary71-- --boundary71--
Figure 15: Reuse of the SDP in a second file transfer Figure 18: Reuse of the SDP in a second file transfer
NOTE: The Content-Type header field and the 'file-selector' NOTE: The Content-Type header field and the 'file-selector'
attribute in the above figure are split in several lines for attribute in the above figure are split in several lines for
formatting purposes. Real implementations will encode it in a formatting purposes. Real implementations will encode it in a
single line. single line.
F7: Bob receives the re-INVITE request, inspects the SDP offer and F7: Bob receives the re-INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and extracts the icon body, checks the creation date and the file size,
decides to accept the file transfer. So Bob creates an SDP answer and decides to accept the file transfer. So Bob creates an SDP
where he reuses the same TCP port number, but changes his MSRP answer where he reuses the same TCP port number, but changes his MSRP
session, according to the procedures of this specification. session, according to the procedures of this specification.
v=0 v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s= s=
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 8888 TCP/MSRP * m=message 8888 TCP/MSRP *
a=recvonly a=recvonly
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg a=file-selector:name:"sunset.jpg" type:image/jpeg
size:4096 hash:sha-1: size:4096 hash:sha-1:
58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F 58:23:1F:E8:65:3B:BC:F3:71:36:2F:86:D4:71:91:3E:E4:B1:DF:2F
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render a=file-disposition:render
Figure 16: SDP answer accepting the SDP offer for file transfer Figure 19: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split NOTE: The 'file-selector' attribute in the above figure is split
in three lines for formatting purposes. Real implementations will in three lines for formatting purposes. Real implementations will
encode it in a single line. encode it in a single line.
F9: If a TCP connection towards Bob is already open, Alice re-uses F9: If a TCP connection towards Bob is already open, Alice re-uses
that TCP connection to send an MSRP SEND request that contains the that TCP connection to send an MSRP SEND request that contains the
file. file.
MSRP d95ksxox SEND MSRP d95ksxox SEND
skipping to change at page 37, line 23 skipping to change at page 39, line 23
From: Alice <sip:alice@example.com> From: Alice <sip:alice@example.com>
DateTime: 2006-05-21T13:02:15-03:00 DateTime: 2006-05-21T13:02:15-03:00
Content-Disposition: render; filename="Sunset.jpg"; Content-Disposition: render; filename="Sunset.jpg";
creation-date="Sun, 21 May 2006 13:02:15 -0300"; creation-date="Sun, 21 May 2006 13:02:15 -0300";
size=1931 size=1931
Content-Type: image/jpeg Content-Type: image/jpeg
...binary JPEG image... ...binary JPEG image...
-------d95ksxox+ -------d95ksxox+
Figure 17: MSRP SEND request containing the actual file Figure 20: MSRP SEND request containing the actual file
F10: Bob acknowledges the reception of the SEND request. F10: Bob acknowledges the reception of the SEND request.
MSRP d95ksxox 200 OK MSRP d95ksxox 200 OK
To-Path: msrp://alicepc.example.com:7654/iau39;tcp To-Path: msrp://alicepc.example.com:7654/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp
Byte-Range: 1-2027/2027 Byte-Range: 1-2027/2027
-------d95ksxox$ -------d95ksxox$
Figure 18: MSRP 200 OK response Figure 21: MSRP 200 OK response
F11: Then Bob terminates the SIP session by sending a SIP BYE F11: Then Bob terminates the SIP session by sending a SIP BYE
request. request.
F12: Alice acknowledges the reception of the BYE request and sends a F12: Alice acknowledges the reception of the BYE request and sends a
200 (OK) response. 200 (OK) response.
9.3. Example of a capability indication 9.3. Example of a capability indication
Alice sends an OPTIONS request to Bob (this request does not contain Alice sends an OPTIONS request to Bob (this request does not contain
SDP). Bob answers with a 200 (OK) response that contain the SDP SDP). Bob answers with a 200 (OK) response that contain the SDP
shown in Figure 20. The SDP indicates support for CPIM messages that shown in Figure 23. The SDP indicates support for CPIM messages that
can contain other MIME types. The maximum MSRP message size that the can contain other MIME types. The maximum MSRP message size that the
endpoint can receive is 20000 octets. The presence of the 'file- endpoint can receive is 20000 octets. The presence of the 'file-
selector' attribute indicates support for the file transfer offer/ selector' attribute indicates support for the file transfer offer/
answer mechanism. answer mechanism.
Alice's UAC Bob's UAS Alice's UAC Bob's UAS
| | | |
|(1) (SIP) OPTIONS | |(1) (SIP) OPTIONS |
|----------------------->| |----------------------->|
|(2) (SIP) 200 OK | |(2) (SIP) 200 OK |
| with SDP | | with SDP |
|<-----------------------| |<-----------------------|
| | | |
| | | |
Figure 19: Flow diagram of a capability request Figure 22: Flow diagram of a capability request
v=0 v=0
o=bob 2890844656 2890855439 IN IP4 bobpc.example.com o=bob 2890844656 2890855439 IN IP4 bobpc.example.com
s=- s=-
c=IN IP4 bobpc.example.com c=IN IP4 bobpc.example.com
t=0 0 t=0 0
m=message 0 TCP/MSRP * m=message 0 TCP/MSRP *
a=accept-types:message/cpim a=accept-types:message/cpim
a=accept-wrapped-types:* a=accept-wrapped-types:*
a=max-size:20000 a=max-size:20000
a=file-selector a=file-selector
Figure 20: SDP of the 200 (OK) response to an OPTIONS request Figure 23: SDP of the 200 (OK) response to an OPTIONS request
10. Security Considerations 10. Security Considerations
The SDP attributes defined in this specification identify a file to The SDP attributes defined in this specification identify a file to
be transferred between two endpoints. An endpoint can offer to send be transferred between two endpoints. An endpoint can offer to send
the file to the other endpoint or request to receive the file from the file to the other endpoint or request to receive the file from
the other endpoint. In the former case, an attacker modifying those the other endpoint. In the former case, an attacker modifying those
SDP attributes could cheat the receiver making it think that the file SDP attributes could cheat the receiver making it think that the file
to be transferred was a different one. In the latter case, the to be transferred was a different one. In the latter case, the
attacker could make the sender send a different file than the one attacker could make the sender send a different file than the one
requested by the receiver. Consequently, it is RECOMMENDED that requested by the receiver. Consequently, it is RECOMMENDED that
integrity protection be applied to the SDP session descriptions integrity protection be applied to the SDP session descriptions
carrying the attributes specified in this specification. carrying the attributes specified in this specification.
The descriptions of the files being transferred between endpoints may The descriptions of the files being transferred between endpoints may
reveal information the endpoints may consider confidential. reveal information the endpoints may consider confidential.
Therefore, it is RECOMMENDED that SDP session descriptions carrying Therefore, it is RECOMMENDED that SDP session descriptions carrying
the attributes specified in this specification be encrypted. the attributes specified in this specification are encrypted.
TLS and S/MIME are the natural choices to provide offer/answer TLS and S/MIME are the natural choices to provide offer/answer
exchanges with integrity protection and confidentiality. exchanges with integrity protection and confidentiality.
It is possible that a malicious or misbehaving implementation tries It is possible that a malicious or misbehaving implementation tries
to exhaust the resources of the remote endpoint, e.g., the internal to exhaust the resources of the remote endpoint, e.g., the internal
memory or the file system, by sending very large files. To protect memory or the file system, by sending very large files. To protect
from this attack an SDP answer SHOULD first verify the identity of from this attack, an SDP answer SHOULD first verify the identity of
the SDP offerer, and perhaps, only accept file transfers from trusted the SDP offerer, and perhaps only accept file transfers from trusted
sources. Mechanisms to verify the identity of the file sender depend sources. Mechanisms to verify the identity of the file sender depend
on the high-level protocol that carries the SDP, for example, SIP on the high-level protocol that carries the SDP, for example, SIP
[RFC3261] and MSRP [RFC4975]. [RFC3261] and MSRP [RFC4975].
It is also RECOMMENDED that implementations take measurements to It is also RECOMMENDED that implementations take measurements to
avoid attacks on resource exhaustion, for example, by limiting the avoid attacks on resource exhaustion, for example, by limiting the
size of receive files, verifying that there is enough space in the size of received files, verifying that there is enough space in the
file system to store the file prior to its reception, or limiting the file system to store the file prior to its reception, or limiting the
number of simultaneous file transfers. number of simultaneous file transfers.
File receivers MUST also sanitize all input, such as the local file File receivers MUST also sanitize all input, such as the local file
name, prior to making calls to the local file system to store a file. name, prior to making calls to the local file system to store a file.
This is to prevent the existence of meaningful characters to the This is to prevent the existence of meaningful characters to the
local operating system that could damage it. local operating system that could damage it.
Once a file has been transferred the file receiver must take care Once a file has been transferred the file receiver must take care of
with it. Typically file transfer is a commonly used mechanism for it. Typically file transfer is a commonly used mechanism for
transmitting computer virus, spyware, and other types of malware. transmitting computer virus, spyware, and other types of malware.
File receivers should apply all possible security technologies (e.g., File receivers should apply all possible security technologies (e.g.,
antivirus, antispaware, etc.) to dismiss the risk of damage at their antivirus, antispyware, etc.) to dismiss the risk of damage at their
host. host.
11. IANA Considerations 11. IANA Considerations
This document instructs IANA to register a number of SDP attributes This document instructs IANA to register a number of SDP attributes
according to the following: according to the following:
11.1. Registration of new SDP attributes 11.1. Registration of new SDP attributes
This memo provides instructions to IANA to register a number of media This memo provides instructions to IANA to register a number of media
skipping to change at page 41, line 38 skipping to change at page 43, line 38
Specification: RFC XXXX Specification: RFC XXXX
12. Acknowledgements 12. Acknowledgements
The authors would like to thank Mats Stille, Nancy Greene, Adamu The authors would like to thank Mats Stille, Nancy Greene, Adamu
Haruna, and Arto Leppisaari for discussing initial concepts described Haruna, and Arto Leppisaari for discussing initial concepts described
in this memo. Thanks to Pekka Kuure for reviewing initial versions in this memo. Thanks to Pekka Kuure for reviewing initial versions
this document and providing helpful comments. Joerg Ott, Jiwey Wang, this document and providing helpful comments. Joerg Ott, Jiwey Wang,
Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis-
Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan
Rosenberg, Eric Rescorla, and Vikram Chhibber discussed and provided Rosenberg, Eric Rescorla, Vikram Chhibber, and Ben Campbell discussed
comments and improvements to this document. and provided comments and improvements to this document.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Extensions (MIME) Part One: Format of Internet Message
 End of changes. 57 change blocks. 
136 lines changed or deleted 235 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/