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.

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