On Mar 02, 2010 at 20:10, I?aki Baz Castillo ibc@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