Subject: RE: [Sip] The Problem with PRACK

From: "Francois Audet" <[email-masked]>
Date: Thu, 9 Mar 2006 12:22:58 -0600

You wouldn't.

You would follow the RFC 3261 rule, i.e., you send the Answer in the
200 (and you MAY also include it in the 18X). That's already how it
works.

I guess what you are worried about is the case where a proxy unilateraly
decides to downgrade from TCP to UDP. While I really don't see any
rationale
for proxies to do such a thing, it is certainly possible. But that would
still be RFC 3261 compliant. The theoretical risk is loosing some
in-band
media until the next 18x or the 200 arrives.

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Wednesday, March 08, 2006 19:29
> To: Audet, Francois [SC100:3055:EXCH]
> Cc: Rohan Mahy; IETF SIP List
> Subject: Re: [Sip] The Problem with PRACK
> 
> 
> 
> 
> Francois Audet wrote:
> > I'm ok with the suggestion to deprecate using PRACK for 
> Offer/Answer.
> > 
> > While we are at it, why not go for deprecating the use PRACK 
> > altogether
> > when TCP transport is used?
> 
> Explain to me again how you would know that reliable 
> transport is used 
> end to end?
> 
> 	Paul
> 
> > On Mar 8, 2006, at 15:51 , Rohan Mahy wrote:
> > 
> >> Hi,
> >>
> >> A things about PRACK come immediately to mind that are a pain to
> >> implement:
> >>
> >> 1) The UAS has to queue provisionals until it receives a PRACK for 
> >> the
> >> first provisional.  This is due to RSeq starting at an 
> arbitrary value 
> >> instead of just starting at 1.  This is probably the 
> simplest to fix, 
> >> by just requiring the UAC to always start with a RSeq of 1.
> >>
> >> 2) Multiple unacknowledged provisionals can be in flight 
> at the same
> >> time.  We could potentially eliminate this requirement by 
> >> acknowledging the current status instead of the whole history.  In 
> >> other words, when the UAS sends a new reliable 
> provisional, it decides 
> >> which (if any) of the previously sent provisionals are 
> still relevant 
> >> and sends all of them (as sipfrags or something) as a 
> single reliable 
> >> request.
> >>
> >> 3) If you "answer" and want to deliver a 200 OK, you have 
> to queue it
> >> and wait if you are waiting for a PRACK to an offer or 
> answer. Keeping 
> >> track of when you can send the 200 would be easier if we 
> did something 
> >> like I recommend in #2. 
> >>
> >> 4) Even for an acknowledged provisional, you still have to 
> retransmit
> >> approximately every minute (I forget exactly) to prevent 
> old proxies 
> >> from deleting state for your transaction.  This is one of 
> those minor 
> >> annoyances that is *almost* operationally irrelevant, and 
> unlikely to 
> >> not get coded.  My proposal for simplification is to 
> retransmit the 
> >> latest reliable provisional in exactly the same way that the UAS 
> >> retransmits unreliable provisionals.  Who cares if there 
> is an extra 
> >> message or two for a call with 1 minute + post-answer delay?
> >>
> >> 5) I would deprecate the PRACK/200 (PRACK) offer/answer 
> exchange.  I
> >> talked Jonathan into this, and I've been sorry I did ever 
> since.  My 
> >> apologies to everyone for making a bad decision.
> >>
> >> Hope this helps.
> >> thanks,
> >> -rohan
> >>
> >> On 3/7/06, *Jonathan Rosenberg* <[email-masked]
> >> <mailto:[email-masked]>> wrote:
> >>
> >>     At the last IETF, there was a lot of discussion and 
> argument around
> >>     PRACK. The spark of this debate was the ICE 
> specification, which had
> >>     words in it requiring the usage of PRACK and UPDATE in 
> order to work
> >>     with early media. There was strong pushback from many 
> implementors
> >>     that
> >>     anything requiring PRACK is unacceptable. Rohan put up 
> a slide (IIRC)
> >>     that showed the state machine in his implementation 
> resulting from
> >>     PRACK, and it was not pretty.
> >>
> >>     So, I'd like to discuss exactly what IS the problem 
> with PRACK? There
> >>     are really two pieces of state machinery in play here. 
> One piece
> >>     is the
> >>     complication that PRACK introduces into the 
> offer/answer model. With
> >>     PRACK, you can now get a final answer in the 18x, and 
> then send a new
> >>     offer in UPDATE, or even in PRACK itself. Another 
> piece is the state
> >>     machinery with the retransmissions itself - 
> correlating the PRACK
> >>     with a
> >>     particular reliable provisional response and causing 
> it to stop.
> >>
> >>     In a chat with Flemming today, he suggested in 
> interested remedy
> >>     to our
> >>     PRACK dilemma. Why not revise PRACK so that you can't 
> send an offer or
> >>     answer with it; it has no impact on the set of allowed 
> O/A exchanges
> >>     defined by RFC 3261. I'm not sure if that would 
> consequently break the
> >>     preconditions mechanism, but maybe there are some kind 
> of offer/answer
> >>     limitations that would simplify things.
> >>
> >>     So, this is one idea. I'd like for people who have 
> complained about
> >>     PRACK implementations to speak up and indicate what 
> exactly makes
> >>     it so
> >>     complicated for them.
> >>
> >>     Thanks,
> >>     Jonathan R.
> >>     --
> >>     Jonathan D. Rosenberg, Ph.D.                   600 
> Lanidex Plaza
> >>     Cisco Fellow                                   Parsippany, NJ
> >>     07054-2711
> >>     Cisco Systems
> >>     [email-masked]
> >>     <mailto:[email-masked]>                              FAX:  
> >>     (973) 952-5050
> >>     http://www.jdrosen.net                         PHONE: 
> (973) 952-5000
> >>     http://www.cisco.com
> >>
> >>     _______________________________________________
> >>     Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >>     <https://www1.ietf.org/mailman/listinfo/sip>
> >>     This list is for NEW development of the core SIP Protocol
> >>     Use [email-masked]
> >>     <mailto:[email-masked]> for 
> questions on current sip
> >>     Use [email-masked] <mailto:[email-masked]> for new
> >>     developments on the application of sip
> >>
> >>
> >> _______________________________________________
> >> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> >> This list is for NEW development of the core SIP Protocol Use 
> >> [email-masked] 
> >> <mailto:[email-masked]> for questions on current 
> >> sip Use [email-masked] <mailto:[email-masked]> for new 
> >> developments on the application of sip
> > 
> > 
> > 
> > 
> ----------------------------------------------------------------------
> > --
> > 
> > _______________________________________________
> > Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP Protocol
> > Use [email-masked] for questions on 
> current sip Use 
> > [email-masked] for new developments on the application of sip
> 
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 09 Mar 2006 13:53:23 -0500

> media until the next 18x or the 200 arrives.

I am still not following what you are suggesting. You say "deprecating 
the use PRACK altogether when TCP transport is used". Does that mean the 
UAC omits Supported:100rel if it is using TCP? Or that the UAS refuses 
100rel when it receives a request over TCP? Or that 100rel is supported 
but still the UAS doesn't use PRACK?

Its clearly possible that the access link for the UAC is TCP while that 
of the UAS is UDP, or visa versa.

Assuming that the e2e path is reliable without prack seems like a really 
bad idea.

And losing in band media can be a bad thing, such as when it is telling 
you why your call didn't get where it was intended to go. This can 
easily happen without there ever being a 200.

	Paul