Re: [MMUSIC] draft-ivov-dispatch-trickle-ice-sip/draft-ivov-mmusic-trickle-ice - PRACK not mandatory

[Paul Kyzivat <[e-mail]>]

On 4/9/13 6:04 AM, Emil Ivov wrote:
> Hey Thomas,
>
> On 08.04.13, 14:15, Stach, Thomas wrote:
>> I agree, that Paul has a good point.
>> However, I still do not see a requirement for PRACK.
>> I would still like to avoid it due to the big debate during development of ICE that occurred back in IETF64.
>
> For those of us who weren't around back then, it would help if you could
> remind exactly what the reasons were. This way we can decide if they
> also apply to the trickle ICE case.

My argument was that without a reliable provisional the UAS can't be 
certain that the UAC has established an early dialog, and without that 
the UAC can't trickle using INFO.

Thinking further, *if* the UAS keeps retransmitting the unreliable 
provisional until it receives some ICE messages then things may work. 
But in the case of trickle ICE this might effectively mean that it must 
keep retransmitting until it receives an INFO with additional 
candidates, because none of the initial candidates may be usable.

	Thanks,
	Paul

>> Once the UAS has sent the 183 there is an early dialog.
>> Of course the 183 can be lost, such that UAS and UAC are out of sync with respect to the dialog state.
>>
>> Now, RFC5245 specifies (in case PRACK is not used) that the provisional response is retransmitted
>> with the exponential backoff timers. I want to keep this behaviour also for trickle ICE because now
>> the UAC will eventually receive one of the retransmissions and could also send trickled candidates.
>
> Not necessarily. The UAC may be performing half trickle in which case it
> won't be sending anything else.
>
>> Interesting is of course what happens with the INFO if the UAC has not yet received a provisional response.
>> I would expect receipt of a 481 response to the INFO request since the UAC does not yet know about the dialog.
>> This 481 could trigger at the UAS the immediate retransmission of the provisional response
>> in order to establish the early dialog. Then, the INFO could also be retransmitted.
>
> This could indeed work and it could potentially help gain almost up to
> an RTT. Anyone has a problem with it?
>
>> Of course you are right.
>> However, since the INFO can carry arbitrary SDP fragments, you can also include ufrag and password
>> and any of the other ICE attributes.
>
> I didn't mean to imply you couldn't, however Paul's comment, discussed
> above, killed this approach anyway.
>
> Cheers,
> Emil
>
>>
>>
>> Regards
>> Thomas
>>
>> Emil Ivov wrote:
>>> On 05.04.13, 21:10, Paul Kyzivat wrote:
>>>> Note that until at least one provisional response makes it back to
>>>> the UAC it won't be possible for the UAC to send INFOs. (It can't do
>>>> so until there is an early dialog.)
>>>>
>>>> So its possible that if you only send unreliable provisionals then
>>>> the trickling from UAC to UAS may not be happen until the call is
>>>> established.
>>>
>>> Great point! So it seems like we are back to mandating PRACK.
>>>
>>> What would be the issue with this anyway?
>>>
>>> Emil
>>>
>>>>
>>>> 	Thanks,
>>>> 	Paul
>>>>
>>>> On 4/6/13 2:51 AM, Emil Ivov wrote:
>>>>> Hey Thomas,
>>>>>
>>>>> On 05.04.13, 12:04, Stach, Thomas wrote:
>>>>>> inline
>>>>>>
>>>>>> Emil Ivov wrote:
>>>>>>> Hey Marc and thanks for your comments!
>>>>>>>
>>>>>>> Replies inline.
>>>>>>>
>>>>>>> On 02.04.13, 17:45, Marc Petit-Huguenin wrote:
>>>>>>>> -----BEGIN PGP SIGNED MESSAGE-----
>>>>>>>> Hash: SHA256
>>>>>>>>
>>>>>>>> I read draft-ivov-dispatch-trickle-ice-sip and
>>>>>>>> draft-ivov-mmusic-trickle-ice during the preparation of the
>>>>>>>> rfc5245bis draft and I have some suggestions that I will be
>>>>>>>> presenting step by step below:
>>>>>>>>
>>>>>>>> 1. The 180 needs to be reliable
>>>>>>>
>>>>>>> Agreed. We'll make the change in the next revision.
>>>>>>>
>>>>>> The answer with any initial candidates needs to be in a 183 not a
>>>>>> 180.
>>>>>
>>>>> Well 5245 actually talks about 18x but I agree that using 183 rather
>>>>> than 180 would help manage post pick-up latency better.
>>>>>
>>>>>> In addition, I don't think that the 183 needs to be reliable.
>>>>>> This was not necessary for RFC5245 and could also be
>>> avoided for trickle ICE, since the
>>>>>> INFO with the new candidates is already reliably sent.
>>>>>
>>>>> Well, it's not only about the candidates (the 183 could actually
>>>>> contain none of those). However, we'd also need to make sure that
>>>>> things like the ufrag and password are also received.
>>>>>
>>>>>> If the INFO contains always the complete list of
>>> candidates (instead of just a delta), the ICE agents will
>>>>>> eventually have all candidates even if the 183 with the
>>> initial candidates got lost with the initial candidates.
>>>>>> As an optimisation if you don't want to always send the complete
>>>>>> list, you could just include it in the first INFO and use deltas
>>>>>> afterwards.
>>>>>
>>>>> I like this suggestion and I agree we could add something along
>>>>> those lines in case PRACK is not user or supported.
>>>>>
>>>>> Thanks for the tip!
>>>>> Emil
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>> Thomas
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>