Add RTCRtpTransceiver and PeerConnection.addMedia. #293

pthatcherg · 2015-09-09T06:27:25Z

This is intended to replace createRtpSender (#271) and createRtpReceiver (#279) with something more powerful and complete. It also fixes #187.

Needs list discussion, and I'd like to present on it at the f2f.

adam-be · 2015-09-09T20:46:48Z

webrtc.html

@@ -2559,6 +2557,17 @@
            </ol>
          </dd>

+          <dt>RTCRtpSender addMedia (DOMString kind, RTCRtpTransceiverInit init)</dt>


RTCRtpTransceiver as return value?
First argument: (MediaStreamTrack or DOMString) media?

Yes and yes.

adam-be · 2015-09-09T21:35:36Z

I couldn't get my microphone working during this session on the f2f meeting.

As I understand this PR, there's API for the A-side to add media and inspect existing transceivers. Have you thought anything about how the B-side API looks?

dontcallmedom · 2015-09-16T16:04:12Z

webrtc.html

@@ -2446,6 +2424,26 @@
            defined and the order does not have to be stable between calls.</p>
          </dd>

+          <dt>sequence&lt;RTCRtpTranseceivers&gt; getMedia()</dt>


This should probably be Transceiver (here and in the rest of the text)

Yep, fixed it.

martinthomson · 2015-09-16T17:28:26Z

Consensus from the meeting was that the name was bad. I don't think that there was wide agreement on a name, but I recall addMediaSection being mentioned. If that is the name then RTCTransceiver could - and maybe should - be named RTCMediaSection.

jan-ivar · 2015-09-16T17:49:16Z

RTCMediaLine?

pthatcherg · 2015-09-16T17:51:13Z

Yes, addMedia is a bad name. But how is RTCRtpTransceiver? If it's
palatable, then we could simply call the method to create one
createRtpTransceiver. It's a bit advanced, but it exists mostly for
advanced use cases anyway.

On Wed, Sep 16, 2015 at 10:28 AM, Martin Thomson notifications@github.com
wrote:

Consensus from the meeting was that the name was bad. I don't think that
there was wide agreement on a name, but I recall addMediaSection being
mentioned. If that is the name then RTCTransceiver could - and maybe
should - be named RTCMediaSection.

—
Reply to this email directly or view it on GitHub
#293 (comment).

pthatcherg · 2015-09-16T17:52:28Z

What was mentioned on one my slides was the full "bear hug":
addSdpMediaSection with RTCSdpMediaSection. But it wasn't met with much
approval.

On Wed, Sep 16, 2015 at 10:28 AM, Martin Thomson notifications@github.com
wrote:

Consensus from the meeting was that the name was bad. I don't think that
there was wide agreement on a name, but I recall addMediaSection being
mentioned. If that is the name then RTCTransceiver could - and maybe
should - be named RTCMediaSection.

—
Reply to this email directly or view it on GitHub
#293 (comment).

alvestrand · 2015-09-17T10:13:21Z

Met with approval in Seattle (modulo name bikeshed). Should be reviewed and merged.

alvestrand · 2015-09-17T14:29:21Z

Waiting for naming discussions to conclude. Also, Travis errors.

pthatcherg · 2015-09-18T23:29:11Z

FYI, I have change the name in the PR to createRtpTransceiver until we come
up with a better one.

On Wed, Sep 16, 2015 at 10:50 AM, Peter Thatcher pthatcher@google.com
wrote:

Yes, addMedia is a bad name. But how is RTCRtpTransceiver? If it's
palatable, then we could simply call the method to create one
createRtpTransceiver. It's a bit advanced, but it exists mostly for
advanced use cases anyway.

On Wed, Sep 16, 2015 at 10:28 AM, Martin Thomson <notifications@github.com

wrote:

Consensus from the meeting was that the name was bad. I don't think that
there was wide agreement on a name, but I recall addMediaSection being
mentioned. If that is the name then RTCTransceiver could - and maybe
should - be named RTCMediaSection.

—
Reply to this email directly or view it on GitHub
#293 (comment).

dontcallmedom · 2015-09-21T08:04:55Z

webrtc.html

@@ -2559,6 +2560,25 @@
            </ol>
          </dd>

+          <dt>RTCRtpTransceiver createRtpTransceiver(MediaStreamTrack or
+          DOMString track_or_kind, RTCRtpTransceiverInit init)</dt>
+


The union type MediaStreamTrack or DOMString needs to be wrapped in parenthesis, i.e. (MediaStreamTrack or DOMString) track_or_kind

pthatcherg · 2015-09-23T12:54:35Z

Sorry about all the typos. I guess I was a little too rushed when writing this. Hopefully you found all of them.

stefhak · 2015-10-20T06:06:13Z

What happens if you create two transceivers (of same type), and two tracks, and then receive one or two tracks (sort of like SSRCs) in RTP? How would that be wired up?
Also, #283 had an event fired when unknown media arrived at any time (i.e. also if there was no ongoing O/A). That is not supported here - are we fine with removing that? Asking @martinthomson.
Finally: if I were to implement this, I think I would need some more normative text. An example showing how the Transceiver can be used to handle early media is good, but the spec must be clear enough to implement.
To be clear: I think we should merge this PR, but knowing there is more work to be done speccing things out.

pthatcherg · 2015-10-20T18:57:57Z

I don't remember what the plan for completely unknown media is. I'd have
to go read the f2f minutes/notes to remember. Martin, do you remember?

As for normative text, I'll add some in the addTransceiver method saying
that the receiver can receive media before setRemoteDescription is called
with an answer, along with the example which I'll add.

If you create two transceivers of the same type, they'll have different
MIDs, and they can be demuxed by MID. Is that what you were asking? It
wasn't completely clear.

On Mon, Oct 19, 2015 at 11:06 PM, stefan hakansson <notifications@github.com

wrote:

What happens if you create two transceivers (of same type), and two
tracks, and then receive one or two tracks (sort of like SSRCs) in RTP? How
would that be wired up?
Also, #283 #283 had an event fired
when unknown media arrived at any time (i.e. also if there was no ongoing
O/A). That is not supported here - are we fine with removing that? Asking
@martinthomson https://github.com/martinthomson.
Finally: if I were to implement this, I think I would need some more
normative text. An example showing how the Transceiver can be used to
handle early media is good, but the spec must be clear enough to implement.
To be clear: I think we should merge this PR, but knowing there is more
work to be done speccing things out.

—
Reply to this email directly or view it on GitHub
#293 (comment).

alvestrand · 2015-10-20T19:10:11Z

Den 20. okt. 2015 20:57, skrev pthatcherg:

I don't remember what the plan for completely unknown media is. I'd have
to go read the f2f minutes/notes to remember. Martin, do you remember?

For media that made it past SRTP verification but can't be associated to
an m-line?
I think it's safe to drop it, but YMMV.

As for normative text, I'll add some in the addTransceiver method saying
that the receiver can receive media before setRemoteDescription is called
with an answer, along with the example which I'll add.

If you create two transceivers of the same type, they'll have different
MIDs, and they can be demuxed by MID. Is that what you were asking? It
wasn't completely clear.

I think that's right. That means MID must be known at addTransceiver
time (or at least before media arrives), which is OK.

On Mon, Oct 19, 2015 at 11:06 PM, stefan hakansson <notifications@github.com

wrote:

What happens if you create two transceivers (of same type), and two
tracks, and then receive one or two tracks (sort of like SSRCs) in RTP? How
would that be wired up?
Also, #283 #283 had an event fired
when unknown media arrived at any time (i.e. also if there was no ongoing
O/A). That is not supported here - are we fine with removing that? Asking
@martinthomson https://github.com/martinthomson.
Finally: if I were to implement this, I think I would need some more
normative text. An example showing how the Transceiver can be used to
handle early media is good, but the spec must be clear enough to implement.
To be clear: I think we should merge this PR, but knowing there is more
work to be done speccing things out.

—
Reply to this email directly or view it on GitHub
#293 (comment).

—
Reply to this email directly or view it on GitHub
#293 (comment).

stefhak · 2015-10-21T05:36:46Z

Yes, I think this would work. Association is made by the MID field in the RTP header.
This does not however address the case #283 addresses, namely firing an event if there is incoming (authenticated) media "out of the blue" (i.e. no ongoing negotiation, or ongoing negotiation but with a MID that is not part of the outstanding offer). Personally I'm fine with that, just want to raise the question to @martinthomson and @fluffy

martinthomson · 2015-10-21T19:30:11Z

As we discussed, I think that this is fine. We can generate messages for the console if we find that diagnosing session errors is difficult.

stefhak · 2015-10-22T13:01:51Z

Given that, I propose we merge this PR.

alvestrand · 2015-10-22T13:32:12Z

Would be great to have a rebase...

alvestrand · 2015-10-22T13:38:53Z

webrtc.html

+
+            <p>If a kind is passed in, the value of the <code>.sender.track</code> will be
+            null and and media type generated by <code>createOffer</code> will be that of
+            the kind.  The MSID generated by <code>createOffer</code> will be selected by


According to the MSID spec, this will cause a track to be created at the remote side after an offer/answer exchange. I assume this is required as part of the "warmup" usage.
Don't we want to prevent this by passing "send:false"?

The MSID is only generated if needed, such as when "send: true". I will make that more explicit.

alvestrand · 2015-10-22T13:45:08Z

I reviewed the PR a little more closely than before, and as always, found a few nits. If you can address them while rebasing, that would be great.

elagerway · 2015-10-22T14:23:15Z

@pthatcherg can you have another look at this, feels like we are close.

pthatcherg · 2015-10-22T23:41:56Z

I'll rebase and address the issues.

On Thu, Oct 22, 2015 at 7:23 AM, Erik Lagerway notifications@github.com
wrote:

@pthatcherg https://github.com/pthatcherg can you have another look at
this, feels like we are close.

—
Reply to this email directly or view it on GitHub
#293 (comment).

pthatcherg · 2015-10-23T23:42:31Z

I've rebased and addressed the issues.

On Thu, Oct 22, 2015 at 4:41 PM, Peter Thatcher pthatcher@google.com
wrote:

I'll rebase and address the issues.

On Thu, Oct 22, 2015 at 7:23 AM, Erik Lagerway notifications@github.com
wrote:

@pthatcherg https://github.com/pthatcherg can you have another look at
this, feels like we are close.

—
Reply to this email directly or view it on GitHub
#293 (comment).

pthatcherg · 2015-10-24T00:03:18Z

I also added an example of receiving media before signalling on the offerer
side.

On Fri, Oct 23, 2015 at 4:41 PM, Peter Thatcher pthatcher@google.com
wrote:

I've rebased and addressed the issues.

On Thu, Oct 22, 2015 at 4:41 PM, Peter Thatcher pthatcher@google.com
wrote:

I'll rebase and address the issues.

On Thu, Oct 22, 2015 at 7:23 AM, Erik Lagerway notifications@github.com
wrote:

@pthatcherg https://github.com/pthatcherg can you have another look
at this, feels like we are close.

—
Reply to this email directly or view it on GitHub
#293 (comment).

Add RTCRtpTransceiver and PeerConnection.addMedia.

Add RTCRtpTransceiver and PeerConnection.addMedia.

e0c1dbe

adam-be reviewed Sep 9, 2015
View reviewed changes

martinthomson mentioned this pull request Sep 9, 2015

Adding null track factory #297

Closed

dontcallmedom reviewed Sep 16, 2015
View reviewed changes

This was referenced Sep 17, 2015

Add PC.createRtpSender. #271

Closed

Add PeerConnection.createRtpReceiver. #279

Closed

alvestrand added the List discussion needed label Sep 17, 2015

pthatcherg added 2 commits September 18, 2015 16:27

Fix some typos and missing things.

00f3b5b

Rename to createRtpTransceiver.

13f23de

dontcallmedom reviewed Sep 21, 2015
View reviewed changes

Fix a bunch of typos.

4999fef

martinthomson mentioned this pull request Oct 21, 2015

Options to guide codec selection #326

Closed

alvestrand reviewed Oct 22, 2015
View reviewed changes

elagerway added the Needs submitter action label Oct 22, 2015

alvestrand mentioned this pull request Oct 22, 2015

.mid attribute - random or Null when MID is not present in SDP? #227

Closed

pthatcherg added 3 commits October 23, 2015 15:41

Merge with master.

3e0deaa

Fix nits

0ff0d7f

Simplify the logic around when addTrack will reuse an RtpSender.

5bcd0c8

Add an example of receiving media before signalling.

3ee53bf

Add a </p>.

15e6453

alvestrand added a commit that referenced this pull request Oct 24, 2015

Merge pull request #293 from pthatcherg/rtp-transceiver

2c46535

Add RTCRtpTransceiver and PeerConnection.addMedia.

alvestrand merged commit 2c46535 into w3c:master Oct 24, 2015

alvestrand removed the Needs submitter action label Jun 20, 2016

alvestrand mentioned this pull request Jun 20, 2016

offerToReceiveAudio/offerToReceiveVideo remain in implementations (likely needed for compat) #709

Closed

burnburn mentioned this pull request Aug 18, 2016

Need JSEP reference for end-of-candidates indication #723

Closed

jan-ivar mentioned this pull request Jun 7, 2017

Do we need a "trackremoved" event? #1161

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add RTCRtpTransceiver and PeerConnection.addMedia. #293

Add RTCRtpTransceiver and PeerConnection.addMedia. #293

pthatcherg commented Sep 9, 2015

adam-be Sep 9, 2015

pthatcherg Sep 18, 2015

adam-be commented Sep 9, 2015

dontcallmedom Sep 16, 2015

pthatcherg Sep 18, 2015

martinthomson commented Sep 16, 2015

jan-ivar commented Sep 16, 2015

pthatcherg commented Sep 16, 2015

pthatcherg commented Sep 16, 2015

alvestrand commented Sep 17, 2015

alvestrand commented Sep 17, 2015

pthatcherg commented Sep 18, 2015

dontcallmedom Sep 21, 2015

pthatcherg Sep 23, 2015

pthatcherg commented Sep 23, 2015

stefhak commented Oct 20, 2015

pthatcherg commented Oct 20, 2015

alvestrand commented Oct 20, 2015

stefhak commented Oct 21, 2015

martinthomson commented Oct 21, 2015

stefhak commented Oct 22, 2015

alvestrand commented Oct 22, 2015

alvestrand Oct 22, 2015

pthatcherg Oct 23, 2015

alvestrand commented Oct 22, 2015

elagerway commented Oct 22, 2015

pthatcherg commented Oct 22, 2015

pthatcherg commented Oct 23, 2015

pthatcherg commented Oct 24, 2015

Add RTCRtpTransceiver and PeerConnection.addMedia. #293

Add RTCRtpTransceiver and PeerConnection.addMedia. #293

Conversation

pthatcherg commented Sep 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

adam-be commented Sep 9, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

martinthomson commented Sep 16, 2015

jan-ivar commented Sep 16, 2015

pthatcherg commented Sep 16, 2015

pthatcherg commented Sep 16, 2015

alvestrand commented Sep 17, 2015

alvestrand commented Sep 17, 2015

pthatcherg commented Sep 18, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

pthatcherg commented Sep 23, 2015

stefhak commented Oct 20, 2015

pthatcherg commented Oct 20, 2015

alvestrand commented Oct 20, 2015

stefhak commented Oct 21, 2015

martinthomson commented Oct 21, 2015

stefhak commented Oct 22, 2015

alvestrand commented Oct 22, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

alvestrand commented Oct 22, 2015

elagerway commented Oct 22, 2015

pthatcherg commented Oct 22, 2015

pthatcherg commented Oct 23, 2015

pthatcherg commented Oct 24, 2015