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

[Maxim Sobolev]

Dan Pascu wrote:
> On Tuesday 08 March 2005 16:15, Maxim Sobolev wrote:
> 
>>In the case when user have been ringed have not picked up call timely
>>the PSTN gateway should use 480 Temporarily Unavailable not 408. Check
>>RFC for details. Any abuse of 408 should be reported to the gateway's
>>vendor instead.
> 
> 
> Well, I'm sure you realize the funny part or your post. SER is in the same 
> boat in this regard since it generates a 408 not a 480 after a phone has 
> ringed but was not answered before the INVITE timeout did expire.

Looks like you are correct. I have not been aware of INV_FR_TIME_OUT. I 
am not quite sure if SER should be adjusted to generate different 
response codes in this case or not. Also it seems that it should take 
into consideration Expires HF instead of hardcoding 120 seconds.

In fact the really funny part of your own post is that you will get 
locally generated 408 not only in the case when gateway can't be reached 
but also in the case when final recipient has been ringed but has not 
answered in 120 seconds. :-P

However, even assuming that you can distinguish between 408 generated 
locally due to no reply received from the remote UAS at all from 408 
generated after INV_FR_TIME_OUT, my point is broader than just that. 
Such detection of whether or not 408 has been generated locally has 
limited practical utility for the purpose of failure routing since in 
real world conditions you can't be sure where you are sending your call. 
Before finally reaching PSTN gateway the request can pass through 
several transaction-stateful SIP proxies, each of them can generate 408 
if next hop is down. Therefore, assuming that 408 received from the 
remote gateway means something is just plain wrong.

I do not rule out situation, though, that in some cases such detection 
can be handy.

-Maxim

> But anyway, what it generates is not the issue here. Also what the PSTN 
> gateway sends back is not the issue either.
> 
> The issue is to determine if the 408 that was generated internally by SER is a 
> result of the fact that the gateway is dead and didn't reply at all, or the 
> fact that the INVITE timeout did expire because the user didn't answer.
> 
> So it is all about distinguishing in which context falls a 408 that was 
> _internally_ generated by SER. Nothing to do with what the PSTN gateway sends 
> back.
> 
> Nevermind this however, as meanwhile I found a way to determine the context in 
> which the 408 was generated using some ser.cfg tricks.
>