RFC 5547
A Session Description Protocol (SDP) Offer/Answer Mechanism to Enable File Transfer
9. Examples
9.1. Offerer Sends a File to the Answerer
This section shows an example flow for a file transfer scenario. The example assumes that SIP [RFC3261] is used to transport the SDP offer/answer exchange, although the SIP details are briefly shown for the sake of brevity.
Alice, the SDP offerer, wishes to send an image file to Bob (the answerer). Alice's User Agent Client (UAC) creates a unidirectional 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 an icon representing the contents of the file to be transferred. The sequence flow is shown in Figure 7. Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (chunk) | |----------------------->| |(5) (MSRP) SEND (chunk) | |----------------------->| |(6) (MSRP) 200 OK | |<-----------------------| |(7) (MSRP) 200 OK | |<-----------------------| | | |(8) (SIP) BYE | |----------------------->| |(9) (SIP) 200 OK | |<-----------------------| | | | | Figure 7: Flow diagram of an offerer sending a file to an answerer F1: Alice constructs an SDP description of the file to be sent and attaches it to a SIP INVITE request addressed to Bob.
INVITE sip:bob@example.com SIP/2.0 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: <sip:alice@alicepc.example.com> Content-Type: multipart/related; type="application/sdp"; boundary="boundary71" Content-Length: [length] --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844526 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://alicepc.example.com:7654/jshA7we;tcp a=file-selector:name:"My cool picture.jpg" type:image/jpeg 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 a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE a=file-disposition:render a=file-date:creation:"Mon, 15 May 2006 15:01:31 +0300" a=file-icon:cid:id2@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id2@alicepc.example.com> Content-Length: [length of image] Content-Disposition: icon [...small preview icon of the file...] --boundary71-- Figure 8: INVITE request containing an SDP offer for file transfer
NOTE: The Content-Type header field and the 'file-selector'
attribute in the above figure are split in several lines for
formatting purposes. Real implementations will encode it in a
single line.
From now on we omit the SIP details for the sake of brevity.
F2: Bob receives the INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and file size, and
decides to accept the file transfer. So Bob creates the following
SDP answer:
v=0
o=bob 2890844656 2890844656 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=file-selector:name:"My cool picture.jpg" type:image/jpeg
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
a=file-transfer-id:Q6LMoGymJdh0IKIgD6wD0jkcfgva4xvE
Figure 9: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split
in three lines for formatting purposes. Real implementations will
encode it in a single line.
F4: Alice opens a TCP connection to Bob and creates an MSRP SEND
request. This SEND request contains the first chunk of the file.
MSRP d93kswow SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 1-2048/4385 Content-Type: message/cpim To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com> DateTime: 2006-05-15T15:02:31-03:00 Content-Disposition: render; filename="My cool picture.jpg"; creation-date="Mon, 15 May 2006 15:01:31 +0300"; size=4092 Content-Type: image/jpeg ... first set of bytes of the JPEG image ... -------d93kswow+ Figure 10: MSRP SEND request containing the first chunk of actual file 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) response from the previous chunk. MSRP op2nc9a SEND To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 12339sdqwer Byte-Range: 2049-4385/4385 Content-Type: message/cpim ... second set of bytes of the JPEG image ... -------op2nc9a$ Figure 11: MSRP SEND request containing the second chunk of actual file F6: Bob acknowledges the reception of the first chunk. MSRP d93kswow 200 OK To-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Byte-Range: 1-2048/4385 -------d93kswow$ Figure 12: MSRP 200 OK response
F7: Bob acknowledges the reception of the second chunk. MSRP op2nc9a 200 OK To-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Byte-Range: 2049-4385/4385 -------op2nc9a$ Figure 13: MSRP 200 OK response 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 (OK) response.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 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 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 offer that contains the file descriptor. Bob accepts the file 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. Therefore, Alice reuses the existing SDP media line with different attributes and updates the description of the new file she wants to send to Bob's User Agent Server (UAS). In particular, Alice creates a new file transfer identifier since this is a new file transfer operation. Figure 14 shows the sequence flow.
Alice's UAC Bob's UAS | | |(1) (SIP) INVITE | |----------------------->| |(2) (SIP) 200 OK | |<-----------------------| |(3) (SIP) ACK | |----------------------->| | | |(4) (MSRP) SEND (file) | |<-----------------------| |(5) (MSRP) 200 OK | |----------------------->| | | |(6) (SIP) INVITE | |----------------------->| |(7) (SIP) 200 OK | |<-----------------------| |(8) (SIP) ACK | |----------------------->| | | |(9) (MSRP) SEND (file) | |----------------------->| |(10) (MSRP) 200 OK | |<-----------------------| | | |(11) (SIP) BYE | |<-----------------------| |(12) (SIP) 200 OK | |----------------------->| | | | | Figure 14: Flow diagram of an offerer requesting a file from the answerer and then sending a file to the answer F1: Alice constructs an SDP description of the file she wants to receive and attaches the SDP offer to a SIP INVITE request addressed to Bob.
INVITE sip:bob@example.com SIP/2.0 To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 1 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:03 GMT Contact: <sip:alice@alicepc.example.com> Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844526 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7654 TCP/MSRP * a=recvonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://alicepc.example.com:7654/jshA7we;tcp 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 a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2 Figure 15: INVITE request containing an SDP offer for file transfer NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line. From now on we omit the SIP details for the sake of brevity. F2: Bob receives the INVITE request, inspects the SDP offer, computes the file descriptor, and finds a local file whose hash equals the one indicated in the SDP. Bob accepts the file transfer and creates an SDP answer as follows:
v=0 o=bob 2890844656 2890855439 IN IP4 bobpc.example.com s= c=IN IP4 bobpc.example.com t=0 0 m=message 8888 TCP/MSRP * a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://bobpc.example.com:8888/9di4ea;tcp 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 a=file-transfer-id:aCQYuBRVoUPGVsFZkCK98vzcX2FXDIk2 Figure 16: SDP answer accepting the SDP offer for file transfer NOTE: The 'file-selector' attribute in the above figure is split in two lines for formatting purposes. Real implementations will encode it in a single line. F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP SEND request that contains the file. MSRP d93kswow SEND To-Path: msrp://alicepc.example.com:7654/jshA7we;tcp From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp Message-ID: 12339sdqwer Byte-Range: 1-2027/2027 Content-Type: message/cpim To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com> DateTime: 2006-05-15T15:02:31-03:00 Content-Disposition: render; filename="My cool photo.jpg"; creation-date="Mon, 15 May 2006 15:01:31 +0300"; modification-date="Mon, 15 May 2006 16:04:53 +0300"; read-date="Mon, 16 May 2006 09:12:27 +0300"; size=1931 Content-Type: image/jpeg ...binary JPEG image... -------d93kswow$ Figure 17: MSRP SEND request containing the actual file F5: Alice acknowledges the reception of the SEND request.
MSRP d93kswow 200 OK To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp From-Path: msrp://alicepc.example.com:7654/jshA7we;tcp Byte-Range: 1-2027/2027 -------d93kswow$ Figure 18: MSRP 200 OK response F6: Alice reuses the existing SDP media line inserting the 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 MSRP stream, but changes the MSRP session and the 'file-transfer-id' value according to this specification.
INVITE sip:bob@example.com SIP/2.0 To: Bob <sip:bob@example.com>;tag=1928323431 From: Alice <sip:alice@example.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 2 INVITE Max-Forwards: 70 Date: Sun, 21 May 2006 13:02:33 GMT Contact: <sip:alice@alicepc.example.com> Content-Type: multipart/related; type="application/sdp"; boundary="boundary71" Content-Length: [length of multipart] --boundary71 Content-Type: application/sdp Content-Length: [length of SDP] v=0 o=alice 2890844526 2890844527 IN IP4 alicepc.example.com s= c=IN IP4 alicepc.example.com t=0 0 m=message 7654 TCP/MSRP * i=This is my latest picture a=sendonly a=accept-types:message/cpim a=accept-wrapped-types:* a=path:msrp://alicepc.example.com:7654/iau39;tcp a=file-selector:name:"sunset.jpg" type:image/jpeg 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 a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO a=file-disposition:render a=file-date:creation:"Sun, 21 May 2006 13:02:15 +0300" a=file-icon:cid:id3@alicepc.example.com --boundary71 Content-Type: image/jpeg Content-Transfer-Encoding: binary Content-ID: <id3@alicepc.example.com> Content-Length: [length of image] Content-Disposition: icon [..small preview icon...] --boundary71-- Figure 19: Reuse of the SDP in a second file transfer
NOTE: The Content-Type header field and the 'file-selector'
attribute in the above figure are split in several lines for
formatting purposes. Real implementations will encode it in a
single line.
F7: Bob receives the re-INVITE request, inspects the SDP offer and
extracts the icon body, checks the creation date and the file size,
and decides to accept the file transfer. So Bob creates an SDP
answer where he reuses the same TCP port number, but changes his MSRP
session, according to the procedures of this specification.
v=0
o=bob 2890844656 2890855440 IN IP4 bobpc.example.com
s=
c=IN IP4 bobpc.example.com
t=0 0
m=message 8888 TCP/MSRP *
a=recvonly
a=accept-types:message/cpim
a=accept-wrapped-types:*
a=path:msrp://bobpc.example.com:8888/eh10dsk;tcp
a=file-selector:name:"sunset.jpg" type:image/jpeg
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
a=file-transfer-id:ZVE8MfI9mhAdZ8GyiNMzNN5dpqgzQlCO
a=file-disposition:render
Figure 20: SDP answer accepting the SDP offer for file transfer
NOTE: The 'file-selector' attribute in the above figure is split
in three lines for formatting purposes. Real implementations will
encode it in a single line.
F9: If a TCP connection towards Bob is already open, Alice reuses
that TCP connection to send an MSRP SEND request that contains the
file.
MSRP d95ksxox SEND To-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp From-Path: msrp://alicepc.example.com:7654/iau39;tcp Message-ID: 13449sdqwer Byte-Range: 1-2027/2027 Content-Type: message/cpim To: Bob <sip:bob@example.com> From: Alice <sip:alice@example.com> DateTime: 2006-05-21T13:02:15-03:00 Content-Disposition: render; filename="Sunset.jpg"; creation-date="Sun, 21 May 2006 13:02:15 -0300"; size=1931 Content-Type: image/jpeg ...binary JPEG image... -------d95ksxox+ Figure 21: MSRP SEND request containing the actual file F10: Bob acknowledges the reception of the SEND request. MSRP d95ksxox 200 OK To-Path: msrp://alicepc.example.com:7654/iau39;tcp From-Path: msrp://bobpc.example.com:8888/eh10dsk;tcp Byte-Range: 1-2027/2027 -------d95ksxox$ Figure 22: MSRP 200 OK response F11: Then Bob terminates the SIP session by sending a SIP BYE request. F12: Alice acknowledges the reception of the BYE request and sends a 200 (OK) response.9.3. Example of a Capability Indication
Alice sends an OPTIONS request to Bob (this request does not contain SDP). Bob answers with a 200 (OK) response that contain the SDP shown in Figure 24. The SDP indicates support for CPIM messages that can contain other MIME types. The maximum MSRP message size that the endpoint can receive is 20000 octets. The presence of the 'file- selector' attribute indicates support for the file transfer offer/ answer mechanism.
Alice's UAC Bob's UAS | | |(1) (SIP) OPTIONS | |----------------------->| |(2) (SIP) 200 OK | | with SDP | |<-----------------------| | | | | Figure 23: Flow diagram of a capability request v=0 o=bob 2890844656 2890855439 IN IP4 bobpc.example.com s=- c=IN IP4 bobpc.example.com t=0 0 m=message 0 TCP/MSRP * a=accept-types:message/cpim a=accept-wrapped-types:* a=max-size:20000 a=file-selector Figure 24: SDP of the 200 (OK) response to an OPTIONS request10. Security Considerations
The SDP attributes defined in this specification identify a file to 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 other endpoint. In the former case, an attacker modifying those SDP attributes could cheat the receiver making it think that the file to be transferred was a different one. In the latter case, the attacker could make the sender send a different file than the one requested by the receiver. Consequently, it is RECOMMENDED that integrity protection be applied to the SDP session descriptions carrying the attributes specified in this specification. Additionally, it is RECOMMENDED that senders verify the properties of the file against the selectors that describe it. The descriptions of the files being transferred between endpoints may reveal information the endpoints may consider confidential. Therefore, it is RECOMMENDED that SDP session descriptions carrying the attributes specified in this specification are encrypted. TLS and S/MIME are the natural choices to provide offer/answer exchanges with integrity protection and confidentiality.
When an SDP offer contains the description of a file to be sent or received, the SDP answerer MUST first authenticate the SDP offerer and then it MUST authorize the file transfer operation, typically according to a local policy. Typically, these functions are integrated in the high-level protocol that carries SDP (e.g., SIP), and in the file transfer protocol (e.g., MSRP). If SIP [RFC3261] and MSRP [RFC4975] are used, the standard mechanisms for user authentication and authorization are sufficient. It is possible that a malicious or misbehaving implementation tries to exhaust the resources of the remote endpoint, e.g., the internal memory or the file system, by sending very large files. To protect from this attack, an SDP answer SHOULD first verify the identity of the SDP offerer, and perhaps only accept file transfers from trusted sources. Mechanisms to verify the identity of the file sender depend on the high-level protocol that carries the SDP, for example, SIP [RFC3261] and MSRP [RFC4975]. It is also RECOMMENDED that implementations take measures to avoid attacks on resource exhaustion, for example, by limiting 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 number of simultaneous file transfers. 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. This is to prevent the existence of meaningful characters to the local operating system that could damage it. Once a file has been transferred, the file receiver must take care of it. Typically, file transfer is a commonly used mechanism for transmitting computer virus, spyware, and other types of malware. File receivers should apply all possible security technologies (e.g., anti-virus, anti-spyware) to mitigate the risk of damage at their host.11. IANA Considerations
IANA has registered a number of SDP attributes according to the following.11.1. Registration of New SDP Attributes
IANA has registered a number of media-level-only attributes in the Session Description Protocol Parameters registry [IANA]. The registration data, according to RFC 4566 [RFC4566], follows.
11.1.1. Registration of the file-selector Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Phone: +34 91 339 1000 Attribute name: file-selector Long-form attribute name: File Selector Type of attribute: media level only This attribute is subject to the charset attribute Description: This attribute unambiguously identifies a file by indicating a combination of the 4-tuple composed of the name, size, type, and hash of the file. Specification: RFC 554711.1.2. Registration of the file-transfer-id Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Phone: +34 91 339 1000 Attribute name: file-transfer-id Long-form attribute name: File Transfer Identifier Type of attribute: media level only This attribute is subject to the charset attribute Description: This attribute contains a unique identifier of the file transfer operation within the session. Specification: RFC 554711.1.3. Registration of the file-disposition Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Phone: +34 91 339 1000 Attribute name: file-disposition Long-form attribute name: File Disposition Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute provides a suggestion to the other
endpoint about the intended disposition of the file.
Specification: RFC 5547
11.1.4. Registration of the file-date Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-date
Long-form attribute name:
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: This attribute indicates the dates on which the file
was created, modified, or last read.
Specification: RFC 5547
11.1.5. Registration of the file-icon Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com>
Phone: +34 91 339 1000
Attribute name: file-icon
Long-form attribute name: File Icon
Type of attribute: media level only
This attribute is not subject to the charset attribute
Description: For image files, this attribute contains a pointer to a
body that includes a small preview icon representing the contents
of the file to be transferred.
Specification: RFC 5547
11.1.6. Registration of the file-range Attribute
Contact: Miguel Garcia <miguel.a.garcia@ericsson.com> Phone: +34 91 339 1000 Attribute name: file-range Long-form attribute name: File Range Type of attribute: media level only This attribute is not subject to the charset attribute Description: This attribute contains the range of transferred octets of the file. Specification: RFC 554712. Acknowledgments
The authors would like to thank Mats Stille, Nancy Greene, Adamu Haruna, and Arto Leppisaari for discussing initial concepts described in this memo. Thanks to Pekka Kuure for reviewing initial versions of this document and providing helpful comments. Joerg Ott, Jiwey Wang, Amitkumar Goel, Sudha Vs, Dan Wing, Juuso Lehtinen, Remi Denis- Courmont, Colin Perkins, Sudhakar An, Peter Saint-Andre, Jonathan Rosenberg, Eric Rescorla, Vikram Chhibber, Ben Campbell, Richard Barnes, and Chris Newman discussed and provided comments and improvements to this document.13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2183] Troost, R., Dorner, S., and K. Moore, "Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field", RFC 2183, August 1997.
[RFC2387] Levinson, E., "The MIME Multipart/Related Content-type", RFC 2387, August 1998. [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [RFC3174] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001. [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004. [RFC3862] Klyne, G. and D. Atkins, "Common Presence and Instant Messaging (CPIM): Message Format", RFC 3862, August 2004. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. [RFC4975] Campbell, B., Mahy, R., and C. Jennings, "The Message Session Relay Protocol (MSRP)", RFC 4975, September 2007. [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008.13.2. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", RFC 4028, April 2005.
[RFC4483] Burger, E., "A Mechanism for Content Indirection in Session Initiation Protocol (SIP) Messages", RFC 4483, May 2006. [RFC4976] Jennings, C., Mahy, R., and A. Roach, "Relay Extensions for the Message Sessions Relay Protocol (MSRP)", RFC 4976, September 2007. [IANA] IANA, "Internet Assigned Numbers Authority", <http://www.iana.org>. [FLUTE-REV] Luby, M., Lehtonen, R., Roca, V., and T. Paila, "FLUTE - File Delivery over Unidirectional Transport", Work in Progress, September 2008.
Appendix A. Alternatives Considered
The requirements are related to the description and negotiation of the session, not to the actual file transfer mechanism. Thus, it is natural that in order to meet them it is enough to define attribute extensions and usage conventions to SDP, while MSRP itself needs no extensions and can be used as it is. This is effectively the approach taken in this specification. Another goal has been to specify the SDP extensions in such a way that a regular MSRP endpoint that does not support them could still in some cases act as an endpoint in a file transfer session, albeit with a somewhat reduced functionality. In some ways, the aim of this specification is similar to the aim of content indirection mechanism in the Session Initiation Protocol (SIP) [RFC4483]. Both mechanisms allow a user agent to decide whether or not to download a file based on information about the file. However, there are some differences. With content indirection, it is not possible for the other endpoint to explicitly accept or reject the file transfer. Also, it is not possible for an endpoint to request a file from another endpoint. Furthermore, content indirection is not tied to the context of a media session, which is sometimes a desirable property. Finally, content indirection typically requires some server infrastructure, which may not always be available. It is possible to use content indirection directly between the endpoints too, but in that case there is no definition for how it works for endpoints behind NATs. The level of requirements in implementations decides which solution meets the requirements. Based on the argumentation above, this document defines the SDP attribute extensions and usage conventions needed for meeting the requirements on file transfer services with the SDP offer/answer model, using MSRP as the transfer protocol within the session. In principle, it is possible to use the SDP extensions defined here and replace MSRP with any other similar protocol that can carry MIME objects. This kind of specification can be written as a separate document if the need arises. Essentially, such a protocol should be able to be negotiated on an SDP offer/answer exchange (RFC 3264 [RFC3264]), be able to describe the file to be transferred in SDP offer/answer exchange, be able to carry MIME objects between two endpoints, and use a reliable transport protocol (e.g., TCP). This specification defines a set of SDP attributes that describe a file to be transferred between two endpoints. The information needed to describe a file could be potentially encoded in a few different
ways. The MMUSIC working group considered a few alternative approaches before deciding to use the encoding described in Section 6. In particular, the working group looked at the MIME 'external-body' type and the use of a single SDP attribute or parameter. A MIME 'external-body' could potentially be used to describe the file to be transferred. In fact, many of the SDP parameters this specification defines are also supported by 'external-body' body parts. The MMUSIC working group decided not to use 'external-body' body parts because a number of existing offer/answer implementations do not support multipart bodies. The information carried in the SDP attributes defined in Section 6 could potentially be encoded in a single SDP attribute. The MMUSIC working group decided not to follow this approach because it is expected that implementations support only a subset of the parameters defined in Section 6. Those implementations will be able to use regular SDP rules in order to ignore non-supported SDP parameters. If all the information was encoded in a single SDP attribute, those rules, which relate to backwards compatibility, would need to be redefined specifically for that parameter.
Authors' Addresses
Miguel A. Garcia-Martin Ericsson Calle Via de los Poblados 13 Madrid, ES 28033 Spain EMail: miguel.a.garcia@ericsson.com Markus Isomaki Nokia Keilalahdentie 2-4 Espoo 02150 Finland EMail: markus.isomaki@nokia.com Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Salvatore Loreto Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Salvatore.Loreto@ericsson.com Paul H. Kyzivat Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: pkyzivat@cisco.com