On Sep 21, 2009 at 21:34, I?aki Baz Castillo <[email protected]> wrote: [...] > > > 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?
It does, what's listed are differences in reply handling from ser 0.9.x. I don't know what k does, so I listed them just in case someone needs a different behviour and we need another switch for turning something off (the default behaviour is rfc conformant, but so is the 6xx handling :-)). > > > > - 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. Andrei _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
