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

[Iñaki Baz Castillo <[e-mail]>]

2010/5/2 Paul Kyzivat <[e-mail]>:
>> 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
<[e-mail]>