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!
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.
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
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@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
-
Anders -
Henning Westerholt -
Iñaki Baz Castillo