Re: [MMUSIC] Trickle ICE for SIP Questions

[Christer Holmberg <[e-mail]>]

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, maybe that is something we need to look into on a more general level.

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