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

["Stach, Thomas" <[e-mail]>]

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. 

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.

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. 


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