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

Re: impact of bundle and retch-mux on the number of Transports

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Wed, 2 Dec 2015 09:02:57 +0000
To: Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com>
CC: Alexandre GOUAILLARD <agouaillard@gmail.com>, "<public-webrtc@w3.org>" <public-webrtc@w3.org>
Message-ID: <52FA71C9-349E-4D06-A80E-6365BE47E07F@microsoft.com>
Comments below.

> On Dec 1, 2015, at 22:53, Stefan HÃ¥kansson LK <stefan.lk.hakansson@ericsson.com> wrote:
> 
>> On 27/11/15 20:39, Alexandre GOUAILLARD wrote:
>> Hi,
>> 
>> I'm trying to draw what the pipeline would be in different cases, to
>> make it easier to understand, and I'm stuck in a few cases.
> 
> Hi Alex, putting in my understanding below.
> 
>> 
>> Let's suppose I have only one audio track.
>> 
>> 1. If I (want to) use rtcp-mux,
>>   1.a will both the "transport" and "rtcpTransport" attributes of the
>> Sender point to the same object?
> 
> According to the spec, rtcpTransport will be null if rtcp-mux is used.
> 
>>   1.b Will I have only one ice transport ?
> 
> Yes.
> 
>>   1.c if the answer to 2.b is Yes, what is the value of the "component"
>> attribute, RTP or RTCP?
> 
> I don't think that clear from the spec. Filed an Issue 
> (https://github.com/w3c/webrtc-pc/issues/408)

[BA] component === "RTP"

> 
>> 
>> Let's now suppose I have one audio and one video track.
>> 
>> 2. if I (want to) use BUNDLE,
>>   2.a Do I need two transceiver / senders ?
> 
> Yes, a sender only handles one track (and in this case you have one 
> video and one audio track)
> 
>>   2.b Do all the senders.transport, respectively senders.rtcpTransport
>> point to the same DTLS transport.
> 
> all senders.transport point at the same DTLS transport, and all 
> senders.rtcpTransport point at another DTLS transport (assuming not 
> using rtcp-mux)
> 
>>   2.c will that be a unique DtlsTransport if I also use rtcp-mux?
> 
> Yes.

[BA] If RTCP-mux is used as well as BUNDLE there is only one DtlsTransport. If there is RTCP-mux but no BUNDLE there are two DtlsTransport objects.

>> Let's suppose I have only one audio track and one data channel.
>> 
>> 3. If I create a transceiver, I will only have a sender and a receiver
>> but no sctp transport.
>>   3.a Must I create an additional sctp transport object?
> 
> I think that is automatically created when you add a dataChannel
> 
>>   3.b What happen if I want to bundle and rtcp-mux all, should I re-use
>> the DTLS transport from the transceiver to have a unique one?
> 
> I think this happens automatically (and with the current API you don't 
> really create the transports explicitly, they are created as an effect 
> of adding tracks/datachannels to the PeerConnection and are readonly 
> attributes).
> 
>>   3.c in that last case, how many ICE transport do I have ? (1, 2, or 3?)
> 
> 1
> 
>>   3.d as in 1.c, what will be the value of the "Component" for the ICE
>> trasnport(s) in this case?
> 
> As said, I think we must clarify this.


If RTCP-mux is used, then component === "RTP"

> 
>> 
>> Thanks in advance.
>> 
>> Alex.
>> 
>> --
>> Alex. Gouaillard, PhD, PhD, MBA
>> ------------------------------------------------------------------------------------
>> Principal Architect - Citrix, San Francisco
>> President - CoSMo Software Consulting, Singapore
>> ------------------------------------------------------------------------------------
>> https://na01.safelinks.protection.outlook.com/?url=sg.linkedin.com%2fagouaillard&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c99270bc96aaf4905eaf108d2fae54de6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=Ax3DIsVeA3lRLeMYpyTi9QwkL0DLCPtOwObERiY1OKQ%3d <https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fsg.linkedin.com%2fagouaillard&data=01%7c01%7cBernard.Aboba%40microsoft.com%7c99270bc96aaf4905eaf108d2fae54de6%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=QJ2iyWvWmCnI%2b30zYfJmv4dshV5Ia5Qc1w%2faGhK%2fbvA%3d>
>> 
>>  *
>> 
>> 
> 
> 
Received on Wednesday, 2 December 2015 09:03:29 UTC

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