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

[Atle Samuelsen]

Hi Maxim,

I have'nt had time to look at your patch yet, but I was wondering if
this would impliment a way to check if a user is unreachable because he
infact times-out after a invite, (no sip-message from 100->199) or if he
timesout because the fr_inv_timer timesout, (sip-message-from 100->199)


The reason I want to distiguis on this is that if a user is temporary
offline, and still in location, or just timeout because he does'nt take
the phone.


I'll look at the patch later tonight (or tomorrow)

-Atle


* Dan Pascu <dan at ag-projects.com> [050307 14:47]:
> 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
>