4 Mar
2010
4 Mar
'10
1:11 a.m.
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?:
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).
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:
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