[SR-Users] TM clarifications Re: CANCEL before INVITE + loose_route()

[Iñaki Baz Castillo]

2010/6/21 Alex Balashov <abalashov at evaristesys.com>:
> Iñaki,
>
> On 06/21/2010 03:35 AM, Iñaki Baz Castillo wrote:
>
>> But from the server/proxy point of view it doesn't matter. This is, if
>> the proxy has received an INVITE it doesn't matter if it has replied a
>> provisional response or not, it already *can* handle a CANCEL from the
>> client. The only requeriment is having a transaction created for such
>> INVITE (which occurs when calling t_relay or t_newtran).
>
> If the proxy has created a transaction for the INVITE and receives a CANCEL
> from initiating UAC before any provisional response has been received from
> UAS, will it forward the CANCEL to the UAS, or just quietly discard it while
> returning 200 to the UAC because it has a transaction for the INVITE that is
> being canceled?

It the same as when UAC to proxy, as here we are speaking about
transaction clients which exist in the UAC and the proxy.
This is, if the proxy receives a CANCEL for an INVITE (without having
yet provisional responses from the destination UAS) then the proxy's
transaction client *cannot* send a CANCEL as a race condition could
occur (such CANCEL arriving to the UAS before the INVITE). The proxy
must wait until a 1XX is received (or release the outgoing transaction
after 64xT1 as usual by generating a local 408).

And yes, the proxy in this case must also reply 200 to the UAC. In
fact, the proxy must reply 200 for the CANCEL inmediately (CANCEL is
hop by hop) if such transaction exists. Later, the proxy must
terminate all the possible branches it has generated by sending a
CANCEL to those for which it has a 1xx response.


> I assume it will not forward CANCEL without having received a reply of some
> kind, but since it is not a UA and is not subject to the same rules, I
> wonder.

The proxy is subject to the same rules as here we are speaking about
transaction client, present in UAC and proxy when creating an outgoing
transaction :)

Regards.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>