Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 May 2010 00:17:44 -0400

Iñaki,

I don't understand what the point is of sending, or forwarding, this 
CANCEL. There is nothing left to cancel. The only possibility would be 
if the INVITE had been forked somewhere along the path. But if it had, 
the forking proxy would have seen the 200 and sent a CANCEL on its own. 
So there is no reason for the UAC to send a CANCEL in this case.

	Thanks,
	Paul

Iñaki Baz Castillo wrote:
> Hi, RFC 3261 clearly states that an INVITE transaction is terminated
> upon receipt of a 200. So let's imagine a proxy between alice and bob:
> 
> - alice sends INVITE to the proxy.
> - The proxy relays it to bob.
> - bob replies 200.
> - The proxy relays the 200 to alice and terminates the INVITE transaction.
> - For some reason alice sends now a CANCEL.
> - The proxy doesn't match a transaction for this CANCEL so it would
> relay it statelessly as section 16.10 states:
> 
>    If a response context is not found, the element does not have any
>    knowledge of the request to apply the CANCEL to.  It MUST statelessly
>    forward the CANCEL request (it may have statelessly forwarded the
>    associated request previously).
> 
> 
> This makes sense because such "response context" doesn't exist after
> the 200 was processed by the proxy. However "invfix" draft adds a new
> state "Accepted" so when the proxy relays the 200 the transaction
> remains in "Accepted" state for a while. What should happen then if
> the UAC sends a CANCEL? does the "response context" still exist or
> not?
> 
> So I suggest that "invfix" draft also changes the section 16.10 of RFC 3261:
> 
>    If no transaction in proceeding state is found, the element does not have any
>    knowledge of the request to apply the CANCEL to.  It MUST statelessly
>    forward the CANCEL request (it may have statelessly forwarded the
>    associated request previously).
> 
> 
> This is, even if the transaction still exists (under "Accepted" state)
> the proxy has nothing to CANCEL so it shouldn't reply 200 to the
> CANCEL. Instead it should forward it statelessly. I think this
> requires some clarification in the original specification of the RFC
> 3261.
> 
> Best regards.
> 
>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 2 May 2010 12:43:24 +0200

2010/5/2 Paul Kyzivat <[email-masked]>:
> Iñaki,
>
> I don't understand what the point is of sending, or forwarding, this CANCEL.
> There is nothing left to cancel. The only possibility would be if the INVITE
> had been forked somewhere along the path. But if it had, the forking proxy
> would have seen the 200 and sent a CANCEL on its own. So there is no reason
> for the UAC to send a CANCEL in this case.

Hi Paul, I do know that the UAC shouldn't send the CANCEL, but it
could occur (race conditions, 200 reply lost in the network...). So
the proxy must know how to behave when a CANCEL arrives for an INVITE
transaction in "Accepted" state, something that doesn't make sense in
the original 3261 specification as the proxy terminates the INVITE
transaction when the 200 arrives (immediately).

I think innfix draft should clarify it: what should do a proxy when a
CANCEL arrives and matches an INVITE transaction in "Accepted" state?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 02 May 2010 14:05:04 -0400

> CANCEL arrives and matches an INVITE transaction in "Accepted" state?

Ok, if you are only concerned with being clear about this, and not that 
it is something of general utility. It seems it doesn't really matter 
whether the CANCEL is propagated by the proxy or not, since it is 
destined to be a no-op. It would be more efficient to block its 
propagation, but given the rarity of the situation I don't think it 
really matters.

	Thanks,
	Paul

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Sun, 2 May 2010 20:17:31 +0200

2010/5/2 Paul Kyzivat <[email-masked]>:
> Ok, if you are only concerned with being clear about this, and not that it
> is something of general utility. It seems it doesn't really matter whether
> the CANCEL is propagated by the proxy or not, since it is destined to be a
> no-op. It would be more efficient to block its propagation, but given the
> rarity of the situation I don't think it really matters.

The problem I've seen is in an existing SIP proxy which mantains the
INVITE transaction in memory after 200 arrives. It does it even before
invfix draft exists (this is, the proxy already fixes the bug in RFC
3261). However when such proxy receives a CANCEL for an INVITE
transaction for which the proxy has already sent a 200, it replies 200
to the CANCEL. This doesn't make sense (as it has canceled nothing
because the transaction was already confirmed by the UAS).

So I would like to know the correct behavior of the proxy in this case
in order to improve/report it. However I would like such behavior to
be clarified in draft invfix as with the original 3261 specification
there was no place to this ambiguity (a CANCEL would never match an
INVITE transaction as the proxy terminated it upon receipt of a 200
for the INVITE).

