Re: [MMUSIC] Comment on SIP Trickle ICE based on INFO draft - FORKING

[Emil Ivov <[e-mail]>]

On 30.03.14, 11:48, Christer Holmberg wrote:
> Hi,
>
>> 2) Trickle ICE INFO with serial forking
>>
>>    a) INVITE from local
>>    b) INVITE is forked by proxy to first remote destination
>>    c) 100 trying is reaching local
>>    d) INFO with Trickle ICE from local
>>    e) INFO is forward by proxy to first remote destination
>>    f) INVITE is forked by proxy to second remote destination
>>    g) Whether INFO has to be forked?
>>
>> It is not mentioned in the draft whether INFO has to be forked to the
>> second remote destination as well. Could you please explain the expect
>> behavior for this scenario.
>
> I am not sure what you mean by the INFO being forked.
>
> When a new fork is created (i.e. when the offerer receives a 18x response from a new destination), whatever candidates have been trickled on previously created fork(s) of course need to be provided also on the new fork.
>
> And, when multiple forks exist, whenever a new candidate is to be trickled, an INFO carrying the candidate needs to be sent on each fork.
>
> I don't see a problem with this, but if it is unclear in the spec then some additional text might be needed.

Making sure we are on the same page:

1. These additional INFOs need to be trickled by the ICE agent that 
generated them in the first place.

2. This would happen as an explicit step that is visible to the TU and 
the ICE agent. That is, it's not something that would be automatically 
handled by a SIP stack, by simply resending all the INFOs from the first 
prong of the fork to the second one.

3. Those INFOs may or may not contain the same candidates (e.g. the 
agent may have chosen to use different port numbers for that prong) and 
they may or may not be the same number (e.g. if the agent is reusing 
addresses, it may decide to send them all in a single INFO, rather than 
in a sequence of INFOs).

Do we agree?

Emil


-- 
https://jitsi.org