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

[Iñaki Baz Castillo]

El Lunes, 21 de Septiembre de 2009, Andrei Pelinescu-Onciul escribió:
> > 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).

Yes, that's the case of how a "wrong" 6XX from a UAS breaks a so common 
feature as voicemail.

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

And that's the reason why I ask for a disable_6xx_block parameters as it 
exists in original Kamailio's TM module. Some UA's use 603 to reject a call 
breaking any parallel forking or serial forking (i.e. voicemail service).

It would be great if disable_6xx_block would be implemented as an optional 
flag in t_relay() function.


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

Yes. It's needed (IMHO) to "fix" a wrong behaviour of UA's rejecting calls 
with 603 instead of using a more appropriate code as 480 or 403.


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

Doesn't SR's TM module implement these features?

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

I think it's the correct order. 


Regards.


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