Statelessly relaying the CANCEL makes no sense for me, it seems an
exotic "feature" as many others that never work. In fact, draft invfix
states that a stateful proxy should not relay responses if they don't
match a transaction, so the possible 481 response to the CANCEL coming
from the UAS would be dropped by the proxy and UAC would generate
useless retransmissions. Same would occur if the proxy just
ignores/drops the CANCEL.

So IMHO a response by the proxy is needed. Perhaps a 481 as the INVITE
transaction is not active (but in "Accepted" state). Anything but a
200.

Thanks.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 24 May 2010 13:46:10 +0200

Hi,

My understanding is that 200 OK for the CANCEL only means "Ok, I got the request". 

It is the INVITE response that matters. If the INVITE transaction was cancelled, the UAC would not have received a 200 OK for the INVITE.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki Baz Castillo
Sent: 2. toukokuuta 2010 21:18
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

2010/5/2 Paul Kyzivat <[email-masked]>:
> Ok, if you are only concerned with being clear about this, and not 
> that it is something of general utility. It seems it doesn't really 
> matter whether the CANCEL is propagated by the proxy or not, since it 
> is destined to be a no-op. It would be more efficient to block its 
> propagation, but given the rarity of the situation I don't think it really matters.

The problem I've seen is in an existing SIP proxy which mantains the INVITE transaction in memory after 200 arrives. It does it even before invfix draft exists (this is, the proxy already fixes the bug in RFC 3261). However when such proxy receives a CANCEL for an INVITE transaction for which the proxy has already sent a 200, it replies 200 to the CANCEL. This doesn't make sense (as it has canceled nothing because the transaction was already confirmed by the UAS).

So I would like to know the correct behavior of the proxy in this case in order to improve/report it. However I would like such behavior to be clarified in draft invfix as with the original 3261 specification there was no place to this ambiguity (a CANCEL would never match an INVITE transaction as the proxy terminated it upon receipt of a 200 for the INVITE).

Statelessly relaying the CANCEL makes no sense for me, it seems an exotic "feature" as many others that never work. In fact, draft invfix states that a stateful proxy should not relay responses if they don't match a transaction, so the possible 481 response to the CANCEL coming from the UAS would be dropped by the proxy and UAC would generate useless retransmissions. Same would occur if the proxy just ignores/drops the CANCEL.

So IMHO a response by the proxy is needed. Perhaps a 481 as the INVITE transaction is not active (but in "Accepted" state). Anything but a 200.

Thanks.

--
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email-masked] for questions on how to develop a SIP implementation.
Use [email-masked] for new developments on the application of sip.
Use [email-masked] for issues related to maintenance of the core SIP specifications.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Mon, 24 May 2010 15:00:44 +0200

> It is the INVITE response that matters. If the INVITE transaction was cancelled, the UAC would not have received a 200 OK for the INVITE.

Hi, let me re-explain my example (assuming the proxy implements invfix draft:

- alice sends INVITE to the proxy.
- The proxy relays it to bob.
- bob replies 200.
- The proxy relays the 200 to alice. The INVITE transaction in the
proxy remains in "Accepted" state (invfix addition).
- alice sends now a CANCEL (before receiving the 200 for the INVITE).
- The proxy receives the CANCEL and matches the existing INVITE
transaction (in "Accepted" state), what should it reply? "200
Canceled"? there is nothing to cancel right now as a 200 was already
received by the proxy.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Harbhanu <[email-masked]>
Date: Tue, 25 May 2010 11:19:51 +0530

IMO it's correct for proxy to reply with '200 CANCEL', evne incase it has
already forwarded a final response.
Here, since the UAC will receive the final response of INVITE, then it will
send a BYE.

We can relate its similarity to handling of CANCEL at UAS after being sent
an INVITE 2xx, as per 3261 itself -
   If the transaction for the original request still exists, the behavior of
the UAS on receiving a CANCEL request depends on whether it has already sent
a final response for the original request.

Also, similar race might happen when there are multiple stateful proxies in
path and CANCEL and INVITE 2xx are converging towards each other from
different UA ends.

Thus as said below, it simply means "Ok, I got the request".

Regards,
Harbhanu

****************************************************************************
***********
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Iñaki
Baz Castillo
Sent: Monday, May 24, 2010 6:31 PM
To: Christer Holmberg
Cc: [email-masked]; Paul Kyzivat
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix
(CANCELprocessing)

2010/5/24 Christer Holmberg <[email-masked]>:
> It is the INVITE response that matters. If the INVITE transaction was
cancelled, the UAC would not have received a 200 OK for the INVITE.

Hi, let me re-explain my example (assuming the proxy implements invfix
draft:

-- 
Iñaki Baz Castillo
<[email-masked]>
_______________________________________________
Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use [email-masked] for questions on how to develop a SIP
implementation.
Use [email-masked] for new developments on the application of sip.
Use [email-masked] for issues related to maintenance of the core SIP
specifications.