Re: [MMUSIC] Trickle ICE for SIP Questions

> -----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.

> 
> >>     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.

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