Enhancements

[sipsorcery]

This issue is to capture issues relating o missing features for the main protocols supported or other generally useful feaures:

WebRTC:

• Session re-negotiation https://w3c.github.io/webrtc-pc/#session-negotiation-model Add support for WebRTC session re-negotation #352 Cannot detect when a track is added by the remote peer #1135
• Google congestion control algorithm Add support for the Google Congestion Control Algorithm #381
• RTCP feedback https://datatracker.ietf.org/doc/html/rfc4585 Add proper RTCP feedback support as per RFC4585 #385 H264 bad video after passing through network; issue with packetization/depacketization apparently.. #877 Problem with receiving image is error #1027
• Bandwidth estimation Bandwidth estimation #825
• Unreliabe data channels Datachannel Reliability Implementation #701
• Data channels general performance Data channels quickly slow down to a crawl under pressure #1088
• Selective Fowarding Unit (SFU) Receiving Substreams from Simulcast-Enabled Devices Without Simulcast Implementation  #976
• TLS connections to STUN/TURN servers About turns and tls in the webRTC #1242

SIP:

• TCP (and TLS) channel performance Growing memory consumption on SipTcpChannel #856
• Add support for STIR/SHAKEN (digitally signing and verifying caller identity) STIR/SHAKEN #1008
• Support for UPDATE requests RFC3311 Add support for RFC3311-UPDATE method #1150

RTP/SRTP:

• SRTP only supports single media type SRTP only works with a single media type at a time #648
• SRTP 256 bit keys as per RFC 7714 RFC 7714 (AES-GCM AEAD support) #871
• RTP audio level extension Issue with Audio Level RTP Extension in Janus-Gateway #1122

Video Ecnoding:

• Performance optimisations Optimisations required for 1080p #384
• VP9 support VP9 Library #505
• Specific encoding parameters Select an exact VideoFormat/AudioFormat during Webrtc SDP #675

STUN:

• Update to support latest RFC8489.

Refactor for RTPSession, MediaStream (including AudioStream & VideoStream) & MediaStreamTrack classes:
The recommendations below are from a ChatGPT review of the relevant classes.

• Extract SDP Logic into a separate class:

  • A new SdpNegotiator (or similarly named) that has:
    • GenerateOffer(), GenerateAnswer(), ApplyRemoteDescription()
    • Maintains a list of chosen audio/video codecs.
    • The old RTPSession (or RTCPeerCOnnection) calls into this class for all offer/answer logic.

• Extract “Transport” (sockets + encryption) from RTPSession:

  • A new RtpTransport that:
    • Owns the RTPChannel, handles raw Send/Receive,
    • Deals with SRTP.
    • RTPSession no longer deals with raw sockets or SRTP. Instead, it calls transport.SendRtp(...), and the transport handles the details.

• Replace “send/receive code in MediaStream” with an RtpSender/RtpReceiver:

  • For each “outgoing” track, create a RtpSender. It references the track’s SSRC, payload type, seqNum counters, etc.
    • For each “incoming” track, create a RtpReceiver. It references the track’s SSRC, handles reordering/jitter.
    • This means MediaStream might just hold references to its associated senders/receivers, or you can rename MediaStream to RTCRtpTransceiver style.
  • Once done, MediaStream might become more about grouping local/remote tracks or might transform into a more direct "WebRTC style" object that references track(s).

Minimize Cross-Dependencies:

• If RTPSession is still big, see if some logic is purely about DTMF events or purely about stats. Move them into smaller classes or modules.
• If you have logic that only deals with one media type (like a reorder buffer specialized for video), consider scoping it to your RtpReceiverVideo or a specialized “video pipeline” class.

Align with naming:

• Rename fields/methods to match WebRTC vocabulary (e.g., SetRemoteDescription, RtpSender, Track.kind, etc.).
• Remove or hide any purely internal references to “RTP session” or “RTP channel” from your public API unless you want advanced users to see them.