[sr-dev] RFC 3326 (Reason header) for CANCEL (TM addition)

[Daniel-Constantin Mierla]

Hi Inaki,

I have 1) in my to-do, maybe others have it too (which would be great if 
they do it first :-) ). For 2) there is an option to propagate headers 
from invite to cancel via ac_extra_headers tm parameter, I guess it is 
easy to extend the functionality to get headers from received cancel as 
well.

Cheers,
Daniel


When I looked

On 2/10/10 1:03 PM, Iñaki Baz Castillo wrote:
> Hi, it would be great if TM implements RFC 3326 by adding a Reason header in
> CANCEL. I explain the use cases:
>
>
>
> 1) Parallel forking:
>
> - alice calls bob through Proxy.
>
> - Proxy does parallel forking to two locations from which bob is registered
> (bob1 and bob2).
>
> - Both phones ring. After a while bob2 answers.
>
> - Proxy generates a CANCEL for bob1 and includes a header:
>      Reason: SIP ;cause=200 ;text="Call completed elsewhere"
>
> - By inspecting such header (cause=200) bob1 device decides not to include
> this call in the list of "missed calls".
>
>
>
> 2) Propagating CANCEL + Reason from an application server or PBX.
>
> - alice calls bob through PBX.
>
> - The PBX "forkes" (no need to really fork as it's a B2BUA/UAC and could just
> generate two different INVITE), and calls to bob's SIP phone and bob's mobile
> (through a PSTN gateway).
>
> - The INVITE to bob's SIP phone is sent to bob's inbound Proxy. The Proxy
> routes the request to the location of bob.
>
> - Bob human was out so answers the call in his mobile.
>
> - The PBX sends a CANCEL to Proxy including the header:
>      Reason: SIP ;cause=200 ;text="Call completed elsewhere"
>
> - Such CANCEL arrives to Proxy. As CANCEL is hop by hop the Proxy generates
> its own CANCEL but due to local policy (i.e. the CANCEL comes from the trusted
> PBX) it *propagates* the Reason header.
>
> - Again bob's SIP phone receives the CANCEL with such Reason header and
> decides not to include this call in the list of "missed calls".
>
>
>
> This is very useful feature IMHO as bob won't waste time by calling to all of
> those non real "missed" calls.
>
>
>
> At implementation level I would consider the following:
>
> - Case 1 doesn't require parameters or script decissions (IMHO) so it's safe
> to add Reason header in a CANCEL when cancelling a branch (in parallel
> forking).
>
> - Case 2 requires a local policy as it wouldn't be safe to propagate any
> Reason header coming in a CANCEL from any sender (imagine you receive a
> malicius call at 5 o'clock in the night and the hacker added "Reason" header
> to the CANCEL so you don't find that call in the missed calls list of the
> phone).
>
> - This local policy could be implemented as follows:
>
> a) Enabling a flag in t_relay() that only makes sense for CANCEL rather than
> INVITE, so:
>
>    if (is_method("CANCEL")) {
>      if ($si == MY_APPLICATION_SERVER_IP)
>        # Allow propagating "Reason" header.
>        t_relay(0x12);
>      else
>        t_relay();
>    }
>
> or a explicit flag:
>
>    if (is_method("CANCEL")) {
>      if ($si == MY_APPLICATION_SERVER_IP)
>        setflag(FLAG_ALLOW_CANCEL_REASON);
>      t_relay();
>    }
>
>
>
> As a side note, Asterisk does implement this Reason header when calls to
> various phones for the same call. Also, this feature is implemented in
> OpenSIPS TM module (case 1 is already implemented and case 2 will be
> implemented soon).
>
>
>
> Do you consider feasible implementing it? opinnions?
> I would like to try it by myself, but being the serious TM module I would like
> to know your opinnions first :)
>
> Regards.
>
>
>
>
>    

-- 
Daniel-Constantin Mierla
eLearning class for Kamailio 3.0.0
Starting Feb 8, 2010
* http://www.asipto.com/