You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[bridge] Feature Request: support multiple concurrent UDP audio streams over a single peer connection #109
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 onlyaddress: "127.0.0.1"# listen address for this UDP socketport: 32001# listen port for this UDP socketsrcId: 1234567# source ID (RID), can be overridden by stream if configureddstId: 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...
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.
Activity
aemcd commentedon Nov 26, 2025
Interested in giving this one a shot (plus I need to comment before someone can assign this to me).
gatekeep commentedon Nov 29, 2025
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.