Subject: [Sipping] Re: [Sip-implementors] Proxy acting as UAS -- CANCEL scenario

From: PRIYA <[email-masked]>
Date: Tue, 5 Jun 2007 10:20:44 +0530

please unsubscribe me from this group...........

On 6/5/07, Iliff, Tina <[email-masked]> wrote:
>
> All,
>
> RFC3261 Section 16 states the following regarding Proxy Behavior:
>
> Being a proxy is a logical role for a SIP element. When a request
> arrives, an element that can play the role of a proxy first decides
> if it needs to respond to the request on its own. For instance, the
> request may be malformed or the element may need credentials from the
> client before acting as a proxy. The element MAY respond with any
> appropriate error code. When responding directly to a request, the
> element is playing the role of a UAS and MUST behave as described in
> Section 8.2.
>
> Please consider the following call flow scenario:
>
> OUA sends INVITE to Proxy
> Proxy sends 100 Trying to OUA
> Proxy routes INVITE to SBC
> SBC sends 100 Trying to Proxy
> SBC routes INVITE to TUA
> SBC does not receive 100 Trying from TUA and retransmits INVITE several
> times
> OUA sends CANCEL to Proxy
> Proxy responds to CANCEL with 200OK
> Proxy routes CANCEL to SBC
> SBC does not route CANCEL to TUA
> A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE request to
> OUA
> Several seconds elapse and Timer B pops on the SBC and it sends a 408
> back to the Proxy for the INVITE request
> The proxy does not ACK the 408 response; therefore, the SBC retransmits
> the 408 for 64*T1 seconds
>
> Note:  The SBC is acting as a proxy and not a B2BUA
>
> Question:  Is the proxy behaving correctly by sending the 487 response
> to the INVITE request on its own?
>
> Regards,
>
> Tina Iliff
>
> _______________________________________________
> Sip-implementors mailing list
> [email-masked]
> https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
>
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: "Iliff, Tina" <[email-masked]>
Date: Mon, 04 Jun 2007 20:37:48 +0000

All,

Regards,

Tina Iliff

---

From: PRIYA <[email-masked]>
Date: Tue, 5 Jun 2007 10:20:44 +0530

---

From: "Avasarala Ranjit-A20990" <[email-masked]>
Date: Tue, 5 Jun 2007 14:28:51 +0800

Hi
 
In ur scenarios, SBC cannot receive 100 Trying, but it should receive
180 Ringing from TUA. Ok say SBC does not receive 180, the SBC will
retransmit INVITE for certain times with timer T1).. 
 
Now say OUA sends CANCEL to proxy and proxy sends 200 OK to OUA - so
here the transaction ends with respect to OUA.
Now Proxy forwards CANCEL to SBC. and 
SBC should send 200 OK to proxy. 
 
Finally SBC can send CANCEL to TUA 
 
why should proxy send 487 to OUA?  I don't think it is required
amd why should SBC send 408 for the INVITE that does not exist anymore?

Regards 
Ranjit 

________________________________

From: Iliff, Tina [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 2:08 AM
To: [email-masked]; [email-masked]
Subject: [Sipping] Proxy acting as UAS -- CANCEL scenario

All, 

Regards, 

Tina Iliff

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 5 Jun 2007 08:24:08 +0100

Usually the order of events would be a little different. After issuing a
CANCEL the proxy waits for 64*T1 seconds for a final response before
considering the client transaction as terminated. During this time,
timer B (which is also 64*T1) on the SBC fires, so the 408 should arrive
while the proxy's client transaction is still alive. Prior to the
cancel, the client transaction received 100 trying and therefore it
waits for timer C which is 3 minutes.

I agree there is a slight race condition, but it's highly unlikely. The
CANCEL would have to be sent almost immediately after the SBC sent the
100 trying for this race condition to occur.

From: Iliff, Tina [mailto:[email-masked]] 
Sent: Monday, June 04, 2007 11:38 PM
To: [email-masked]; [email-masked]
Subject: [Sipping] Proxy acting as UAS -- CANCEL scenario

All, 

Regards, 

Tina Iliff

---

From: Adam Roach <[email-masked]>
Date: Tue, 05 Jun 2007 17:54:29 -0500

On 6/4/07 3:37 PM, Iliff, Tina wrote:
> SBC does not receive 100 Trying from TUA and retransmits INVITE 
> several times
> A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE request to OUA
>

It shouldn't be running a timer for the CANCEL. CANCEL is a matter to be 
handled by the User Agents, not the proxies. Now, the proxy *will* be 
running timer C, and may tear down the transaction using section 16.8 
processing, but this will happen long after Timer B pops. So, in 
practice, when the transaction times out at the SBC, it will send a 408 
to the Proxy; the proxy ACKs the 408; the proxy sends a 408 to the UAC; 
and the UAC ACKs it. Everything works fine.

However, let's imagine that the proxy *has* somehow lost transaction 
state here, and think about what happens when the SBC Timer B pops. (I 
think there might be a way to reach a similar state if Timer C expires 
at the Proxy before it expires on the SBC).

> The proxy does not ACK the 408 response; therefore, the SBC 
> retransmits the 408 for 64*T1 seconds
>

The proxy can do exactly one of two things here, and dropping the 
response isn't either of them.

If the proxy still has transaction state for the INVITE transaction, 
then the proxy sends an ACK to the 408 -- retransmission stops.

If the proxy does *not* have transaction state for the INVITE 
transaction, then it must forward the 408 towards the UAC (what you're 
calling the "OUA" in your example) according to the Via header fields:

    16.7 Response Processing

      When a response is received by an element, it first tries to locate a
      client transaction (Section 17.1.3) matching the response.  If none
      is found, the element MUST process the response (even if it is an
      informational response) as a stateless proxy (described below).

(then, in section 16.11)...

       When a response arrives at a stateless
       proxy, the proxy MUST inspect the sent-by value in the first
       (topmost) Via header field value.  If that address matches the proxy,
       (it equals a value this proxy has inserted into previous requests)
       the proxy MUST remove that header field value from the response and
       forward the result to the location indicated in the next Via header
       field value.

The UAC will hold on to the client transaction until Timer D expires (32 
seconds), and any responses that match the client transaction (including 
these 408s) will cause the ACK to be retransmitted.

       Any retransmissions of the final response that are received while in
       the "Completed" state MUST cause the ACK to be re-passed to the
       transport layer for retransmission, but the newly received response
       MUST NOT be passed up to the TU.  A retransmission of the response is
       defined as any response which would match the same client transaction
       based on the rules of Section 17.1.3.

Now, there _is_ a bit of underspecification here (at least, as far as I 
can tell), since there's no normative behavior that would require the 
proxy to route this ACK to the SBC; however, the nominal case for most 
proxies will be to process the Request-URI in the ACK in the same way as 
it did the Request-URI in the INVITE, which would result in routing to 
the SBC, and consequently squelching the retransmissions.

I'm sure someone will step in and correct me if I've gotten any of this 
wrong. :)

/a

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 05:32:01 +0100

Hi Adam,

Not sure it's a correction or more of a question, as I might have got
this wrong myself...

