Subject: [Sip] The Problem with PRACK

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 07 Mar 2006 23:32:18 -0500

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Mar 2006 11:54:46 -0500

> limitations that would simplify things.

The precondition *mechanism* could still work, using UPDATE, though 
somewhat less efficiently. But it would have to be modified so that it 
no longer specifies using PRACK.

Unless you believe *nobody* currently uses preconditions, it seems to be 
that this cat is already out of the bag, and putting it back in will be 
difficult.

> PRACK implementations to speak up and indicate what exactly makes it so 

The advantage here is that it simplifies life for those who want to use 
PRACK for reasons unrelated to offer/answer. It leaves UPDATE, along 
with INVITE, to handle offer/answer.

But, I also see people wanting to use UPDATE as a way to do things like 
session-timer updates without the risk of starting a new offer/answer 
cycle. UPDATE does allow this, but if you advertise support for UPDATE 
you cannot guarantee it won't be used to send you an offer.

I think the real problem is that people are too damn lazy to implement 
the more elaborate offer/answer model, and they are trying to find a way 
to avoid doing so. IMO adding restrictions on the mechanisms that are 
involved in this is a big hammer approach. To me it is now clear what 
must be done to implement this, and doing so is easier than coping with 
changes at this late date.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 8 Mar 2006 18:00:22 -0500

> 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.  Thus the sender needs to handle PRACK 200 without SDP and handle a
failure response because of the sdp.  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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Mar 2006 18:42:36 -0500

Brett Tate wrote:
> 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

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

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 8 Mar 2006 15:51:24 -0800

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

---

From: "Brett Tate" <[email-masked]>
Date: Wed, 8 Mar 2006 20:46:59 -0500

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

For this situation, typically devices which implemented the draft versions
of 100rel before it finally required such support.  And the operator of the
device desires to keep 100rel active (for UDP reasons) until upgrading.

> - not support PRACK with sdp?

Nope, just mentioning some common interop problems.

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

I prefer removing ability for prack to contain an offer.

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

As I indicated my prior email, I have the same type of concerns.

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

If vendors have deployed requiring support of offer in PRACK, I agree the
changes might present some interoperability challenges.  However the new tag
(if required) is not complex; the tag just indicates functionality similar
to 100rel without certain offer/answer requirements.  It just means a UAS
can have reliability without some of the offer/answer headaches.

However if all/most vendors currently do not require support of offer in
PRACK, it might be acceptable to document the change without requiring a new
option tag.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Mar 2006 21:46:49 -0500

comment at end

Rohan Mahy wrote:
> 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. 
> 
> 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.

As I mentioned elsewhere, if you deprecate this, then another way is 
needed to answer an offer that comes in a reliable provisional. The only 
obvious way would be to permit an answer in an UPDATE.

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.

	Paul

	Paul

> 
> Hope this helps.
> thanks,
> -rohan
> 
> On 3/7/06, *Jonathan Rosenberg* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     [email-masked]
>     <mailto:[email-masked]>                              FAX:   (973)
>     952-5050
>     <https://www1.ietf.org/mailman/listinfo/sip>
>     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
> 
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 8 Mar 2006 18:55:45 -0800

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?

On Mar 8, 2006, at 15:51 , Rohan Mahy wrote:

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 08 Mar 2006 22:29:16 -0500

Francois Audet wrote:
> 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

>> 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.
>>
>> time.  We could potentially eliminate this requirement by 
>> 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.
>>
>>     <mailto:[email-masked]>                              FAX:  
>>     (973) 952-5050
>>     Use [email-masked] <mailto:[email-masked]> for new
>>     developments on the application of sip
>>
>>
>> Use [email-masked] <mailto:[email-masked]> for new developments on 
>> the application of sip
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 12 Mar 2006 12:27:21 -0800

One of the difficult parts of PRACK has to do with fact that there are times
when a UA can not sent a new set of SDP and has to wait until some current
round completed then merge in all the SDP changes it wanted. I have not seen
a single implementation that correctly implemented this. I imagine there are
some correct implementation but the fact that there are so many wrong once
suggests this is very hard to get right.

