W3C home > Mailing lists > Public > public-webrtc@w3.org > August 2015

Re: Proposal: Replace offerToReceiveVideo with PeerConnection.createRtpReceiver.

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 28 Aug 2015 13:37:52 +0200
Message-ID: <55E04810.1070905@alvestrand.no>
To: public-webrtc@w3.org
Den 27. aug. 2015 23:14, skrev Peter Thatcher:
> 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. 

I seem to be repeating this forever... the purpose of MSID is to carry
the ID of the media stream, the media stream track and the association
between the two inside SDP.

Nothing you can do with a single value can do that.
MID and MSID do not serve the same purpose.

> 
> #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.

I like #2. I also think that it's equivalent to #1 (presumably it would
return Null if called before either setLocal or setRemote has been
called), so the difference is syntax, not semantics.

#3-#5 are problematic if the call is incoming; if the MIDs match, what
then? If the MIDs don't match, what then?

As far as I understand the spec for MID, it's set in the offer (so it's
decided by the offerer), and can't be changed, except that if it's not
set in the offer, the answerer may add it.
Received on Friday, 28 August 2015 11:38:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:45 UTC