[Kamailio-Users] 404 sparks next gw and 503
Anders
vaerge at gmail.com
Tue Nov 3 19:37:05 CET 2009
Hi Henning and Iñaki,
Thank you for the feedback.
It's been solved by handling it in the failure_route - doing pretty
much what Henning suggests. This works great and gets me more
transparent stats on how the call turned out if it doesn't get
through.
Thanks!
On Tue, Nov 3, 2009 at 1:32 PM, Henning Westerholt
<henning.westerholt at 1und1.de> wrote:
> On Dienstag, 3. November 2009, Anders wrote:
>> [..]
>
> Hello Anders,
>
>> My call termination provider is rightfully returning a 404 for a call
>> to a number that doesn't exist. This currently seems to spark Kamailio
>> to look for the next gw, but in this case there is no next gw set up
>> in the lcr/gw - so it returns a 503 to the caller. If I'm confident
>> that my provider is right that there is no such number, and 404 is the
>> correct answer, wouldn't it be better to return a 404 to the caller
>> rather than a 503? With 503 stats also get screwed up, because my
>> client can just see a bunch of 503s, which is not a very detailed
>> picture of the real situation.
>>
>> If I should return a 404, how would I go about this? What would I do
>> in cfg to ensure that a 404 return does not spark it to look for a
>> next gw, but sends 404 back to the caller?
>
> How do you re-route the call for the received 404? If you do it in the
> normal failure_route, just check for the received reply code, and stop
> execution on a 404. For example like this:
>
> failure_route[1] {
> if (t_check_status("404")) {
> exit;
> }
> ... normal processing follows
> }
>
>> Alternatively, I could try to figure out how to get the return from my
>> provider saved to the acc table on the INVITE record, and I'd have
>> something more detailed to run stats on. Does that make sense?
>
> Normally the failure from the upstream provider should inserted in the
> accounting just fine. If you want to store the result code from previous
> attempts (like the 404) you could store in in a AVP, and evaluate this later
> on.
>
> Regards,
>
> Henning
More information about the Users
mailing list