Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

By the way, I think there is (at least) one issue we need to resolve.  For
RtpReceiver to have a .mid, it needs to be chosen at the time of
createRtpReceiver().  But offerToReceiverAudio is chosen at the time of
createOffer(), and making the MID of createRtpReceiver match the MID of
addTrack might be desirable (to have one bidirectional m-line rather than 2
unidirectional ones).  There are a few ways we can do accomplish this:

1.  Make RtpReceiver.mid nullable (only set once negotiated).
2.  Move MID from RtpReceiver.mid to RtpReceiver.getParameters().mid (where
it is in ORTC, by the way).
3.  Allow the JS to choose the MID (which would largely remove the need for
MSID, I think)
4.  Allow createRtpReceiver/createRtpSender to specify it's associate
sender/receiver (the one with the same MID).
5.  Add a method called createRtpSenderAndReceiver which creates a sender
and a receiver with the same MID.

I kind of like #3 since it's a path to cleaning up the MSID situation.

#4 and #5 might be desirable if we don't want to allow #3 but want to allow
JS flexibility in how senders and receiver pair up.

#1 or #2 would be simple to do, and #2 would match ORTC as well.



On Thu, Aug 27, 2015 at 5:01 AM, Adam Bergkvist <adam.bergkvist@ericsson.com
> wrote:

> On 2015-08-26 23:57, Peter Thatcher wrote:
> > It looks like we'll soon be adding PeerConnection.createRtpSender, which
> > is a way to create an RtpSender before one has a track to send.
> >
> > The logic corollary is PeerConnection.createRtpReceiver, which would be
> > a way to create an RtpReceiver before any media negotiation has
> > occurred.  In other words, it would serve the same purpose as
> > "offerToReceiveVideo".
> >
> > In both implementing offerToReceiveVideo and using it in JS, I found it
> > awkward.  I think the following example code would be more natural:
> >
> > var receiver = pc.createRtpReceiver("video");
> > // The offer now acts like it currently does with "offerToReceiveVideo =
> 1".
> > var offer = pc.createOffer();
> > // JS can use the receiver.track immediately.
> >
> >
> > I think this would be more natural, and more logically consistent with
> > PeerConnection.createRtpSender.
> >
> >
> > If you'd like to see how it would look in a PR, here it is:
> >
> > https://github.com/w3c/webrtc-pc/pull/279/files
>
> I like this approach when you explicitly create a new receiver.
>
> It eliminates the confusing with offerToReceiveAudio/Video whether the
> numbers represents *extra* media descriptions that should be added on
> top of those created by the addTrack() API or if the number represents a
> total.
>
> /Adam
>