Subject: RE: [Sip] The Problem with PRACK (18x queuwing)

From: "Arunachalam Venkatraman \(arunvenk\)" <[email-masked]>
Date: Wed, 15 Mar 2006 13:20:51 -0800

My point is that without queuing the provisionals, there is a risk of
losing some of the PRACKs.
 
Suppose 18x with Rseq 2 and Rseq 3 are sent serially.
If the PRACK for Rseq 2 were lost for some reason and the PRACK for Rseq
3 were received first, then a subsequent receipt of a retransmitted
PRACK with Rseq 2 will be rejected by the protocol stack due to CSeq
error, by sending a 500 response. Now, the retransmissions of the 18x
with Rseq 2 will continue with no hope of matching up with its PRACK.

________________________________

From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Tuesday, March 14, 2006 6:59 AM
To: Arunachalam Venkatraman (arunvenk); Rohan Mahy; Jonathan Rosenberg
(jdrosen)
Cc: IETF SIP List
Subject: RE: [Sip] The Problem with PRACK

Hi,
 
A long time ago, I proposed a solution which would not require the
queueing: the INVITE request would contain the RSeq value that the UAS
MUST use for the FIRST reliable provisional response.
 
Regards,
 
Christer

________________________________

From: Arunachalam Venkatraman (arunvenk) [mailto:[email-masked]] 
Sent: 9. maaliskuuta 2006 6:06
To: Rohan Mahy; Jonathan Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: RE: [Sip] The Problem with PRACK

Regarding 1 below about having to queue up provisionals pending PRACK
for first one, an additional nuance is that it is also required to queue
up provisionals even after the first is PRACKed and send them one at a
time, as the PRACK for each is received.
If this were not done, then the PRACKS may be received out of sequence
and mess up the CSeq check for requests received at the UAS.
Then the UAS will futilely continue to retransmit the provisionals with
no hope of ever matching the PRACKS that were returned a 500 response
due to out-of-sequence receipt.

________________________________

From: Rohan Mahy [mailto:[email-masked]] 
Sent: Wednesday, March 08, 2006 5:51 PM
To: Jonathan Rosenberg (jdrosen)
Cc: IETF SIP List
Subject: Re: [Sip] The Problem with PRACK

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]> 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]                              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 
	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: "Christer Holmberg" <[email-masked]>
Date: Thu, 16 Mar 2006 10:09:12 +0200

Hi,

That is exactly my point. If the UAC in the INVITE indicates that the first value MUST be 2 (your example), and the UAC then receives 3, it KNOWS the 2 hasn't arrived yet.

Regards,

Christer