- cancel_b_method is now 1 by default => changes default cancel unreplied

 branch behaviour: keep retransmitting the INVITE until a response is received
 or the timeout kicks in (if the received response is provisional a CANCEL
 will be automatically sent back). To revert to the old behaviour (stop
 retransmissions and send back fake 487s) use
 modparam("tm", "cancel_b_method", 0).

NEWS

@@ -55,11 +55,12 @@ modules:
                         - cancel_b_method - selects one of the three methods
                           for dealing with unreplied branches when the 
                           transaction must be canceled. The possible values
-                          are 0 (default and old behaviour) for stopping 
-                          request retransmission on the branch and act as if 
+                          are 0 (old behaviour) for stopping request 
+                          retransmission on the branch and act as if 
                           the branch was immediately replied with a 487,
                           1 for continuing to retransmit the request until an
-                          answer is received or the timeout kicks in and
+                          answer is received or the timeout kicks in (default)
+                          and
                           2 for stopping the request retransmission and sending
                           CANCEL on the branch (not rfc conforming).
                           For more information see tm docs.

modules/tm/README

@@ -368,7 +368,8 @@ cancel_b_method (integer)
    have an UA receiving a 2xx after a 487. Moreover this risk is greatly
    amplified by packet loss (e.g. if an 180 is lost the branch will look
    as unreplied and a CANCEL will silently drop the branch, but a 2xx can
-   still come at a later time).
+   still come at a later time). This is the behaviour for ser versions
+   older then 2.1.
 
    1 will keep retransmitting the request on unreplied branches. If a
    provisional answer is later received a CANCEL will be immediately sent
@@ -384,8 +385,7 @@ cancel_b_method (integer)
    it's not RFC 3261 conforming (the RFC allows sending CANCELs only on
    pending branches).
 
-   The default value is 0 (the same behaviour as ser versions less then
-   2.1).
+   The default value is 1.
 
    Example 18. Set cancel_b_method parameter
 ...

modules/tm/config.c

@@ -87,7 +87,7 @@ struct cfg_group_tm	default_tm_cfg = {
 			 * timeouts by default */
 	~METHOD_BYE,	/* tm_blst_methods_lookup -- look-up the blacklist
 			 * for every method except BYE by default */
-	0,	/* cancel_b_method used for e2e and 6xx cancels*/
+	1,	/* cancel_b_method used for e2e and 6xx cancels*/
 	1,	/* reparse_on_dns_failover */
 };
 

modules/tm/doc/params.xml

@@ -445,7 +445,7 @@ modparam("tm", "blst_methods_lookup", 1)
 		 487. Moreover this risk is greatly amplified by packet loss
 		(e.g. if an 180 is lost the branch will look as unreplied and
 		 a CANCEL will silently drop the branch, but a 2xx can still come at
-		 a later time).
+		 a later time). This is the behaviour for ser versions older then 2.1.
 	</para>
 	<para>
 		<emphasis>1</emphasis> will keep retransmitting the request on 
@@ -464,8 +464,7 @@ modparam("tm", "blst_methods_lookup", 1)
 		conforming (the RFC allows sending CANCELs only on pending branches).
 	</para>
 	<para>
-		The default value is 0 (the same behaviour as ser versions
-		less then 2.1).
+		The default value is 1.
 	</para>
 	<example>
 	    <title>Set <varname>cancel_b_method</varname> parameter</title>