tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 5547

 
 
 

A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer

Part 2 of 3, p. 13 to 28
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 13 
8.  Protocol Operation

   This section discusses how to use the parameters defined in Section 6
   in the context of an offer/answer [RFC3264] exchange.  Additionally,
   this section also discusses the behavior of the endpoints using MSRP.

Top      Up      ToC       Page 14 
   A file transfer session is initiated by the offerer sending an SDP
   offer to the answerer.  The answerer either accepts or rejects the
   file transfer session and sends an SDP answer to the offerer.

   We can differentiate two use cases, depending on whether the offerer
   is the file sender or file receiver:

   1.  The offerer is the file sender, i.e., the offerer wants to
       transmit a file to the answerer.  Consequently, the answerer is
       the file receiver.  In this case, the SDP offer contains a
       'sendonly' attribute, and accordingly the SDP answer contains a
       'recvonly' attribute.

   2.  The offerer is the file receiver, i.e., the offerer wants to
       fetch a file from the answerer.  Consequently, the answerer is
       the file sender.  In this case, the SDP offer contains a session
       or media 'recvonly' attribute, and accordingly the SDP answer
       contains a session or media 'sendonly' attribute.

8.1.  The 'file-transfer-id' Attribute

   This specification creates an extension to the SDP offer/answer model
   [RFC3264], and because of that, it is assumed that the existing SDP
   behavior is kept intact.  The SDP behavior requires, for example,
   that SDP is sent again to the remote party in situations where the
   media description or perhaps other SDP parameters have not changed
   with respect to a previous offer/answer exchange.  Let's consider the
   SIP Session Timer (RFC 4028) [RFC4028], which uses re-INVITE requests
   to refresh sessions.  RFC 4028 recommends to send unmodified SDP in a
   re-INVITE to refresh the session.  Should this re-INVITE contain SDP
   describing a file transfer operation and occur while the file
   transfer was still going on, there would be no means to detect
   whether the SDP creator wanted to abort the current file transfer
   operation and initiate a new one or the SDP file description was
   included in the SDP due to other reasons (e.g., session timer
   refresh).

   A similar scenario occurs when two endpoints have successfully agreed
   on a file transfer, which is currently taking place when one of the
   endpoints wants to add additional media streams to the existing
   session.  In this case, the endpoint sends a re-INVITE request that
   contains the SDP.  The SDP needs to maintain the media descriptions
   for the current ongoing file transfer and add the new media
   descriptions.  The problem is that the other endpoint is not able to
   determine whether or not a new file transfer is requested.

Top      Up      ToC       Page 15 
   In other cases, a file transfer was successfully completed.  Then, if
   an endpoint resends the SDP offer with the media stream for the file
   transfer, then the other endpoint wouldn't be able to determine
   whether or not a new file transfer should start.

   To address these scenarios, this specification defines the 'file-
   transfer-id' attribute, which contains a globally unique random
   identifier allocated to the file transfer operation.  The file
   transfer identifier helps both endpoints to determine whether the SDP
   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
   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
   abort the existing file transfer and restart the file transfer once
   more.  On the other hand, the repetition of the SDP does not lead to
   any actual file to be transferred, potentially because the file
   transfer is still going on or because it has already finished.  This
   is the case of repeated offer/answer exchanges, which can be due to a
   number of reasons (session timer, addition/removal of other media
   types in the SDP, update in SDP due to changes in other session
   parameters, etc.).

   Implementations according to this specification MUST include a 'file-
   transfer-id' attribute in SDP offers and answers.  The SDP offerer
   MUST select a file transfer identifier according to the syntax and
   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.

   The file transfer identifier MUST be unique within the current
   session (never used before in this session), and it is RECOMMENDED to
   be unique across different sessions.  It is RECOMMENDED to select a
   relatively big random identifier (e.g., 32 characters) to avoid
   duplications.  The SDP answerer MUST keep track of the proposed file
   transfer identifiers in each session and copy the value of the
   received file transfer identifier in the SDP answer.

   If a file transfer is suspended and resumed at a later time, the
   resumption is considered a new file transfer (even when the file to
   be transferred is the same); therefore, the SDP offerer MUST choose a
   new file transfer identifier.

   If an endpoint sets the port number to zero in the media description
   of a file transfer, for example, because it wants to reject the file
   transfer operation, then the SDP answer MUST mirror the value of the
   'file-transfer-id' attribute included in the SDP offer.  This
   effectively means that setting a media stream to zero has higher
   precedence than any value that the 'file-transfer-id' attribute can
   take.

