Subject: Re: RE: [Sip] The Problem with PRACK

From: "Prince A P" <[email-masked]>
Date: Thu, 9 Mar 2006 19:57:19 +0530

Hi,

If the 3262 is only for Reliability of Provisional responses, Why should
it mandate Offer-Answer completion?

Was there any rationale behind clubbing Reliability with Offer-Answer?

rgds,
Prince

>  To: "Samir Srivastava" <[email-masked]>, "Paul Kyzivat" <
> [email-masked]>, "Francois Audet" <[email-masked]>
> From: "Samir Srivastava" <[email-masked]>
> Date: 03/09/2006 01:18PM
> cc: IETF SIP List <[email-masked]>
> Subject: RE: [Sip] The Problem with PRACK
>
> We can do it, by adding more logic / header. UAS knows about all the
> hops by complete via header set inspection. When sending 1xx, it need to
> indicate in this new header to be defined. Is it worth
> defining this ?
>
>
> Thx
> Samir
>
> -----Original Message-----
> From: Srivastava, Samir [SC100:8826:EXCH]
> Sent: Wednesday, March 08, 2006 11:19 PM
> To: Paul Kyzivat; Audet, Francois [SC100:3055:EXCH]
> Cc: IETF SIP List
> Subject: RE: [Sip] The Problem with PRACK
>
> We can do for SIPS only.
>
> Thx
> Samir
>
> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked] <[email-masked]>]
> Sent: Wednesday, March 08, 2006 7:29 PM
> To: Audet, Francois [SC100:3055:EXCH]
> Cc: 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] <[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] <[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]<[email-masked]>>
> for questions on
> current sip
> >>     Use [email-masked] <mailto:[email-masked] <[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]<[email-masked]>>
> for questions on current
> >> sip Use [email-masked] <mailto:[email-masked] <[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
>
>
> _______________________________________________
> 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
>
>
>
>
>
_______________________________________________
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 11:28:41 -0500

> Was there any rationale behind clubbing Reliability with Offer-Answer?

I wasn't there when that was done, so I can't speak to the actual 
motives of those who were.

But note that offer/answer has no mechanism of its own - it must be 
associated with some messages in the signaling system.

Reliable provisionals, without sdp in the PRACK, are sufficient for 
early completion of the offer/answer exchange when the offer is in the 
invite. But that isn't sufficient to achieve early completion of 
offer/answer when there is no offer in the invite. In that case the 
offer is in the reliable provisional, and the obvious place for the 
answer is in the PRACK. That seems to be reasonable justification for 
involving PRACK in offer/answer.

Allowing an offer in PRACK is less motivated. Essentially the same thing 
can be done using UPDATE. I can speculate on some reasons for allowing 
PRACK to be used for this:
- done before UPDATE was invented
- efficiency - the prack is required anyway
- prack already needs to carry an answer, why not an offer

	Paul

>  
> rgds,
> Prince
> 
> 
>  
> 
>         To: "Samir Srivastava" < [email-masked]
>         <mailto:[email-masked]>>, "Paul Kyzivat" <[email-masked]
>         <mailto:[email-masked]>>, "Francois Audet" <
>         [email-masked] <mailto:[email-masked]>>
>         From: "Samir Srivastava" < [email-masked]
>         <mailto:[email-masked]>>
>         Date: 03/09/2006 01:18PM
>         cc: IETF SIP List <[email-masked] <mailto:[email-masked]>>
>         From: Paul Kyzivat [ mailto:[email-masked]]
>          >> On 3/7/06, *Jonathan Rosenberg* < [email-masked]
>         <mailto:[email-masked]>
>          >> <mailto:[email-masked]>> wrote:
>          >>
>          >>     [email-masked] <mailto:[email-masked]>
>          >>     < mailto:[email-masked]>                            
>          FAX:  
>          >>     (973) 952-5050
>          >>     http://www.jdrosen.net <http://www.jdrosen.net/>       
>                         PHONE: (973)
>         952-5000
>          >>     http://www.cisco.com <http://www.cisco.com/>
>          >>
>          >>     Sip mailing list  
>         https://www1.ietf.org/mailman/listinfo/sip
>          >>     <https://www1.ietf.org/mailman/listinfo/sip
>         <https://www1.ietf.org/mailman/listinfo/sip>>
>         <mailto:[email-masked]>
>          >>     <mailto:[email-masked] > for questions on
>         current sip
>          >>     Use [email-masked] <mailto:[email-masked]> <
>         mailto:[email-masked]> for new
>         <mailto:[email-masked]>
>          >> <mailto:[email-masked]> for questions on
>         current
>          >> sip Use [email-masked] <mailto:[email-masked]> <
>         mailto:[email-masked]> for new
>         <mailto:[email-masked]> for questions on
>         current sip Use
>          > [email-masked] <mailto:[email-masked]> for new
>         <mailto:[email-masked]> for questions on
>         current sip Use
>         [email-masked] <mailto:[email-masked]> for new developments
>         on the application of sip
> 
> 
>         <mailto:[email-masked]> for questions on
>         current sip
>         Use [email-masked] <mailto:[email-masked]> for new
>         <mailto:[email-masked]> for questions on
>         current sip
>         Use [email-masked] <mailto:[email-masked]> for new
> ------------------------------------------------------------------------
>

---

From: <[email-masked]>
Date: Tue, 14 Mar 2006 14:08:30 +0200

Hi,

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

> In any case, any change like this must be accompanied by a some
strategy 
> for backward compatibility. This seems not so easy. As much as it is
fun 
> to imagine how it might have been done better the first time around, I

> suspect that at this point the cure is worse than the disease.

I would just like to point out that the session setup specified
for 3GPP IMS networks uses preconditions and implicitely assume
sending an offer within PRACK. This is done for efficiency reasons

>- efficiency - the prack is required anyway

The 3GPP call setup with preconditions consists of 4 SIP transactions:
INVITE, two PRACKs for reliable responses and one UPDATE, covering
two to three offer-answer exchanges. All this (performed over long-range
radio access) will take considerable amount of time, more than 10
seconds
in the worst case. Adding yet another UPDATE transaction to those would
make the setup time even longer.

This far 3GPP has adopted a strategy to be compliant to IETF specs.
However obsoleting PRACK to contain an SDP offer would have a
backward compatibility problem towards all 3GPP compliant
implementations,
whether they would be applied within IMS networks or Internet.

Anyway the issue here is that for any transport requiring resource
reservation (and preconditions) and providing long RTT, this kind
of change would push session setup times to their limits, no more
acceptable to average users.

Regards,

Erkki

>From: ext Paul Kyzivat [mailto:[email-masked]] 
>Sent: 09.March.2006 18:29
>To: Prince A P
>Cc: [email-masked]
>>         hops by complete via header set inspection. When 
>sending 1xx, it
>>         need to
>>         Explain to me again how you would know that reliable 
>transport
>>         is used
>>         end to end?
>> 
>>             Paul
>> 
>>          >> the first provisional.  This is due to RSeq 
>starting at an
>>         arbitrary
>>          >> value instead of just starting at 1.  This is 
>probably the
>>         simplest
>>          >> 2) Multiple unacknowledged provisionals can be 
>in flight at
>>         the same
>>          >> 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
>> 
>>          >> Keeping track of when you can send the 200 would 
>be easier
>>         if we did
>>          >> 4) Even for an acknowledged provisional, you 
>still have to
>>         retransmit
>> 
>>          >> approximately every minute (I forget exactly) to 
>prevent old
>>         proxies
>>          >> latest reliable provisional in exactly the same 
>way that the
>>         UAS
>>          >> retransmits unreliable provisionals.  Who cares 
>if there is
>>         an extra
>>          >>     words in it requiring the usage of PRACK and 
>UPDATE in
>>         order to
>>         work
>>          >>     anything requiring PRACK is unacceptable. 
>Rohan put up a
>>         slide
>>         (IIRC)
>>          >>     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
>>          >>     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.
>>          >>

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 14 Mar 2006 14:32:50 +0200

