Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SDP mangling: control encoding or control packetization? #199

Closed
alvestrand opened this issue Aug 31, 2023 · 1 comment
Closed

SDP mangling: control encoding or control packetization? #199

alvestrand opened this issue Aug 31, 2023 · 1 comment

Comments

@alvestrand
Copy link
Contributor

(Unusual usage of bug tracker: asking for input on a feature of an outstanding PR)
While pondering #186 , I wonder if I should redesign.

The purpose of having a packetizer field in the codec description is to control the packetizer/depacketizer once the codec has been negotiated. But putting it in the SDP description kind of mixes the SDP negotiation (outside of transport) with the transport control.

This came to a head when considering how to set the outgoing codec, given that we have a new API for setting it using SetParameters.

New suggestion:

  • Drop the packetizer from the negotiation. The two parties have to agree that they are willing to understand what this codec name represent, that's all the SDP module should care about.
  • Use SetParameters() to get the encoder to encode the type that the transform expects as input. This already exists.
  • Add a new call - RtpSender.SetPacketizer(PT, DOMString) - where the MIME type has a predefined effect, others may be added.
  • Similarly, RtpReceiver.SetDepacketizer(PT, DOMString)
  • If no packetizer /depacketizer is registered for a PT when a frame/packet is sent for packetization/depacketization, drop it.

It seems cleaner.

@jan-ivar @youennf @Orphis @henbos - WDYT?

@alvestrand
Copy link
Contributor Author

Switched to setting packetizer in today's version of #186

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant