Add support for plain RTP participants in AudioBridge

[lminiero]

This PR adds support for plain RTP participants to the AudioBridge. By "plain RTP" I mean that, up until now, to join an AudioBridge mix you had to use WebRTC: this patch adds a new mode, where you can issue a "join" without actually establishing a PeerConnection, but exchange plain ip/ports instead to be able to send media via plain RTP directly to the mix, and receive it via plain RTP as well. Use cases include manual injection of external RTP input (which is what #1360 was about), but also facilitating the integration with legacy endpoints (e.g., to have SIP users join a Janus AudioBridge).

In order to re-use as much of the existing code as possible, this patch basically just extends the existing API. This means that, to create a plain RTP participant, you still need to attach a Janus handle as you normally would, and still use the join request to let the participant join the room: the difference is that you don't provide any JSEP SDP to negotiate a PeerConnection, but provide an rtp object instead with some info on how the manual RTP connection should be created; the plugin sends back a similar rtp object back in the joined event, and so the external RTP endpoint (which will be seen as a normal participant) and the AudioBridge plugin can send RTP packets to each other.

The syntax for the rtp object is quite simple. An example of a join request might be this:

var join = {
	request: "join",
	room: 1234,
	display: "Plain RTP participant",
	rtp: {
		ip: "192.168.1.10",
		port: 2468,
		audiolevel_ext: 1,
		payload_type: 111,
		fec: true
	}
}

This will tell the plugin that this participant will use plain RTP, and will be listening on the specified ip/port address; if ip/port are missing, it means this participant will only send media, and will not receive any (e.g., for injecting audio), even though resources will still be created for that (encoder, etc.). There's a few additional properties you can provide, like the audio-level extension ID, the payload type to use, and whether FEC should be enabled (basically what you'd normally expect to find in the SDP).

The joined event from the plugin will look exactly as it normally does, but will include an rtp object of its own, e.g.:

{
        "audiobridge" : "joined",
        "room" : <numeric ID of the room>,
        "id" : <unique ID assigned to the participant>,
        "display" : "<display name of the new participant>",
        "participants" : [
                // Array of existing participants in the room
        ],
        "rtp": {
                "ip": "<ip of the plugin">,
                "port": <port the plugin will wait for RTP traffic on>
        }
}

As an application orchestrating an RTP participant, that's all you need to know to complete the setup (where to send RTP packets, and where to expect them from). Notice that the plugin doesn't do any ICE or complex stuff, here: just as the SIP and NoSIP plugins, it expects to be able to communicate on those addresses directly.

I've tested this by modifying the NoSIP demo to connect to the AudioBridge via plain RTP, and it seems to be working as expected. Of course, more testing will need to happen, as I expect issues/crashes/leaks to arise here and there: probably some fine tuning will be needed, which is why for the time being I'll open this as a draft PR. If this interests you, please start testing and provide feedback.

[lminiero]

I've made some more tests for an internal scenario, and it seems to be working as expected for me. I'll wait for (more) feedback before merging, but I consider this effort complete. Unless I see objections, this will be merged soon.

[lminiero]

I've changed the default for the new feature to FALSE, which means that out of the box the plugin will not accept plain RTP Participants: this is to ensure consistency with the current behaviour.

[lminiero]

Merging.