Re: [MMUSIC] Trickle ICE for SIP Questions

[Emil Ivov <[e-mail]>]

On 22.07.13, 08:33, Christer Holmberg wrote:
> Hi,
>
>>> How is this better than PRACK?
>>
>> Well, you don't have to worry about supporting offers and answers in the PRACK (which could indeed be a pain).
>
> In my years of "PRACK experience", PRACK itself (for the purpose of acknowledging reliable 18x responses) has never been a problem. But, I agree there could be issues when it is used for O/A - especially if one wants to reject an offer. In my experience, however, offers in PRACK are normally used e.g. to change pre-condition state, and/or to remove codecs, so the likelihood of rejection based on the SDP content should be rather small.
>
> There are also implementations that don't accept offers in PRACK to begin with, but I think that goes under "bad implementation" :)
>
> Having said that, not specific to trickle ICE, if O/A is a show stopper for the community to use PRACK,

Well, speaking as an implementor, I can completely see how many would 
feel uneasy about adding this to working implementations. It basically 
means adding some additional complexity with no actual benefit in return.

> maybe that is something we need to look into on a more general level.

You mean something like PRACK-lite that doesn't have offer answer? This 
sounds like something that could be relatively straightforward to 
specify. It would basically have to mimic PRACK but remove the part that 
talks about the additional O/A possibilities.

Trickle ICE for SIP could then have a dependency on it ...

Emil
>
> Regards,
>
> Christer
>
>
>
>
>> On 7/21/13 2:56 PM, Emil Ivov wrote:
>>> Hey Christer,
>>>
>>> On 21.07.13, 19:49, Christer Holmberg wrote:
>>>> Hi,
>>>>
>>>> As I've been on vacation,
>>>
>>> Hope you had a good one!
>>>
>>>> I tried to go through this thread in one sweep. I may have
>>>> missed/misunderstood some parts, and my apologies if my comments
>>>> below have already been dealt with.
>>>>
>>>> First, regarding 180, no matter if we use PRACK or not, SIP requires
>>>> the SDP to be identical in all 180 responses. That means you can't
>>>> add new candidates in subsequent 180 responses (eventhough vanilla
>>>> ICE uses 180s without PRACK, the SDP is identical in all 180s,
>>>> AFAIR).
>>>
>>> Good point!
>>>
>>>> Second, I get a little confused when we talk about the UAS sending
>>>> INFO before it knows that the dialog is established, and that we
>>>> would define some new handling rules when an error response is
>>>> received. Now, IF we want the UAC to inform the UAS that the dialog
>>>> has been established, we don't need PRACK for that. The UAC could
>>>> send an INFO when it receives the 180, and when the UAS receives the
>>>> INFO it knows the dialog has been established. I haven't thought so
>>>> much about it, so I am not suggesting such mechanism at this point,
>>>> I am only saying that it would be a possible solution from a SIP
>>>> protocol perspective :)
>>>
>>> This could indeed work! It would also make a lot of sense in cases
>>> where both agents are doing full trickle.
>>>
>>> Of course it does mean that, especially in half trickle scenarios, we
>>> basically have one full end-to-end signalling RTT (180 + INFO) during
>>> which trickling will be completely blocked. This could take a while.
>>>
>>> Still, if we don't come up with a better alternative, the worst case
>>> (i.e. half trickle + slow signalling) shouldn't be much worse than
>>> vanilla ICE.
>>>
>>> Emil
>>>
>>
>>
>
> --
> https://jitsi.org
>

-- 
https://jitsi.org