Re: [MMUSIC] Trickle ICE for SIP Questions

[Paul Kyzivat <[e-mail]>]

Thomas,

On 7/8/13 5:24 AM, Stach, Thomas wrote:

> [TS] Saving the half RTT is not my primary goal. When implementing ICE we got away without requiring PRACK.
> I want to keep this property, since it allows

I get it that you think PRACK is hard to implement.
But hard compared to *what*? I suspect that this will introduce 
complexity elsewhere.

>>     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. The 481 to the INFO would rather be the indicator for this situation. As stated above we can prescribe that the 481 (and only the 481) is to be sent for the INFO and what happens next, i.e. retransmit the 180.

This is part of the house of cards that I was talking about.
You seem to be saying that a special rule should be be adopted, allowing 
INFO to be sent from INVITE-UAS before it is known that the dialog has 
been established. And then a special rule for processing 481 responses 
to INFO in this context.

>> Also, keep in mind that the 180 carries an entire SDP answer. If INFOs
>> are competing with 180s then they may potentially need to carry that
>> too
>> (or at least the ICE parts) and it would be good if we don't have to
>> open that can of worms.
> [TS] For the trickle-ICE application of the info-package I would just recommend sending (all) the ICE candidates.
> This eliminates the competition, you just take what you got last.

Certainly it will be simpler if all candidates are sent each time.
But I don't think that means you can just take what you got last. You 
still need to check if what you got is *older* than what you already 
have, and if so ignore it.

	Thanks,
	Paul