Skip to main content

Making Event Socket behave like the console

About

A handy trick to allow mod_event_socket commands to be treated like they are being run from the FreeSWITCH console.

Click here to expand Table of Contents

Problem

The console includes some features that are not active when a command is sent over the Event Socket. A good example is the syntax for sending multiple commands in sequence:

freeswitch@localhost> version;;status
FreeSWITCH Version 1.7.0+git~20160321T203641Z~9e6593aa73~64bit (git 9e6593a 2016-03-21 20:36:41Z 64bit)
UP 0 years, 0 days, 0 hours, 0 minutes, 35 seconds, 870 milliseconds, 654 microseconds
FreeSWITCH (Version 1.7.0 git 9e6593a 2016-03-21 20:36:41Z 64bit) is ready
0 session(s) since startup
0 session(s) - peak 0, last 5min 0
0 session(s) per Sec out of max 30, peak 0, last 5min 0
1000 session(s) max
min idle cpu 0.00/91.37
Current Stack Size/Max 240K/8192K

However, this same command syntax will not work when sent via the Event Socket:

api version;;status

Content-Type: api/response
Content-Length: 40

-ERR version;;status Command not found!

Solution

To force the command to be run as it would in the console, enable console_execute functionality as part of the command sent over the socket, like so:

api version;;status
console_execute: true

Content-Type: api/response
Content-Length: 464

FreeSWITCH Version 1.7.0+git~20160321T203641Z~9e6593aa73~64bit (git 9e6593a 2016-03-21 20:36:41Z 64bit)
UP 0 years, 0 days, 0 hours, 5 minutes, 39 seconds, 345 milliseconds, 627 microseconds
FreeSWITCH (Version 1.7.0 git 9e6593a 2016-03-21 20:36:41Z 64bit) is ready
0 session(s) since startup
0 session(s) - peak 0, last 5min 0
0 session(s) per Sec out of max 30, peak 0, last 5min 0
1000 session(s) max
min idle cpu 0.00/93.13
Current Stack Size/Max 240K/8192K

In fact, this is exactly what the fs_cli executable does behind the scenes when it sends commands to FreeSWITCH!

Caveats

  • It must be enabled per command sent to the socket
  • It incurs extra overhead to run. This is probably not a problem unless you're sending a high volume of commands using this strategy, and, it's not advised to use it unless you actually need it.
  • And a brief note on the particular approach of sending multiple commands in one execution: they will run synchronously, and in the order provided, and subsequent commands will run even if previous commands failed (unlike, for example 'test -f blah && rm blah' in a Bash shell, which would not run the second command if the first returned a non-zero exit status).