Top      Up      ToC       Page 16 
   As a side effect, the 'file-transfer-id' attribute can be used for
   aborting and restarting again an ongoing file transfer.  Assume that
   two endpoints agree on a file transfer and the actual transfer of the
   file is taking place.  At some point in time in the middle of the
   file transfer, one endpoint sends a new SDP offer, equal to the
   initial one except for the value of the 'file-transfer-id' attribute,
   which is a new globally unique random value.  This indicates that the
   offerer wants to abort the existing transfer and start a new one,
   according to the SDP parameters.  The SDP answerer SHOULD abort the
   ongoing file transfer, according to the procedures of the file
   transfer protocol (e.g., MSRP), and start sending file once more from
   the initial requested octet.  Section 8.4 further discusses aborting
   a file transfer.

   If an endpoint creates an SDP offer where the 'file-transfer-id'
   attribute value does not change with respect to a previously sent
   one, but the file selector changes so that a new file is selected,
   then this is considered an error, and the SDP answerer MUST abort the
   file transfer operation (e.g., by setting the port number to zero in
   the SDP answer).  Note that endpoints MAY change the 'file-selector'
   attribute as long as the selected file does not change (e.g., by
   adding a hash selector); however, it is RECOMMENDED that endpoints do
   not change the value of the 'file-selector' attribute if it is
   requested to transfer the same file described in a previous SDP
   offer/answer exchange.

   Figure 3 summarizes the relation of the 'file-transfer-id' attribute
   with the file selector in subsequent SDP exchanges.

                      \                |             |               |
                       \ file selector |  different  |     same      |
     'file-transfer-id' \              |    file     |     file      |
     ==================================+=============+===============+
                                       |  new file   |   new file    |
      changed                          |  transfer   |   transfer    |
                                       |  operation  |   operation   |
     ----------------------------------+-------------+---------------+
                                       |             | existing file |
      unchanged                        |   error     |   transfer    |
                                       |             |   operation   |
     ----------------------------------+-------------+---------------+

      Figure 3: Relation of the 'file-transfer-id' attribute with the
             selector of the file in a subsequent SDP exchange

   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.  The SDP offerer creates an SDP file description that maintains

Top      Up      ToC       Page 17 
   the media description line corresponding to the file transfer.  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
   transfer got.

8.2.  Offerer's Behavior

   An offerer who wishes to send or receive one or more files to or from
   an answerer MUST build an SDP [RFC4566] description of a session
   containing one "m=" line per file.  When MSRP is used as the transfer
   mechanism, each "m=" line also describes a single MSRP session,
   according to the MSRP [RFC4975] procedures.  Any "m=" lines that may
   have already been present in a previous SDP exchange are normally
   kept unmodified; the new "m=" lines are added afterwards (Section 8.6
   describes cases when "m=" lines are reused).  All the media line
   attributes specified and required by MSRP [RFC4975] (e.g., "a=path",
   "a=accept-types", etc.)  MUST be included as well.

8.2.1.  The Offerer Is a File Sender

   In a push operation, the file sender creates an SDP offer describing
   the file to be sent.  The file sender MUST add a 'file-selector'
   attribute media line containing at least one of the 'type', 'size',
   or 'hash' selectors in indicating the type, size, or hash of the
   file, respectively.  If the file sender wishes to start a new file
   transfer, the file sender MUST add a 'file-transfer-id' attribute
   containing a new globally unique random identifier value.
   Additionally, the file sender MUST add a session or media 'sendonly'
   attribute to the SDP offer.  Then the file sender sends the SDP offer
   to the file receiver.

      Not all the selectors in the 'file-selector' attribute might be
      known when the file sender creates the SDP offer, for example,
      because the host is still processing the file.

      The 'hash' selector in the 'file-selector' attribute contains
      valuable information for the file receiver to identify whether the
      file is already available and need not be transmitted.

   The file sender MAY also add a 'name' selector in the 'file-selector'
   attribute, and 'file-icon', 'file-disposition', and 'file-date'
   attributes further describing the file to be transferred.  The 'file-
   disposition' attribute provides a presentation suggestion (for
   example: the file sender would like the file receiver to render the
   file or not).  The three date attributes provide the answerer with an
   indication of the age of the file.  The file sender MAY also add a
   'file-range' attribute indicating the start and stop offsets of the
   file.

Top      Up      ToC       Page 18 
   When the file sender receives the SDP answer, if the port number of
   the answer for a file request is non-zero, the file sender starts the
   transfer of the file according to the negotiated parameters in SDP.

8.2.2.  The Offerer Is a File Receiver

   In a pull operation, the file receiver creates the SDP offer and
   sends it to the file sender.  The file receiver MUST include a 'file-
   selector' attribute and MUST include, at least, one of the selectors
   defined for such attribute (i.e., 'name', 'type', 'size', or 'hash').
   In many cases, if the hash of the file is known, that is enough to
   identify the file; therefore, the offerer can include only a 'hash'
   selector.  However, particularly in cases where the hash of the file
   is 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 file transfer, it MUST add a 'file-transfer-id' attribute
   containing 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.  There is no need for the file receiver to
   include further file attributes in the SDP offer; thus, it is
   RECOMMENDED that SDP offerers do not include any other file attribute
   defined by this specification (other than the mandatory ones).
   Additionally, the file receiver MUST add a session or media
   'recvonly' attribute in the SDP offer.  Then, the file receiver sends
   the SDP offer to the file sender.

   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
   should receive the file using the protocol indicated in the "m="
   line.  If the SDP answer contains a supported hashing algorithm in
   the 'hash' selectors of the 'file-selector' attribute, then the file
   receiver SHOULD compute the hash of the file after its reception and
   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
   file receiver SHOULD consider that the file transfer failed and
   SHOULD inform the user.  Similarly, the file receiver SHOULD also
   verify that the other selectors declared in the SDP match the file
   properties, otherwise, the file receiver SHOULD consider that the
   file transfer failed and SHOULD inform the user.

8.2.3.  SDP Offer for Several Files

   An offerer that wishes to send or receive more than one file
   generates an "m=" line per file along with the file attributes
   described in this specification.  This way, the answerer can reject
   individual files by setting the port number of their associated "m="
   lines to zero, as per regular SDP [RFC4566] procedures.  Similarly,
   the answerer can accept each individual file separately by setting

Top      Up      ToC       Page 19 
   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
   transferred using different MSRP sessions.  However, all those MSRP
   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
   connection can also be reused for sequential file transfers.

8.3.  Answerer's Behavior

   If the answerer wishes to reject a file offered by the offerer, it
   sets the port number of the "m=" line associated with the file to
   zero, as per regular SDP [RFC4566] procedures.  The rejected answer
   MUST contained a 'file-selector' and 'file-transfer-id' attributes
   whose values mirror the corresponding values of the SDP offer.

   If the answerer decides to accept the file, it proceeds as per
   regular MSRP [RFC4975] and SDP [RFC4566] procedures.

8.3.1.  The Answerer Is a File Receiver

   In a push operation, the SDP answerer is the file receiver.  When the
   file receiver gets the SDP offer, it first examines the port number.
   If the port number is set to zero, the file transfer operation is
   closed, and no more data is expected over the media stream.  Then, if
   the port number is different than zero, the file receiver inspects
   the 'file-transfer-id' attribute.  If the value of the 'file-
   transfer-id' attribute has been previously used, then the existing
   session remains without changes; perhaps the file transfer is still
   in progress, or perhaps it has concluded, but there are no changes
   with respect to the current status.  In any case, independently of
   the port number, the SDP answerer creates a regular SDP answer and
   sends it to the offerer.

   If the port number is different than zero and the SDP offer contains
   a new 'file-transfer-id' attribute, then it is signaling a request
   for a new file transfer.  The SDP answerer extracts the attributes
   and parameters that describe the file and typically requests
   permission from the user to accept or reject the reception of the
   file.  If the file transfer operation is accepted, the file receiver
   MUST create an SDP answer according to the procedures specified in
   RFC 3264 [RFC3264].  If the offer contains 'name', 'type', or 'size'
   selectors in the 'file-selector' attribute, the answerer MUST copy
   them into the answer.  The file receiver copies the value of the
   'file-transfer-id' attribute to the SDP answer.  Then the file
   receiver MUST add a session or media 'recvonly' attribute according

Top      Up      ToC       Page 20 
   to the procedures specified in RFC 3264 [RFC3264].  The file receiver
   MUST NOT include 'file-icon', 'file-disposition', or 'file-date'
   attributes in the SDP answer.

   The file receiver can use the hash to find out if a local file with
   the same hash is already available, in which case, this could imply
   the reception of a duplicated file.  It is up to the answerer to
   determine whether or not the file transfer is accepted in case of a
   duplicated file.

   If the SDP offer contains a 'file-range' attribute and the file
   receiver accepts to receive the range of octets declared in there,
   the 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 the reception of that range of octets, it SHOULD reject the
   transfer of the file.

   When the file transfer operation is complete, the file receiver
   computes the hash of the file and SHOULD verify that it matches the
   hash declared in the SDP.  If they do not match, the file receiver
   SHOULD consider that the file transfer failed and SHOULD inform the
   user.  Similarly, the file receiver SHOULD also verify that the other
   selectors declared in the SDP match the file properties; otherwise,
   the file receiver SHOULD consider that the file transfer failed and
   SHOULD inform the user.

8.3.2.  The Answerer Is a File Sender

   In a pull operation the answerer is the file sender.  In this case,
   the SDP answerer MUST first inspect the value of the
   'file-transfer-id' attribute.  If it has not been previously used
   throughout the session, then acceptance of the file MUST provoke the
   transfer of the file over the negotiated protocol.  However, if the
   value has been previously used by another file transfer operation
   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 or not
   an actual file transfer is initiated, the file sender MUST create a
   proper SDP answer that contains the 'file-transfer-id' attribute with
   the same value received in the SDP offer, and then it MUST continue
   processing the SDP answer.

   The file sender MUST always create an SDP answer according to the SDP
   offer/answer procedures specified in RFC 3264 [RFC3264].  The file
   sender inspects the file selector of the received SDP offer, which is
   encoded in the 'file-selector' media attribute line.  Then the file
   sender applies the file selector, which implies selecting those files
   that match one by one with the 'name', 'type', 'size', and 'hash'
   selectors of the 'file-selector' attribute line (if they are

Top      Up      ToC       Page 21 
   present).  The file selector identifies zero or more candidate files
   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
   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
   the only stream described in the SDP offer.

   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
   SDP answer that contains a 'sendonly' attribute, according to the
   procedures described in RFC 3264 [RFC3264].  The file sender SHOULD
   add 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 differs from that specified by the file receiver, the file
   sender can either send the file without that hash value or reject the
   request by setting the port in the media stream to zero.  The file
   sender MAY also include a 'type' selector in the 'file-selector'
   attribute line of the SDP answer.  The answerer MAY also include
   'file-icon' and 'file-disposition' attributes to further describe the
   file.  Although the answerer MAY also include a 'name' and 'size'
   selectors in the 'file-selector' attribute, and a 'file-date'
   attribute, it is RECOMMENDED not to include them in the SDP answer if
   the actual file transfer protocol (e.g., MSRP [RFC4975]) can
   accommodate a Content-Disposition header field [RFC2183] with the
   equivalent parameters.

      The whole idea of adding file descriptors to SDP is to provide a
      mechanism where a file transfer can be accepted prior to its
      start.  Adding any SDP attributes that are otherwise signaled
      later in the file transfer protocol would just duplicate the
      information, but will not provide any information to the offerer
      to accept or reject the file transfer (note that the offerer is
      requesting a file).

   Last, if the file selector points to multiple candidate files, the
   answerer MAY use some local policy, e.g., consulting the user, to
   choose one of them to be defined in the SDP answer.  If that choice
   cannot be done, the answerer SHOULD reject the MSRP media stream for
   file transfer (by setting the port number to zero).

      If the need arises, future specifications can provide a suitable
      mechanism that allows to either select multiple files or, e.g.,
      resolve ambiguities by returning a list of files that match the
      file selector.

   If the SDP offer contains a 'file-range' attribute and the file
   sender accepts to send the range of octets declared in there, the
   file sender MUST include a 'file-range' attribute in the SDP answer

