Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[FEATURE REQUEST] - Forwarding Media Websocket (not just TCP/TLS)

Aperta
  • Qualcosa non va?
#1,861 0 commenti 2 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Funzionalità
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
json
Ambito
networking

Direzione di ricerca

Start from the documented start-forwarding/stop-forwarding control messages in ng_control_protocol (rtpengine.readthedocs.io), and the recording daemon that currently emits PCM over plain TCP/TLS. The request bundles three separable changes — a WS/WSS transport option, a base64 metadata header on the first packet, and a per-call dynamic destination — so scope needs agreement before any code. Check the media-forking discussion for prior art; no branch or test exists yet, and "done" would only be definable once the transport and metadata framing are settled.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

feature-request
Is your feature request related to a problem? Please describe

There seems to be a bit of momentum in media forking to a websocket (per call), it would be ideal if this functionality was native to rtpengine.

Describe the solution you'd like

RTPEngine already has a feature

https://rtpengine.readthedocs.io/en/latest/ng_control_protocol.html#start-forwarding-and-stop-forwarding-messages

start forwarding and stop forwarding

These messages control the recording daemon’s mechanism to forward PCM via TCP/TLS. Unlike the call recording mechanism, forwarding can be enabled for individual participants (directionally) only, therefore these messages can be used with the same options as the block and unblock messages above. The PCM forwarding mechanism is independent of the call recording mechanism, and so forwarding and recording can be started and stopped independently of each other.

To increase interoperability and standardized media forking I would suggest the following:

  1. Optionally allow raw TLS/TCP to use the WS/WSS protocol instead.
  2. Allow the first packet to include metadata decoded from base64 (This allows for good escaping from data flowing from the signaling servers), which could be decoded when sent. This allows for payloads such as JSON.
  3. Allow dynamic setting of the WS/WSS destination per call.
Describe alternatives you've considered

It is possible to build a side-car process to receive media forwarded to localhost on plain TCP/TLS, parse and process the metadata headers. to then allow forwarding to a destination specified in the metadata. However I feel that this adds unecessary complexity to something which would be useful to have a native integration.

The rtpengine version you checked that didn't have the feature you are asking for

No response

Lingua principale
Perl
Stelle
992
Fork
459
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di sipwise/rtpengine

Tutte le issue di sipwise/rtpengine

Issue simili

Altre issue su Perl

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.