Detect and broadcast janus streams over zeroconf

[fnoop]

In addition to broadcasting visiond rtsp/rtp streams so clients such as GCS can find them, it should also broadcast janus streams so -discovery can find the webrtc endpoints and -web can pick them up automatically.

[fnoop]

Janus has eventhandlers, which can be used to act on events (such as when streams are created/connected). There is a websocket eventhandler which will connect to a websocket and broadcast json events. We could create a visiond websocket which sits and listens for events from janus, and publishes over zeroconf.

[SamuelDudley]

Sounds like a plan. Some links https://janus.conf.meetecho.com/docs/eventhandlers.html

https://janus.conf.meetecho.com/docs/rest.html#WS

With WebSockets, this is not needed: as soon as you create a session on a WebSocket, that channel becomes automatically subscribed for events related to that sessions, and you'll receive them on the same WebSocket. For the same reason, as soon as the WebSocket is closed, all the sessions created within its context are considered closed as well, and so their resources (including all the handles and PeerConnections) will be released as well.

[fnoop]

Interesting but creating a full webrtc websocket stream connection from visiond to janus would have some problems. Ideally hopefully we can use the wsevh eventhandler to connect the other way round - we setup a websocket server in visiond and then if/when janus is configured appropriately and starts up then it connects over wsevh to visiond websocket handler and starts firing events at visiond. visiond can then advertise the webrtc streams through zeroconf, and -discovery can pick them up and fire them at -web.

It sounds a bit convoluted but it's a relatively straight forward chain and is fully event driven from end to end. Hopefully it will work, otherwise we can look at creating the full webrtc connection.

[SamuelDudley]

Okay, so the first link I posted is still the format expected on events. The second link is not applicable at this stage.

[fnoop]

Alternatively we could also create a lua plugin that directly publishes zeroconf https://janus.conf.meetecho.com/docs/lua.html

[SamuelDudley]

Would the janus stream be a new advertised service via zeroconf, alongside the existing rtsp advertisement or added into the description field of the existing rtsp advertisement?

[fnoop]

I think a separate service. It runs on a separate port. I guess it could be an extra field in the rtsp, but it's really a different service and used by different clients, so probably best as a separate service registration?

[SamuelDudley]

Okay, if we go down the websockets route I'll need to update visiond to support creating zeroconf entries via the queue. No problems with that plan.

[fnoop]

Mar 24 21:56:17 maverick-nano janus[32130]: [WARN] Event handlers support disabled :(

[SamuelDudley]

Is this a compile, plugin or config issue?

[fnoop]

Fixed in maverick janus config. Now getting this in visiond:

Mar 24 22:22:15 maverick-nano python3[5933]: 2020-03-24 22:22:15,949 - zeroconf - WARNING - Exception occurred:
Mar 24 22:22:15 maverick-nano python3[5933]: Traceback (most recent call last):
Mar 24 22:22:15 maverick-nano python3[5933]:   File "/srv/maverick/software/python/lib/python3.7/site-packages/zeroconf/__init__.py", line 2638, in send
Mar 24 22:22:15 maverick-nano python3[5933]:     bytes_sent = s.sendto(packet, 0, (real_addr, port))
Mar 24 22:22:15 maverick-nano python3[5933]: OSError: [Errno 101] Network is unreachable

This doesn't happen in maverick-ubuntuvm or maverick-raspberry, only maverick-nano. Odd, ignoring for now, will use raspberry for further dev/testing.

[SamuelDudley]

Visiond now has a websocket handler. Currently janus cannot connect. Possible port issue. Haven't investigated yet.

Edit: Looking at the configuration of janus it seems unlikely to be a port error. Need to reassess my approach to the starting and stopping of the server. Install a periodic callback and check to see if the thread should exit. If it should, add a callback to the current ioloop to stop it.