Re: [MMUSIC] Trickle ICE for SIP Questions

On 7/9/13 5:20 PM, Stach, Thomas wrote:
>
>
>> -----Original Message-----
>> From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat
>> Sent: Monday, 08 July, 2013 17:53
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Trickle ICE for SIP Questions
>>
>> 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
> [TS] The remainder of the sentence got lost. It should have read "... since it allows easier introduction RTCWEB client with trickle ICE into a SIP network that never used PRACK."
>>
>> I get it that you think PRACK is hard to implement.
>> But hard compared to *what*? I suspect that this will introduce
>> complexity elsewhere.
> [TS] With respect to this complexity I just see the 481 handling for the INFO.
> Compared to all the new states that I need when I implement PRACK (which can include a new offer as you know), I just have to keep the previously sent provisional response together with the INFO request. The latter I have to keep anyhow for potential retransmissions.
> If I get a 481, I resent the 18x and the INFO request.
> 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.

With PRACK, the work is implementing it as it is specified. And then you 
can use it everywhere, not just for trickle-ICE.

I'm not sure I understand your proposal for using info in the context, 
but I *think* you are asking for *special* handling of 481 for INFO, 
contrary to how specs call for it to be implemented. For one think, this 
would effectively be a revision to some existing specification. And 
maybe you only what this handling when INFO is used for trickle-ICE?

Remember, introducing this will often mean using an existing 
implementation of INFO for this purpose.

>>>>      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.
> [TS] Let me reject the comparison with a "house of cards". We are currently specifying a new feature. There are no deployed implementations yet. Thus we can exactly specify what should happen at the UAC when it receives an out-of-dialog INFO because the dialog establishing unreliable 18x was lost, i.e. to send 481.
> On the UAS side we can also specify what to do when the INFO gets a 481. I.e. resend the 18x and the INFO request.
> I consider this closer to a solid foundation than to a house of cards.

Lets first decide in you are proposing a special mechanism for use with 
trickle-ICE, or if you are proposing a revison (bug fix?) to INFO, or to 
3261 & 5057.

If you are proposing a change in how INFO works exclusively when used 
for trickle-ICE then I think it is a non-starter.

If you are proposing a revision regarding the handling of presumed-to-be 
in-dialog requests from UAS to UAC before the UAS has proof that the UAC 
knows of the dialog, then we can talk.

	Thanks,
	Paul

> Regards
> Thomas
>
>>
>>>> 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
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>