[email-masked] writes:

 > two to three offer-answer exchanges.

why do you use prack rather than tcp or just udp with retransmissions in
case 200 OK gets lost?

-- juha

---

From: <[email-masked]>
Date: Tue, 14 Mar 2006 14:46:55 +0200

Hi,

Like already explained in this thread, SIP does not have a
way to request or guarantee end-to-end TCP. And when using
UDP, the important response that might get lost is a provisional 
one like 180 or 183 (losing 200 is another case). 

If such a provisional response (with SDP due to applying 
preconditions) can get lost, there is no other mechanism
than PRACK to inform the sender of the response that the
response was actually correctly received. Provisional
responses are not retransmitted by default, they are
retransmitted only when there is the Require: 100rel
header and PRACK does not arrive on time.

Regards,

Erkki 

>From: ext Juha Heinanen [mailto:[email-masked]] 
>Sent: 14.March.2006 14:33
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki)
>Cc: [email-masked]; [email-masked]; [email-masked]

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Mar 2006 08:42:11 -0500

> why do you use prack rather than tcp or just udp 
> with retransmissions in case 200 OK gets lost?

As currently specified (rfc3261 section 13.2.1) for offer/answer, a 18x with
SDP sent over a reliable transport without use of 100rel is not considered
an answer.  Thus if 100rel is not used, UPDATE cannot carry a related offer
since there is still an outstanding offer without an official answer.

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 14 Mar 2006 15:59:24 +0200

> since there is still an outstanding offer without an official answer.

if offer in invite is not acceptable, why not reject it and tell what
kind of offer would have been acceptable?

-- juha

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Mar 2006 09:16:48 -0500