Top      Up      ToC       Page 22 
   with the same range of values.  If the file sender does not accept
   sending that range of octets, it SHOULD reject the transfer of the
   file.

8.4.  Aborting an Ongoing File Transfer Operation

   Either the file sender or the file receiver can abort an ongoing file
   transfer at any time.  Unless otherwise noted, the entity that aborts
   an ongoing file transfer operation MUST follow the procedures at the
   media level (e.g., MSRP) and at the signaling level (SDP offer/
   answer), as described below.

   Assume the scenario depicted in Figure 4 where a file sender wishes
   to abort an ongoing file transfer without initiating an alternative
   file transfer.  Assume that an ongoing MSRP SEND request is being
   transmitted.  The file sender aborts the MSRP message by 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 RFC
   4975 [RFC4975]).  Since a file is transmitted as one MSRP message,
   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.2.1.  The 'file-transfer-id' attribute MUST be the same
   attribute that identifies the ongoing transfer.  Then the file sender
   sends this SDP offer to the file receiver.

      Rather than close the MSRP session by setting the port number to
      zero in the related "m=" line, the file sender could also tear
      down the whole session, e.g., by sending a SIP BYE request.

   Note that it is the responsibility of the file sender to tear down
   the MSRP session.  Implementations should be prepared for
   misbehaviors and implement measures to avoid hang states.  For
   example, upon expiration of a timer the file receiver can close the
   aborted MSRP session by using regular MSRP procedures.

   A file receiver that receives the above SDP offer creates an SDP
   answer according to the procedures of the SDP offer/answer (RFC 3264
   [RFC3264]).  This SDP answer MUST conform with the requirements of
   Section 8.3.1.  Then the file receiver sends this SDP answer to the
   file sender.

