Re: Proposal for a way to set the send codec on an RtpSender.

On Wed, Aug 5, 2015 at 2:07 PM, Adam Roach <adam@nostrum.com> wrote:

> 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
>
> ​
>
​Well, I was thinking of an MCU that doesn't use SDP for the signalling in
the first place.  But if you changed rewrote your description in terms of
SetLocalDescription and SetRemoteDescription instead of offer/answer, then
yes, that's what I'm describing.

​|​

​I​
f 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 new offer from the client (not the MCU) would express what the client
is willing/able to receive, which is independent from what it can send.
So, no, it would not be excluded, because what it can receive is still the
same.  If the MCU were to send a new offer to the client, I think it would
leave VP8 in there because should it decided later that it wants VP8 again,
it could ask the client to switch using the new RtpSender knob back to VP8
without doing a new offer, which is easier.

So, in all cases that I can think of, VP8 would stay.