Subject: Re: SIP and QOS + some more unrelated questions

From: [email-masked]
Date: Thu, 27 May 1999 09:58:53 +0530

well, quite a while ago , I had a look at MINT from the GMD fokus ppl. They
had implemented a basic SIP service. I dont know their status now. If it
helps you could take a look. If there are any other free sources available,
Id like to know too !

BTW, is there any planned movement in SIP like Openh323 ?

One more thing, recently I was searching hgs' site for docs on how to make
PSTN systems interwork with SIP, and I only found a functional specs for
the same. Is there any further work on that , a draft maybe, which outlines
a standard way in which a
PSTN-SIP gateway should operate ?

Thx
Regds
Arjun

Sanjay Nayak <[email-masked]> on 05/27/99 03:17:14 AM

Please respond to [email-masked]

To:   [email-masked]
cc:
Subject:  Re: SIP and QOS

Any sample code of SIP is available  for  experiments
-sanjay
Sanjay Nayak wrote:
> I am  intretsed in the issues involved  in SIP and QOS, specially
following
> once.
>
> 1. Can any one of the method of  SIP can accomodate the QOS parameters (
> bandwidth, latency ..).  So that we need not go for  any resource
> reservation protocols. During the phase of the session establisment , we
> can  make sure that  bandwidth is available end-to-end.
>
> 2. IT seems to be that SIP will compleatly isolate the control plane from
> data plane. that means connection estblishment  path is different from
the
> data path. won't his be a problem for QOS issues. how to gauretee the
> end-to-end QOS  , if the signalling path is different from the data.

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 27 May 1999 07:07:21 -0500

>Is there any further work on that , a draft maybe,
> which outlines

Some of us had a long-standing intention to write such a "best practices"
document, but were just to busy to get it done. It should be looked as a to
do work item for this group I believe.

Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081, USA

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> [email-masked]
> Sent: Wednesday, May 26, 1999 11:29 PM
> To: [email-masked]
> Subject: Re: SIP and QOS + some more unrelated questions
>
>

---

From: Lars Berggren <[email-masked]>
Date: Thu, 27 May 1999 14:49:33 +0200

Folks,

Does anybody have a suggestion of what the UAS should do in the
following scenario:

1) UAC sends INVITE to UAS.
2) UAS receives INVITE.
3) UAS sends 200 OK (INVITE) to UAC.
4) UAC sends CANCEL to UAS.
5) UAC receives 200 OK (INVITE).
6) UAS receives the CANCEL.

Now what should the UAS do? How do it respond to the CANCEL? According
to the rfc it is not affected by the CANCEL since it has sent a 200
response.

Is there a failure status code to send in response to the CANCEL or
should the UAS just silently drop the CANCEL request?

Thanks 

Lars

-- 
Lars Berggren       <[email-masked]>
Intertex Data AB    tel: +46-8-6282828
Sundbyberg, Sweden  fax: +46-8-6286414

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 27 May 1999 11:30:34 -0500 (CDT)

>should the UAS just silently drop the CANCEL request?

I beleive it should send a 200 in response to the CANCEL.

UAC                        UAS
 |----------INVITE--------->|
 |---CANCEL--\  /-INV. 200--|
 |            \/            |
 |            /\            |
 |<----------/  \---------->| The CANCEL does not terminate the session
 |<--------CANCEL 200-------|
 |------------BYE---------->|
 |<---------BYE 200---------|
 |                          |

The UAC knows that, since the INVITE received a 200 reply, the CANCEL was
not received in time. As is implied in RFC2543 section 10.5.1, you can
then send a BYE instead of an ACK to tear down the call. 

Since there may be intervening proxies which generate their own 200 
response to CANCEL, there's no way to propigate an error code all the way
from the UAS to the UAC:

   UAC                       PROXY                       UAS
 1  |----------INVITE--------->|                          |
 2  |                          |----------INVITE--------->|
 3  |----------CANCEL--------->|                          |
 4  |<-------CANCEL 200--------|                          |
 5  |                          |<-------INVITE 200--------|
 6  |                          |----------CANCEL--------->|
 7  |<-------INVITE 200--------|                          |
 8  |                          |<-------CANCEL 200--------|
 9  |------------BYE---------->|                          |
 10 |                          |------------BYE---------->|
 11 |                          |<---------BYE 200---------|
 12 |<---------BYE 200---------|                          |