The things that make PRACK hard may have to do with rigid limits on what can
be correlated between an offer and answer in SDP. In finding a solution to
PRACK, we might need to consider if we need slightly more powerful
correlation facilities in SDP such that we can relax some of the current SIP
level rules that make PRACK so hard.

---

From: Pekka Pessi <[email-masked]>
Date: Tue, 14 Mar 2006 19:18:55 +0200

Cullen Jennings <[email-masked]> writes:
>One of the difficult parts of PRACK has to do with fact that
>there are times when a UA can not sent a new set of SDP and has
>to wait until some current round completed then merge in all the
>SDP changes it wanted. I have not seen a single implementation
>that correctly implemented this. I imagine there are some correct
>implementation but the fact that there are so many wrong once

It must hard to make a distributed UA.

But doesn't 3261 and 3264 say that the current round must be
completed before sending new offer? I don't see any difference
between ACK and PRACK in this sense, both must be sent at once. I
must be missing what makes PRACK so different and hard.

Only possible addditional difficulty I see here is deciding
whether the SDP in PRACK is offer or answer. If UA has sent offer
in 100rel, it is answer, otherwise it is offer. Two bits in your
negotiation engine, or four states (init/sent-offer/recv-offer/
complete) in a SDL-like service.

The really interesting parts come with UPDATE, where the recipient
of INVITE can send an answer in 100rel and after it has received
PRACK it can decide that it has done enough this answering thing
and proceed to send an offer in UPDATE. It must be prepared to get
491 and retry UPDATE, but that is again standard part of
implementing UPDATE.

>The things that make PRACK hard may have to do with rigid limits
>on what can be correlated between an offer and answer in SDP. In
>finding a solution to PRACK, we might need to consider if we need
>slightly more powerful correlation facilities in SDP such that we
>can relax some of the current SIP level rules that make PRACK so
>hard.

Such as?

--Pekka

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 15 Mar 2006 17:49:27 -0800

> obvious way would be to permit an answer in an UPDATE.

For clarity, I am suggesting deprecating PRACK (offer) / 200 to PRACK
(answer).  I was no suggesting deprecating reliable 18x (offer) / PRACK
(answer).

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 15 Mar 2006 18:46:36 -0800

Hi Everyone,

I went back over the 102 messages in this thread and did not hear any
comments on my concrete proposals:

- require RSeq to start at 1
- only acknowledge the most recent provisional. if the UAS wants to send as
new provisional that completely replaces a previous one it can send
immediately.  if the UAS wants to send a new provisional but wants
acknowledgement of a previous one, it has to wait for the PRACK.
- send a provisional every 1 minute whether reliable or not.  (instead of
every one minute for unreliable and every 2.5 minutes for reliable)
- deprecate *offers* in PRACK (answers are still OK)

comments on *this*?

thanks,
-rohan

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 15 Mar 2006 23:00:57 -0500

Rohan Mahy wrote:
> 
> 
> On 3/8/06, *Paul Kyzivat* <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 

Oh. I thought you were proposing abandoning PRACK entirely for 
offer/answer. (But I haven't really been tracking exactly who has 
advocated what.)

The limited form you suggest is far less troublesome.

OTOH, I still struggle to understand how removing existing features 
simplifies life for anyone. It only gets simpler for those that 
implement *only* the new way. So a deployment strategy is required that 
allows that.

	Paul

---

From: "Brett Tate" <[email-masked]>
Date: Thu, 16 Mar 2006 10:01:23 -0500

> I went back over the 102 messages in this thread and 
> did not hear any comments on my concrete proposals:
> 

I do not understand how this really helps.  The queuing at UAS because of
offer/answer rules (and ensuring dialog established) is still required.  And
if I recall correctly, UPDATEs are now required instead of sending a new
offer within INVITE 18x/2xx. 

Are you wanting the UAC to queue out-of-order 18x's?

> - only acknowledge the most recent provisional. 
> if the UAS wants to send as new provisional that 
> completely replaces a previous one it can send 
> immediately.  if the UAS wants to send a new 
> provisional but wants acknowledgement of a previous 
> one, it has to wait for the PRACK.

I assume RSeq would still be checked so UAC is able to notice out of order
provisional responses.

