Subject: [MMUSIC] Re: File tranfer in SIP

From: Joerg Ott <[email-masked]>
Date: Fri, 07 Apr 2006 15:41:18 +0300

Hi Gonzalo,

moving this to MMUSIC:

> I agree that we want to provide the same information as existing file 
> description mechanisms provide. In particular, we have looked into MIME. 
> We will make sure that we go thru MIME again to see if we have forgotten 
> something (e.g., creation of the file timestamp).

Sounds good.

> I have looked into FLUTE, and it provides the same information as we 
> provide in the draft. From:
> http://www.ietf.org/internet-drafts/draft-ietf-rmt-flute-revised-01.txt
> 
>    -  Name, Identification and Location of file (specified by the URI)
>    -  MIME media type of file
>    -  Size of file
>    -  Encoding of file
>    -  Message digest of file
> 
> In any case, this information needs to be encoded in the SDP way, and 
> therefore, we should use 'a' lines for that.

I am still missing a last modification timestamp here.  Regarding the
encoding, I suppose we will have to worry about how to put this into
SDP.  This brings up -- again -- the discussion of whether to include
some "blob" of, from an SDP perspective, opaque metadata (e.g., b64
encoded zip version of the FLUTE FDT, just to give some weird example)
or whether to make these attributes explicit.

If we make the attributes explicit, this is essentially a more general
aspect of describing the purpuse of a media stream and would not be
restricted to file transfer.  We have some informal hints for audio
and video already and this appears conceptually similar in that it
identifies the purpose and helps the answerer to decide whether to
accept it or not.

Keeping this in mind, it would be extremely useful, not to invent
independent sets of attributes for file transfer, MSRP sessions,
audio, video, whiteboard, and so so.

I clearly _do_not_ want to end up in an XCON-style discussion about
metadata and the like, but it may be worthwhile given some
consideration to future evolution of this stuff and compatibility
with existing attributes.

>> I am also concerned about motivating the use of inline images for
>> icons.  I can hardly see why you would need an icon to decide
>> whether or not to accept a file transfer.
> 
> A lot of commercial IM systems support it, and users find it very 
> useful. SIP-based systems need to be able to provide a similar user 
> experience if we do not want people to start doing things is proprietary 
> ways.

It's your call in the end of the day.  Often, icons are created based
upon the filename extension -- and I suspect that the filename is going
to be much more relevant that the icon in deciding whether or not to
accept it.  Icons are not worth much and only increase volume.  But if
we decide that it is useful:

You must decide how much you worry about the SIP signaling architecture.
Given that the INFO method is "damned" (which I fully support), I do not
believe that turning parts of SDP into a transport is a particularly
smart idea.  It clearly does not ad efficiency.  If you follow
traditional SIPPING thinking, you will need to separate the desired
effect from the mechanism to achieve it.  There may be better ways.

I am simply worried to open a door that we better leave closed.
Would you want to limit the media type or the size of an icon?
If so, what would be the right value?  Would you negotiate it and
come up with an "embedded contents too large" status code?

Also, remember, that any SDP contents potentially wants to be signed.

>> Performing file selection based upon only the hash may be nice for
>> the receiver but it may be counter-intuitive and difficult to implement
>> for the sender since it would require the sender to keep a hash of
>> all its local files which if there are so many that on-the-fly
>> calculation may not be a good idea.
> 
> The user selects the file to send, the application hashes it on the fly, 
> and sends the hash to the receiver. I just calculated the MD5 and SHA1 
> hashes of a big file (165 MB) on a non-very-powerful laptop, and it took 
> 8 and 10 seconds respectively. If you send pictures, which are much 
> smaller, the hash calculation would be very fast.

I think I got somewhat confused that I constructed a close to impossible
scenario.  For the sender it is indeed trivial if the sending user
selects the file.  Of course, the filename should be included because
otherwise the receiver does not easily find out whether or not it has
a copy of the file already.  If the receiving users wants to initiate
a file transfer, of course, it does not have a checksum at hand to
include.

