[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