El Miércoles, 3 de Marzo de 2010, Andrei Pelinescu-Onciul escribió:
On Mar 02, 2010 at 20:10, I?aki Baz Castillo
<ibc(a)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).
Great :)
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.
So this can be set during INVITE transaction, right? this is really better
than what I suggested.
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).
Neither me as such "Reason" header is trusted (it has been created locally by
SR, so it's safe to allow it always).
Thanks a lot.
--
Iñaki Baz Castillo <ibc(a)aliax.net>