[Kamailio-Devel] Flags are not visible when processing CANCEL

[Daniel-Constantin Mierla]

Hello,

back to original topic, indeed the flags from INVITE are not visible to 
CANCEL, but for future we can introduce $T_inv(pv) in the same way we 
have now $T-req(pv) to access requests in onreply routes and $T_rpl(pv) 
to access reply in failure_route.
http://www.kamailio.org/dokuwiki/doku.php/pseudovariables:1.5.x#t_req_pv

Cheers,
Daniel


On 05/22/2009 04:37 PM, Iñaki Baz Castillo wrote:
> 2009/5/22 Alex Balashov <abalashov at evaristesys.com>:
>
>   
>> Hmm, that's true.  End-to-end CANCELs aren't sent by the originating UA to
>> the destination URI of the far end, are they?  Otherwise they would be
>> routed like any other sequential in-dialog request, and they're not.
>>     
>
> For generating an in-dialog request you need first having a dialog or
> early-dialog (To tag). It could not occur (UAC sends INVITE, proxy
> replies "100 Trying" and after a while the UAC sends a CANCEL).
>
>
>   
>> I'm curious, why are they designed that way?  Why not route end-to-end
>> CANCELs the same way one routes end-to-end BYEs?
>>     
>
> The CANCEL is sent to the proxy (or the SIP node in front of the UAC).
> Imagine the UAC sends the INVITE, the proxy does parallel forking so
> the UA Creceives various 1XX with different "To tags". If CANCEL would
> be end-to-end and an in-dialog request, then the UAC should generate
> so many CANCEL's as different "To tags" received in the 1XX responses.
>
> So, when an UAC sends a CANCEL it is asking its proxy to CANCEL the
> INVITE transaction at all, so the proxy replies "200 cancelled" and
> later, the proxy handles all the pending branches by sending a CANCEL
> to each one.
>
> It's easier in this way :)
>
>
>
>   
>> --
>> Alex Balashov
>> Evariste Systems
>> Web     : http://www.evaristesys.com/
>> Tel     : (+1) (678) 954-0670
>> Direct  : (+1) (678) 954-0671
>>
>>     
>
>
>
>   

-- 
Daniel-Constantin Mierla
http://www.asipto.com/