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.
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.
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 5547
11.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 5547
11.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 5547
12. 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
