One document matched: draft-garcia-sipping-file-transfer-mech-00.txt
SIPPING Working Group M. Garcia-Martin
Internet-Draft M. Isomaki
Expires: August 27, 2006 Nokia
G. Camarillo
S. Loreto
Ericsson
February 23, 2006
A Mechanism to Enable File Transfer with the Session Initiation Protocol
(SIP)
draft-garcia-sipping-file-transfer-mech-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides a mechanism that enables the transfer of one
or more files between two User Agents (UAs). SIP and the Session
Description Protocol (SDP) offer/answer model are used to signal the
establishment of a session. The Message Session Relay Protocol
Garcia-Martin, et al. Expires August 27, 2006 [Page 1]
Internet-Draft SIP File Transfer February 2006
(MSRP) is used to actually transfer the files between the two
endpoints.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Overview of Operation . . . . . . . . . . . . . . . . . . . . 5
5. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 5
6. Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 8
6.1. File selector . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Offerer's Behavior . . . . . . . . . . . . . . . . . . . . 9
6.2.1. The Offerer is a File Sender . . . . . . . . . . . . . 9
6.2.2. The Offerer is a File Receiver . . . . . . . . . . . . 9
6.2.3. SDP Offer for Several Files . . . . . . . . . . . . . 10
6.3. Answerer's Behavior . . . . . . . . . . . . . . . . . . . 10
6.3.1. The Answerer is a File Receiver . . . . . . . . . . . 10
6.3.2. The Answerer is a File Sender . . . . . . . . . . . . 10
6.4. MSRP Usage . . . . . . . . . . . . . . . . . . . . . . . . 11
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. UAC sends a file to the UAS . . . . . . . . . . . . . . . 11
7.2. UAC requests a file from the UAS . . . . . . . . . . . . . 15
8. Security Considerations . . . . . . . . . . . . . . . . . . . 17
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
11.2. Informational References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 19
Garcia-Martin, et al. Expires August 27, 2006 [Page 2]
Internet-Draft SIP File Transfer February 2006
1. Introduction
Session Initiation Protocol (SIP) [5] provides generic functions for
setting up and managing multimedia sessions between users. These
sessions often contain real-time media streams such as voice and
video, but are not limited to that. Basically any media component
type can be supported, as long as there is a specification how to
negotiate it within the Session Description Protocol (SDP) [9] offer/
answer exchange [6].
The Message Session Relay Protocol (MSRP) [10] is a protocol for
transmitting instant messages (IM) in the context of a session. The
protocol specification includes a description how to use it with SIP
and SDP. In addition to plain text messages, MSRP is able to carry
arbitrary (binary) Multipurpose Internet Mail Extensions (MIME) [2]
compliant content, such as images or video clips.
There are many cases where users involved in a SIP-based multimedia
session would like to exchange files within the context of that
session. With MSRP it is possible to embed files as MIME objects
inside the stream of instant messages. MSRP also has other features
that are useful for file transfer. Message chunking enables the
sharing of the same transport connection between the transfer of a
large file and interactive IM exchange without blocking the IM. MSRP
relays [14] provide a mechanism for Network Address Translator (NAT)
traversal. Finally, Secure MIME (S/MIME) [7] can be used for
ensuring the integrity and confidentiality of the transfer between
the peers.
However, the baseline MSRP does not readily meet all the requirements
expressed in [13] for file transfer services within SIP-based
sessions. There are three main missing features:
o The recipient MUST be able to distinguish "file transfer" from
"file attached to IM", allowing the recipient to treat the cases
differently.
o It MUST be possible for the sender to send the request for a file
transfer. It MUST be possible for the recipient to accept or
decline it. The actual transfer MUST take place only after
acceptance by the recipient.
o It MUST be possible for the sender to pass some meta information
on the file before the actual transfer. This MUST include at
least content type and size, and a short (human readable)
description.
All these 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
Garcia-Martin, et al. Expires August 27, 2006 [Page 3]
Internet-Draft SIP File Transfer February 2006
attribute extensions and usage conventions to SDP, while MSRP itself
needs no extensions and can be used as it is. Furthermore, all the
SDP extensions can be specified in such a way that and end-point who
does not support them but only implements what basic MSRP requires
can still act as a Callee in a file transfer session, albeit with a
somewhat reduced functionality.
This document defines the SDP attribute extensions and usage
conventions needed for meeting the requirements on file transfer
services within SIP sessions 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.
The mechanism described in this document allows either to send or
receive files to or from a remote user agent.
Section 3 defines a few terms used in this document. Section 4
provides the overview of operation. The detailed syntax and
semantics of the new SDP attributes and conventions on how the
existing ones are used is defined in Section 5. Section 6 describes
the protocol operation involving SIP, SDP and MSRP. Some examples
are given in Section 7.
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in BCP 14, RFC 2119 [1] and indicate requirement levels for
compliant implementations.
3. Definitions
For the purpose of this document, the following definitions specified
in RFC 3264 [6] apply:
o Answerer
o Offerer
Additionally, we define the following terms:
Garcia-Martin, et al. Expires August 27, 2006 [Page 4]
Internet-Draft SIP File Transfer February 2006
File sender: The endpoint that is willing to transmit a file to the
file receiver.
File receiver: The endpoint that is willing to receive a file from
the file sender.
File selector: The intersection of several SDP attributes that
results in the selection of zero or more files. This is described
in more detail in Section 6.1.
4. Overview of Operation
The file transfer service specified in this document uses the SDP
offer/answer [6] to establish the MSRP-based media streams that will
transfer the files. Each "m=" line describes an MSRP-based media
stream used to transfer a single file. That is, the transfer of
multiple files requires multiple "m=" lines.
This document defines a set of SDP attributes and some conventions
that allow a user agent to describe a file to be sent to or received
from a remote user agent. This way, user agents can decide whether
or not to accept a given file transfer based on the file's name,
size, description, hash, icon (e.g., if the file is a picture), etc.
Effectively, the aim of this mechanism is similar to the aim of the
content indirection mechanism in SIP [15]. Both mechanisms allow a
user agent to decide whether or not to download a file based on
information about the file. However, while the content indirection
mechanism could be used in SIP MESSAGE [12] requests to transfer
files (the actual file transfer mechanism would be the Hypertext
Transfer Protocol (HTTP) [11]), it cannot be used within a session
established by an offer/answer exchange where the file transfer
protocol is MSRP [10].
5. Extensions to SDP
We define a number of attributes in SDP [9] that provide the required
information to describe the transfer of a file with MSRP. The
following is the formal ABNF syntax [8] of these new attributes. It
is built above the SDP [9] grammar, RFC 2045 [2], and RFC 2392 [3].
Garcia-Martin, et al. Expires August 27, 2006 [Page 5]
Internet-Draft SIP File Transfer February 2006
attribute = filename-attr / filetype-attr /
disposition-attr / filesize-attr /
icon-attr / hash-attr
;attribute is defined in sdp-new
filename-attr = "filename:" filename-string
filename-string = byte-string ;byte-string defined in sdp-new
filetype-attr = "filetype:" type "/" subtype *(";" parameter)
; parameter defined in RFC 2045
type = token
subtype = token
disposition-attr = "disposition:" disposition-value
disposition-value = token
filesize-attr = "filesize:" filesize-value
filesize-value = integer ;integer defined in sdp-new
icon-attr = "icon:" icon-value
icon-value = cid-url ;cid-url defined in RFC 2392
hash-attr = "hash:" hash-algorithm WSP hash-value
hash-algorithm = token ;see IANA Hash Algorithm
;section in the IPSEC
;registry
hash-value = byte-string ;byte-string defined in sdp-new
Figure 1: Syntax of the SDP extension
The 'filename' attribute contains the filename of the content, and
its value is a byte string (specified in SDP [9]).
The 'filetype' attribute contains the MIME media type of the content.
In general, anything that can be expressed in a Content-Type header
field (see RFC 2045 [2]) can also be expressed with the 'filetype'
attribute. Possible MIME Media Type values are the ones listed in
the IANA registry for MIME Media Types. Zero or more parameters can
follow. The syntax of 'parameter' is specified in RFC 2045 [2].
The 'disposition' attribute provides a suggestion to the peer of the
intended disposition of the file. Possible values are the one listed
in the IANA registry for Mail Content Disposition Values, although
most likely only the "inline" and "attachment" values are significant
for file transfer applications.
The 'filesize' attribute indicates the size of the file in octets.
Garcia-Martin, et al. Expires August 27, 2006 [Page 6]
Internet-Draft SIP File Transfer February 2006
The 'icon' attribute can be useful with certain file types such as
images. It allows the sender to include a pointer to a body that
includes an icon representing the contents of the file to be
transferred. This allows the sender to include the icon as another
body accompanying the SDP, and to the recipient to get the icon of
the file that can potentially be transferred. It is recommended to
keep icons restricted to the minimum number of bytes that provide
significance. The 'icon' attribute contains a Content-ID URL, which
is specified in RFC 2392 [3].
The 'hash' attribute provides a hash of the file to be transferred.
The purpose is two-fold: On one side, it allows the file receiver to
identify a file by its hash rather than by its file name, providing
that the file receiver has learn the hash of the file by some out-of-
band mechanism. On the other side, it allows the file sender to
provide the hash of the file to be transmitted, which can be used by
the file receiver for verification of its contents or to avoid the
unnecessary transmission of a file that already exists. The 'hash'
attribute includes the type of hash and its value. Possible types of
hash are the ones defined in the Hash Algorithm Section of the IANA
registry of the IPSec registry. Implementations according to this
specification MUST implement the US Secure Hash Algorithm 1 (SHA1)
[4] and MAY implement other hashing algorithms. The creator of the
SDP MAY also add more than one 'hash' attribute (presumably with
different types of hash) to the same file. The value is the byte
string resulting of applying the hash algorithm to the content of the
file.
The following is an example of an SDP body that contains the
extensions defined in this memo:
v=0
o=alice 2890844526 2890844526 IN IP4 host.atlanta.example.com
s=
c=IN IP4 host.atlanta.example.com
t=0 0
m=message 7654 TCP/MSRP *
i=This is my latest picture
a=sendonly
a=accept-types:*
a=path:msrp://atlanta.example.com:7654/jshA7we;tcp
a=filename:My cool picture.jpg
a=filetype:image/jpeg
a=disposition:inline
a=filesize:32349
a=icon:cid:id2@alicepc.example.com
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
Garcia-Martin, et al. Expires August 27, 2006 [Page 7]
Internet-Draft SIP File Transfer February 2006
Figure 2: Example of SDP describing a file transfer
6. Protocol Operation
This Section discusses how to use the parameters defined in Section 5
in the context of an offer/answer [6] exchange. Additionally, this
section also discusses the behavior of the endpoints using MSRP.
Usually the file transfer session is initiated when the offerer sends
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. 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. The answerer is the file sender.
In this case the SDP offer contains a 'recvonly' attribute, and
accordingly the SDP answer contains a 'sendonly' attribute.
6.1. File selector
The protocol specified in this document requires a mechanism to
identify files in a remote host. We introduce the concept of a file
selector, which is the intersection of the 'hash', 'filename',
'filesize', and 'filetype' attributes.
A file selector can point to zero, one, or more files, depending on
the presence of the mentioned attributes in the SDP and depending on
the available files in a host. The file transfer mechanism that we
specify in this document requires that a file selector results in a
single file selection. Typically, if the 'hash' attribute is known,
the 'hash' attribute is enough to produce a file selector that points
to zero or one file. However, not always the file selector is known
or available. Sometimes only the 'filename', 'filesize', or
'filetype' attributes are known, so the file selector may result in
more than one file, an undesired case. The opposite is also true, if
the file selector contains a 'hash' and a 'filename' attributes, but
the user at the remote host has renamed the file, although there is a
file with the indicated hash, the file name does not match, thus, the
file selector will result in the selection of zero files.
Garcia-Martin, et al. Expires August 27, 2006 [Page 8]
Internet-Draft SIP File Transfer February 2006
6.2. Offerer's Behavior
An offerer that wishes to send or receive one or more files to or
from an answerer MUST build an SDP [9] description of a session
containing one or more "m=" lines, each one describing an MSRP
session (and thus, one file transfer operation), according to the
MSRP [10] procedures. All the media line attributes specified and
required by MSRP [10] (e.g., "a=path", "a=accept-types", etc.) MUST
be included as well. For each file to be transferred there MUST be a
separate "m=" line.
6.2.1. The Offerer is a File Sender
If the offerer is a file sender, it MUST add a session or media
'sendonly' attribute to the SDP offer. Additionally, the offerer
SHOULD also add a 'filetype', 'filesize', and 'hash' attributes
indicating the type, size, and hash of the file, respectively.
These attributes might not be known when the offerer creates the
SDP offer, for example, because the host is still processing the
file.
The 'hash' attribute contains valuable information to the file
receiver to identify whether the file is already available and
need not be transmitted.
The offerer MAY also add a 'filename', 'icon', and 'disposition'
attributes further describing the file to be transferred. The
'disposition' attribute provides a presentation suggestion, (for
example: the file sender would like the file receiver to render file
"inline", or save it as an "attachment"). Additionally, the offerer
MAY provide a human readable description of the file using an "i="
media line.
6.2.2. The Offerer is a File Receiver
If the offerer is a file receiver, it MUST create an SDP offer that
contains a session or media 'recvonly' attribute. Then the offerer
SHOULD add at least one of the attributes that constitute the file
selector ('hash', 'filename', 'filesize', or 'filetype'). 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' attribute.
However, specially 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.
Garcia-Martin, et al. Expires August 27, 2006 [Page 9]
Internet-Draft SIP File Transfer February 2006
6.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. This way, the answerer can reject
individual files by setting the port number of their associated "m="
lines to zero, as per regular SDP [9] procedures.
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 [10].
6.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 [9] procedures. If the answerer decides to
accept the file, it proceeds as per regular MSRP [10] and SDP [9]
procedures.
6.3.1. The Answerer is a File Receiver
If the answerer is a file receiver and decides to accept the file
transfer it MUST create an SDP answer (per RFC 3264 [6]) containing a
'recvonly' attribute. If the offer contains 'filetype', 'filesize',
or 'filename' attributes, the answerer MUST copy them into the
answer. This informs the offerer that the answerer supports this
specification. If the answerer is a file receiver, it MUST NOT
include 'icon', 'hash', or 'disposition' attributes in the SDP
answer.
If the received offer contains a 'hash' attribute, the answerer can
use it 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 the
file transfer is accepted or not in case of a duplicated file.
6.3.2. The Answerer is a File Sender
If the answerer is a file sender, it MUST first inspect the received
SDP offer and compute the file selector. The file selector is the
result of a intersection of the 'filetype', 'filesize', 'filename',
and 'hash' attributes (if they are present) that modify the same "m="
line in the SDP offer (i.e., the four mentioned attributes are
located under the same "m=" line in SDP). The file selector
identifies zero or more 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 if
Garcia-Martin, et al. Expires August 27, 2006 [Page 10]
Internet-Draft SIP File Transfer February 2006
it is the only stream in the SDP offer, then if SHOULD reject the SDP
as per procedures in RFC 3264 [6]).
If the file selector points to a single file and the answerer decides
to accept the file transfer, the answerer MUST create an SDP answer
(per RFC 3264 [6]) that contains a 'sendonly' attribute. The
answerer SHOULD add a 'hash' attribute containing the hash of the
file to be sent and MAY include 'filename', 'filetype', 'filesize',
'icon', or 'disposition' attributes to further describe the file.
Last, if the file selector points to multiple files, 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.
6.4. MSRP Usage
The file transfer service specified in this document uses "m=" lines
to describe the unidirectional transfer of a file. Consequently,
each MSRP session established following the procedures in Section 6.2
and Section 6.3 is only used to transfer a single file. So, senders
MUST only use a given 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.
Once the file transfer is completed, the file sender SHOULD close the
MSRP session, and MUST behave according to the MSRP [10] procedures
with respect closing MSRP sessions.
7. Examples
7.1. UAC sends a file to the UAS
This section shows an example flow for a file transfer scenario. The
example assumes that SIP is used to transport the SDP exchange,
although the SIP details are briefly shown in the sake of brevity.
Alice, the SDP offerer, wishes to send an image file to Bob (the
answerer). Alice's UAC creates a unidirectional SDP offer that
contains the description of the file that she wants to send to Bob.
The description also includes an icon representing the contents of
the file to be transferred. The sequence flow is shown in Figure 3.
Garcia-Martin, et al. Expires August 27, 2006 [Page 11]
Internet-Draft SIP File Transfer February 2006
Alice's UAC Bob's UAS
| |
|(1) (SIP) INVITE |
|----------------------->|
|(2) (SIP) 200 OK |
|<-----------------------|
|(3) (SIP) ACK |
|----------------------->|
| |
|(4) (MSRP) SEND (chunk) |
|----------------------->|
|(5) (MSRP) 200 OK |
|<-----------------------|
|(6) (MSRP) SEND (chunk) |
|----------------------->|
|(7) (MSRP) 200 OK |
|<-----------------------|
| |
|(8) (SIP) BYE |
|----------------------->|
|(9) (SIP) 200 OK |
|<-----------------------|
| |
| |
Figure 3: Flow diagram of a UAC sending a file to a UAS
F1: Alice constructs an SDP description of the file to be sent and
attaches it to a SIP INVITE request addressed to Bob.
Garcia-Martin, et al. Expires August 27, 2006 [Page 12]
Internet-Draft SIP File Transfer February 2006
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: Fri, 17 Feb 2006 13:02:03 GMT
Contact: <sip:alice@alicepc.example.com>
Content-Type: multipart/mixed; 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:*
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=filename:My cool picture.jpg
a=filetype:image/jpeg
a=disposition:inline
a=filesize:4096
a=icon:cid:id2@alicepc.example.com
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
--boundary71
Content-Type: image/jpeg
Content-Transfer-Encoding: binary
Content-ID: <id2@alicepc.example.com>
Content-Length: [length of image]
...binary JPEG image...
--boundary71
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 file size and decides to accept
the file transfer. So Bob creates the following SDP answer:
Garcia-Martin, et al. Expires August 27, 2006 [Page 13]
Internet-Draft SIP File Transfer February 2006
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:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=filename:My cool picture.jpg
a=filetype:image/jpeg
a=filesize:4096
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:7777/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2048/4096
Content-Type: image/jpeg
... first chunk of the JPEG image ...
-------d93kswow+
F5: Bob acknowledges the reception of the first chunk.
MSRP d93kswow 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 1-2048/4096
-------d93kswow$
F6: Alice sends the second and last chunk.
MSRP op2nc9a SEND
To-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
From-Path: msrp://alicepc.example.com:7777/iau39;tcp
Message-ID: 12339sdqwer
Byte-Range: 2049-4096/4096
Content-Type: image/jpeg
... second (and last) chunk of the JPEG image ...
-------op2nc9a$
F5: Bob acknowledges the reception of the second chunk.
Garcia-Martin, et al. Expires August 27, 2006 [Page 14]
Internet-Draft SIP File Transfer February 2006
MSRP op2nc9a 200 OK
To-Path: msrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Byte-Range: 2049-4096/4096
-------op2nc9a$
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.
7.2. UAC requests a file from the UAS
In this example Alice, the SDP offerer, 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 attribute 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
transmission and sends the file to Alice. Figure 10 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) BYE |
|<-----------------------|
|(7) (SIP) 200 OK |
|----------------------->|
| |
| |
Figure 10: Flow diagram of a UAC requesting a file from a UAS
F1: Alice constructs n SDP description of the file she wants to
receive and attaches the SDP offer to a SIP INVITE request addressed
to Bob.
Garcia-Martin, et al. Expires August 27, 2006 [Page 15]
Internet-Draft SIP File Transfer February 2006
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: Fri, 17 Feb 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:image/jpeg
a=path:msrp://alicepc.example.com:7654/jshA7we;tcp
a=hash:SHA 72245fe8653ddaf371362f86d471913ee4a2ce2e
From now on we omit the SIP details for the sake of brevity.
F2: Bob receives the INVITE request, inspect 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 transmission and creates
an SDP answer as follows:
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=sendonly
a=accept-types:*
a=path:msrp://bobpc.example.com:8888/9di4ea;tcp
a=filename:My cool photo.jpg
a=filetype:image/jpeg
a=filesize:2027
F4: Alice opens a TCP connection to Bob. Bob then creates an MSRP
SEND request that contains the file.
Garcia-Martin, et al. Expires August 27, 2006 [Page 16]
Internet-Draft SIP File Transfer February 2006
MSRP d93kswow SEND
To-Path: msrp://alicepc.example.com:7777/iau39;tcp
From-Path: msrp://bobpc.example.com:8888/9di4ea;tcp
Message-ID: 12339sdqwer
Byte-Range: 1-2027/2027
Content-Type: image/jpeg
...binary JPEG image...
-------d93kswow$
F6: 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:7777/iau39;tcp
Byte-Range: 1-2027/2027
-------d93kswow$
F6: Then Bob terminates the SIP session by sending a SIP BYE request.
F7: Alice acknowledges the reception of the BYE request and sends a
200 (OK) response.
8. Security Considerations
TBD
9. IANA Considerations
TBD
10. Acknowledgements
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 this document and providing helpful comments.
11. References
11.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Garcia-Martin, et al. Expires August 27, 2006 [Page 17]
Internet-Draft SIP File Transfer February 2006
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[3] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[4] Eastlake, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)",
RFC 3174, September 2001.
[5] 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.
[6] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[7] Ramsdell, B., "Secure/Multipurpose Internet Mail Extensions
(S/MIME) Version 3.1 Message Specification", RFC 3851,
July 2004.
[8] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[9] Handley, M., "SDP: Session Description Protocol",
draft-ietf-mmusic-sdp-new-25 (work in progress), July 2005.
[10] Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-13 (work in progress),
December 2005.
11.2. Informational References
[11] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[12] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
D. Gurle, "Session Initiation Protocol (SIP) Extension for
Instant Messaging", RFC 3428, December 2002.
[13] Isomaki, M., "Requirements and Possible Mechanisms for File
Transfer Services Within the Context of SIP Based
Communication", draft-isomaki-sipping-file-transfer-00 (work in
progress), October 2005.
[14] Jennings, C., "Relay Extensions for the Message Sessions Relay
Protocol (MSRP)", draft-ietf-simple-msrp-relays-06 (work in
Garcia-Martin, et al. Expires August 27, 2006 [Page 18]
Internet-Draft SIP File Transfer February 2006
progress), December 2005.
[15] Burger, E., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-05 (work in progress),
October 2004.
Authors' Addresses
Miguel A. Garcia-Martin
Nokia
P.O.Box 407
NOKIA GROUP, FIN 00045
Finland
Email: miguel.an.garcia@nokia.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
Full Copyright Statement
Garcia-Martin, et al. Expires August 27, 2006 [Page 19]
Internet-Draft SIP File Transfer February 2006
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Garcia-Martin, et al. Expires August 27, 2006 [Page 20]
| PAFTECH AB 2003-2026 | 2026-04-23 11:46:37 |