[sr-dev] git:andrei/cancel_reason: tm: Reason header copy for received CANCELs

Andrei Pelinescu-Onciul andrei at iptel.org
Wed Mar 3 15:11:44 CET 2010


On Mar 02, 2010 at 20:10, I?aki Baz Castillo <ibc at aliax.net> wrote:
> El Martes, 2 de Marzo de 2010, Andrei Pelinescu-Onciul escribi?:
> > tm: Reason header copy for received CANCELs
> > 
> > When canceling branches due to a received CANCEL, use the Reason
> > headers in the received CANCEL (all the Reason headers from the
> > received CANCEL will be copied in the generated CANCELs, see
> > RFC3326 for more details).
> 
> 
> 
> Hi Andrei, great addition. However there could be a minor security issue:
> 
> Perhaps 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:

I've added support for it. It can be turned on/off per transaction by
using t_set_no_e2e_cancel_reason(0|1). The default state is controlled
by e2e_cancel_reason modparam or runtime config variable
(e.g. sercmd cfg.set_now_int tm e2e_cancel_reason 0 # disable).

> 
>   if (is_method("CANCEL")) {
>     if ($si == MY_APPLICATION_SERVER_IP)
>       # Allow propagating "Reason" header.
>       t_relay(0x12);
        ^^^^^^^^^^^^^
        this would look like this:
        t_set_no_e2e_cancel_reason(1);
        t_relay();
>     else
>       t_relay();
>   }

Note that you could use t_set_no_e2e_cancel_reason() at any time, before
or after creating the transaction.
local_cancel_reason can be turned on/off independently, but only
globally (I couldn't find any reason for wanting to do it per
transaction).


Andrei



More information about the sr-dev mailing list