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

On 01/01/14 16:41, Eric Rescorla wrote:
> 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.

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

>
> -Ekr
>
>
> On Tue, Dec 31, 2013 at 10:55 PM, Stefan Håkansson LK
> <stefan.lk.hakansson@ericsson.com> wrote:
>> On 01/01/14 02:47, Martin Thomson wrote:
>>> On 29 December 2013 16:02, Dave Taht <dave.taht@gmail.com> 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
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>