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

[Gonzalo Camarillo <[e-mail]>]

Hi,

I do not think we should change comedia at this point. There are already 
implementations out there that would need to be updated.

Regarding the consideration of such identifiers, as far as I can 
remember, they were brought up (since RTP uses them) but the collision 
rules in RTP seemed too complicated and we did not pursue that option 
further.

Cheers,

Gonzalo


Paul Kyzivat wrote:
> This usage was inherited from Comedia. If the proposal is to change it, 
> shouldn't it be changed for Comedia as well?
> 
> I thought we had fully explored the set of potential solutions before 
> settling for what we did in comedia. I don't remember for certain if we 
> considered random identifiers. (Its a bit embarrassing if we failed to 
> discover that solution, since it does seem a bit better.)
> 
>     Paul
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> the issue with using identifiers was that you could have collisions. 
>> When the offerer or the answerer changes during a session (e.g., a 
>> B2BUA in the middle uses 3pcc to perform call transfer) the new 
>> offerer or answerer could use the same identifier as the original 
>> parties were using. Then, instead of establishing a new connection, 
>> the original party could have thought that it had to keep using the 
>> existing one.
>>
>> Of course, this can be resolved by using long and random identifiers 
>> so that collisions almost never occur. This mechanism is probably the 
>> best option; however, it opens a new issue: how do we handle collisions?
>>
>> We could simply say that they are so unlikely that we assume they 
>> simply do not occur, we can define a collision detection mechanism, or 
>> we can tro to ensure that collisions never occur by the same the 
>> identifiers are formed (e.g., embedding a hash of a MAC address or an 
>> IP address).
>>
>> Cheers,
>>
>> Gonzalo
>>
>>
>> Paul Kyzivat wrote:
>>> More info inline.
>>>
>>>     Paul
>>>
>>> Paul Kyzivat wrote:
>>>> inline
>>>>
>>>> Miguel Garcia wrote:
>>>>> 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.
>>>>
>>>> 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.
>>>
>>> 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.
>>>
>>>>> 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'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.
>>>
>>> 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.
>>>
>>>
>>>>     Paul
>>>>
>>>>> I propose to replace the current file-transfer attribute with a 
>>>>> file-transfer-id attribute, according to Jonathan's suggestions.
>>>>>
>>>>> /Miguel
>>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> Subject:
>>> comedia connid
>>> From:
>>> Paul Kyzivat <[e-mail]>
>>> Date:
>>> Tue, 03 Aug 2004 12:03:16 -0400
>>> To:
>>> gonzalo Camarillo <[e-mail]>
>>>
>>> To:
>>> gonzalo Camarillo <[e-mail]>
>>>
>>>
>>> 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
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> [e-mail]
>>> https://www1.ietf.org/mailman/listinfo/mmusic
>>


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