[sr-dev] personal summary of what still needs to be done

[Andrei Pelinescu-Onciul]

On Sep 19, 2009 at 15:55, I?aki Baz Castillo <ibc at aliax.net> wrote:
> El S?bado, 19 de Septiembre de 2009, Andrei Pelinescu-Onciul escribi?:
> > However one can override it, by simply adding branches in the failure
> > route (the ideea being that if you add a branch in the failure route,
> > you know what you're doing an you want forking re-enabled). If I understand
> > correctly this is mostly equivalent to disable_6xx_block=1, at least for 
> > the voicemail scenario.
> > 
> > Am I correct in assuming that we don't need it, because sr handles this
> > automatically?
> 
> You miss the usual case in which there is parallel forking and a "wrong" UAS 
> replies 603 "Decline" (instead of a better 480 code). The 603 reply makes the 
> proxy cancelling the parallel branch (still ringing in other branch) and this 
> is, commonly, an undesirable behaviour.

Juha asked initially for voicemail after 6xx (which should work out of
the box).

Just to clarify:
in the above case SR will send a CANCEL on all the open branches that
have not received a final reply yet.  (so the "ringing" should stop on
all of them)

> 
> So IMHO, "disable_6xx_block" as it's implemented in Kamailio TM module should 
> also exist in SR as its funcionality is not covered by the current code.

So what you want is a treat 6xxx like a normal reply config option
(both parallel forking and cancel branches disabled)?


BTW here are other possible differences in reply handling:

 - received 503 triggers dns failover. If 503 is the final reply, it's
   replaced with a 500. Also if the blst_503 parameter is on (default
   off), the source of the 503 reply is blacklisted (using the value
   in the Retry-After header if present and the blst_503 def_timeout,
   min_timeout and max_timeout parameters).
 - if the final reply is 401 or 407, all the www & proxy auth. headers
   from all the 401 & 407 replies received on all the branches are
   aggregated into the final reply (can be turned off with
   aggregate_challenges).
 
 - reply priority (negative reply that wins):
   6xx
   3xx
   4xx
   5xx

   4xx priority: 401, 407, 415, 420, 484 and then the rest (ascending
   order of their number)

   With the exception of 4xx, all other replies in the same class, are
   sorted according to their number (e.g. 501 wins over 502).


Andrei