[Serdev] [Patch] Ability to check negative reply code in the failure_route

[Zeus Ng]

I ask a similar question last year and here is the answer from Jiri. 
http://lists.iptel.org/pipermail/serusers/2004-May/008360.html

It explains the reasons why status is not available in failure route. It
further explain why t_check_status() should be used. He did mentioned to
deprecate status in a later mail but obviously there still exists demand on
using it. Thus, status is still available. Now, I'm not going to debate
which method is better, I find using one function does unified the way
checking status. A lot of new comers have set their foot on examples using
t_check_status(), introducing new mechanism of similar thing will create
unnecessary questions from the community. (like rtpproxy vs mediaproxy,
which one is better?)

As for the syntax, I have no trouble using t_check_status() verse status.
Certainly this is subjective and you can say what you like. For now, I'll
stick with t_check_status until something greater, better comes up.

Zeus

 
> -----Original Message-----
> From: serdev-bounces at lists.iptel.org 
> [mailto:serdev-bounces at lists.iptel.org] On Behalf Of Dan Pascu
> Sent: Tuesday, 8 March 2005 12:47 AM
> To: serdev at lists.iptel.org
> Cc: Maxim Sobolev
> Subject: Re: [Serdev] [Patch] Ability to check negative reply 
> code in the failure_route
> 
> 
> On Monday 07 March 2005 15:14, Maxim Sobolev wrote:
> > Looks like that it does what we want, the main problem then is the 
> > lack of proper documentation. However, my patch may be still valid 
> > since it provides unified way to access negative status in failure 
> > route similar to the way to check status in reply route.
> 
> Having a consistent way of doing the tests is good, none 
> argues with that. I asked just because I was curious if this 
> new approach acts any different 
> than the old one, except for the more convenient way of calling it.
> 
> In fact the most consistent way of doing the test, would be 
> if the status in 
> the failure route would be available under the same name: 
> 'status', not like 
> failure_status (i.e. 'status' always holds the status code no 
> matter if in 
> on_reply or failure routes and you write the test the same 
> way in both of 
> them). I'm not sure if that is possible though.
> 
> > Alternatively, use of status
> > builtin in the routing script should be depreciated in the favour of
> > t_check_status(), which provides the same functionality.
> 
> I wouldn't deprecate status. status is better than 
> t_check_status() from one 
> point of view: it is clear from the syntax if it applies to a regular 
> expression match or a simple comparison match depending what 
> operator you 
> use, while for t_check_status() you need to read the docs to 
> know what type 
> of parameter it accepts and how is interpreted.
> Because of this status is better: is simpler and more 
> intuitive to use.
> 
> 
> -- 
> Dan
> 
> _______________________________________________
> Serdev mailing list
> serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
> 
>