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

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

2010/5/2 Paul Kyzivat <pkyzivat@cisco.com>:
>> 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
<ibc@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-implementors@cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch@ietf.org for new developments on the application of sip.
Use sipcore@ietf.org for issues related to maintenance of the core SIP specifications.