Even if you were to put an error code in the CANCEL response transmitted 
in step 8, it's too late to send it back to the UAC, since the proxy
already responded in step 4.

Read literally, the spec. says you should re-transmit until you receive
a response to the CANCEL, so silently discarding the CANCEL with no 
response seems like a bad idea.

Notice, also, the flow of messages between the proxy and the UAC
in the diagram above: if you receive an INVITE 200, even after a 
CANCEL 200, you must assume that the far-end UAS is expecting to be 
in a session with you, and it is your responsibility to tear the 
session down.

--
Adam Roach, Ericsson Inc. |  Ph: +1 972 583 7594 | 1010 E. Arapaho, MS L-04
[email-masked]   | Fax: +1 972 669 0154 | Richardson, TX 75081 USA

---

From: Jeff Mark <[email-masked]>
Date: Thu, 27 May 1999 11:17:23 -0700

> Adam B. Roach
> Sent: Thursday, May 27, 1999 9:31 AM
> To: Lars Berggren
> Cc: [email-masked]
> Subject: Re: SIP: CANCEL request/2xx-response to INVITE
>
>

Shouldn't the UAS send something other than a 200 reply to the CANCEL?  From
the UAS perspective it receives a CANCEL request after accepting the INVITE.
I think it might be better for the UAS to send some error code (maybe 403
Forbidden) to signify it has already accepted the call and is now awaiting
an ACK or BYE.

If this were the scenario (CANCEL 200 received before INV 200 below) the UAC
might think it's CANCEL was successful in tearing down the call, remove all
state it had on this transaction and go on to do other things.  When the UAC
receives the INVITE 200 response it would discard it since it now know's
nothing about this transaction.

UAC                        UAS
 |----------INVITE--------->|
 |---CANCEL--\  /-INV. 200--|
 |            \/            |
 |            /\            |
 |<----------/--\--CAN. 200-|
 |<---------/    \----------|

If, however, the CANCEL response was some error code, it might tell the UAC
that the UAS I was contacting did send an INVITE final response but it has
not arrived yet.  The UAC could then send a BYE to make sure the call get's
disconnected.

Comments?

-Jeff

_|_|_|  Jeff Mark
_|_|_|  Software Engineer
_|_|_|  Dialogic Santa Barbara Labs
_|_|_|  http://www.dialogic.com/

---

From: Igor Slepchin <[email-masked]>
Date: Thu, 27 May 1999 16:40:35 -0400

As Adam pointed out, sending an error response to CANCEL is pointless in
most situations because the UAC will receive the response sent by the
next upstream proxy, not by UAS. Besides, UAC can figure out that there
was a race condition when it sees the INVITE 200 after sending CANCEL,
there is no need to even wait for the response to CANCEL. The RFC2543 is
also fairly clear about what response should be sent:

   A redirect or user agent server receiving a CANCEL request responds
   with a status of 200 (OK) if the transaction exists and a status of
   481 (Transaction Does Not Exist) if not, but takes no further action.
   In particular, any existing call is unaffected.

As an aside, even if UAC does not send a BYE to INVITE 200, the UAS will
not consider the call established as it will never see the ACK. Of
course, this scenario is not very graceful but it still works.

Thanks,
Igor Slepchin

Jeff Mark wrote:
> <...>

---

From: "Adam B. Roach" <[email-masked]>
Date: Thu, 27 May 1999 15:48:28 -0500 (CDT)

>nothing about this transaction.

This is not acceptable behavior.

The purpose of the second example I included in my previous message 
was to demonstrate this *EXACT* point. I will reiterate:

   UAC                       PROXY                       UAS

Even if you *were* to put an error code in the CANCEL response 
transmitted in step 8, it's too late to send it back to the UAC, 
since the proxy already responded in step 4 (each stateful proxy
responds to a CANCEL request locally).

If the client behaves as you've described above, then it will
*not* handle communication through proxies correctly.

