SDP mangling: control encoding or control packetization?

[alvestrand]

(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]

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