> > As currently specified (rfc3261 section 13.2.1) for 
> > offer/answer, a 18x with SDP sent over a reliable 
> > transport without use of 100rel is not considered  
> > an answer.  Thus if 100rel is not used, UPDATE cannot 
> > carry a related offer since there is still an 
> > outstanding offer without an official answer.
> 
> if offer in invite is not acceptable, why not reject it 
> and tell what kind of offer would have been acceptable?

My comment has nothing to do with acceptability of the SDP.  

My comment is to indicate that reliability of transport currently has
nothing to do with "reliability" related to offer/answer rules.  Thus 100rel
is currently still required on reliable transports for offer/answer reasons.

---

From: Dean Willis <[email-masked]>
Date: Tue, 14 Mar 2006 15:33:34 -0600

> why do you use prack rather than tcp or just udp with  

Preconditions. They need acknowledgement that the request was  
received and acted on by meeting the preconditions at both ends  
BEFORE alerting the terminating user.

At the terminating side, this requires seeing an INVITE and "some  
other message" before sending back a 180 or 200 OK.

While I find the requirement questionable, this was the best  
mechanism we could come up with back in 1999.

Notes at: http://www.softarmor.com/sipwg/meets/interim-nov-1999/

Lots of design approaches were considered. We considered having an  
dialog for QoS preconditions, inside which we'd run another dialog  
for media. We considered reINVITE to move from "precondition  
establishment" to "media establishment". We considered lots of  
alternatives. We picked the PRACK model. We were probably wrong, but  
that's for another day.

Then we found out there was an IPR issue:

https://datatracker.ietf.org/public/ipr_search.cgi? 
option=rfc_search&rfc_search=3312

and could no longer get anybody to think much about preconditions.

--
Dean

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 00:38:49 +0200

> is currently still required on reliable transports for offer/answer

final response to INVITE is always reliable without PRACK, because it is
ACKed.  i was just questioning, why do you need to reliable provisional
responses at all, i.e., why all this complexity introduced by PRACK and
UPDATE?

-- ju

---

From: "Brett Tate" <[email-masked]>
Date: Tue, 14 Mar 2006 18:41:43 -0500

> i was just questioning, why do you need to reliable 
> provisional responses at all, i.e., why all this 
> complexity introduced by PRACK and UPDATE?

They are byproducts of working group decisions related to forking, early
media, and offer/answer.

The concepts are not overly complex; however there are some common interop
problems which I mentioned within the following email.

http://www1.ietf.org/mail-archive/web/sip/current/msg13240.html

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 02:05:16 +0200

> BEFORE alerting the terminating user.

i still don't get it.  my UAC does not send an INVITE that would
advertise a media that requires more bandwidth than what my current
access connection provides.  when that INVITE reaches UAS, it would
reject the INVITE if it does not have a media listed that would fit into
its access connection.  why would we need all those new messages and the
hassle that comes with them?

-- juha

---

From: <[email-masked]>
Date: Wed, 15 Mar 2006 09:24:01 +0200

Hi,

In 3G networks the access connections are reserved dynamically
(call by call basis). Preconditions are used to make sure that
the callee will be alerted only if the network was able to
reserve the needed bandwidth for both the users. Otherwise
it would be possible that the phone could start ringing and
the callee would answer it, but the network failed to provide 
the needed bandwidth for media and the call fails.

Regards,

Erkki

>Sent: 15.March.2006 02:05
>To: Dean Willis
>Cc: [email-masked]; [email-masked]; [email-masked]

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 10:42:19 +0200

> the needed bandwidth for media and the call fails.

still don't get it.  why can't the 3g proxy allocate bandwidth for the
highest bandwidth codec in the invite?

-- juha

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 10:51:58 +0200

> highest bandwidth codec in the invite?

... and then possibly reduce the allocation when 200 OK comes back or
remove the allocation completely if something else comes back.

-- juha

---

From: <[email-masked]>
Date: Wed, 15 Mar 2006 11:41:43 +0200

Hi,

One reason might be that the 3G SIP proxy would be located to
the home network of the user in Germany while the user is
travelling to Venzuela and using the local 3G access network.
The proxy does not have any control to the remote access.

SIP proxies are in general not related to access networks and
in my opinion it would not be so good idea to try tying them
together like that. Internet approach has been to keep most of
the intelligence in terminals and the networks to provide services
as the terminals request them. I know that in 3G the spec is not
always like that, but the less that kind of dependencies there
are the better.

Regards,

Erkki 

>Sent: 15.March.2006 10:52
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); [email-masked]; 
>[email-masked]; [email-masked]; [email-masked]

---

From: Juha Heinanen <[email-masked]>
Date: Wed, 15 Mar 2006 11:52:10 +0200

> The proxy does not have any control to the remote access.

fine, i don't like the proxy approach either.  if SIP UA does the
allocation, it can follow the same procedure: allocate first for the
highest it can support and reallocate if less comes back.

-- juha