Let's say the UAC ignores the INVITE 200 after step 7. The
UAS is still waiting for an ACK or BYE in response to its
INVITE 200, and will continue to send it six more times
over the course of the next minute or so, before finally
timing out. The called user gets no error indication until
after this timeout period. In fact, it looks to him as if
the call has completed sucessfully. Not necessarily
harmful, but certainly well into what I would consider
annoying.

With that said, there is no harm in sending back an error code
of your choosing in response to a CANCEL. However, you can't count
on it travelling end-to-end, so there's very little point in
doing so.

Above all, you can't count on a 200 response to a CANCEL to indicate
the the call has been sucessfully canceled.

It seems to me that if you won't be keeping information about past 
sessions around for some period of time (and even if you will), you 
should accomodate this situation by sending a "BYE" back in response
to any INVITE 200:s you receive but can't correlate.

---

From: Jeff Mark <[email-masked]>
Date: Thu, 27 May 1999 14:03:46 -0700

Thanks for the correction.  It just seemed odd to me at first, but the
examples helped clarify what the RFC said.  I didn't really examine your
proxy example the first time -- sorry about that.

Thanks,

-Jeff

> From: Igor Slepchin [mailto:[email-masked]]
> Sent: Thursday, May 27, 1999 1:41 PM
> To: Jeff Mark
> Cc: Adam B. Roach; Lars Berggren; [email-masked]

---

From: Jeff Mark <[email-masked]>
Date: Thu, 27 May 1999 17:20:59 -0700

>  12 |<---------BYE 200---------|                          |

After some discussion among my co-workers I had another issue I wanted to
raise / point out.  In this example I believe step 7 disagrees with some of
the wording in RFC2543.

In section 4.2.5:

    Once a user agent server has received a CANCEL, it MUST NOT
    issue a 2xx response for the cancelled original request.

In section 12.3:

    A stateful proxy acts as a virtual UAS/UAC.  It implements
    the server state machine when receiving requests, and the
    client state machine for generating outgoing requests, with
    the exception of receiving a 2xx response to an INVITE.
    Instead of generating an ACK, the 2xx response is always
    forwarded upstream towards the caller.

Now since the proxy is acting as both the UAS and UAC it appears from
reading 4.2.5 the INVITE 200 response sent in step 7 is in violation to this
rule.  Since the proxy "implements the server state machine when receiving
requests" (12.3) it shouldn't send the INVITE 200 response.  The exception
noted in 12.3 applies to the client state machine of the proxy and was
intended (from my reading) on preventing the proxy from ACKing an INVITE
response.  So, if we abide by the server state machine, the proxy MUST NOT
forward the INVITE 200 response (4.2.5).  Now since the proxy already
accepted the cancellation of the call, it seems appropriate it should deal
with the INVITE 200 it receives in step 5 by sending the BYE itself.
Although this behavior is not mentioned in the spec, it seems like an
appropriate action to take since the transaction has been canceled.

Perhaps the chain of messages in your example is the correct way to do
things and the way the spec authors intended, but I think there needs to be
a clarification on how to respond to a CANCEL if a server has already
responded to the INVITE.  It just seems to me that sending a CANCEL 200
response _after_ sending an INVITE 200 response is not consistent with the
meaning of CANCEL.  Taking your proxy example I think the following exchange
of messages would still be consistent with the spec.  In step 8 the proxy
generates a BYE since it is not allowed to forward the INVITE 200 (4.2.5):

   UAC                       PROXY                       UAS
 1  |----------INVITE--------->|                          |
 2  |                          |----------INVITE--------->|
 3  |----------CANCEL--------->|                          |
 4  |<-------CANCEL 200--------|                          |
 5  |                          |<-------INVITE 200--------|
 6  |                          |----------CANCEL--------->|
 7  |                          |<-------CANCEL 403--------|
 8  |                          |------------BYE---------->|
 9  |                          |<---------BYE 200---------|

So if your original example is the intended way for a proxy to behave then
the spec needs to add some extra wording in section 12.3 to signify it is ok
to forward the INVITE 200 after it has received the CANCEL request.  If the
above example is the decided to be the way to go, then extra wording needs
to be inserted in 4.2.5 to allow the CANCEL 403 response to be sent if a
final response to an INVITE has already been sent and to assert in 12.3 the
behavior the proxy should have on CANCELed transactions (i.e. BYEing any
subsequent INVITE 200 response).

