New Post on freeswitch.org from anthm check it out at http://ift.tt/1vL90Zr Verto™ Not just for call signaling Verto is not only focused on call signaling; There are a few other key components that are important to understand. One key component of Verto is event channels. Event channels are bi-directional subscription-based logical data channels used to relay information in an organized fashion. This is a low level building block for many features. For instance, call or chat presence. Event channels can be subscribed to from JS and granular permissions may be set from FS on-the-fly or ahead of time. Modules inside FreeSWITCH fire json events and every connection who has a subscription will get a copy of the data allowing action to be taken. At the same time each browser connection is able to send a request back to the server on a particular event channel which can trigger action varying from sending more events, a full sync of saved data or even pushing the events into another event bus to send to another external application. Our demo site http://ift.tt/12g7Iff and call 3500 you can see an example of the data synchronization functionality as it will generate events that sync and update in real time a data structure in FreeSWITCH and one in the page of anyone subscribed. Because 3500 is a conference, the conference module will grant you access to the data about who else is called into the conference. It sends an event scoped to the exact uuid of the connection of the calling verto client. This event says that there is an available data synchronization for the particular conference. Using the data from this event, you can initialize an object that uses event channels to subscribe to the conference data and request a full sync and then keeps the object in sync with update events as long as you are on the call. This allows a table to be drawn in real time reflecting the changes going on in the conference. When you hangup, it sends a similar event telling you that you should unregister from this service and removes your permission. If you wanted, you could allow permissions to one or all conference data from your FS config and use verto to connect and provide info about who’s in the conference even when you are not connected directly. Another important feature of the module is the ability to communicate with FreeSWITCH and invent your own api modules. The lower level json-rpc in FS contains 2 important commands, fsapi and jsapi. fsapi allows you to execute any FreeSWITCH FSAPI command (basically all the commands you can type at the cli) This is set on a per command permission basis and is of course best used with security in mind. The other command, jsapi, is used to interface with a new type of module interface in FreeSWITCH called the JSON API Interface (JSONAPI) This interface is similar to FSAPI only its designed with a JSON in JSON out structure. One could write a C module defining a series of JSONAPI designed to allow your html5 application to communicate directly with your module in the same fashion that mod_verto does. This allows mod_verto to host the server logic and just pass commands up to your module and communicate in basic json exchanges. There some examples in FreeSWITCH now that you can test from your cli There is a FSAPI command called json that just assumes the input is a chunk of json and passes it right into JSONAPI then gets the results and converts it back to text so you can see it on the screen. Paste this command into your terminal: json {“command”: “status”, “format”: “pretty”, “data”: {}} Had it been over jsonrpc it would have been sent with method of jsapi and the json below would have been the params element: { “jsonrpc”: “2.0”, “method”: “jsapi”, “params”:{“command”: “status”, “format”: “pretty”, “data”: {}} “id”: 2 }