>> The draft refers to MSRP for connection setup and teardown but the
>> examples only show trivia.  The most interesting thing would be
>> to show how sending, say, 4 files in each direction works and
>> how the SDP descriptions grow (and if there will be a chance to
>> shrink them again).
> 
> We will include a note pointing out that 'm' lines can be reused after a 
> media stream is terminated. That is regular SDP behavior.

True.  But an example would still be nice (you know, most people code
by example rather than by spec and we don't want them to screw up :-)
After all, I would be surprised that re-INVITEs or UPDATEs with media
stream addition, removal, addition, etc. have been common practice so
far.  But I may be wrong.

>>  Also, how do simultaneous initiations in both
>> directions work (concerning counting the many m= lines)?
> 
> I do not see any issue with having simultaneous media streams. It is 
> again regular SDP behavior.

Well, I assume that if I send you a second offer within a session
and you also send me one at the same time, we will have to do some
conflict resolution since both of us will use the (n+1)st m-line
for potentially different purposes.  Since this has probably not
received much implementation attention in the past (and happened
rather rarely in practice), it have not been noticed.  But it may
be specified and just did not find this upon a quick search.

Cheers,
Joerg

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Apr 2006 10:39:50 +0300

[removing recipients so that the filters do not mark it as moderated]

Hi Joerg,

 > moving this to MMUSIC:

perfect.

 > Regarding the

I would go for explicit SDP attributed (i.e., 'a' lines).

 > audio, video, whiteboard, and so so.

The attributes defined in the draft describe a file to be transfered. If 
somebody comes up with different attributes to describe the contents of 
the audio being sent over a media stream, those will not have any 
interaction with our attributes. Different types of media streams need 
different attributes to describe their contents.

 > with existing attributes.

We have not found any interactions with existing attributes.

 > we decide that it is useful:

If I want to send you a picture called PCJ00234.JPG, you will not know 
whether or not you want to receive it. However, if you see a small icon 
of the picture, you will be in a better position to make that decision. 
Many people find icons very useful, in many cases much more than the 
file name.

 > come up with an "embedded contents too large" status code?

We have created small icons with a resolution of 32 x 24 pixels using 4 
bits for depth color whose size was around 500 bytes. In any case, we 
can add text stating the problems of sending too large SIP messages.

 > a file transfer, of course, it does not have a checksum at hand to

If some scenarios (e.g., file sharing) you will have the hash of the 
file you want, but you will not have the file yet.

 > be specified and just did not find this upon a quick search.

That conflict resolution is already defined at the offer/answer level. 
Of course, we do not intend to redefine that behavior.

Thanks,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Apr 2006 11:13:04 +0300

Joerg,

regarding the issue about transferring icons in the body of a SIP 
message, note that this was already defined by RFC 3261.

Section 20.11 of RFC 3261 says:

   "The disposition type "icon" indicates that the body part contains an
    image suitable as an iconic representation of the caller or callee
    that could be rendered informationally by a user agent when a message
    has been received, or persistently while a dialog takes place."

You can find the registration of the 'icon' disposition type at:
http://www.iana.org/assignments/mail-cont-disp

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 Apr 2006 10:37:09 +0300

Hi Joerg,

perfect.

>> experience if we do not want people to start doing things is 
>> proprietary ways.
> 
> It's you 28 Apr 2006 09:37:14 +0200
Date: Fri, 28 Apr 2006 10:37:09 +0300
From: Gonzalo Camarillo <[email-masked]>
To: Joerg Ott <[email-masked]>
Cc: Cullen Jennings <[email-masked]>, Rohan Mahy <[email-masked]>,
	[email-masked], Jon Peterson <[email-masked]>,
	Allison Mankin <[email-masked]>,
	Miguel Garcia <[email-masked]>, Joerg Ott <[email-masked]>,
	Markus Isomaki <[email-masked]>,
	"Salvatore Loreto \(SA/ERI\)" <[email-masked]>,
	Colin Perkins <[email-masked]>
Subject: [MMUSIC] Re: File tranfer in SIP

Hi Joerg,

perfect.

>> experience if we do not want people to start doing things is 
>> proprietary ways.
> 

Thanks,

Gonzalo

r call in the end of the day.  Often, icons are created based

Thanks,

Gonzalo