VoIP Mailing List Archives

[killarny at gmail.com]

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:

sendmsgcall-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.

[christian at jensenbox...]

I have not worked with FS events, but this seems like a sound premise.

Anyone care to enlighten an alternative?

From: Luke Graybill <killarny@gmail.com>
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:

sendmsgcall-command: execute
execute-app-name: answer\n\n

The response is this:

Content-Type: command/replyReply-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.

[oss.richard at gmail.com]

[oss.richard at gmail.com]

oops...sorry for the mess...


import org.apache.mina.common.IoSession
import java.util.concurrent.BlockingQueue
import java.util.concurrent.Executors
import java.util.concurrent.ExecutorService
import java.util.concurrent.Future
import java.util.concurrent.Callable
import java.util.concurrent.ExecutionException
import java.util.concurrent.TimeoutException
import java.util.concurrent.TimeUnit



class Session {
private IoSession session
private FSEventHandler handler
private BlockingQueue<String> msgQ
private final ExecutorService executor =
Executors.newSingleThreadExecutor()
private final static long DEFAULT_TIMEOUT = 5000

def data

def Session(IoSession s, BlockingQueue q) {
session = s
msgQ = q
}

private def executeAndWait(Closure task, long timeout=0) {
Future <CommandResult> f = executor.submit(task as Callable)
def result
def boolean success = false
try {
if (timeout != 0) {
result = f.get(timeout, TimeUnit.MILLISECONDS)
} else {
result = f.get()
}
if (result.code == CommandResult.OK) data = result.data
} catch (ExecutionException e) {
// Should log here
} catch (TimeoutException e) {
f.cancel(true)
}

return result
}

def answer() {
def task = {
def done = false
def r = new CommandResult()
sendMessage("answer")
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE") && (m?.Application == "answer")) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task, DEFAULT_TIMEOUT)
}

def unset(var) {
def task = {
def done = false
def r = new CommandResult()
sendMessage("unset", var)
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "unset")
&&
(m?.ApplicationData == var)) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task, DEFAULT_TIMEOUT)
}

def queueDtmf(dtmfs) {
def task = {
def done = false
def r = new CommandResult()
sendMessage("queue_dtmf", dtmfs)
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "queue_dtmf")
&&
(m?.ApplicationData == dtmfs)) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task, DEFAULT_TIMEOUT)
}

/*
def hangup() {
def task = {
def done = false
def r = new CommandResult()
sendMessage("hangup")
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "queue_dtmf")
&&
(m?.ApplicationData == dtmfs)) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task, DEFAULT_TIMEOUT)
}
*/

def setVariable(String var, String value) {
def task = {
def done = false
def r = new CommandResult()
sendMessage("set", "${var}=${value}")
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "set")
&&
(m?.ApplicationData == "${var}=${value}")) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task, DEFAULT_TIMEOUT)

}

def export(String var) {
set("export_vars", var)
}

def bridge(String number) {
def task = {
def done = false
def r = new CommandResult()
sendMessage("bridge", number)
while (! done) {
def m = msgQ.take()
// println m
if (((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "bridge")
&&
(m?.ApplicationData == number)) ||

((m?.event?.Name == "CHANNEL_UNBRIDGE")
&&
(m?.variable.bridge_channel == number)) || (m?.SESSIONCLOSED ==
"true")) {
done = true
r.code = CommandResult.OK
r.data = m
}
}
return r
}
executeAndWait(task)
}

def promptForDigits(int min, int max, String soundFile, String
variableName, long timeout, String terminator) {
def task = {
def done = false
def r = new CommandResult()
def appData = "${min} ${max}
${soundFile} ${variableName} ${timeout} ${terminator}"
sendMessage("read", appData, true)
while (! done) {
def m = msgQ.take()
if ((m?.event?.Name ==
"CHANNEL_EXECUTE_COMPLETE")
&&
(m?.Application == "read")
&&
(m?.ApplicationData == appData)) {
done = true
r.code =
CommandResult.OK r.data
= m
}
}
return r
}
executeAndWait(task, timeout)
}

def originate(String url) {
sendMessage("originate", url, true)
}

def sleep(int sec) {
sendMessage("sleep", new Integer(sec*1000).toString())
}

def say(String phrase) {
sendMessage("phrase", "spell,$phrase")
}

def script() {
return "jeprox"
}

private def sendMessage(String app, String arg=null, boolean
event_lock=false) {
String msg = "sendmsg\ncall-command:
execute\nexecute-app-name: ${app}"
if (arg) {
msg += "\nexecute-app-arg: ${arg}"
}
if (event_lock) {
msg += "\nevent-lock: ${event_lock}"
}
System.out.println(msg)
session.write("$msg\n\n")
}
}

On Fri, Sep 19, 2008 at 9:35 AM, Richard Open Source
<oss.richard@gmail.com> wrote:

[brian at freeswitch.org]

Large pastes on the mailing list are ok... if they aren't over 100k

/b

On Sep 19, 2008, at 10:24 AM, Christian Jensen wrote:

[christian at jensenbox...]

Use the pastebin please.



On Sep 19, 2008, at 7:00 AM, "Richard Open Source" <oss.richard@gmail.com

[christian at jensenbox...]

[killarny at gmail.com]

On Thu, Sep 18, 2008 at 3:49 PM, Luke Graybill <killarny@gmail.com (killarny@gmail.com)> wrote:

[killarny at gmail.com]

Oops, I forgot to mention anthm as well - he provided great feedback on irc!

On Fri, Sep 19, 2008 at 10:19 AM, Luke Graybill <killarny@gmail.com (killarny@gmail.com)> wrote:

[mike at jerris.com]

On Sep 19, 2008, at 12:19 PM, Luke Graybill wrote:

[killarny at gmail.com]

I haven't encountered every event yet (I'm still in the process of writing my client) but perhaps some others can help? I'll post the ones I know about so far though..

- command/reply
- CHANNEL_EXECUTE
- CHANNEL_EXECUTE_COMPLETE
- CHANNEL_ANSWER
- CHANNEL_PARK

The last two are uncertain because, in my view, they apply to channel state; something that the client can track independently without regard to whether it is related to a previously sent command.

Note: I tend to use the word 'command' when referring to anything that the client is transmitting to mod_event_socket. I hope that doesn't confuse things - I'm not great on concise terminology.

Killarny

On Fri, Sep 19, 2008 at 10:45 AM, Michael Jerris <mike@jerris.com (mike@jerris.com)> wrote: