[sr-dev] RFC 3326 (Reason header) for CANCEL (TM addition)

Iñaki Baz Castillo ibc at aliax.net
Wed Feb 10 13:03:27 CET 2010


Hi, it would be great if TM implements RFC 3326 by adding a Reason header in 
CANCEL. I explain the use cases:



1) Parallel forking:

- alice calls bob through Proxy.

- Proxy does parallel forking to two locations from which bob is registered 
(bob1 and bob2).

- Both phones ring. After a while bob2 answers.

- Proxy generates a CANCEL for bob1 and includes a header:
    Reason: SIP ;cause=200 ;text="Call completed elsewhere"

- By inspecting such header (cause=200) bob1 device decides not to include 
this call in the list of "missed calls".



2) Propagating CANCEL + Reason from an application server or PBX.

- alice calls bob through PBX.

- The PBX "forkes" (no need to really fork as it's a B2BUA/UAC and could just 
generate two different INVITE), and calls to bob's SIP phone and bob's mobile 
(through a PSTN gateway).

- The INVITE to bob's SIP phone is sent to bob's inbound Proxy. The Proxy 
routes the request to the location of bob.

- Bob human was out so answers the call in his mobile.

- The PBX sends a CANCEL to Proxy including the header:
    Reason: SIP ;cause=200 ;text="Call completed elsewhere"

- Such CANCEL arrives to Proxy. As CANCEL is hop by hop the Proxy generates 
its own CANCEL but due to local policy (i.e. the CANCEL comes from the trusted 
PBX) it *propagates* the Reason header.

- Again bob's SIP phone receives the CANCEL with such Reason header and 
decides not to include this call in the list of "missed calls".



This is very useful feature IMHO as bob won't waste time by calling to all of 
those non real "missed" calls.



At implementation level I would consider the following:

- Case 1 doesn't require parameters or script decissions (IMHO) so it's safe 
to add Reason header in a CANCEL when cancelling a branch (in parallel 
forking).

- Case 2 requires a local policy as 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);
    else
      t_relay();
  }

or a explicit flag:

  if (is_method("CANCEL")) {
    if ($si == MY_APPLICATION_SERVER_IP)
      setflag(FLAG_ALLOW_CANCEL_REASON);
    t_relay();
  }



As a side note, Asterisk does implement this Reason header when calls to 
various phones for the same call. Also, this feature is implemented in 
OpenSIPS TM module (case 1 is already implemented and case 2 will be 
implemented soon).



Do you consider feasible implementing it? opinnions?
I would like to try it by myself, but being the serious TM module I would like 
to know your opinnions first :)

Regards.




-- 
Iñaki Baz Castillo <ibc at aliax.net>



More information about the sr-dev mailing list