I'm not sure if I'm doing the correct thing - help please

First, let me start by saying I am not an Asterisk expert, but am looking for expert advise.

I’ve written a web app that is at its core a php/html form. When the form is submitted it calls a php file that does lots of different things. Amongst the various things that it does is use php’s system command to echo contents into a call file then touch the file with a timestamp in the future, and places it in the asterisk outgoing directory:

system(“echo ‘Channel: sip/myprovider/phone_number
Maxretries: 5
Retrytime: 300
Context: context_name
Extension: h
Priority: 1
Waittime: 40’ >> /location/of/call/files/context_name.call”);

the script also does something similar by using php’s system command to echo contents at the end of extensions.conf:

system("/bin/echo ‘context_name]
exten => h,1,Wait(1)
exten => h,n,Answer
exten => h,n,Set(TIMEOUT(digit)=5)
exten => h,n,Set(TIMEOUT(response)=10)
exten => h,n,Playback(context_name)
exten => h,n,Hangup’ >> /etc/asterisk/extensions.conf");

The script also creates the sound file needed, reloads the dialplan and a million other things.

My question isn’t a matter of “will this work?” b/c I know it works, I’ve tested it. My question is, do you think this is bad practice? Is there a better way to do what I’m trying? I’m not sure exactly how much cpu it is taking each time I submit the form, etc etc etc

If I need to clarify more clearly what I’m asking, let me know…thought I’d start with that explanation in the hopes that it would be enough.

if i understand this, every time someone hits the form, it goes through a bunch of steps that leads to, amongst things, modifying and therefore reloading the dial plan. as you say, this works …but i suppose this depends on how busy this is planned to become. this is not going to scale well at all.

i think you need to think more in terms of having a dial plan that can handle dynamic variables which can be passed to it in the .call file so you do not have to keep changing the extensions.conf file with every new form use.

[quote=“mudslide567”]if i understand this, every time someone hits the form, it goes through a bunch of steps that leads to, amongst things, modifying and therefore reloading the dial plan. as you say, this works …but i suppose this depends on how busy this is planned to become. this is not going to scale well at all.

i think you need to think more in terms of having a dial plan that can handle dynamic variables which can be passed to it in the .call file so you do not have to keep changing the extensions.conf file with every new form use.[/quote]

You are correct in understanding this. I plan on this becoming very busy, which is why I am concerned about scalability. Can you please lend me a hand by pointing me in the right direction? I don’t want to reload the dialplan every time a form is submitted … and the way I have my code setup now, I am adding something to extensions.conf at each form submission…is that necessary? I don’t really understand what you mean…

why do you need to add something to extensions.conf every time a form hits? if, as you say, this is to be busy, this will never hold up. what exactly are you trying to accomplish that you feel the need to keep modifying the dial plan? You have provided little code snippets…enough to know that you have a catastrophic design flaw but not enough to figure out what you are trying to do in the first place… you say it works but obviously you have not tried any form of load testing. Just out of interest, what made you pick extension “h” which is usually reserved for hangup handling?

so …speculating here on what you are trying to do… you want to set off a .call file and when the call is placed, it will play some sound file to to the callee. so why not put the sound file name in .call file …when the call is made, that variable can be read by a STATIC part of a dial plan that reads the variable and uses that to play the file? never need to touch the dial plan once you are up and running… many people have done this this way and achieved excellent scale.

[quote=“mudslide567”]why do you need to add something to extensions.conf every time a form hits? if, as you say, this is to be busy, this will never hold up. what exactly are you trying to accomplish that you feel the need to keep modifying the dial plan? You have provided little code snippets…enough to know that you have a catastrophic design flaw but not enough to figure out what you are trying to do in the first place… you say it works but obviously you have not tried any form of load testing. Just out of interest, what made you pick extension “h” which is usually reserved for hangup handling?

so …speculating here on what you are trying to do… you want to set off a .call file and when the call is placed, it will play some sound file to to the callee. so why not put the sound file name in .call file …when the call is made, that variable can be read by a STATIC part of a dial plan that reads the variable and uses that to play the file? never need to touch the dial plan once you are up and running… many people have done this this way and achieved excellent scale.[/quote]

The short answer to your first question is I thought I had to edit extensions.conf to do this. Maybe I don’t really understand the purpose of extensions.conf. What I’d like to happen is: at a certain date/time call person “x” and play message “x”. Things I obtain from the form are the person’s phone number, the message (text to speech conversion), and the date/time to place the call. So, those are all of the things I know.

I guess I thought that the .call had to include “Context: context_name” in order to place the appropriate call to the appropriate individual. And, was also thinking that in order for that to happen, the extensions.conf file must contain that said context name, hence why I’m appending a context at the end of extensions.conf each time my form is submitted.

You are right, I have not tested this at load at all, I’ve only tested 1 form submission at a time…but I’ve always been concerned that I’m doing this in a way that, like you said, is a catastrophic flaw.

So, are you saying that extensions.conf need not include a “context” for each person that I want to call? Forgive me if I’m mis-using terminology.

Thanks,

Here is an example of one of the contexts I add to extensions.conf prior to reloading the dialplan:

[9134994127201010061142.00-20101006155205]
exten => s,1,Wait(1)
exten => s,n,Answer
exten => s,n,Set(TIMEOUT(digit)=5)
exten => s,n,Set(TIMEOUT(response)=10)
exten => s,n,Playback(9134994127201010061142.00-20101006155205)
exten => s,n,Hangup

So, are you saying that I could have 1 context, maybe called [outbound_calls] with all of the same applications (Wait, Answer, Set, etc) … I’m so confused. So, for my .call file to work, it has to have an extension, right? Can I have all my .call files use Context: outbound_calls and configure that context like so?

[outbound_calls]
exten => s,1,Wait(1)
exten => s,n,Answer
exten => s,n,Set(TIMEOUT(digit)=5)
exten => s,n,Set(TIMEOUT(response)=10)
exten => s,n,Hangup

I still need a specific sound file to play during the call…I thought that was extensions.conf’s job and not the .call - I will try to put the sound file in the .call and test

At this point, if I were you planning a high volume service with such little understanding of how this works, I would enlist professional help. There are a bunch of things that you have not even started to consider for a high volume service so while you might be able to slowly kluge you way along with some free help here, you are not going to get to high volume production worthy system without a lot of pain along the way.

To try to answer your direct question, you do not put the sound file in the call file. You put a variable in the call file that points to the sound file. So, in your call file, change the extension and context and add a variable:

Context: outbound-calls
Extension: mycaller
SetVar: PLAYFILE=9134994127201010061142.00-20101006155205

Then in the extensions.conf…

Dump all the TIMEOUT since you are not waiting for any response from the called number, and simplify the code to something like:

[outbound-calls]
exten => mycaller,1,Answer
exten => mycaller,n,Wait(1)
exten => mycaller,n,Playback(${PLAYFILE})
exten => mycaller,n,Hangup

Of course, you would want to change/add code to avoid playing the file when the call appears to have been answered by a machine – eg an IVR or voicemail]

