Re: [MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

A few cross mail replies:

On 09.07.13, 23:20, Stach, Thomas wrote:
> BTW: Just form emphasis. This is only needed if there is a UDP hop
> somewhere, in case of TCP/TLS the 18x would never be lost.

What does this change for anyone? Clients have no way of knowing whether
there would be UDP hops along the way so they would always need to be
ready for this option.

> [TS] As Trickle-ICE is just being specified, we are in a position to
> specify this handling.

While this is true, I see the following issue here: cumulative sending
is only necessary for SIP/UDP (which is quite a paradox because SIP/UDP
with ICE would break in a big number of cases).

> [TS] As the ICE/STUN logic resides in the browser not in the JS app,
> this would be a matter of the API definition to always provide all
> known candidates towards the JS APP for sending. On the receiving
> side the JS APP would also just have to push all received candidates
> through the browser API.

I find it strange that we would be imposing constraints on a new generic
API because of a broken use case that only exists with one usage
protocol. Especially given that the said use case (SIP+ICE over UDP) is
NOT going to work anyway because of MTUs and improper IP fragmentation
handling on various devices today.

>>> We are indeed likely to get a 481 when sending INFOs and the 180
>>> hasn't yet made it to the remote side. However 481 might also
>>> imply that our dialog is simply dead for some reason and in this
>>> case 3261 says:
>>>
>>>
>>> If the response for a request within a dialog is a 481
>>> (Call/Transaction Does Not Exist) or a 408 (Request Timeout),
>>> the UAC SHOULD terminate the dialog.
>
> [TS] We are in the dialog establishing phase here and when the 180
> was lost we don't even have an early dialog. So this rule does not
> apply.

I am not sure this is true. There *is* an early dialog at the side 
that's sending the 180. The INFO is a second request within that same 
dialog and 3261 is very clear that a 481 would lead to termination of 
the dialog. Specifying different behaviour here would mean that many 
developers may need to start fighting/changing their SIP stacks.

Cheers,
Emil

-- 
https://jitsi.org