[Freeswitch-users] Questions on Building an application for FreeSWITCH

[Michael Collins]

On Wed, May 26, 2010 at 8:59 AM, Phone <phone.bytes at gmail.com> wrote:

> Thanks to all for the most helpful feedback.  Sharing your approaches
> and experiences are a big help.  I look forward to the upcoming code
> samples.
>
No problem.

>
> I was coming from a windows/dialogic environment where I used a library
> that allowed me to work on a little higher level.  For example, I had a
> call to "play a file" that took a parameter of whether or not to allow a
> dtmf to interrupt.  There was also a call to "ReadDtmfs" that took
> parameters to specify the number of Dtmf's to read, how long to wait for
> them, and what terminating character to use.  I guess that you could
> write some scripts or compiled code with these same types of functions
> to simplify some of these routine tasks with reusable code?
>
FreeSWITCH has several tools to assist with this, most notably
playAndGetDigits
The dialplan app is doc'd here:
http://wiki.freeswitch.org/wiki/Misc._Dialplan_Tools_play_and_get_digits
The IVR-ish way is doc'd here: http://wiki.freeswitch.org/wiki/IVR
The mod_lua docs have good info about using it from calling lua from the
dialplan: http://wiki.freeswitch.org/wiki/Mod_lua#session:playAndGetDigits


>
> Also, the library handled the threading and scheduling with the OS.  I
> am still unclear on handling the events.  I guess you have a big loop
> reading events and then acting on them using the uuid to determine which
> call it is and how to deal with the next step of the call?  Any feedback
> on this part of the project?
>
I think you might be suffering from information overload. :)
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.

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:
http://wiki.freeswitch.org/wiki/Event_socket_outbound
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.

As far as inbound event socket goes, the official docs start here:
http://wiki.freeswitch.org/wiki/Event_socket

The classic example of an event socket application is one you may not
expect: fs_cli
If you REALLY want to see what the event socket looks like then fire up
fs_cli and do this:
/log 0
/events plain all

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.

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.

Are you sure you still want to do this? :)
-MC
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20100526/81d92266/attachment.html