404 sparks next gw and 503

[Anders-26]

Hi,

This list becomes a mix of high-level tech and low-level beginner
questions... - and I'm in the latter group. Making two lists might be
over-kill, though.

Here's my issue:

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?

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?

Thanks!

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

El Martes, 3 de Noviembre de 2009, Anders escribió:

> Hi,
>
> This list becomes a mix of high-level tech and low-level beginner
> questions... - and I'm in the latter group. Making two lists might be
> over-kill, though.
>
> Here's my issue:
>
> 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?
>
> 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?

You are using lcr module, right?
Then you must not call "next_gw()" if the reply is 404 (as it's a correct
response), and instead just forward the response.


--
Iñaki Baz Castillo <ibc@...>

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Henning Westerholt-2]

Some parts of this message have been removed. Learn more about Nabble's security policy.

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

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users

[Anders-26]

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@...> 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

_______________________________________________
Kamailio (OpenSER) - Users mailing list
Users@...
http://lists.kamailio.org/cgi-bin/mailman/listinfo/users
http://lists.openser-project.org/cgi-bin/mailman/listinfo/users