Maybe an explanation of how I interpret the CANCEL response would help in
deciphering my message :)

CANCEL 200
    I know about the request you want cancelled, I have not
    sent any final response to this request, and I promise
    to stop any further processing of the cancelled request.
    You may consider the original request complete.

CANCEL 403
    I know about this transaction, but am refusing to fulfill
    your CANCEL request because I have already sent a final
    response for the request you want to CANCEL.

CANCEL 481
    I have no idea what request you are trying to CANCEL.

You'll probably argue for the initial case as my interpretation seems to add
more to the spec.  I just thought I would bring this up as an issue on
something that I think is unclear both from reading the spec and from a
higher level interpretation of the messages that are sent.

-Jeff

_|_|_|  Jeff Mark
_|_|_|  Software Engineer

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 May 1999 00:48:58 -0400

Jeff Mark wrote:

> intended (from my reading) on preventing the proxy from ACKing an INVITE

I regret this particular sentence, as this is the second case of where
incorrect behavior has come by interpreting this too strictly. To answer
your question: the proxy should still send the 200. The INVITE 200's are
handled end to end. Having them stop at a proxy causes all kind of bad
things to happen. In particular, the UAC never knows that the UAS
thought the call was set up. If the 200 was forwarded, it could know
this and send a BYE. See my comments below on your suggestion of having
the proxy send a BYE.

> meaning of CANCEL.

Remember, CANCEL is an optimization. The spec is quite clear on the
behavior - send a 200 but don't do anything otherwise. Sending any other
response doesn't break anything, and it won't help the UAC, since its
not end to end. (See my note at the end of this mail on helping the
proxy out)

  Taking your proxy example I think the following exchange
>  9  |                          |<---------BYE 200---------|

A proxy cannot, and should not, send a BYE. There are several reasons,
not the least of which is:

1. its a big gaping security hole. BYE should be authenticated. This
means it must be sent by the caller, since the UAS is verifying
authenticity based on the calling parties key. In your proposal, the UAS
could not authenticate BYE's since any proxy might send one.

2. The CSeq number spaces get screwed up. The CSeq in the BYE from the
proxy is probably one higher. Now, the UAC might also issue another
request, perhaps a BYE, perhaps a re-INVITE. This might cause the UAS to
receive two messages, with the same Call-ID, To, From, AND CSeq, even
though they are, in fact, different. 

> to forward the INVITE 200 after it has received the CANCEL request.

OK. I think we need to strike this virtual UAC/UAS sentence too.

>     I have no idea what request you are trying to CANCEL.

While we're on the subject of CANCEL, let me raise a very closely
related problem. The problem is that of state timeout in a proxy when
CANCEL is used. In the current behavior, a UAS always sends a 200 OK to
the CANCEL, whether or not it arrived before the response to the INVITE
was sent. Thus, if a proxy sends a CANCEL, and then gets a 200 to the
CANCEL, it could mean that the CANCEL actually succeeded (in which case
no final response to the INVITE will ever arrive), or, the UAS did send
a final response to the INVITE already, but it hasn't arrived at the
proxy yet (perhaps it was lost). In one case, the proxy should wait
around for the final response to the INVITE, and in the other case, it
should not. So, the proxy has no way to know whether it is safe to
destroy transaction state. No major harm if it does, but there should be
a way to know.

Solution:

Keep the current behavior (200 to CANCEL), but still have the original
INVITE complete. Basically, if the CANCEL comes before the INVITE
response, the UAS sends a 200 OK to the CANCEL, and then immediately a
4xx to the INVITE itself. This way, a proxy knows that independent of
whether it sent a CANCEL or not, it should wait for a final response to
the INVITE. This solution also has an interesting side effect: if the
call is cancelled at all branches, the UAC receives the 4xx response to
the INVITE (since the 4xx IS propagated back to the UAC). So, for a UAC
which sends CANCEL, it gets a 200 OK to the CANCEL, and then it will
quickly receive a final response to the INVITE - the 4xx if it was
cancelled, or some other final response if it wasn't cancelled in time.

