Subject: [MMUSIC] File transfer Issue 51: transfer identifier

From: Miguel Garcia <[email-masked]>
Date: Mon, 13 Aug 2007 15:15:46 +0300

In the file transfer draft, the current a=file-transfer attribute is 
used to indicate to the remote endpoint whether a new file transfer is 
requested or not. This allows to keep the file description without 
provoking a new file transfer, if, for example, the SDP is repeated 
(imagine, due to session timer re-invite).

The problem is: in order to keep the existing ongoing file transfer, the 
  SDP creator has to change the SDP and set a=file-transfer to 
"existing". This is a fragile mechanism: if the application just ships 
the last SDP without any changes, then it will provoke a restart of the 
file, due to the presence of a=file-transfer:new.

Ideally we would like a mechanism so that, in case the application 
repeats the SDP, nothing happens, i.e., if the file transfer is still 
going on, remains. If it is concluded, it is not restarted.

Jonathan suggested to use a transfer identifier instead. This looks 
interesting: When the endpoint repeats the SDP, if a transfer is still 
taking place, it continues. If it already concluded, nothing happens. If 
it is a new identifier, it will start at this point.

I propose to replace the current file-transfer attribute with a 
file-transfer-id attribute, according to Jonathan's suggestions.

/Miguel
-- 
Miguel A. Garcia           tel:+358-50-4804586
Nokia Siemens Networks     Espoo, Finland

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

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 13 Aug 2007 10:18:05 -0400

inline

> going on, remains. If it is concluded, it is not restarted.

This was a major concern of mine when discussing comedia.
I tried very hard to come up with a mechanism that had this property. 
But in the end I was unsuccessful. What is proposed here is what was 
used in comedia.

I will have to dig back through all the discussion of comedia to 
discover what the major impediments were to a mechanism with this 
property. I just don't remember any longer.

> it is a new identifier, it will start at this point.

I'm quite sure we investigated mechanisms like this for comedia and 
found them problematic for some reason. Perhaps Gonzalo remembers - he 
was the other person involved in that I think.

	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 14 Aug 2007 09:22:15 -0400

More info inline.

	Paul

Paul Kyzivat wrote:
>> The problem is: in order to keep the existing ongoing file transfer, 
>> the  SDP creator has to change the SDP and set a=file-transfer to 
>> the last SDP without any changes, then it will provoke a restart of 
>> the file, due to the presence of a=file-transfer:new.
>>

I went digging in my archives. I came up with two messages on the 
subject. One is in the official archives:

http://www1.ietf.org/mail-archive/web/mmusic/current/msg02686.html

The other was private between me and gonzalo. I'm attaching a copy. This 
one eventually led to what was adopted, but I don't have any more 
discussion on the topic.

>> taking place, it continues. If it already concluded, nothing happens. 
>> If it is a new identifier, it will start at this point.
> 

draft-ietf-mmusic-sdp-comedia-08 used an a=connid attribute with a 
token, which I presume is similar to what Jonathan is suggesting.

In any case, as is often the case with o/a issues, 3pcc scenarios broke 
this mechanism.

>> file-transfer-id attribute, according to Jonathan's suggestions.

Subject: comedia connid
From: Paul Kyzivat <[email-masked]>
To: gonzalo Camarillo <[email-masked]>
Date: Tue, 03 Aug 2004 12:03:16 -0400

Gonzalo,

I thought about this some more while sleeping. I agree the problem 
cannot be fixed to achieve the goal I was trying to achieve. In 
retrospect, there are other cases where it can't be achieved. For 
instance, there is a similar situation with preconditions, where after 
one offer/answer cycle, the next offer is dependent on something in the 
previous answer.

So I think the best we can hope for is a weaker condition - that at the 
end of one offer/answer cycle it is possible to compute what the next 
offer should be in order to preserve the status quo. Then that only need 
be changed if change is subsequently required.

Having said that, if that is the goal, then I think we can do 
considerably better than the current proposal for connid - something 
that is much mor intuitive. I propose we replace connid with:

	a=connection: new
or
	a=connection: existing

This is very similar to the old proposal of a=reconnect, except for one 
small but significant difference - use in the initial offer.

I don't especially like having to weaken the condition for preserving 
the status quo, but if one acknowledges the need to do so I think this 
change is an improvement.

	Paul