<br><br><div class="gmail_quote">On Wed, May 26, 2010 at 8:59 AM, Phone <span dir="ltr"><<a href="mailto:phone.bytes@gmail.com" target="_blank">phone.bytes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Thanks to all for the most helpful feedback. Sharing your approaches<br>
and experiences are a big help. I look forward to the upcoming code<br>
samples.<br></blockquote><div>No problem. <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
I was coming from a windows/dialogic environment where I used a library<br>
that allowed me to work on a little higher level. For example, I had a<br>
call to "play a file" that took a parameter of whether or not to allow a<br>
dtmf to interrupt. There was also a call to "ReadDtmfs" that took<br>
parameters to specify the number of Dtmf's to read, how long to wait for<br>
them, and what terminating character to use. I guess that you could<br>
write some scripts or compiled code with these same types of functions<br>
to simplify some of these routine tasks with reusable code?<br></blockquote><div>FreeSWITCH has several tools to assist with this, most notably playAndGetDigits<br>The dialplan app is doc'd here: <a href="http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_play_and_get_digits" target="_blank">http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_play_and_get_digits</a><br>
The IVR-ish way is doc'd here: <a href="http://wiki.freeswitch.org/wiki/IVR" target="_blank">http://wiki.freeswitch.org/wiki/IVR</a><br>The mod_lua docs have good info about using it from calling lua from the dialplan: <a href="http://wiki.freeswitch.org/wiki/Mod_lua#session:playAndGetDigits" target="_blank">http://wiki.freeswitch.org/wiki/Mod_lua#session:playAndGetDigits</a><br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
Also, the library handled the threading and scheduling with the OS. I<br>
am still unclear on handling the events. I guess you have a big loop<br>
reading events and then acting on them using the uuid to determine which<br>
call it is and how to deal with the next step of the call? Any feedback<br>
on this part of the project?<br></blockquote><div>I think you might be suffering from information overload. :)<br>The event socket works in two methods: inbound and outbound. We have been throwing around concepts that apply to both without really doing a lot of qualifying. <br>
<br>In most cases we are talking about inbound event socket where your server establishes a connection to FreeSWITCH. To see more about the outbound event socket look at this:<br><a href="http://wiki.freeswitch.org/wiki/Event_socket_outbound">http://wiki.freeswitch.org/wiki/Event_socket_outbound</a><br>
Essentially you can create a program/script that sits and listens on a TCP port for connections from FS. When your program gets a connection then it can control the call leg via event socket commands. In the outbound event socket paradigm your program sees *ONLY* the events related to your specific call leg. When the call ends, so does your socket connection. You can use outbound socket for call control if you want to do so, however it is by no means required.<br>
<br>As far as inbound event socket goes, the official docs start here:<br><a href="http://wiki.freeswitch.org/wiki/Event_socket">http://wiki.freeswitch.org/wiki/Event_socket</a><br><br>The classic example of an event socket application is one you may not expect: fs_cli<br>
If you REALLY want to see what the event socket looks like then fire up fs_cli and do this:<br>/log 0<br>/events plain all<br><br>At that point your terminal is a raw event socket client. :) You can send commands and see all the crazy stuff that comes across via events. Once you get a feel for the events that come and go then you can think about how to attack your problem. <br>
<br>In your specific question about using the uuid to figure out what to do with the call... yes, you *could* do that if you wanted to. You could also have the call controlled by the dialplan. For example, you originate a call and drop it into the dialplan and let the dialplan handle it. You will still get events about that channel, for examples when the caller changes states, or even DTMFs, etc. (if you want to see them) but the call is being controlled by the dialplan itself so that your program doesn't have to control it. You could then have, as part of your event loop, a "show channels" (or "show channels as xml") happen every x seconds and just parse it to see what's happening on your calls. If you're a real stud programmer you could have your script maintain a state machine for each call and use the incoming events from the event socket to update your call states. <br>
<br>Are you sure you still want to do this? :)<br>-MC<br>
</div></div><br>