Top      Up      ToC       Page 23 
                        File sender            File receiver
                            |                        |
                            |\                       |
                            | \                      |
                            |  \                     |
                            |   \                    |
                            |    \                   |
                            |     \                  |
                     abort->|      \  MSRP SEND (#)  |
                            |       +--------------->|
                            | MSRP 200               |
                            |<-----------------------|
                            | re-INVITE (SDP offer)  |
                            |----------------------->|
                            | SIP 200 OK (SDP answer)|
                            |<-----------------------|
                            | SIP ACK                |
                            |----------------------->|
                            |                        |

           Figure 4: 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 5 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
   MUST conform with the requirements expressed in Section 8.2.2.  The
   'file-transfer-id' attribute MUST be the same attribute that
   identifies the ongoing transfer.  Then the file receiver sends this
   SDP offer to the file sender.

Top      Up      ToC       Page 24 
                     File sender            File receiver
                         |                        |
                         |\                       |
                         | \  MSRP SEND           |
                         |  \ Failure-Report: yes |
                         |   \                    |
                         |    \                   |
                         |     \                  |
                         |      \                 |
                         |       \                |
                         |        \               |
                         | MSRP 413               |<-abort
                         |<-----------------------|
                         |          \   (#)       |
                         |           +----------->|
                         | re-INVITE (SDP offer)  |
                         |<-----------------------|
                         | SIP 200 OK (SDP answer)|
                         |----------------------->|
                         | SIP ACK                |
                         |<-----------------------|
                         |                        |

    Figure 5: File receiver aborts an ongoing file transfer.  Failure-
             Report set to a value different than "no" in MSRP

   In another scenario, depicted in Figure 6, 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 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 MUST conform with the
   requirements expressed in Section 8.2.2.  The 'file-transfer-id'
   attribute MUST be the same attribute that identifies the ongoing
   transfer.  Then the file receiver sends this SDP offer to the file
   sender.

Top      Up      ToC       Page 25 
                     File sender            File receiver
                         |                        |
                         |\                       |
                         | \  MSRP SEND           |
                         |  \ Failure-Report: no  |
                         |   \                    |
                         |    \                   |
                         |     \                  |
                         |      \                 |
                         |       \                |
                         |        \               |
                         | re-INVITE (SDP offer)  |<-abort
                         |<-----------------------|
                         |          \   (#)       |
                         |           +----------->|
                         | MSRP 200               |
                         |<-----------------------|
                         | SIP 200 OK (SDP answer)|
                         |----------------------->|
                         | SIP ACK                |
                         |<-----------------------|
                         |                        |

    Figure 6: 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
   zero in the related "m=" line for file transfer, first, if an ongoing
   MSRP SEND request is being transmitted, aborts the MSRP message by
   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 RFC 4975 [RFC4975]).  Since a file is transmitted as one MSRP
   message, aborting the MSRP message effectively aborts the file
   transfer.  Then the file sender creates an SDP answer according to
   the procedures of the SDP offer/answer (RFC 3264 [RFC3264]).  This
   SDP answer MUST conform with the requirements of Section 8.3.2.  Then
   the file sender sends this SDP answer to the file receiver.

8.5.  Indicating File Transfer Offer/Answer Capability

   The SDP offer/answer model [RFC3264] provides provisions for
   indicating a capability to another endpoint (see Section 9 of RFC
   3264 [RFC3264]).  The mechanism assumes a high-level protocol, such
   as SIP [RFC3261], that provides a capability query (such as a SIP
   OPTIONS request).  RFC 3264 [RFC3264] indicates how to build the SDP
   that is included in the response to such capability query.  As such,
   RFC 3264 indicates that an endpoint builds an SDP body that contains

Top      Up      ToC       Page 26 
   an "m=" line containing the media type (message, for MSRP).  An
   endpoint that implements the procedures specified in this document
   SHOULD also add a 'file-selector' media attribute for the "m=message"
   line.  The 'file-selector' media attribute MUST be empty, i.e., it
   MUST NOT contain any selector.  The endpoint MUST NOT add any of the
   other file attributes defined in this specification.

8.6.  Reusage of Existing "m=" Lines in SDP

   The SDP offer/answer model [RFC3264] provides rules that allow SDP
   offerers and answerers to modify an existing media line, i.e., reuse
   an existing media line with different attributes.  The same is also
   possible when SDP signals a file transfer operation according to the
   rules of this memo.  Therefore, the procedures defined in RFC 3264
   [RFC3264], in particular those defined in Section 8.3, MUST apply for
   file transfer operations.  An endpoint that wants to reuse an
   existing "m=" line to start the file transfer of another file creates
   a different 'file-selector' attribute and selects a new globally
   unique random value of the 'file-transfer-id' attribute.

   If the file offerer resends an SDP offer with a port different than
   zero, then the 'file-transfer-id' attribute determines whether a new
   file transfer will start or whether the file transfer does not need
   to start.  If the SDP answerer accepts the SDP, then file transfer
   starts from the indicated octet (if a 'file-range' attribute is
   present).

8.7.  MSRP Usage

   The file transfer service specified in this document uses "m=" lines
   in SDP to describe the unidirectional transfer of a file.
   Consequently, each MSRP session established following the procedures
   in Section 8.2 and Section 8.3 is only used to transfer a single
   file.  So, senders MUST only use the dedicated MSRP session to send
   the file described in the SDP offer or answer.  That is, senders MUST
   NOT send additional files over the same MSRP session.

   File transfer may be accomplished using a new multimedia session
   established for the purpose.  Alternatively, a file transfer may be
   conducted within an existing multimedia session, without regard for
   the media in use within that session.  Of particular note, file
   transfer may be done within a multimedia session containing an MSRP
   session used for regular instant messaging.  If file transfer is
   initiated within an existing multimedia session, the SDP offerer MUST
   NOT reuse an existing "m=" line that is still being used by MSRP
   (either regular MSRP for instant messaging or an ongoing file
   transfer).  Rather, it MUST add an additional "m=" line or else reuse
   an "m=" line that is no longer being used.

Top      Up      ToC       Page 27 
   Additionally, implementations according to this specification MUST
   include a single file in a single MSRP message.  Notice that the MSRP
   specification defines "MSRP message" as a complete unit of MIME or
   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
   "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
   message: the Common Presence and Instant Messaging (CPIM) message
   that wraps the file.  When chunking is used, it should be noticed
   that MSRP does not require to wait for a 200-class response for a
   chunk before sending the following one.  Therefore, it is valid to
   send pipelined MSRP SEND requests containing chunks of the same MSRP
   message (the file).  Section 9.1 contains an example of a file
   transfer using pipelined MSRP requests.

   The MSRP specification [RFC4975] defines a 'max-size' SDP attribute.
   This attribute specifies the maximum number of octets of an MSRP
   message that the creator of the SDP is willing to receive (notice
   once more the definition of "MSRP message").  File receivers MAY add
   a 'max-size' attribute to the MSRP "m=" line that specifies the 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
   the resulting session.

   In the absence of a 'file-range' attribute in the SDP, the MSRP file
   transfer MUST start with the first octet of the file and end with the
   last octet (i.e., the whole file is transferred).  If a 'file-range'
   attribute is present in SDP, the file sender application MUST extract
   the indicated range of octets from the file (start and stop offset
   octets, both inclusive).  Then the file sender application MAY wrap
   those octets in an appropriate wrapper.  MSRP mandates
   implementations to implement the message/cpim wrapper [RFC3862].
   Usage of a wrapper is negotiated in the SDP (see Section 8.6 in RFC
   4975 [RFC4975]).  Last, the file sender application delivers the
   content (e.g., the message/cpim body) to MSRP for transportation.
   MSRP will consider the delivered content as a whole message, and will
   start numbering bytes with the number 1.

   Note that the default content disposition of MSRP bodies is 'render'.
   When MSRP is used to transfer files, the MSRP Content-Disposition
   header can also take the value 'attachment' as indicated in
   Section 7.

   Once the file transfer is completed, the file sender SHOULD close the
   MSRP session and MUST behave according to the MSRP [RFC4975]
   procedures with respect to closing MSRP sessions.  Note that MSRP

Top      Up      ToC       Page 28 
   session management is not related to TCP connection management.  As a
   matter of fact, MSRP allows multiple MSRP sessions to share the same
   TCP connection.

8.8.  Considerations about the 'file-icon' Attribute

   This specification allows a file sender to include a small preview of
   an image file: an icon.  A 'file-icon' attribute contains a
   Content-ID (CID) URL [RFC2392] pointing to an additional body that
   contains the actual 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 multipart/related body.  Therefore,
   implementations according to this specification MUST implement the
   multipart/related MIME type [RFC2387].  When creating a multipart/
   related MIME wrapper, the SDP 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 explicitly identified by the
   'start' parameter.  According to RFC 2387 [RFC2387], the 'type'
   parameter MUST be present and point to the root body, i.e., the SDP
   body.

   Assume that an endpoint behaving according to this specification
   tries to send a file to a remote endpoint that neither implements
   this specification nor implements multipart MIME bodies.  The file
   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
   receiver, not supporting multipart MIME types, will reject the SDP
   offer via a higher protocol mechanism (e.g., SIP).  In this case, it
   is RECOMMENDED that the file sender removes the icon body part,
   creates a single SDP body (i.e., without multipart MIME), and resends
   the SDP offer.  This provides some backwards compatibility with file
   receives that do not implement this specification and increases 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
   keep the size of icons restricted to the minimum number of octets
   that provide significance.



(page 28 continued on part 3)

Next RFC Part