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 <[email protected]> _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
