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

[Paul Kyzivat <[e-mail]>]

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.

	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
>>
>