Subject: [MMUSIC] File-transfer issue 32: Re-send of the same file, vs. re-send of SDP only

From: Miguel Garcia <[email-masked]>
Date: Mon, 21 May 2007 16:37:10 +0300

Paul Kyzivat wrote
 > Section 8.4.  Re-usage of Existing m= Lines in SDP
 >
 >    The SDP Offer/Answer Model [7] provides rules that allow SDP offerers
 >    and answerers to modify an existing media line, i.e., re-use an
 >    existing media line with different attributes.  The same is also
 >    possible when SDP signals a file transfer operation according to the
 >    rules of this memo.  Therefore, the procedures defined in RFC 3264
 >    [7], in particular those defined in Section 8.3, MUST apply for file
 >    transfer operations.
 >
 > What does this mean? In other usage, a reinvite will cause another o/a
 > exchange. In some cases the SDP is unchanged in this o/a and the result
 > is that things remain as they are.
 >
 > When using the procedures of this draft, if a new o/a exchange is made
 > where there are no changes in the SDP, does it initiate a new transfer
 > of the file that was previously exchanged? Or does it do nothing?
 >
 > There will be cases following a file transfer when there is need to do
 > another o/a without repeating the transfer. And there may also be cases
 > when there is an explicit desire to repeat the transmission. (Maybe via
 > other means it is known that the file has changed.)
 >
 > Either the port must be set to zero in the subsequent o/a if
 > retransmission is not desired, or else something must be changed (e.g.
 > the msrp url) if retransmission is desired.

I think this is a good point. There are cases when the endpoint wants
to repeat the SDP, for example due to session timer, but does not want
to repeat the file transfer. This implies a copy of the previously
sent SDP without changes.

There are other cases where the sender wants to add additional media
streams to the session (not related to MSRP). In this case, the m=
line would be the same, especially if a file transfer is still going
on. But there would be additional m= lines. We don't want to repeat
the file transfer here either.

There are other cases where we want to repeat the file transfer,
perhaps because the hash computation failed, or because the user
accidentally deleted the file.

So, considering the use cases we have, and the discussion in
SIP/SIPPING of the service-ID, I would apply Jonathan's view: be
explicit in the signaling with what you ask. I would propose that we
create a new attribute, named 'file-transfer', which can take two
values: "new" (which is the default) and "existing". A file transfer
with the "new" attribute indicates the desire to do a new file
transfer, i.e., repeat it (if it was already done). A file transfer
with the "existing" attribute indicates that the file already exists
and we the file transfer should not take place. This approach was used
in the past with comedia and the management of TCP connections. Any
views?

/Miguel
-- 
Please note my new e-mail address: miguel.garcia at nsn.com
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Helsinki, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 21 May 2007 16:09:18 -0400

This seems reasonable to me. My first thought was that we should reuse 
the parameter from comedia, but it isn't quite right because it refers 
to the connection rather than the transfer. So this seems appropriate.

	Paul

---

From: Miguel Garcia <[email-masked]>
Date: Tue, 22 May 2007 09:42:33 +0300

Ok, since we seem to be converging, I will start implementing these changes.

/Miguel