Subject: Re: [rtcweb] 5 tuples and rmcat-cc-requirements-01

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jan 2014 07:40:49 -0800

Is there some reason why people are avoiding the obvious avenue
of creating an API to control BUNDLE? We already need one for
BUNDLE-only anyway.

-Ekr

On Tue, Dec 31, 2013 at 10:55 PM, Stefan Håkansson LK
<[email-masked]> wrote:
> On 01/01/14 02:47, Martin Thomson wrote:
>> On 29 December 2013 16:02, Dave Taht <[email-masked]> wrote:
>>> In current implementations, is it possible to force flows onto
>>> different tuples? What are the other flaws in suggesting or requiring
>>> a different tuple?
>>
>> There are quite a few ways to achieve this, depending on your
>> configuration.  All will require some fair amount of SDP cracking.
>>
>> If you have browsers at both ends, try creating two RTCPeerConnection
>> objects on each, and treat one pair as audio and the other video.  You
>> can do this by telling the answerer that audio (or video) is not
>> wanted in the offer (set port zero for the unwanted component).
>> offer.sdp.replace(/m=audio \d+ /, 'm=audio 0 ') should be done before
>> sending the offer out (I don't know whether you can pass this to
>> setLocalDescription safely, so I wouldn't).
>
> One way of doing it without any SDP cracking would be to create two
> different MediaStream's out of the one obtained from getUserMedia; one
> with the audio MediaStreamTrack only, and one with the video one.
>
> Then use one of them with one PeerConnection, and the other with another
> PeerConnection, and assemble into a MediaStream with audio and video at
> the receiving end.
>
> (And this becomes more straightforward if we move to adding tracks and
> not streams to PeerConnection)
>
> If you want to use one PeerConnection only, I think the simplest way
> would be to remove bundle from the SDP offer - either before setLocal or
> before sending the offer to the remote endpoint.
>
>> _______________________________________________
>> rtcweb mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Stefan Håkansson LK <[email-masked]>
Date: Wed, 1 Jan 2014 18:10:06 +0000

> of creating an API to control BUNDLE? We already need one for

I think it would be quite easy to add; for simplicity it could be just 
something stated when constructing the PeerConnection (nobundle).

---

From: Harald Alvestrand <[email-masked]>
Date: Wed, 01 Jan 2014 23:04:59 +0100

> of creating an API to control BUNDLE? We already need one for
I've been thinking that the bundle-only properties of tracks belong with 
the SenderController.

The decision on whether or not to do BUNDLE probably belongs to the 
PeerConnection initialization parameters. Should be easy enough to 
specify, once we all agree that we want it to exist.

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 1 Jan 2014 14:28:29 -0800

On Wed, Jan 1, 2014 at 2:04 PM, Harald Alvestrand <[email-masked]> wrote:
> I've been thinking that the bundle-only properties of tracks belong with the
> SenderController.
>
> PeerConnection initialization parameters. Should be easy enough to specify,
> once we all agree that we want it to exist.

Why do you think one wouldn't want to be able to individually specify
bundle for some of the the m-lines but not others?

-Ekr

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 02 Jan 2014 08:17:13 +0100

> bundle for some of the the m-lines but not others?
I didn't say that!

Some people have said that they want to be able to turn off the entire 
BUNDLE mechanism (no multiplexing at all) - with SDP manipulation, that 
can be accomplished by removing the relevant SDP-session-level line 
(a=group:BUNDLE); since this is an SDP session level attribute, it would 
seem to be reasonable to have the corresponding control on 
PeerConnection initialization.

This is in addition to the disable/enable per track, which I would 
assume would be an extension to the current transmission controller 
proposal, which is at 
http://www.w3.org/2011/04/webrtc/wiki/Transport_Control#API_proposals - 
I haven't seen a specific proposal here yet, but it seems easy enough to 
make.

(now officially back from vacation, so will respond a bit faster now. 
Happy new year, everyone!)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 2 Jan 2014 09:54:18 -0800

> of creating an API to control BUNDLE? We already need one for

The only reason I suggested what I did was because said API doesn't
exist and Dave was looking for immediate answers.  That was why I
didn't mention OfferToReceiveAudio/Video either.

Justin presented (in the IETF, wrong venue :) some very reasonable
suggestions for API on bundle controls.  I see no reason not to do
that, but I was under the impression that current implementations
don't support this either.