Subject: RE: [Sip] The Problem with PRACK

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 15 Mar 2006 09:52:36 +0100

Hi, 

>An answer can always be sent in the ACK, but the problem is if we want 
>to send it earlier.
> 
>I also agree that if a device does not support an offer in a PRACK 
>it's a bug.
> 
>HOWEVER, the standard does not specify how an offer in a PRACK is 
>rejected.  This has been discussed before,

I don't recall that. When and where was it discussed?

[CHH] It was a while ago. I THINK it was on the implementors list.

I'm not sure I see a real problem here. An offer in a prack can't be the
first offer. As a subsequent offer, it is constrained it what it can
contain in such a way that the answer should always be able to achieve
something tolerable, if not desirable.

[CHH] In theory, the offer could contain one or more new streams. But,
there can also be a technical reason why the receiver simply isn't
capable of processing the offer at the time it is received.

In any case, I don't a solution where one isn't able to reject an offer
- for whatever reason...

Regards,

Christer

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 9. maaliskuuta 2006 1:43
> To: Brett Tate
> Cc: 'IETF SIP List'
> Subject: Re: [Sip] The Problem with PRACK
> 
> 
> 
> Brett Tate wrote:
> 
>>>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.
>>
>>
>>An offer within the prack is a pain and potentially a little under 
>>specified.
>>
>>One problem is that some devices don't support receiving prack with an
> 
> 
>>offer.
> 
> 
> There are lots of things that some devices don't support.
> We call those cases BUGS.
> 
> Which devices are those?
> 
> 
>>Thus the sender needs to handle PRACK 200 without SDP and handle a 
>>failure response because of the sdp.
> 
> 
> Are you suggesting that it is *legal* to:
> - support PRACK
> - not support PRACK with sdp?
> 
> I don't think that is valid. Prack use is enabled via the 100rel
option.
> 
> I'm pretty sure that option comes with the whole boat.
> 
> 
>>And if the UAS does not accept the
>>offer, some vendors return 488/606 type responses; others return 200 
>>without SDP.
>>
>>I prefer removing ability for prack to contain an offer.  However 
>>leaving it is ok if vendors who send it can deal with the typical
> 
> interop problems.
> 
> You only want to remove ability for it to contain an offer, but allow 
> it to contain an answer? Or remove support for both offer and answer?
> 
> As I noted in earlier reply, if we were to do that, then how do you 
> answer an offer that comes in a reliable provisional response?
> 
> Any change in this stuff has backward compatibility issues. It would 
> require use of new option tags, and even more complex support than the

> existing situation does.
> 
> 	Paul
> 
> 
>>>Another piece is the state machinery with the retransmissions itself 
>>>-
> 
> 
>>>correlating the PRACK with a particular reliable provisional response

>>>and causing it to stop.
>>
>>
>>I'm not aware of this being very complicated.
>>
>>
>>
>>
>>>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.
>>
>>
>>Answer within prack is needed unless willing to allow subsequent
> 
> different
> 
>>offer from the uas (UPDATE; and maybe other 18x and 2xx) to still
> 
> override
> 
>>first 18x offer.
>>
>>
>>
>>
>>>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.
>>
>>
>>It isn't complicated.  It is just a matter of getting it implemented
> 
> and
> 
>>deployed; and dealing with the various interoperability pains.  (BTW 
>>draft-sawada-sipping-sip-offeranswer has been a good reference for
> 
> answering
> 
>>many of the common questions about offer/answer within sip; hopefully
> 
> the
> 
>>draft gets adopted by sipping or sip.)
>>
>>One reason devices don't (or quit) supporting 100rel was because of
> 
> the
> 
>>SHOULDs/MUSTs related to offer/answer.  Another reason is because of
> 
> the
> 
>>extra messaging.
>>
>>And because subsequent SDPs sent within INVITE 18x/2xx no longer have 
>>precedent over the prior SDP, interoperability is a pain.  The UAS now

>>requires rfc3311 and rfc3262 support, and/or ability for UAC to
> 
> finally
> 
>>support forking interactions (18x/2xx with different tags).
>>
>>
>>The following are a few random things currently not resolved and/or
> 
> clearly
> 
>>specified.  Others are just some random thoughts/rants concerning 
>>interoperability.
>>
>>1) Dealing with 18x offer/answer rules with timer c is under
> 
> specified.
> 
>>Should the periodic 18x contain an SDP again?  And if so, which one if

>>another sent in UPDATE, PRACK, or their responses?
>>
>>2) RFC3261 discusses possibility of sending SDP again in INVITE 200 
>>response.  And it says it must be same as prior 18x SDP.  However I
> 
> assume
> 
>>if some send it (for backwards compatibility reasons), UAS should send
> 
> the
> 
>>latest correct SDP (if different SDP sent in UPDATE, PRACK response,
> 
> or
> 
>>UPDATE response).
>>
>>3) A forking proxy currently has no mechanism to indicate to uac when
> 
> a
> 
>>branch has been terminated.  Thus the UAC is currently unable to
> 
> easily
> 
>>determine which early dialogs have disappeared.  Hopefully this 
>>functionality will get resolved/included within herfp or another
> 
> draft.
> 
>>4) Concerning UPDATE and SDP, some vendors think SDP is required.  And
> 
> some
> 
>>vendors can't handle receiving the 504 response mentioned within
> 
> rfc3311
> 
>>without releasing the call.
>>
>>5) "audit" with sdp is pain (especially when prior "answer" becomes
> 
> "offer"
> 
>>within audit).  This is mainly just a pain to B2BUAs.  Hopefully more 
>>devices will start correctly support receiving UPDATE without SDP.
>>
>>6) Some devices still do not support forking proxy interactions very
> 
> well
> 
>>because some B2BUAs reduced the need.  And because of all the current 
>>offer/answer rules, devices expecting correct offer/answer behavior
> 
> need to
> 
>>interact well with forking proxies.  I mention this because if a UAS
> 
> needs
> 
>>to update the SDP and can't (because of offer/answer rules, etcetera),
> 
> it
> 
>>might act like forking occurred and send a 18x/2xx with a different
> 
> tag.
> 
>>
>>
>>_______________________________________________
>>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: "Brett Tate" <[email-masked]>
Date: Wed, 15 Mar 2006 12:27:45 -0500

> I'm not sure I see a real problem here. An offer in a prack can't be 
> the first offer. As a subsequent offer, it is constrained it what it 
> can contain in such a way that the answer should always be able to 
> achieve something tolerable, if not desirable.
> 

I agree; the UAS should be able to reject the PRACK's offer.  The solution
presented within draft-sawada-sipping-sip-offeranswer is to answer the offer
and trigger an immediate UPDATE to try to change things again.  Returning
responses like 488, 606, 504, etcetera seem more appropriate.

Unfortunately, rfc3262 and rfc3311 did not clearly identify a failure
response to send when the UAS cannot accept a PRACK/UPDATE with an
offer/answer SDP.  This has led to interoperability problems with devices
desiring benefits of UPDATE and PRACK; but don't desire/support them
containing an SDP.

The 504 response mentioned within rfc3311 helps for UPDATE if devices
actually support receiving without releasing the call; however it definitely
isn't a perfect solution.  

Returning a 200 response without an SDP to PRACK offer is not a perfect
solution and is currently considered non compliant.  However it is commonly
observed when interworking with devices which implemented (deployed) draft
versions of 100rel functionality and are unable/unwilling to disable 100rel
usage.  And because it isn't explicitly mentioned within the rfc3262, many
devices currently do not expect to receive a 504 as discussed within
rfc3311.