Browse code

- 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).

Andrei Pelinescu-Onciul authored on 11/03/2008 22:05:44
Showing 4 changed files
... ...
@@ -55,11 +55,12 @@ modules:
55 55
                         - cancel_b_method - selects one of the three methods
56 56
                           for dealing with unreplied branches when the 
57 57
                           transaction must be canceled. The possible values
58
-                          are 0 (default and old behaviour) for stopping 
59
-                          request retransmission on the branch and act as if 
58
+                          are 0 (old behaviour) for stopping request 
59
+                          retransmission on the branch and act as if 
60 60
                           the branch was immediately replied with a 487,
61 61
                           1 for continuing to retransmit the request until an
62
-                          answer is received or the timeout kicks in and
62
+                          answer is received or the timeout kicks in (default)
63
+                          and
63 64
                           2 for stopping the request retransmission and sending
64 65
                           CANCEL on the branch (not rfc conforming).
65 66
                           For more information see tm docs.
... ...
@@ -368,7 +368,8 @@ cancel_b_method (integer)
368 368
    have an UA receiving a 2xx after a 487. Moreover this risk is greatly
369 369
    amplified by packet loss (e.g. if an 180 is lost the branch will look
370 370
    as unreplied and a CANCEL will silently drop the branch, but a 2xx can
371
-   still come at a later time).
371
+   still come at a later time). This is the behaviour for ser versions
372
+   older then 2.1.
372 373
 
373 374
    1 will keep retransmitting the request on unreplied branches. If a
374 375
    provisional answer is later received a CANCEL will be immediately sent
... ...
@@ -384,8 +385,7 @@ cancel_b_method (integer)
384 384
    it's not RFC 3261 conforming (the RFC allows sending CANCELs only on
385 385
    pending branches).
386 386
 
387
-   The default value is 0 (the same behaviour as ser versions less then
388
-   2.1).
387
+   The default value is 1.
389 388
 
390 389
    Example 18. Set cancel_b_method parameter
391 390
 ...
... ...
@@ -87,7 +87,7 @@ struct cfg_group_tm	default_tm_cfg = {
87 87
 			 * timeouts by default */
88 88
 	~METHOD_BYE,	/* tm_blst_methods_lookup -- look-up the blacklist
89 89
 			 * for every method except BYE by default */
90
-	0,	/* cancel_b_method used for e2e and 6xx cancels*/
90
+	1,	/* cancel_b_method used for e2e and 6xx cancels*/
91 91
 	1,	/* reparse_on_dns_failover */
92 92
 };
93 93
 
... ...
@@ -445,7 +445,7 @@ modparam("tm", "blst_methods_lookup", 1)
445 445
 		 487. Moreover this risk is greatly amplified by packet loss
446 446
 		(e.g. if an 180 is lost the branch will look as unreplied and
447 447
 		 a CANCEL will silently drop the branch, but a 2xx can still come at
448
-		 a later time).
448
+		 a later time). This is the behaviour for ser versions older then 2.1.
449 449
 	</para>
450 450
 	<para>
451 451
 		<emphasis>1</emphasis> will keep retransmitting the request on 
... ...
@@ -464,8 +464,7 @@ modparam("tm", "blst_methods_lookup", 1)
464 464
 		conforming (the RFC allows sending CANCELs only on pending branches).
465 465
 	</para>
466 466
 	<para>
467
-		The default value is 0 (the same behaviour as ser versions
468
-		less then 2.1).
467
+		The default value is 1.
469 468
 	</para>
470 469
 	<example>
471 470
 	    <title>Set <varname>cancel_b_method</varname> parameter</title>