Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

[Iñaki Baz Castillo]

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.

[Paul Kyzivat]

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

Post by Iñaki Baz Castillo
Hi, RFC 3261 clearly states that an INVITE transaction is terminated
- 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
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?
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.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenanc

[Iñaki Baz Castillo]

Post by Paul Kyzivat
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?

[Paul Kyzivat]

Post by Iñaki Baz Castillo

Post by Paul Kyzivat
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?

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to

[Iñaki Baz Castillo]

Post by Iñaki Baz Castillo
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?

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.

[Christer Holmberg]

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: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of Iñaki Baz Castillo
Sent: 2. toukokuuta 2010 21:18
To: Paul Kyzivat
Cc: ***@ietf.org
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix (CANCEL processing)

Post by Paul Kyzivat

Post by Iñaki Baz Castillo
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?

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

Post by Christer Holmberg
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.

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.

[Harbhanu]

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: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of Iñaki
Baz Castillo
Sent: Monday, May 24, 2010 6:31 PM
To: Christer Holmberg
Cc: ***@ietf.org; Paul Kyzivat
Subject: Re: [Sip] Possible improvement in draft-ietf-sipcore-invfix
(CANCELprocessing)

Post by Christer Holmberg
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.


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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP
implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP
specifications.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.