We’ve been tossing around some ideas on providing additional features for the ARI WebSocket and wanted to get some feedback. These are just ideas at this point with no commitment.
- REST over WebSocket: The ability to issue ARI REST calls over the same wwebsocket you get events on instead of making separate HTTP requests. There are a few different ways to support this…
-
socket.io: Seems OK from an API perspective but it’s pretty heavy for what we want and there don’t seem to be any decent C implementations which means we’d have to implement it ourselves.
-
SwaggerSocket: Seems to be exactly what we want and it’s dead simple to implement although the reference implementation repo has been archived.
Any other protocols we should consider?
- Outbound WebSockets: Have the dialplan establish an outgoing websocket to your server using an ‘ARI()’ dialplan app.
- Define named connections in ari.conf with URI and any credentials needed.
- Could be a persistent connection that gets used by all calls to ARI() using that connection name or each call to ARI() could open a new websocket.
Once established, the websocket would act just as an inbound websocket would. Events would be sent over it and it would accept REST calls.
- Media over WebSocket: This one’s a bit trickier. Would you want media plus ARI events and REST calls all multiplexed over the same websocket? I’m thinking it should be a separate websocket, either persistent or per call. If the server is a Node application for instance, I’m not sure I’d want a single event loop trying to deal with both media and control data at the same time. Separate websockets for media would also be easier for us to implement since we wouldn’t have to hook chan_rtp into the ARI websocket framework. Thoughts?
As I said, we’re just tossing these around right now but feedback would be appreciated.