3 Nov
2009
3 Nov
'09
7:37 p.m.
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(a)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