Hi,
In our ser.cfg we do a database query to determine if the dialed number is a valid subscriber, if the user dialed a wrong number then it is sent to an IVR prompt. This works well most of the time, but every now an then we see calls that were dialed properly yet they where transfered to the prompt. I would like to know how long exec_msg waits for the query result and if it is tunable. The database is on the same host as ser so the result should be very fast, yet I am unsure as to why it is failing to query the subscriber table many times a day.
MySQL is set for 1000 connections and I am not seeing a problem here. Any other MySQL things to look at?
Here is the code snippet:
#Now check to see if Dialed Number is Valid for one of our Subs if (method == "INVITE"){ if (!exec_msg(' QUERY="select username from subscriber where username="$SIP_OUSER""; RESULT=`mysql -uXXX -pXXX -e "$QUERY" ser`; if [ -z "$RESULT" ]; then exit 1; fi ;')) {# User Does Not Exist rewriteuser("9993"); log(1, "Wrong Number IVR Prompt\n"); route(6); break; }; };
Our estimates indicate this fails about 5% of the time. Any ideas?
At 03:22 AM 8/13/2004, Andres wrote:
Hi,
In our ser.cfg we do a database query to determine if the dialed number is a valid subscriber, if the user dialed a wrong number then it is sent to an IVR prompt. This works well most of the time, but every now an then we see calls that were dialed properly yet they where transfered to the prompt. I would like to know how long exec_msg waits for the query result and if it is tunable.
There is no timeout for unresponsive exec command. If it never returns, the SER process will be blocked. I think that introducing a timer that stops a too long child process would be a good feature, however it is not having a high priority.
The database is on the same host as ser so the result should be very fast, yet I am unsure as to why it is failing to query the subscriber table many times a day.
MySQL is set for 1000 connections and I am not seeing a problem here. Any other MySQL things to look at?
Here is the code snippet:
#Now check to see if Dialed Number is Valid for one of our Subs if (method == "INVITE"){ if (!exec_msg(' QUERY="select username from subscriber where username="$SIP_OUSER""; RESULT=`mysql -uXXX -pXXX -e "$QUERY" ser`; if [ -z "$RESULT" ]; then exit 1; fi ;')) {# User Does Not Exist rewriteuser("9993"); log(1, "Wrong Number IVR Prompt\n"); route(6); break; }; };
Our estimates indicate this fails about 5% of the time. Any ideas?
What does it mean it fails? Generally, I think the exec module is good for new features, my intuition is that the overhead is fairly high and once features stabilize it is benefitial to implement them as a native module.
-jiri
err.... Shouldn't that be exec_dset for a return, not exec_msg??
Not sure if exec_dset works, I assume it does. ---- Andrew
Jiri Kuthan wrote:
At 03:22 AM 8/13/2004, Andres wrote:
Hi,
In our ser.cfg we do a database query to determine if the dialed number is a valid subscriber, if the user dialed a wrong number then it is sent to an IVR prompt. This works well most of the time, but every now an then we see calls that were dialed properly yet they where transfered to the prompt. I would like to know how long exec_msg waits for the query result and if it is tunable.
There is no timeout for unresponsive exec command. If it never returns, the SER process will be blocked. I think that introducing a timer that stops a too long child process would be a good feature, however it is not having a high priority.
The database is on the same host as ser so the result should be very fast, yet I am unsure as to why it is failing to query the subscriber table many times a day.
MySQL is set for 1000 connections and I am not seeing a problem here. Any other MySQL things to look at?
Here is the code snippet:
#Now check to see if Dialed Number is Valid for one of our Subs if (method == "INVITE"){ if (!exec_msg(' QUERY="select username from subscriber where username="$SIP_OUSER""; RESULT=`mysql -uXXX -pXXX -e "$QUERY" ser`; if [ -z "$RESULT" ]; then exit 1; fi ;')) {# User Does Not Exist rewriteuser("9993"); log(1, "Wrong Number IVR Prompt\n"); route(6); break; }; };
Our estimates indicate this fails about 5% of the time. Any ideas?
What does it mean it fails? Generally, I think the exec module is good for new features, my intuition is that the overhead is fairly high and once features stabilize it is benefitial to implement them as a native module.
-jiri
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Andrew Mee wrote:
err.... Shouldn't that be exec_dset for a return, not exec_msg??
No...its exec_msg. I'm doing a simple database query. This comes straight from the SER PDF manual on page 64.
What does it mean it fails?
What I mean is that the call is routed to the IVR that says "the number you dialed does not belong to any of our subs...". If I sit down and dial one of my phones 20 times in a row, I will get at least 1 time where the "
QUERY="select username from subscriber where username="$SIP_OUSER"";"
Does not return a positive result even though the SIP trace shows I dialed the right number. So I am not sure where it is being missed. This is a server with virtually no load, 1GB Memory, P4, 2.4GHz, so I am sure I am not running out of resources. What else could it be?
Generally, I think the exec module is good for new features, my intuition is that the overhead is fairly high and once features stabilize it is benefitial to implement them as a native module.
-jiri
At 06:00 AM 8/13/2004, Andres wrote:
What does it mean it fails?
What I mean is that the call is routed to the IVR that says "the number you dialed does not belong to any of our subs...". If I sit down and dial one of my phones 20 times in a row, I will get at least 1 time where the "
QUERY="select username from subscriber where username="$SIP_OUSER"";"
Does not return a positive result even though the SIP trace shows I dialed the right number. So I am not sure where it is being missed.
That's what I actually wanted to ask ;)
This is a server with virtually no load, 1GB Memory, P4, 2.4GHz, so I am sure I am not running out of resources. What else could it be?
I don't know.
-jiri
This does not directly address you problem, but why don't you use the does_uri_exist() function to check the user account instead of calling an external function?
Zeus
Hi,
In our ser.cfg we do a database query to determine if the dialed number is a valid subscriber, if the user dialed a wrong number then it is sent to an IVR prompt. This works well most of the time, but every now an then we see calls that were dialed properly yet they where transfered to the prompt. I would like to know how long exec_msg waits for the query result and if it is tunable. The database is on the same host as ser so the result should be very fast, yet I am unsure as to why it is failing to query the subscriber table many times a day.
MySQL is set for 1000 connections and I am not seeing a problem here. Any other MySQL things to look at?
Here is the code snippet:
#Now check to see if Dialed Number is Valid for one of our Subs if (method == "INVITE"){ if (!exec_msg(' QUERY="select username from subscriber where username="$SIP_OUSER""; RESULT=`mysql -uXXX -pXXX -e "$QUERY" ser`; if [ -z "$RESULT" ]; then exit 1; fi ;')) {# User Does Not Exist rewriteuser("9993"); log(1, "Wrong Number IVR Prompt\n"); route(6); break; }; };
Our estimates indicate this fails about 5% of the time. Any ideas?
-- Andres Network Admin http://www.telesip.net
Serusers mailing list serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Zeus Ng wrote:
This does not directly address you problem, but why don't you use the does_uri_exist() function to check the user account instead of calling an external function?
Thanks Zeus! does_uri_exist() is a much more elegant way of doing the same thing. I wonder why I missed it, I guess I read too much of that old SER PDF manual:) And I would certainly expect it to be more efficient. It seems to be working fine. I will give it the load test over the next couple of days to see if works ok.
Zeus