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

[Paul Kyzivat <[e-mail]>]

Iñaki Baz Castillo wrote:
> 2010/5/2 Paul Kyzivat <[e-mail]>:
>> 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