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

[Christer Holmberg <[e-mail]>]

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.

Yes.

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

It would be handled by the ICE agent. 

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

Correct. The INFOs would contain whatever candiates are "valid" at that given point. The point was that, IF candidates have previously been trickled on other forks, and they are still "valid", they need to be trickled also on the new fork.

>Do we agree?

We always do :)

Regards,

Christer