Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 14 Mar 2006 15:58:29 +0100

Hi,

3GPP has now also defined procedures where the usage of the precondition
mechanism is not mandated.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: 14. maaliskuuta 2006 14:09
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: RE: [Sip] The Problem with PRACK

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 like Paul indicated:

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

>-----Original Message-----
>From: ext Paul Kyzivat [mailto:[email-masked]]
>Sent: 09.March.2006 18:29
>To: Prince A P
>Cc: [email-masked]
>Subject: Re: [Sip] The Problem with PRACK
>
>
>
>Prince A P wrote:
>> 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?
>
>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]>>
>>         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]]
>>         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]>
>>          >> <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]>
>>          >>     < 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>>
>>          >>     This list is for NEW development of the core 
>SIP Protocol
>>          >>     Use [email-masked]
>>         <mailto:[email-masked]>
>>          >>     <mailto:[email-masked] > 
>for questions on
>>         current sip
>>          >>     Use [email-masked] <mailto:[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]>
>>          >> <mailto:[email-masked]> for
>questions on
>>         current
>>          >> sip Use [email-masked] <mailto:[email-masked]> <
>>         mailto:[email-masked]> for new
>>          >> developments on the application of sip
>>          >
>>          >
>>          >
>>          >
>>         
>----------------------------------------------------------------------
>>          > --
>>          >
>>          > _______________________________________________
>>          > 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
>>         <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
>>         <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
>>         <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
>

_______________________________________________
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: <[email-masked]>
Date: Tue, 14 Mar 2006 17:48:18 +0200

Hi,

>3GPP has now also defined procedures where the usage of the 
>precondition mechanism is not mandated.

True, but I do not still agree that the problem would be non-existent.
Excuse me citing 3GPP specs here, but I just want to highlight the
foreseeable backwards compatibility problems towards existing mobile
SIP implementations, that could result if offer within PRACK would
be obsoleted.

Originally the usage of preconditions was mandatory for 3GPP IMS.
3GPP specs are still promoting the usage of preconditions as the 
preferred option like this (UE effectively meaning UA in IETF terms):

"The preconditions mechanism should be supported by the originating UE.

The UE may initiate a session without the precondition mechanism if the
originating UE does not require local resource reservation. The
originating UE can decide if local resource reservation is required
based on e.g. application requirements, current access network
capabilities, local configuration, etc.

In order to allow the peer entity to reserve its required resources, an
originating UE supporting the precondition mechanism should make use of
the precondition mechanism, even if it does not require local resource
reservation."

And sending offer within PRACK is specified in 3GPP like this:

"Upon successful reservation of local resources the UE shall confirm the
successful resource reservation within the next SIP request. In case of
the precondition mechanism being used on both sides, this confirmation
will be sent in either a PRACK request or an UPDATE request."

Regards,

Erkki

>From: ext Christer Holmberg (JO/LMF) 
>[mailto:[email-masked]] 
>Sent: 14.March.2006 16:58
>To: Koivusalo Erkki (Nokia-TP-MSW/Helsinki); 
>[email-masked]; [email-masked]
>Cc: [email-masked]

---

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

> mechanism is not mandated.

sounds like a much better idea than keep on complicating the protocol
beyond comprehension.

-- juha