openob
openob copied to clipboard
JamesHarrison
Removing redis dependency
Redis has made some unfortunate licensing changes lately, and we don't actually use redis for much in OpenOB, just transferring some basic information about the link.
It would be better to either use an RPC mechanism between client/server to exchange information, with direct communication instead of using a server to mediate communication, or to use standard protocols in-band to transfer information from server to client.
I started work on a daemon ages ago over in my fork, but it doesn't really work yet. I'd be happy to move away from Redis, but I don't know anything about the more native platform features like RTCP/SIP! Perhaps we could use a message broker like AMQP instead?
I'd love to some extent to have something in-band using GStreamer hooks to inject/retrieve data in the RTP stream - that has the huge bonus of simplifying firewall config and keeping communication tied to the actual data being transferred. That doesn't work well for pre-establishment or when you want to change remote settings that might disrupt the RTP stream, though.
As far as message broker protocols go, I'd prefer MQTT over AMQP since MQTT is very low overhead, and brokers like mosquitto do basically everything we're using redis for.
However, thinking a bit further, it might now be possible to pick up the AMWA standards: https://amwa.tv/projects/interface_specifications.shtml
The benefit of doing an AMWA implementation (which still defers to RTP for actual media transport, but needs an SDP or similar) would be interoperability - in theory OpenOB could be dropped into AMWA studios and take advantage of tools developed in that ecosystem where they're open source. It'd be a fair bit more work, though.
I am considering modification of OpenOB to migrate from redis to MQTT as it doesn't look too difficult to implement (famous last words, I know!). Unless I'm missing something, it appears that everything redis related is neatly contained in link_config.py, could someone confirm this for me?
I took a look at AMWA, I think the relevant spec would be IS - 05, but I wasn't convinced it would be the right route to go down.
My long term goal is to build a link negotiation server, then to have a series of nodes that automatically connect to the server as soon as they have an active internet connection, a web interface on the server would allow them to be "patched" together including some form of NAT traversal. Using MQTT for config seems to fit the bill for that role too.
I don't know much about MQTT or AMWA, but some sort of direct connection would be cool - like a quorum with managers and nodes.
If we end up with more back-end config stores, could we do it in a modular way so that people who still want to use Redis can do so via config or command line?
I've been thinking of adding config file support in anyway!
On Mon, 20 May 2019 at 17:00, M0GUR [email protected] wrote:
I am considering modification of OpenOB to migrate from redis to MQTT as it doesn't look too difficult to implement (famous last words, I know!). Unless I'm missing something, it appears that everything redis related is neatly contained in link_config.py, could someone confirm this for me?
I took a look at AMWA, I think the relevant spec would be IS - 05, but I wasn't convinced it would be the right route to go down.
My long term goal is to build a link negotiation server, then to have a series of nodes that automatically connect to the server as soon as they have an active internet connection, a web interface on the server would allow them to be "patched" together including some form of NAT traversal. Using MQTT for config seems to fit the bill for that role too.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/JamesHarrison/openob/issues/39?email_source=notifications&email_token=AAI3CU22V6YQF3JCHWKDWF3PWLDK7A5CNFSM4FQ5PYOKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODVZJN4Q#issuecomment-494049010, or mute the thread https://github.com/notifications/unsubscribe-auth/AAI3CU3LZABD7BN3YUM3GCDPWLDK7ANCNFSM4FQ5PYOA .
And why not the ZeroMQ library used for example by the excellent suite Open Digital Radio (DAB+ multiplexer tools) ?
