[bridge] Feature Request: support multiple concurrent UDP audio streams over a single peer connection

[W3AXL]

Currently, dvmbridge requires a unique instance configured for every UDP audio stream. This is an inefficient use of the peer connection established with the FNE, as it natively supports multiple concurrent call paths. For users who wish to send many distinct audio streams to an FNE, it would be better if one instance of bridge could handle receiving multiple concurrent UDP streams.

To avoid overcomplicating things (at least for now), this configuration should only need to support one-way audio (UDP in, P25/DMR out). We also don't want to change or break any of the currently supported bridge configurations as they are in use in many different places.

I propose the following changes:

• abstract the UDP audio handler and vocoder routines to a class which can be instantiated for each desired input audio stream
• create a new root config stanza (multistream or some similar name) which signals bridge that it should enter into this new, one-way multi stream mode and ignore the standard global UDP config
• in the new multistream config stanza, we would have an array of streams like the following:

  multistream:
    streams:
      - name: "stream1"  # name used for logging and reference only
        address: "127.0.0.1"  # listen address for this UDP socket
        port: 32001  # listen port for this UDP socket
        srcId: 1234567  # source ID (RID), can be overridden by stream if configured
        dstId: 65432  # destination ID (TGID) to use for this stream when sending frames to the FNE
        ...
        # incorporate the rest of the standard UDP audio config options from the global `network` config stanza as well 
        # (usrp, ulaw, silence, etc)
      - name: "stream2"
        # and so on...

[aemcd]

Interested in giving this one a shot (plus I need to comment before someone can assign this to me).

[gatekeep]

Please do this work against the current developer branch and not master. r04k34_dev (which is actually R05A02) will be merged into master, in the next week or so. Doing work against master will cause code conflicts.