It looks like this would impact the current offer/answer rules.  Are you
suggesting changes related to offer/answer within first 18x and/or
subsequent 18x's?

> - send a provisional every 1 minute whether reliable 
> or not.  (instead of every one minute for unreliable 
> and every 2.5 minutes for reliable)

I assume this is to better deal with a mixture of reliable and unreliable
transports.  The idea sounds fine.  However if 100rel is used, I do not see
a reason to reduce the interval.  Did you want Timer C reduced also?

> - deprecate *offers* in PRACK (answers are still OK)

Sounds good to me.  However leaving it is ok if vendors who send it can deal
with the typical interop problems such as receiving PRACK 200 without an
answer indicating the PRACK's offer was ignored.

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 16 Mar 2006 10:28:34 -0800

Hi Paul,

I was actually thinking of a new "1xxrel" option tag.  This makes the
compatiblity easy for the small percentage that implemented 100rel and
trivial for the majority who have not.

- Anyone that does not support PRACK now has an easier time implementing the
new simplified mechanism.

Anyone who supports 100rel as a UAC, only has to advertise (in INVITE) and
recognize (in 1xx responses) the new option tag in addition to the exiting
one.  The rest of the UAC behavior is fully RFC 3262 compatible and in most
cases identical.

Anyone who supports PRACK as a UAS can already unilaterally start RSeqs are
1 and send a provisional every 1 minute (these are both backwards safe).
The only additional change is that the UAS does not have to retransmit 1xx
responses that are no longer relevant (have been completely replaced by a
new response) when using the new version (retransmitting irrelevant 1xx
responses is still forward comaptible).

Hope this helps.
thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 16 Mar 2006 14:02:29 -0800

Hi Brett,

> offer within INVITE 18x/2xx.

An offer or answer can only appear in INV/first rel18x   or  first rel
18x/PRACK.  You can't have offers or answers in additional 18x responses, or
with my proposal PRACKs or PRACK responses.

The great simplification is that the UAS probably only needs to queue at
maximum a single response, and only if the FIRST response (because it
contains an offer or answer) is unacknowledged.

No, the UAC just checks if an incoming provisional has a higher RSeq than
the last received RSeq.  The last received provisional superceeds the
previous ones.  (It does not affect the offer/answer state).

> suggesting changes related to offer/answer within first 18x and/or

Even today, you cannot start a subsequent offer/answer exchange in a
subsequent 18x, so I'm not suggesting any new offer/answer rules.

> a reason to reduce the interval.  Did you want Timer C reduced also?

It is easier for implementations to do one thing rather than having special
case code.  Needing to send additional provisionals is so rare anyway, that
there is no reason to optimize out the one minute case.  I don't see any
reason to change Timer C.

thanks,
-rohan

---

From: "Brett Tate" <[email-masked]>
Date: Fri, 17 Mar 2006 08:39:04 -0500

Hi Rohan,

Thanks for the clarity.

> - require RSeq to start at 1

The change sounds good if the following changes are also accepted.  Without
the following changes, there might be poor interaction between UACs
supporting and UASs not supporting the requirement; thus a new option-tag
might be needed.

> one, it has to wait for the PRACK.

The change sounds good.  Some UACs already act this way because of
misinterpretation of rfc3262's "one higher" text or they implemented drafts
and haven't became compliant to rfc3262.

Are there currently UASs which don't queue 1xx's and expect the UACs to
ignore 1xx containing two higher RSeq as discussed in rfc3262 section 4?  If
so, the mentioned new option-tag would likely be needed.

---

From: Adam Roach <[email-masked]>
Date: Fri, 17 Mar 2006 18:58:04 -0600

Rohan Mahy wrote:

> - only acknowledge the most recent provisional. if the UAS wants to 
> send as new provisional that completely replaces a previous one it can 
> send immediately.  if the UAS wants to send a new provisional but 
> wants acknowledgement of a previous one, it has to wait for the PRACK.
> - send a provisional every 1 minute whether reliable or not.  (instead 
> of every one minute for unreliable and every 2.5 minutes for reliable)

Out of curiosity, did you go through the exercise of putting together an 
offer/answer state machine that takes this change into account? Is it 
much simpler?

/a