On 8/5/15 15:25, Peter Thatcher wrote:
> 3. Sending to an MCU, the MCU might have a new receiving client join
> that can't do a certain codec (say, Opus). All senders need to switch
> to a different codec. Doing a full offer/answer, or doing SDP
> munging, for just that, is overkill for the operation desired.
I think you *might* have lost me here. Is the behavior you're imagining
something like:
* Offerer sends an offer with VP8 and H.264
* Answerer replies with an answer with VP8 and H.264
* Offerer sends VP8
* At some later time, the javascript tweaks a knob on the RtpSender,
and the offerer switches from VP8 to H.264 without any SDP exchanged
If that's the case you have in mind, do you envision that the offerer,
if he sent a new offer at this point, would exclude VP8 from the offer?
/a