> -----Original Message-----
> From: Adam Roach [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2007 1:54 AM
> To: Iliff, Tina
> Cc: [email-masked]; [email-masked]
> Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario
> 

The stateful proxy has client transaction(s) for each server
transaction. Meaning that on one end it acts as a UAS and on the other a
UAC.

Section 16.10 (CANCEL Processing):
   A stateful proxy MAY generate a CANCEL to any other request it has
   generated at any time (subject to receiving a provisional response to
   that request as described in section 9.1).  A proxy MUST cancel any
   pending client transactions associated with a response context when
   it receives a matching CANCEL request.

When the proxy cancels the client transaction is it also subject to the
following statement in section 9.1?

   Note that both the transaction corresponding to the original request
   and the CANCEL transaction will complete independently.  However, a
   UAC canceling a request cannot rely on receiving a 487 (Request
   Terminated) response for the original request, as an RFC 2543-
   compliant UAS will not generate such a response.  If there is no
   final response for the original request in 64*T1 seconds (T1 is
   defined in Section 17.1.1.1), the client SHOULD then consider the
   original transaction cancelled and SHOULD destroy the client
   transaction handling the original request.

It seems to me as if it should because the proxy might have sent the
CANCEL request to an RFC 2543-compliant UAS. Is it a good idea to leave
this behavior to user agents only? I cannot think of a scenario that
would really require the proxy to hold the transaction for 3 minutes
given the fact that if it won't respond to the CANCEL request the UAC
will terminate it after 64*T1 seconds.

If the proxy does not send the 487 response, I still think there is a
slight race condition. The UAC will only receive the 408 response, not
487, because the proxy waits. Therefore, if the CANCEL was sent almost
immediately after the INVITE both the UAC and the SBC are waiting for
64*T1 seconds. It's possible the 408 will not reach in time.

If anyone is really into solving this rare scenario, one possible
solution is to wait a bit longer after the CANCEL, for example 64*T1 +
T4.

Cheers,
Gilad

---

From: "Iliff, Tina" <[email-masked]>
Date: Tue, 05 Jun 2007 14:03:10 +0000

My interpretation of RFC3261 agrees with your statement.  However, I
have received a differing response on this mailing list which does not
surprise me.  I would prefer to see more responses to this question in
order to obtain a majority.
 
Regards,
 
Tina Iliff

From: Gilad Shaham [mailto:[email-masked]] 
Sent: Tuesday, June 05, 2007 2:24 AM
To: Iliff, Tina
Cc: [email-masked]
Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

All, 

Regards, 

Tina Iliff

---

From: "Iliff, Tina" <[email-masked]>
Date: Tue, 05 Jun 2007 14:03:10 +0000

Regards,
 
Tina Iliff

All, 

Regards, 

Tina Iliff

---

From: Byron Campen <[email-masked]>
Date: Wed, 6 Jun 2007 09:39:32 -0500

> solution is to wait a bit longer after the CANCEL, for example 64*T1 +

	Unfortunately, this does not really solve the problem. Suppose we  
have more than one proxy in a chain, each with this timer of 64T1+T4.  
We end up having a problem still (since the first proxy's timer pops,  
then the second, etc). It seems to me that we should set a timer for  
64T1 that causes a 408 to be forwarded back, and tear down the  
transaction later (maybe another 64T1 later). This way, we can ACK  
the responses that might come in as a result of timers popping  
downstream. Alternately, we could just ACK all stray responses.

Best regards,
Byron Campen

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 18:45:14 +0100

> downstream.

What I meant was that if the retransmission timer is 64*T1 and the
cancel timer is a bit larger (e.g., 64*T1 + T4) then this case would be
resolved because the retransmission would occur before the cancel,
giving enough time for a 408 to propagate. It's possible I missed
something, but I think the difference between the 2 suggestions is the
cancel timer 64*T1+T4 vs 2*64*T1.

> Alternately, we could just ACK all stray responses.

ACKing stray responses is something that could have some issues:
* Not all error responses have contact headers and in that case it's
impossible to know the destination.
* Contact headers may be different than the original request URI which
may cause the ACK of an error response to go through a different path.
* A source of possible DoS attack (?)

Gilad.

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jun 2007 13:24:09 -0500

> may cause the ACK of an error response to go through a different path.

The ACK for an _error_ response ignores the contact -- it's sent to the 
same IP address and port as the original INVITE was.

/a

---

From: Byron Campen <[email-masked]>
Date: Wed, 6 Jun 2007 13:31:20 -0500

On Jun 6, 2007, at 1:24 PM, Adam Roach wrote:

> The ACK for an _error_ response ignores the contact -- it's sent to  
> the same IP address and port as the original INVITE was.
>
> /a

	But we don't have this info anymore; the transaction is not there.

Best regards,
Byron Campen

---

From: Byron Campen <[email-masked]>
Date: Wed, 6 Jun 2007 13:32:52 -0500

> cancel timer 64*T1+T4 vs 2*64*T1.

	Let's make sure of whether we're on the same page or not; we might  
be, but let me describe my scenario in a little more detail. Lets say  
we have a _chain_ of proxies between the UAC and UAS, and an INVITE  
has already gone through, and everything has sent a 100.

UAC -> P1 -> P2 -> P3 -> ... -> Pn -> UAS

Scenario 1:
	Now, suppose UAC CANCELs. P1-Pn all set their CANCEL timer for 64T1 
+T4, one after the other, as the CANCEL is forwarded. And let's say  
UAS is out to cause trouble, and sends CANCEL/200, but no INVITE/487.  
What happens? Seems like P1's CANCEL timer will pop, causing teardown  
of its transaction with P2, and sending a 408 to UAC. Very soon  
after, P2's timer pops, causing teardown of the P2->P3 transaction,  
and sends a 408 back to P1. But P1's transaction with P2 is already  
gone, and so it never ACKs. This then repeats at each proxy in the  
chain, so they are all retransmitting 408 upstream.

Scenario 2:
	On the other hand, suppose each proxy sets two timers when they send  
a CANCEL; one that will cause a 408 to be sent upstream on the Server  
Invite transaction(64*T1, let's call this Timer L), and another that  
will cause the Client Invite transaction to be torn down (64*T1+X,  
let's call this Timer M). What happens after the CANCEL in this case?  
P1's Timer L pops, and it sends a 408 back to UAC. If X is  
sufficiently large, P2's Timer L will pop next, and it will send a  
408 back to P1 _before_ Timer M pops on P1. We avoid the retransmit  
storm.

	Were you thinking of the technique described in scenario 1, or  
scenario 2?

	At this point, we have the question of how large X needs to be.  
Setting X to 64*T1 would ensure that we'd stay around until all  
possible retransmissions have been sent (except maybe one, since the  
downstream element's retransmit timer starts slightly later, but that  
won't happen often). It might be overkill to wait this long, however.  
We want to set it to at least T1, but if we do this and the first 408  
gets dropped, we end up with the full compliment of retransmissions.

> * A source of possible DoS attack (?)
	
	Yeah, we would have to do something non-standard to make this work  
(like sending back to the source of the error). I don't think that  
this presents a DoS attack that is any worse than just bombarding the  
server with requests (since well-meaning elements would not worsen  
the problem). I still like the double-timer approach more though.

Best regards,
Byron Campen

---

From: "Iliff, Tina" <[email-masked]>
Date: Wed, 06 Jun 2007 18:38:56 +0000

Correct.  The ACK will just be sent to the IP address from which the
error response was received and not based on to where the original
INVITE was proxied.

Regards, 

Tina Iliff

-----Original Message-----
From: Byron Campen [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 1:31 PM
To: Adam Roach
Cc: Iliff, Tina; [email-masked]; [email-masked];
Gilad Shaham

On Jun 6, 2007, at 1:24 PM, Adam Roach wrote:

>> * Contact headers may be different than the original request URI 
>> which may cause the ACK of an error response to go through a 
>> different path.
>
>

	But we don't have this info anymore; the transaction is not
there.

Best regards,
Byron Campen

---

From: "Iliff, Tina" <[email-masked]>
Date: Wed, 06 Jun 2007 18:52:39 +0000

Allow me to correct your description of the scenario just a bit.  The
correction is that everything sends a 100 Trying to the INVITE EXCEPT
for the last element, the UAS.

Regards,
 
Tina Iliff

From: Byron Campen [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 1:33 PM
To: Gilad Shaham
Cc: Adam Roach; Iliff, Tina; [email-masked];
[email-masked]
Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

			If anyone is really into solving this rare
scenario, one possible
			solution is to wait a bit longer after the
CANCEL, for example 64*T1

	+

			T4.

		Unfortunately, this does not really solve the problem.
Suppose

	we

		have more than one proxy in a chain, each with this
timer of 64T1+T4.
		We end up having a problem still (since the first
proxy's timer pops,
		then the second, etc). It seems to me that we should set
a timer for
		64T1 that causes a 408 to be forwarded back, and tear
down the
		transaction later (maybe another 64T1 later). This way,
we can ACK
		the responses that might come in as a result of timers
popping
		downstream.

	What I meant was that if the retransmission timer is 64*T1 and
the
	cancel timer is a bit larger (e.g., 64*T1 + T4) then this case
would be
	resolved because the retransmission would occur before the
cancel,
	giving enough time for a 408 to propagate. It's possible I
missed
	something, but I think the difference between the 2 suggestions
is the
	cancel timer 64*T1+T4 vs 2*64*T1.

Let's make sure of whether we're on the same page or not; we might be,
but let me describe my scenario in a little more detail. Lets say we
have a _chain_ of proxies between the UAC and UAS, and an INVITE has
already gone through, and everything has sent a 100.

Scenario 1:
Now, suppose UAC CANCELs. P1-Pn all set their CANCEL timer for 64T1+T4,
one after the other, as the CANCEL is forwarded. And let's say UAS is
out to cause trouble, and sends CANCEL/200, but no INVITE/487. What
happens? Seems like P1's CANCEL timer will pop, causing teardown of its
transaction with P2, and sending a 408 to UAC. Very soon after, P2's
timer pops, causing teardown of the P2->P3 transaction, and sends a 408
back to P1. But P1's transaction with P2 is already gone, and so it
never ACKs. This then repeats at each proxy in the chain, so they are
all retransmitting 408 upstream.

Scenario 2:
On the other hand, suppose each proxy sets two timers when they send a
CANCEL; one that will cause a 408 to be sent upstream on the Server
Invite transaction(64*T1, let's call this Timer L), and another that
will cause the Client Invite transaction to be torn down (64*T1+X, let's
call this Timer M). What happens after the CANCEL in this case? P1's
Timer L pops, and it sends a 408 back to UAC. If X is sufficiently
large, P2's Timer L will pop next, and it will send a 408 back to P1
_before_ Timer M pops on P1. We avoid the retransmit storm.

Were you thinking of the technique described in scenario 1, or scenario
2?

At this point, we have the question of how large X needs to be. Setting
X to 64*T1 would ensure that we'd stay around until all possible
retransmissions have been sent (except maybe one, since the downstream
element's retransmit timer starts slightly later, but that won't happen
often). It might be overkill to wait this long, however. We want to set
it to at least T1, but if we do this and the first 408 gets dropped, we
end up with the full compliment of retransmissions.

	ACKing stray responses is something that could have some issues:
	* Not all error responses have contact headers and in that case
it's
	impossible to know the destination.
	* Contact headers may be different than the original request URI
which
	may cause the ACK of an error response to go through a different
path.
	* A source of possible DoS attack (?)

Yeah, we would have to do something non-standard to make this work (like
sending back to the source of the error). I don't think that this
presents a DoS attack that is any worse than just bombarding the server
with requests (since well-meaning elements would not worsen the
problem). I still like the double-timer approach more though.

	Gilad.

Best regards,
Byron Campen

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 21:47:26 +0100

It seems to me as if this is a bug in the spec and there is a proposed
solution. I don't know if this problem will ever be addressed in future
RFCs, but at the very least it should be documented in bugs.sipit.net.

Anyone thinks this is not a bug?

Further comments inline:

From: Iliff, Tina [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 9:53 PM
To: Byron Campen; Gilad Shaham
Cc: Adam Roach; [email-masked]; [email-masked]
Subject: RE: [Sipping] Proxy acting as UAS -- CANCEL scenario

[Gilad Shaham] 

I think we are discussing 2 cases here and both exhibit the similar end
result, but in the case you describe the CANCEL has to be transmitted a
very short time after the INVITE and in the case Byron describes this
pre-condition is not required since all client transactions are waiting
on timer C prior to the CANCEL and all will set their timers to 64*T1
almost at the same time. I think the solution resolves both cases.

Regards,

Tina Iliff

 

		If anyone is really into solving this rare scenario, one
possible

		solution is to wait a bit longer after the CANCEL, for
example 64*T1

+

		T4.

	Unfortunately, this does not really solve the problem. Suppose

we

	have more than one proxy in a chain, each with this timer of
64T1+T4.

	We end up having a problem still (since the first proxy's timer
pops,

	then the second, etc). It seems to me that we should set a timer
for

	transaction later (maybe another 64T1 later). This way, we can
ACK

	downstream.

 

Scenario 1:

Scenario 2:

[Gilad Shaham] I had scenario 2 in mind, with 1 minor difference, I
thought that after 64*T1 seconds the proxy should send 487 since this
timer is a result of a CANCEL. I don't remember what the standard states
on this issue, but it's totally irrelevant.

[Gilad Shaham] I agree, it's a question of how graceful we really want
to be. If the wind blows towards X=64*T1 or X=32 seconds I would
recommend that as soon as the first T1*64 seconds elapse, the INVITE
client transaction state will change from "proceeding" to "completed"
and therefore waits at least 32 seconds for timer D. Meaning timer D's
definition (>32 seconds) will represent X.

I'm not 100% certain it's right to wait that long as I view this as rare
coincidences, but I agree that waiting the full retransmission time is
more in line with the spirit of the RFC.

One more question - should the timer start after sending the CANCEL or
after receiving the 200 OK on the CANCEL? Seems to me that 200 OK is the
right answer because if the CANCEL timer starts as soon as the first
message is transmitted it's possible that the UAS will set its 64*T1
timer quite later "wasting" all the X seconds. Does the standard clearly
specify this?

[Gilad Shaham] Yes, the timer solution seems more solid.

Gilad.

Best regards,

Byron Campen

---

From: "Iliff, Tina" <[email-masked]>
Date: Wed, 06 Jun 2007 20:52:59 +0000

I do believe that this issue warrants a clearly defined solution.
I can possibly think of one or two additional solution scenarios so I am
not sure if your proposed solution is the best solution.
 
Regards,
 
Tina Iliff

From: Gilad Shaham [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 3:47 PM
To: Iliff, Tina; Byron Campen
Cc: Adam Roach; [email-masked]; [email-masked]
Subject: RE: [Sipping] Proxy acting as UAS -- CANCEL scenario

 

Further comments inline:

[Gilad Shaham] 

 

Regards,

Tina Iliff

 

+

		T4.

we

	downstream.

 

Scenario 1:

Scenario 2:

 

Gilad.

Best regards,

Byron Campen

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 22:15:21 +0100

The proposal is only to document it as a bug.

The solution is far from complete. I'm not even sure that the WG will
decide that this issue warrants a solution. If you have comments on this
solution or additional solutions, it will be great if you would provide
them.

From: Iliff, Tina [mailto:[email-masked]] 
Sent: Wednesday, June 06, 2007 11:53 PM
To: Gilad Shaham; Byron Campen
Cc: Adam Roach; [email-masked]; [email-masked]
Subject: RE: [Sipping] Proxy acting as UAS -- CANCEL scenario

Regards,

Tina Iliff

 

Further comments inline:

[Gilad Shaham] 

 

Regards,

Tina Iliff

 

+

		T4.

we

	downstream.

 

Scenario 1:

Scenario 2:

 

Gilad.

Best regards,

Byron Campen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jun 2007 00:30:26 +0200

Isn't the solution simply to not send a 408 response when the "CANCEL timer" 
expires because no 487 was received?

RFC3261 says "[...] the client SHOULD then consider the original transaction 
cancelled and SHOULD destroy the client transaction handling the original 
request."

It does not explicitly say that a 408 should be sent for the INVITE. If it 
is not sent, and all proxies in the chain follow this same logic, there is 
no issue

Regards,
Jeroen

Gilad Shaham wrote:
> decide that this issue warrants a solution. If you have comments on
> this solution or additional solutions, it will be great if you would
> provide them.
>
>
>
>
>
> I can possibly think of one or two additional solution scenarios so I
> am not sure if your proposed solution is the best solution.
>
>
>
> Regards,
>
>
>
> Tina Iliff
>
>
>
> solution. I don't know if this problem will ever be addressed in
> future RFCs, but at the very least it should be documented in
> bugs.sipit.net.
>
> I think we are discussing 2 cases here and both exhibit the similar
> end result, but in the case you describe the CANCEL has to be
> transmitted a very short time after the INVITE and in the case Byron
> describes this pre-condition is not required since all client
> transactions are waiting on timer C prior to the CANCEL and all will
> set their timers to 64*T1 almost at the same time. I think the
> solution resolves both cases.
>
>
>
>
>
> Regards,
>
>
>
> Tina Iliff
>
>
>
> Now, suppose UAC CANCELs. P1-Pn all set their CANCEL timer for
> 64T1+T4, one after the other, as the CANCEL is forwarded. And let's
> say UAS is out to cause trouble, and sends CANCEL/200, but no
> INVITE/487. What happens? Seems like P1's CANCEL timer will pop,
> causing teardown of its transaction with P2, and sending a 408 to
> UAC. Very soon after, P2's timer pops, causing teardown of the P2->P3
> transaction, and sends a 408 back to P1. But P1's transaction with P2
> is already gone, and so it never ACKs. This then repeats at each
> proxy in the chain, so they are all retransmitting 408 upstream.
>
>
>
> Scenario 2:
>
> timer is a result of a CANCEL. I don't remember what the standard
> states on this issue, but it's totally irrelevant.
>
>
>
> I'm not 100% certain it's right to wait that long as I view this as
> rare coincidences, but I agree that waiting the full retransmission
> time is more in line with the spirit of the RFC.
>
> after receiving the 200 OK on the CANCEL? Seems to me that 200 OK is
> the right answer because if the CANCEL timer starts as soon as the
> first message is transmitted it's possible that the UAS will set its
> 64*T1 timer quite later "wasting" all the X seconds. Does the
> standard clearly specify this?
>
>
>
>
>
> server with requests (since well-meaning elements would not worsen the
> [email-masked]

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jun 2007 00:42:40 +0200

Proxy acting as UAS -- CANCEL scenarioTina,

I believe the answer is: no, the proxy should not send 487 when its CANCEL 
timer fires. It should not send any response to the INVITE, only destroy the 
transaction

It appears that the proxy is using a CANCEL timer that is too short. It is 
not allowed to send CANCEL before it receives a 100 trying, it is highly 
unlikely that the CANCEL timer is started before the INVITE Timer B at the 
SBC

RFC3261 17.2 says that a received INVITE should _first_ be passed to the TU, 
and _then_ a 100 trying response should be generated. Depending on SIP stack 
implementation the INVITE can get forwarded before the 100 trying is sent 
back (mine does). Only a high latency towards the next hop could cause a 
race, and then only if a proxy sends a CANCEL extremely shortly after 
receiving 100 (there should probably be a rule that it should wait at least 
T1 after sending the INVITE before sending CANCEL to avoid this race)

Regards,
Jeroen

  ----- Original Message ----- 
  From: Iliff, Tina
  To: [email-masked] ; [email-masked]
  Sent: Monday, June 04, 2007 10:37 PM
  Subject: [Sipping] Proxy acting as UAS -- CANCEL scenario

  All,

  Several seconds elapse and Timer B pops on the SBC and it sends a 408 back 
to the Proxy for the INVITE request

  Question:  Is the proxy behaving correctly by sending the 487 response to 
the INVITE request on its own?

  Regards,

  Tina Iliff

------------------------------------------------------------------------------

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 7 Jun 2007 05:32:18 +0100

Perhaps what's missing is a clarification in section 16.10:
If there is no final response for the original request in 64*T1 seconds,
a proxy MUST follow the procedures described in section 9.1 and SHOULD
destroy the server transaction without generating a final response.

There is still the original scenario that has the pre-condition of small
interval between the CANCEL and INVITE. The severity of the problem
seems lower, but so far I haven't seen this scenario resolved without
the timer change (or simply a decision to ignore this case).

Gilad

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 1:30 AM
> To: Gilad Shaham; Iliff, Tina
> Cc: [email-masked]; [email-masked]; Adam Roach
> Subject: Re: [Sip-implementors] [Sipping] Proxy acting as UAS --
> CANCELscenario
> 
be,
> > On the other hand, suppose each proxy sets two timers when they send
a
which
path.
the

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 7 Jun 2007 05:33:12 +0100

If the first INVITE the proxy forwards gets lost and retransmits you are
back with the same problem, the UAC will send a CANCEL T1 after the
initial INVITE and the UAS will receive the INVITE and the CANCEL at
approximately the same time.

Waiting T1 after receiving 100 trying will work better at delaying the
race condition, but the proxy implementation would become much more
complex. In the CANCEL processing it might have to delay the
cancellation of the server transaction for 500 ms even if 100 trying was
already received.

Gilad

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 1:43 AM
To: Iliff, Tina; [email-masked]; [email-masked]
Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

Tina,

I believe the answer is: no, the proxy should not send 487 when its
CANCEL timer fires. It should not send any response to the INVITE, only
destroy the transaction

It appears that the proxy is using a CANCEL timer that is too short. It
is not allowed to send CANCEL before it receives a 100 trying, it is
highly unlikely that the CANCEL timer is started before the INVITE Timer
B at the SBC

RFC3261 17.2 says that a received INVITE should _first_ be passed to the
TU, and _then_ a 100 trying response should be generated. Depending on
SIP stack implementation the INVITE can get forwarded before the 100
trying is sent back (mine does). Only a high latency towards the next
hop could cause a race, and then only if a proxy sends a CANCEL
extremely shortly after receiving 100 (there should probably be a rule
that it should wait at least T1 after sending the INVITE before sending
CANCEL to avoid this race)

Regards,

Jeroen

	----- Original Message ----- 

	From: Iliff, Tina <mailto:[email-masked]>  

	All, 

	RFC3261 Section 16 states the following regarding Proxy
Behavior: 

	Being a proxy is a logical role for a SIP element. When a
request
	arrives, an element that can play the role of a proxy first
decides
	if it needs to respond to the request on its own. For instance,
the
	request may be malformed or the element may need credentials
from the
	client before acting as a proxy. The element MAY respond with
any appropriate error code. When responding directly to a request, the
	element is playing the role of a UAS and MUST behave as
described in
	Section 8.2.

	OUA sends INVITE to Proxy 
	Proxy sends 100 Trying to OUA 
	Proxy routes INVITE to SBC 
	SBC sends 100 Trying to Proxy 
	SBC routes INVITE to TUA 
	SBC does not receive 100 Trying from TUA and retransmits INVITE
several times 
	OUA sends CANCEL to Proxy 
	Proxy responds to CANCEL with 200OK 
	Proxy routes CANCEL to SBC 
	SBC does not route CANCEL to TUA 
	A CANCEL timer on Proxy pops and Proxy sends 487 for INVITE
request to OUA 
	Several seconds elapse and Timer B pops on the SBC and it sends
a 408 back to the Proxy for the INVITE request 
	The proxy does not ACK the 408 response; therefore, the SBC
retransmits the 408 for 64*T1 seconds 

	Question:  Is the proxy behaving correctly by sending the 487
response to the INVITE request on its own? 

	Regards, 

	Tina Iliff 

	_______________________________________________
	Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
	This list is for NEW development of the application of SIP
	Use [email-masked] for questions on current
sip
	Use [email-masked] for new developments of core SIP

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Thu, 7 Jun 2007 08:38:07 +0200

Proxy acting as UAS -- CANCEL scenarioGilad,

T1 after 100 trying: that's what I meant. Implementation wise it could 
simply be a matter of reusing the retransmission timer of the CANCEL Client 
Transaction.

Another point to change could be to not send a 408 when a CANCEL is received 
but the INVITE ClientTransaction has not yet received a 100. Let the CANCEL 
destroy the INVITE ServerTransaction, and have the INVITE ClientTransaction 
not send any response when the INVITE ServerTransaction is gone

Regards,
Jeroen
  ----- Original Message ----- 
  From: Gilad Shaham
  To: Jeroen van Bemmel ; Iliff, Tina
  Cc: [email-masked] ; [email-masked]
  Sent: Thursday, June 07, 2007 6:33 AM
  Subject: RE: [Sipping] Proxy acting as UAS -- CANCEL scenario

  If the first INVITE the proxy forwards gets lost and retransmits you are 
back with the same problem, the UAC will send a CANCEL T1 after the initial 
INVITE and the UAS will receive the INVITE and the CANCEL at approximately 
the same time.

  Waiting T1 after receiving 100 trying will work better at delaying the 
race condition, but the proxy implementation would become much more complex. 
In the CANCEL processing it might have to delay the cancellation of the 
server transaction for 500 ms even if 100 trying was already received.

  Gilad

  Tina,

  RFC3261 17.2 says that a received INVITE should _first_ be passed to the 
TU, and _then_ a 100 trying response should be generated. Depending on SIP 
stack implementation the INVITE can get forwarded before the 100 trying is 
sent back (mine does). Only a high latency towards the next hop could cause 
a race, and then only if a proxy sends a CANCEL extremely shortly after 
receiving 100 (there should probably be a rule that it should wait at least 
T1 after sending the INVITE before sending CANCEL to avoid this race)

  Regards,

  Jeroen

    ----- Original Message ----- 

    From: Iliff, Tina

    All,

    Regards,

    Tina Iliff

----------------------------------------------------------------------------

---

From: "Gilad Shaham" <[email-masked]>
Date: Thu, 7 Jun 2007 11:58:55 +0100

From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Thursday, June 07, 2007 9:38 AM
To: Gilad Shaham; Iliff, Tina
Cc: [email-masked]; [email-masked]
Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

Gilad,

T1 after 100 trying: that's what I meant. Implementation wise it could
simply be a matter of reusing the retransmission timer of the CANCEL
Client Transaction.

[Gilad Shaham] I'm not sure I understand the solution. Let's see the
following flow:

1. Time = 0 ms:

    a. UAC Sends INVITE to Proxy

    b. Proxy receives INVITE on client transaction

    c. Proxy sends INVITE on server transaction

    d. Proxy responds with 100 on client transaction

2. Time = 500 ms:

    a. Timer A on proxy client transaction fires - INVITE retransmits

    b. UAC Sends CANCEL (500 ms have elapsed from 100 trying to CANCEL,
so it's ok)

    c. Proxy receives 100 trying on server transaction - Now timer A and
timer B are dropped, Timer C is set to 3 minutes.

    d. Proxy receives CANCEL on client transaction.

    e. Proxy sends 200 OK on CANCEL.

    f. Proxy cannot forward 200 OK because 500 ms have not elapsed since
it received 100 trying on client transaction.

    g. UAC receives 200 OK on CANCEL, CANCEL transaction ends. INVITE
transaction will terminate in 64*T1 seconds if it has not received final
response.

3. Time = 1000 ms:

    a. Proxy is supposed to create a new transaction and send CANCEL.
What is the source of the event? It seems to me the proxy has to set a
special timer at step 2.f.

After breaking it down I think that this solution is equivalent in
strength to the previous solution where X=T1. This means that if the
first retransmission of 408 would drop, we the rest of the 408 responses
will not receive an ACK because the transactions would be dropped.

Another point to change could be to not send a 408 when a CANCEL is
received but the INVITE ClientTransaction has not yet received a 100.
Let the CANCEL destroy the INVITE ServerTransaction, and have the INVITE
ClientTransaction not send any response when the INVITE
ServerTransaction is gone

[Gilad Shaham] I agree.

Regards,

Jeroen

	----- Original Message ----- 

	From: Gilad Shaham <mailto:[email-masked]>  

	To: Jeroen van Bemmel <mailto:[email-masked]>  ; Iliff, Tina
<mailto:[email-masked]>  

	If the first INVITE the proxy forwards gets lost and retransmits
you are back with the same problem, the UAC will send a CANCEL T1 after
the initial INVITE and the UAS will receive the INVITE and the CANCEL at
approximately the same time.

	Waiting T1 after receiving 100 trying will work better at
delaying the race condition, but the proxy implementation would become
much more complex. In the CANCEL processing it might have to delay the
cancellation of the server transaction for 500 ms even if 100 trying was
already received.

	Gilad

	From: Jeroen van Bemmel [mailto:[email-masked]] 
	Sent: Thursday, June 07, 2007 1:43 AM
	To: Iliff, Tina; [email-masked];
[email-masked]
	Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

	Tina,

	I believe the answer is: no, the proxy should not send 487 when
its CANCEL timer fires. It should not send any response to the INVITE,
only destroy the transaction

	It appears that the proxy is using a CANCEL timer that is too
short. It is not allowed to send CANCEL before it receives a 100 trying,
it is highly unlikely that the CANCEL timer is started before the INVITE
Timer B at the SBC

	RFC3261 17.2 says that a received INVITE should _first_ be
passed to the TU, and _then_ a 100 trying response should be generated.
Depending on SIP stack implementation the INVITE can get forwarded
before the 100 trying is sent back (mine does). Only a high latency
towards the next hop could cause a race, and then only if a proxy sends
a CANCEL extremely shortly after receiving 100 (there should probably be
a rule that it should wait at least T1 after sending the INVITE before
sending CANCEL to avoid this race)

	Regards,

	Jeroen

		----- Original Message ----- 

		From: Iliff, Tina
<mailto:[email-masked]>  

		Subject: [Sipping] Proxy acting as UAS -- CANCEL
scenario

		All, 

		Being a proxy is a logical role for a SIP element. When
a request
		arrives, an element that can play the role of a proxy
first decides
		if it needs to respond to the request on its own. For
instance, the
		request may be malformed or the element may need
credentials from the
		client before acting as a proxy. The element MAY respond
with any appropriate error code. When responding directly to a request,
the
		element is playing the role of a UAS and MUST behave as
described in
		Section 8.2.

		OUA sends INVITE to Proxy 
		Proxy sends 100 Trying to OUA 
		Proxy routes INVITE to SBC 
		SBC sends 100 Trying to Proxy 
		SBC routes INVITE to TUA 
		SBC does not receive 100 Trying from TUA and retransmits
INVITE several times 
		OUA sends CANCEL to Proxy 
		Proxy responds to CANCEL with 200OK 
		Proxy routes CANCEL to SBC 
		SBC does not route CANCEL to TUA 
		A CANCEL timer on Proxy pops and Proxy sends 487 for
INVITE request to OUA 
		Several seconds elapse and Timer B pops on the SBC and
it sends a 408 back to the Proxy for the INVITE request 
		The proxy does not ACK the 408 response; therefore, the
SBC retransmits the 408 for 64*T1 seconds 

		Question:  Is the proxy behaving correctly by sending
the 487 response to the INVITE request on its own? 

		Regards, 

		Tina Iliff 

		_______________________________________________
		Sipping mailing list
https://www1.ietf.org/mailman/listinfo/sipping
		This list is for NEW development of the application of
SIP
		Use [email-masked] for questions on
current sip
		Use [email-masked] for new developments of core SIP

---

From: Byron Campen <[email-masked]>
Date: Thu, 7 Jun 2007 08:34:30 -0500

This is the simpler solution, since it can be worded as a  
clarification to 3261, as opposed to new behavior. The only issue I  
see is the case where the proxy tears transactions down because of  
Timer C; the call is over, but the UAC never hears about it. Of  
course, UAs are expected to eventually time out in this case, usually  
as a result of the user abandoning the call. But it seems that this  
is a sub-optimal user experience. (This may not be enough to warrant  
the extra complexity of the double-timer approach, however.) Thoughts?

Best regards,
Byron Campen

> Isn't the solution simply to not send a 408 response when the  
> "CANCEL timer" expires because no 487 was received?
>
> RFC3261 says "[...] the client SHOULD then consider the original  
> transaction cancelled and SHOULD destroy the client transaction  
> handling the original request."
>
> It does not explicitly say that a 408 should be sent for the  
> INVITE. If it is not sent, and all proxies in the chain follow this  
> same logic, there is no issue
>
> Regards,
> Jeroen
>
> Gilad Shaham wrote:

---

From: Byron Campen <[email-masked]>
Date: Wed, 6 Jun 2007 16:32:17 -0500

Stuff inline:

Best regards,
Byron Campen

> It seems to me as if this is a bug in the spec and there is a  
> proposed solution. I don’t know if this problem will ever be  
> addressed in future RFCs, but at the very least it should be  
> documented in bugs.sipit.net.
>
> Allow me to correct your description of the scenario just a bit.   
> The correction is that everything sends a 100 Trying to the INVITE  
> EXCEPT for the last element, the UAS.
>
>
>
> [Gilad Shaham]
>
> transmitted a very short time after the INVITE and in the case  
> Byron describes this pre-condition is not required since all client  
> transactions are waiting on timer C prior to the CANCEL and all  
> will set their timers to 64*T1 almost at the same time. I think the  
> be, but let me describe my scenario in a little more detail. Lets  
> say we have a _chain_ of proxies between the UAC and UAS, and an  
> INVITE has already gone through, and everything has sent a 100.
>
>
>
> UAS is out to cause trouble, and sends CANCEL/200, but no INVITE/ 
> 487. What happens? Seems like P1's CANCEL timer will pop, causing  
> teardown of its transaction with P2, and sending a 408 to UAC. Very  
> soon after, P2's timer pops, causing teardown of the P2->P3  
> transaction, and sends a 408 back to P1. But P1's transaction with  
> P2 is already gone, and so it never ACKs. This then repeats at each  
> On the other hand, suppose each proxy sets two timers when they  
> send a CANCEL; one that will cause a 408 to be sent upstream on the  
> Server Invite transaction(64*T1, let's call this Timer L), and  
> another that will cause the Client Invite transaction to be torn  
> down (64*T1+X, let's call this Timer M). What happens after the  
> CANCEL in this case? P1's Timer L pops, and it sends a 408 back to  
> UAC. If X is sufficiently large, P2's Timer L will pop next, and it  
> will send a 408 back to P1 _before_ Timer M pops on P1. We avoid  
> the retransmit storm.
>
>
>
> thought that after 64*T1 seconds the proxy should send 487 since  
> this timer is a result of a CANCEL. I don’t remember what the  
> standard states on this issue, but it’s totally irrelevant.
>
>
	I can't find any text that specifies one way or the other for this  
particular case, but in general, INVITE transactions that are torn  
down because of a timeout send back a 408.

> possible retransmissions have been sent (except maybe one, since  
> the downstream element's retransmit timer starts slightly later,  
> but that won't happen often). It might be overkill to wait this  
> long, however. We want to set it to at least T1, but if we do this  
> and the first 408 gets dropped, we end up with the full compliment  
> of retransmissions.
>
> [Gilad Shaham] I agree, it’s a question of how graceful we really  
> want to be. If the wind blows towards X=64*T1 or X=32 seconds I  
> would recommend that as soon as the first T1*64 seconds elapse, the  
> INVITE client transaction state will change from “proceeding” to  
> “completed” and therefore waits at least 32 seconds for timer D.  
> Meaning timer D’s definition (>32 seconds) will represent X.
>
>
	Agreed.

> I’m not 100% certain it’s right to wait that long as I view this as  
> One more question – should the timer start after sending the CANCEL  
> or after receiving the 200 OK on the CANCEL? Seems to me that 200  
> OK is the right answer because if the CANCEL timer starts as soon  
> as the first message is transmitted it’s possible that the UAS will  
> set its 64*T1 timer quite later “wasting” all the X seconds. Does  
> the standard clearly specify this?
	Good point, although any response will do in the place of the 200  
(including a timeout on the CANCEL). The standard does not specify this.

> this presents a DoS attack that is any worse than just bombarding  
> the server with requests (since well-meaning elements would not  
> worsen the problem). I still like the double-timer approach more  
> though.
>

---

From: "Nayak, Subhransu S" <[email-masked]>
Date: Thu, 7 Jun 2007 22:06:26 -0400

Let's take some call flows into acoounting while deciding the right behavior  for the stateful proxy or, the SBC.
 
UAC        Proxy
                              UAS
 -------> INV (UAS-p) 
 <------ 100 
               UAC-p -------->
                     <------- 100 
 --------> CANCEL
 <------- 200 ok CANCEL
                 UAC-p ---------> CANCEL
                        CANCEL transaction times out
 Proxy ( UAS-p ) should send 408 back to UAC. This would indicate the request timeout at proxy while attempting to route the request to UAS.

UAC        Proxy
                              UAS
 -------> INV (UAS-p) 
 <------ 100 
               UAC-p -------->
                      
 --------> CANCEL
 <------- 200 ok CANCEL
                  UAC-p ---------> INVITE
                         Timer B expires
 Proxy ( UAS-p ) should send 408 back to UAC. This would indicate the request timeout at proxy while attempting to route the INVITE to UAS.

UAC        Proxy
                              UAS
 -------> INV (UAS-p) 
 <------ 100 
               UAC-p --------> INVITE
                     <------- 100 
 --------> CANCEL
 <------- 200 ok CANCEL
                      ---------> CANCEL
                      <-------- 200 ok CANCEL 
          This completes the CANCEL transaction at UAC-p , however INVITE client transaction at UAC-p is in proceeding state waiting for the final response i.e. 487 . Proxy relies on timer C to clean up the transaction resources.
               
If UAC-p never receives 487 from the UAS , and time C fires at proxy , then proxy should clean up its transaction resources. Proxy shouldn't attempt to send 487 back to the UAC . Now, there is known issue in RFC 3261 - Invite client transaction at UAC is not protected in the proceeding state by any timer. Now the implementation can choose the timeout ( as long as it is more than 64 *T1 ) to clean up the client transaction.  

Thanks,
- Subhransu
 
-----Original Message-----
From: Byron Campen [mailto:[email-masked]]
Sent: Thursday, June 07, 2007 9:35 AM
To: Jeroen van Bemmel
Cc: Iliff, Tina; [email-masked]; [email-masked];
Gilad Shaham; Adam Roach

Best regards,
Byron Campen

>> proposed

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 8 Jun 2007 05:53:23 +0100

We have spread across many discussions. I think we reached some
conclusions, but the original scenario is still open, so I'm trying to
summarize what we have been saying. This is based on my understanding of
this discussion, so I hope I did not forget anything anyone said and
that I got it right. Please correct me anywhere I got this wrong or
missed anything.

Here is our original scenario:

         Alice          Proxy 1          Proxy 2          Bob
          |                |               |              |
          |    INVITE F1   |               |              |
          |--------------->|               |              |
          |                |  INVITE F2    |              |
          |  100 Trying F3 |-------------->|              |
          |<---------------|               |  INVITE F4   |
          |                |100 Trying F5  |------------->|
          |                |<--------------|              |
          |    CANCEL F6   |               |              |
          |--------------->|               |              |
          |                |   CANCEL F7   |              |
          |    200 OK F8   |-------------->|              |
          |<---------------|               |              |
          |                |  200 OK F9    |              |
          |                |<--------------|              |
          |                |               |              |
          |                |408 Timeout F10|              |
          |                |<--------------|              |

We assume that F1 and F6 occur at a very short interval and consequently
so are F4 and F9.

Alice
    * Destroys the client transaction 64*T1 after receiving F8,
      as described in RFC 3261/9.1
Proxy 1:
    * Destroys the client transaction 64*T1 after receiving F9,
      as described in RFC 3261/9.1
    * 64*T1 seconds after F6, it should destroy server transaction.
      Some of us think this should be clarified.
Proxy 2:
    * T1*64 seconds after F4, timer B fires on client transaction.
      The proxy sends a 408 response. It's possible there is a race
      Condition with the proxy 1 that destroys client transaction 64*T1
      after F9.
Bob:
    * Bob cannot really send a final response anymore. If he does it
      would not receive an ACK.

We already raised 2 items that might need to be clarified:
1. If there is no final response on the INVITE transaction after CANCEL,
the the proxy should silently destroy the _server_ transaction T1*64
seconds after CANCEL was received.
2. The client transaction should be destroyed by CANCEL T1*64 seconds
after receiving 200 OK on CANCEL or on as soon as the CANCEL transaction
times out.

These are the possible options to resolve the race condition, based on
the discussion:
1. Change description in section 9.1, allow client transaction to wait
for X additional seconds (where X is at least T1). Server transaction
should still drop after 64*T1 seconds.
2. Answer stay error responses with ACK.
3. Delay the CANCEL transaction for at least T1 after 100 trying.

Another option that is similar to the solution raised in a different,
but similar, scenario is to refrain from sending the 408 in the first
place. The proxy detects it received a CANCEL before sending 408 and
lets the transaction terminate due to the CANCEL.

My personal opinion is that this last option is the simpler than the
other solutions we discussed.

Gilad

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 8 Jun 2007 09:38:44 +0200

Gilad,

see inline

Regards,
Jeroen

Gilad Shaham wrote:
> summarize what we have been saying. This is based on my understanding
> of this discussion, so I hope I did not forget anything anyone said
> and that I got it right. Please correct me anywhere I got this wrong
> or missed anything.
>
> We assume that F1 and F6 occur at a very short interval and
> consequently so are F4 and F9.
>
> Alice
[jvb] I interpret RFC3261 as saying 64*T1 after sending F6. But it could 
also be read as 64*T1 after sending the original INVITE (F1)

>       as described in RFC 3261/9.1

[jvb] For sending the CANCEL the proxy acts as a UAC. However, a proxy does 
not need a separate CANCEL timer, since it has Timer C which will eventually 
clean up the INVITE transactions. This is actually another solution: have 
proxies wait for Timer C, and not 64*T1

>       Condition with the proxy 1 that destroys client transaction
>       64*T1 after F9.

[jvb] Reading RFC3261 16.8 (timer C processing) it could also be argued that 
Proxy 2 should immediately generate a 408 response for the INVITE at this 
point. It cannot forward the CANCEL since it has not yet received a 
provisional response. It could wait for this, but sending 408 immediately 
avoids the RACE condition nicely. To be complete it should still generate a 
CANCEL upon receiving a provisional response for the INVITE, any final 
responses should be blocked

> 1. If there is no final response on the INVITE transaction after
> CANCEL, the the proxy should silently destroy the _server_
> transaction T1*64 seconds after CANCEL was received.
> after receiving 200 OK on CANCEL or on as soon as the CANCEL
> transaction times out.
>
>

[jvb] As remarked, a 5th solution is to have proxies rely on Timer C 
(minimum 3 minutes) and not start a 64*T1 timer upon CANCEL. RFC3261 16.8 
says that upon timer C firing the proxy MUST either generate a CANCEL (when 
a provisional response was received) or behave as if 408 was received.

Timer C would ensure that all proxies still have the transaction state when 
the 408 for the INVITE arrives (F10). This leaves only the missing state at 
the UAC

A 6th solution is to have proxies which receive CANCEL but cannot forward it 
due to not having received a provisional response, send a 408 for the INVITE 
immediately

---

From: Spencer Dawkins <[email-masked]>
Date: Fri, 08 Jun 2007 05:59:08 -0500

Replying to Gilad using Jeroen's posting (because he's adding proposed 
solutions)...

From: "Jeroen van Bemmel" <[email-masked]>

> says that upon timer C firing the proxy MUST either generate a CANCEL 
> (when a provisional response was received) or behave as if 408 was 
> received.
>
> Timer C would ensure that all proxies still have the transaction state 
> when the 408 for the INVITE arrives (F10). This leaves only the missing 
> state at the UAC
>
> A 6th solution is to have proxies which receive CANCEL but cannot forward 
> it due to not having received a provisional response, send a 408 for the 
> INVITE immediately

Some of these possible options are more robust in the case of significant 
signaling path degredation (ex 1, because "server should still drop after 
64*T1 seconds") than others (ex. 3, because "Delay the CANCEL transaction 
for at least T1 after 100 trying." just puts off the same situation for 
another T1 timeout period).

Is the degree of robustness important, when discussing these alternatives?

Thanks,

Spencer

---

From: Byron Campen <[email-masked]>
Date: Fri, 8 Jun 2007 08:27:55 -0500

Inline:

> 64*T1
> CANCEL,

	I still like this.

> 2. Answer stay error responses with ACK.

	This would be a pretty large change from what the spec presently  
requires; ie statelessly forwarding the response (which I honestly  
don't like). If we only apply it to UAs, we end up statelessly  
forwarding the response to the UA, which then ACKs, and then the  
first proxy treats the ACK like an ACK/200 (since it no longer knows  
the transaction-id). Will this work?

> 3. Delay the CANCEL transaction for at least T1 after 100 trying.

	I just want to remind everyone that if the UAS is malicious, and  
_does_ send back a 100 before going non-responsive, this approach  
does not help us. We need a solution that will work in this scenario,  
because this scenario can be triggered at will by UAS once it  
receives an INVITE.

	Also, we have the option of just not forwarding 408s. If everything  
is compliant, it will cope.

Best regards,
Byron Campen

---

From: "Gilad Shaham" <[email-masked]>
Date: Fri, 8 Jun 2007 15:59:03 +0100

I think it is a factor, but probably not the only factor.
Solution 3 seems less robust and Byron detected other problems in it as
well.
Solution 2 is a significant change (also noted by Byron) and probably
overkill.

The rest of the solutions seem to have the same robustness. Maybe
solution 5 is a little too robust as it waits 3 minutes until closing
the transaction.

There is a 7th solution that is not very robust, but it's the simplest -
do nothing and accept this "limitation".

Gilad

> From: Spencer Dawkins [mailto:[email-masked]]
> Sent: Friday, June 08, 2007 1:59 PM
> To: Jeroen van Bemmel; Gilad Shaham; Iliff, Tina; Byron Campen
> Cc: [email-masked]; [email-masked]; Adam Roach

---

From: Byron Campen <[email-masked]>
Date: Fri, 8 Jun 2007 10:57:48 -0500

So, to recap:
1. Double-timer approach (applies to all sip-elements).
2. ACK stray responses (all elements, or just proxies).
3. Delay CANCEL by T1 after provisional (all elements, or just proxies).
4. Don't forward 408 in these cases (proxies).
5. Don't use a timeout for CANCEL at proxies, rely on Timer C (proxies).
6. Forward back an INVITE/408 immediately upon receiving a CANCEL, if  
client transaction hasn't gotten a provisional (proxies).
7. Leave things as-is.

	I don't think 6 is workable. It seems like this would break existing  
deployments. Solution can 5 end up triggering the same sort of  
behavior if the UAS is non-responsive (ie, all the INVITEs and 100s  
have been sent, _*including*_ a 100 from the UAS, and then Timer C  
pops at each proxy one-by-one). Also, solution 5 can really eat up  
state.

	Obviously, 7 is not acceptable to me either. I don't like giving  
every UAS in the world free reign to DoS the network.

	I have already voiced my objection to 3, and a lesser issue with 2.  
The two approaches that I think are most likely to work well are 1  
and 4. I think that the deciding factor for me would be how many  
proxies already do not forward back 408. If most proxies already  
follow solution 4, then I would favor it more strongly. On the other  
hand, if most proxies are forwarding back 408 in these scenarios, I  
would favor 1 more strongly, since in this case solution 4 would  
change the externally observable behavior of most proxies.

	It appears to me (right now) that most proxies forward back 408 (I  
know repro does, and I am pretty sure SER does as well), hence by  
bias toward solution 1. However, I do not know for sure, and if it  
turns out I am wrong, I have no problem with backing solution 4.

Best regards,
Byron Campen

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 8 Jun 2007 18:17:01 +0200

There is an additional option: don't generate a 408 if CANCEL was received 
for the INVITE

Regards,
Jeroen

Byron Campen wrote:
> 3. Delay CANCEL by T1 after provisional (all elements, or just
> proxies). 4. Don't forward 408 in these cases (proxies).
> 5. Don't use a timeout for CANCEL at proxies, rely on Timer C
> (proxies). 6. Forward back an INVITE/408 immediately upon receiving a 
> CANCEL, if
>>>>> These are the possible options to resolve the race condition,
>>>>> based on the discussion:
>>>>> 1. Change description in section 9.1, allow client transaction to
>>>>> wait for X additional seconds (where X is at least T1). Server
>>>>> transaction should still drop after 64*T1 seconds.
>>>>> Another option that is similar to the solution raised in a
>>>>> different, but similar, scenario is to refrain from sending the
>>>>> 408 in the first place. The proxy detects it received a CANCEL
>>>>> before sending 408 and lets the transaction terminate due to the
>>>>> CANCEL.
>>>>
>>>> [jvb] As remarked, a 5th solution is to have proxies rely on Timer
>>>> C (minimum 3 minutes) and not start a 64*T1 timer upon CANCEL.
>>>> RFC3261 16.8 says that upon timer C firing the proxy MUST either
>>>> generate a CANCEL (when a provisional response was received) or
>>>> behave as if 408 was received.
>>>>
>>>> Timer C would ensure that all proxies still have the transaction
>>>> state when the 408 for the INVITE arrives (F10). This leaves only
>>>> the missing state at the UAC
>>>>
>>>> A 6th solution is to have proxies which receive CANCEL but cannot
>>>> forward it due to not having received a provisional response, send
>>>> a 408 for the INVITE immediately
>>>
>>> Some of these possible options are more robust in the case of
>>> significant signaling path degredation (ex 1, because "server
>>> should still drop after 64*T1 seconds") than others (ex. 3, because
>>> "Delay the CANCEL transaction for at least T1 after 100 trying."
>>> just puts off the same situation for another T1 timeout period).
>>>
>>> Is the degree of robustness important, when discussing these
>>> alternatives? Thanks,
>>>
>>> Spencer

---

From: "Iliff, Tina" <[email-masked]>
Date: Fri, 08 Jun 2007 16:25:15 +0000

All,

Thank you so much for the great discussion on this issue!  Personally, I
am leaning towards agreeing with Byron's preferred approaches.
I definitely agree that approach 5. would cause state to remain for too
long in all elements and the UAC (originating element) would already
have destroyed the INVITE transaction.

What happened to the discussion on a proxy responding with a 487
immediately on the INVITE transaction if it has received a CANCEL
request prior to receiving a 100 Trying (in the case where the CANCEL
arrives after T1).  The only issue which I might see with this scenario
is a race condition with the 100 Trying if the proxy does not also send
the CANCEL downstream.

Regards, 

Tina Iliff

-----Original Message-----
From: Byron Campen [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 10:58 AM
To: Gilad Shaham
Cc: Adam Roach; Iliff, Tina; [email-masked];
[email-masked]

	So, to recap:

	I don't think 6 is workable. It seems like this would break
existing deployments. Solution can 5 end up triggering the same sort of
behavior if the UAS is non-responsive (ie, all the INVITEs and 100s have
been sent, _*including*_ a 100 from the UAS, and then Timer C pops at
each proxy one-by-one). Also, solution 5 can really eat up state.

	I have already voiced my objection to 3, and a lesser issue with
2.  
The two approaches that I think are most likely to work well are 1 and
4. I think that the deciding factor for me would be how many proxies
already do not forward back 408. If most proxies already follow solution
4, then I would favor it more strongly. On the other hand, if most
proxies are forwarding back 408 in these scenarios, I would favor 1 more
strongly, since in this case solution 4 would change the externally
observable behavior of most proxies.

	It appears to me (right now) that most proxies forward back 408
(I know repro does, and I am pretty sure SER does as well), hence by
bias toward solution 1. However, I do not know for sure, and if it turns
out I am wrong, I have no problem with backing solution 4.

Best regards,
Byron Campen

> Solution 3 seems less robust and Byron detected other problems in it 
> as well.
> There is a 7th solution that is not very robust, but it's the simplest

> - do nothing and accept this "limitation".
>
> Gilad
>
>> Replying to Gilad using Jeroen's posting (because he's adding 
>> proposed solutions)...
>>
> wait
> different,

> state
>> forward
> significant
> alternatives?

---

From: "Iliff, Tina" <[email-masked]>
Date: Fri, 08 Jun 2007 16:31:51 +0000

Would this imply having each element destroy the INVITE transaction at
64*T1 after receipt or sending of the CANCEL request?

Regards, 

Tina Iliff

-----Original Message-----
From: Jeroen van Bemmel [mailto:[email-masked]] 
Sent: Friday, June 08, 2007 11:17 AM
To: Byron Campen; Gilad Shaham
Cc: Spencer Dawkins; Iliff, Tina; [email-masked];
[email-masked]; Adam Roach
Subject: Re: [Sipping] Proxy acting as UAS -- CANCEL scenario

There is an additional option: don't generate a 408 if CANCEL was
received for the INVITE

Regards,
Jeroen

Byron Campen wrote:
> CANCEL, if client transaction hasn't gotten a provisional (proxies).
> 7. Leave things as-is.
>
> Obviously, 7 is not acceptable to me either. I don't like giving every

> UAS in the world free reign to DoS the network.
>

> already do not forward back 408. If most proxies already follow 
> solution 4, then I would favor it more strongly. On the other hand, if

> most proxies are forwarding back 408 in these scenarios, I would favor

> 1 more strongly, since in this case solution 4 would change the 
> externally observable behavior of most proxies.
>
> know repro does, and I am pretty sure SER does as well), hence by bias

> toward solution 1. However, I do not know for sure, and if it turns 

>> the transaction.
>>
>> There is a 7th solution that is not very robust, but it's the 
>> simplest - do nothing and accept this "limitation".
>>
>> Gilad
>>
>>> significant signaling path degredation (ex 1, because "server should

>>> still drop after 64*T1 seconds") than others (ex. 3, because "Delay 
>>> the CANCEL transaction for at least T1 after 100 trying."

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Fri, 8 Jun 2007 18:37:46 +0200

Yes, destroyed without generating any final response (408 or other)

Filtering all stray 408s for INVITEs at proxies is too rigorous. RFC4320 
already takes care of not generating and filtering stray 408 for non-INVITE, 
I think this particular case warrants the same for 408 on INVITE. After all, 
the firing of the 64*T1 timer can be considered as a timeout on the CANCEL 
request (end-2-end that is, the next hop may have answered the CANCEL itself 
but there is no 487 which indicates it reached the other endpoint)

Regards,
Jeroen

Iliff, Tina wrote:
>> every
>> and
>> bias
>>>> should

---

From: "Gilad Shaham" <[email-masked]>
Date: Sat, 9 Jun 2007 01:25:13 +0100

Refraining from generating the 408 is the way I see solution 4.

I tend to agree that solutions 1 and 4 are the best candidates. How
about a combination of solutions 1 and 4:
* If a proxy receives CANCEL on client transaction, it should not
generate a 408 response.
* If a proxy receives a final response after CANCEL was received and
before 64*T1 seconds elapsed, it should forward the response.
* If a CANCEL was received and there is no final response on the
original request in 64*T1 seconds, the proxy should destroy the server
transaction without sending a final response.
* In case of CANCEL and no final response on the original request in
64*T1 seconds, a UAC (including a proxy) should keep the client
transaction for additional X seconds beyond the first 64*T1 seconds.
* If the proxy receives a final error response on the client transaction
after the server transaction was destroyed, the proxy will send an ACK
and will NOT forward the response.

I think this option interops well with elements that do not implement
this procedure.

I hope the wording is clear - obviously if the concept is agreed then it
needs to be formalized.
If the concept is ok, there are some small things to close, such as what
is X and the exact event that starts the 64*T1 timer for CANCEL, but
these can be concluded later.

Gilad

> Sent: Friday, June 08, 2007 7:38 PM
> To: Iliff, Tina; Byron Campen; Gilad Shaham
> Cc: Adam Roach; [email-masked]; [email-masked]
> I think this particular case warrants the same for 408 on INVITE.
After
> all,
existing

---

From: Byron Campen <[email-masked]>
Date: Sat, 9 Jun 2007 10:27:31 -0500

You are absolutely correct. Solution 1 by itself only fixes the  
client INVITE transaction at a proxy that implements it. Solution 4  
by itself fixes the server INVITE transaction. Combined, these will  
protect both. This is a perfect example of applying Postel's law. I  
think we should do both.

Best regards,
Byron Campen