I believe this solution to be closely aligned with the view of CANCEL as
purely an optimization to speed up INVITE completion. The original
transaction still completes, CANCEL just speeds it up and causes phones
to stop ringing if not answered. I think its easy to support, since it
more cleanly separates the CANCEL and INVITE transactions - both still
complete normally (of course, as with any transaction, it may not
complete, and a proxy/UAC should be prepared for this. That handles the
backwards compatibility).

At first, Jeff's proposal (send a 4xx of some sort to the CANCEL if it
arrives after a response is sent), seems like it might solve this
problem too. If the proxy gets a 200 to the CANCEL, its safe to
terminate. If its the 4xx, it should wait for the response. This works
at the proxy which talks to the UAS, but not at any other proxy. Thats
because each proxy will generate its own local 200 response to the
CANCEL before even forwarding the CANCEL. Thus, a proxy receiving the
200 OK won't know whether the next hop was a proxy or a UAS. Having
different semantics for 200 CANCEL based on next hop is very bad and
won't work.

Comments?

-Jonathan R.
-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX: (732) 834-5379                         Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen

---

From: Gonzalo Camarillo <[email-masked]>
Date: Fri, 28 May 1999 10:16:16 +0300

> do work item for this group I believe.

Henry,

I think a draft about PSTN-SIP mapping is important enough that it
should not be included in a general "best current practices" draft. I
would like to have a draft just about this mapping.

There are lots of issues that could be addressed by the draft (message
flow, mapping of parameters, address translation, implementation of
services...). Then, inside PSTN, we have many protocols (ISUP, TUP...),
and the mapping between them and SIP have some differences.

We intend to write such a draft... I think that it cannot wait any
longer to be written.

Best regards,

Gonzalo
-- 
Gonzalo Camarillo         Phone :  +358  9 299 33 71
Oy L M Ericsson Ab        Mobile:  +358 40 702 35 35
Telecom R&D               Fax   :  +358  9 299 31 18
FIN-02420 Jorvas          Email :  [email-masked]
Finland

---

From: Lars Berggren <[email-masked]>
Date: Fri, 28 May 1999 09:38:39 +0200

Jeff Mark wrote:
....
>  9  |                          |<---------BYE 200---------|

When CANCELing an INVITE request it doesn't mean that the UAC wants to
terminate the call. It means that the UAC wants to terminate all
branches which have not sent a 2xx response. If the UAC wants to
terminate the call it sends a BYE instead of the CANCEL.

I interpret the part in the rfc that Igor quoted as that there are only
two possible final reponses to a CANCEL, 200 and 481. Is this correct?

A 200-CANCEL means that the transaction exists at the server and that it
will prevent all user agent servers that have not sent a 2xx to send
them. It does not mean that the original request really was cancelled,
and thus the UAC should still expect that 2xx to the original request
may arrive.

A 481-CANCEL means that the transaction does not exist at the server.

Thanks for the clarifications,
/Lars

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 May 1999 06:59:19 -0400

> incorrect behavior has come by interpreting this too strictly. To answer

Tentatively changed to:

\begin{changebar}
A stateful proxy acts similar to a virtual UAS/UAC, but cannot be viewed 
as just a UAS and UAC glued together at the back. (In particular, it
does not originate requests.)  
\end{changebar}

> different semantics for 200 CANCEL based on next hop is very bad and

Sounds like a good idea. What 4xx code? Suggestion: be explicit:

487 Request cancelled

The original request was cancelled by a {\CANCEL} request.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Lars Berggren <[email-masked]>
Date: Fri, 28 May 1999 14:27:09 +0200

Jonathan Rosenberg wrote:
... 
> different semantics for 200 CANCEL based on next hop is very bad and

The solution you describe ( 200 to CANCEL and then 4xx to INVITE ) seems
to me like a good solution. However there might be a backward
compability problem.

I don't know if you mean that the 4xx to the INVITE is to be
retransmitted as the final responses to INVITEs usually are. If it is
retransmitted, I think an existing UAC/proxy can get confused when they
send a CANCEL, receives a 200 to it and still gets a lot of final
responses to the INVITE which they will have to ACK to get rid of. In
the current state diagram for the INVITE method, a CANCEL with a 200
response causes these retransmissions to stop without having to ACK
them. But things will still work, since the client should be prepared to
receive final responses even if they get a 200 to a CANCEL ( In the case
where the server already had sent final responses. ).