[You could actually do this without running into the dial plan at all by simply having it terminate with an application. This will be very fast but you lose all ability to track calls through the CDR so you never know how calls are completed etc. Thats another option though you might want to consider]

[quote=“mudslide567”]At this point, if I were you planning a high volume service with such little understanding of how this works, I would enlist professional help. There are a bunch of things that you have not even started to consider for a high volume service so while you might be able to slowly kluge you way along with some free help here, you are not going to get to high volume production worthy system without a lot of pain along the way.

To try to answer your direct question, you do not put the sound file in the call file. You put a variable in the call file that points to the sound file. So, in your call file, change the extension and context and add a variable:

Context: outbound-calls
Extension: mycaller
SetVar: PLAYFILE=9134994127201010061142.00-20101006155205

Then in the extensions.conf…

Dump all the TIMEOUT since you are not waiting for any response from the called number, and simplify the code to something like:

[outbound-calls]
exten => mycaller,1,Answer
exten => mycaller,n,Wait(1)
exten => mycaller,n,Playback(${PLAYFILE})
exten => mycaller,n,Hangup

Of course, you would want to change/add code to avoid playing the file when the call appears to have been answered by a machine – eg an IVR or voicemail]

[You could actually do this without running into the dial plan at all by simply having it terminate with an application. This will be very fast but you lose all ability to track calls through the CDR so you never know how calls are completed etc. Thats another option though you might want to consider][/quote]

mudslide567: I agree with you, and believe that I may enlist some professional help soon. I am not planning on releasing my app any time soon, I am just trying to learn the bread and butter of things. I really appreciate your help. I’ll give it a go with the example you’ve given me…