I have not worked with FS events, but this seems like a sound premise.
Anyone care to enlighten an alternative?
-----Original Message-----
From: Luke Graybill <[EMAIL PROTECTED]>
Sent: September 18, 2008 2:49 PM
To: freeswitch-users@lists.freeswitch.org
Subject: [Freeswitch-users] Asynchronous communication with FreeSWITCH's
mod_event_socket
I've been doing a lot of work recently with FreeSWITCH's mod_event_socket, and
I wanted to comment a bit about the syntax used for commands through the socket
while using asynchronous mode. I haven't tried the synchronous mode yet, as I
always want to be free to be able to execute commands without waiting for other
commands to finish. For instance, I need to be able to collect DTMF events
while I'm playing a sound file, so that the user can do things like select menu
items without listening to the entire menu first.
Asterisk's AMI protocol allows you to specify an ActionID along with every
command that you send. Asterisk then includes this ActionID with every event
that is related to that command, making it cake to coordinate an asynchronous
client.
However, even in async mode, FreeSWITCH's mod_event_socket doesn't communicate
any identifying information for command responses, or for events triggered by a
previous command, unless one uses the bgapi command set. This command set is
not applicable to every situation, though. It only applies to commands which
manipulate the call; if one needs to manipulate the channel, then messages must
be used through the sendmsg command set, which doesn't provide any specific
identifying information.
Now, to complicate things, with all commands (even bgapi) the protocol works
something like this: you send a command, and wait for a response from
mod_event_socket. This response is assumed to be immediate before anything else
the client might receive from mod_event_socket, and in the case of bgapi, this
response will contain a job-id to use for comparing job-related events later.
For example, for the following command:
sendmsg
call-command: execute
execute-app-name: answer\n\n
The response is this:
Content-Type: command/reply
Reply-Text: +OK
That response is generic to nearly every single command sent, and is only
really saying "The last transmission was a valid command, and didn't
immediately fail". The command may actually fail later, and command specific
feedback is generally contained in later events (which have no unique
identifying information).
My issue here is that this seems to be forcing an asynchronous client to rely
upon a synchronous ordering of response directly following command, thus
violating the very concepts of an asynchronous protocol in which there should
be no assumed order. Not only that, but this method increases the complexity of
a client, which must be aware of limitations that wouldn't ordinarily be
required by a true asynchronous protocol. An asynchronous client should be
unconcerned with listening for a synchronous response to every command.
My suggested solution is to apply the job-id concept from bgapi to messages as
well, and to go a step further; borrow the Asterisk idea of transmitting an
identifier along with each command. Every response and event related to that
command should then contain the very same identifier in the header.
_______________________________________________
Freeswitch-users mailing list
Freeswitch-users@lists.freeswitch.org
http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
http://www.freeswitch.org