On the other hand, if this 4xx is not retransmitted, what about
reliability issues?

Also of course, this solution requires fundamental server behaviour
modifications to the rfc.

/Lars

---

From: Henry Sinnreich <[email-masked]>
Date: Fri, 28 May 1999 07:27:54 -0500

> We intend to write such a draft... I think that it cannot wait any

Agree and looking forward to it!

Henry

> Gonzalo Camarillo
> Sent: Friday, May 28, 1999 2:16 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; Dean Willis; Ricky Project

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 May 1999 10:09:15 -0400

Lars Berggren wrote:

> where the server already had sent final responses. ).

In the current specification, a UAC/proxy has to be prepared to receive
a final response to the INVITE (200 or otherwise), after sending a
CANCEL, and even after getting a 200 OK to the CANCEL. If the CANCEL and
final response to the INVITE pass each other on the wire, the UAC/proxy
will still need to send an ACK to the final response (assuming its not a
200 response). So, there should not be backwards compatibility problems,
as an implementation should be prepared to receive any final response to
the INVITE after sending a CANCEL.

As far as the UAS is concerned, it sent a final response and then the
got the CANCEL; so, it sends a 200 OK to the CANCEL, but otherwise
ignores it. This means that the UAS will continue to retransmit the
final response. So, a proxy/UAC should also be prepared to receive
retransmissions of the final response to the INVITE, even after a
CANCEL.

> modifications to the rfc.

No, it does not, as I point out above. It just makes a more unusual case
(but still a possible one) more likely.

-Jonathan R.

---

From: Lars Berggren <[email-masked]>
Date: Fri, 28 May 1999 17:14:10 +0200

> the INVITE after sending a CANCEL.

Agreed. The client always has to ACK final responses to INVITEs.

> retransmissions of the final response to the INVITE, even after a

I do not agree that the server will continue to retransmit. This is
where the changes has to be made. See my comments below.

> (but still a possible one) more likely.

Well, in the server state diagram for the INVITE method (rfc2543, figure
13), there is an arrow going from the 'failure' state to the 'initial'
state. This state change is triggered by the CANCEL request. The
retransmissions occur in the 'failure' state. How then, can the UAS
continue to retransmit the final response if not this behaviour is
changed?

Lars.

---

From: Igor Slepchin <[email-masked]>
Date: Fri, 28 May 1999 14:58:11 -0400

> continue to retransmit the final response if not this behaviour is

This diagram also does not include the state transitions to handle
CANCEL in Success or Confirmed state (it should be 200Ok'ed without any
state change). These actions are explained elsewhere in the RFC, though.
However, I agree that what Jonathan suggested changes UAS's behavior in
Failure state: section 1.5.1 says the following:

Response retransmissions cease when:
...
3. a CANCEL request for the same call leg is received and the
   final response status was equal or greater to 300;

---
Igor Slepchin

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 May 1999 22:33:24 -0400

Igor Slepchin wrote:

>    final response status was equal or greater to 300;

Forgot about that... OK, so in that case there is not really a big
problem. A proxy which gets a 200 to the CANCEL knows that either:

a. no response will be sent to the INVITE (if CANCEL came before the
INVITE response was sent)
b. a non-200 response to INVITE may have been sent, but isn't being
retransmitted, so it can be ignored, and treated as if it were never
sent
c. a 200 response to INVITE may have been sent, and it will be
transmitted according to normal procedures.

In all three cases, the proxy is reasonably safe in destroying state. In
case (c) it should be acting as a stateless proxy anyway (forwarding
responses upstream), case (a) there are no subsequent responses. Case
(b) is mildly problematic. Lets say a 300 response was sent to the
INVITE. If the proxy destroys state before it arrives, the proxy will
forward the 300 upstream (since it destroyed state and doesn't remember
that it sent a CANCEL and should rather drop the response). So, if all
the proxies along the path go stateless, this rogue 300 might reach the
UAC. This is in addition to 200's which will (and should) reach the UAC.
This is quite a corner case, though. My original proposal helps it here,
but it can still happen in other cases (a proxy which simply times out,
returns a 408 response, goes stateless, and later receives a very late
response to the INVITE). So, I doubt its worth it.

-Jonathan R.