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

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

From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
Date: Wed, 2 Dec 2015 09:22:26 +0000
To: Bernard Aboba <Bernard.Aboba@microsoft.com>
CC: Alexandre GOUAILLARD <agouaillard@gmail.com>, "<public-webrtc@w3.org>" <public-webrtc@w3.org>
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B373FCC13@ESESSMB209.ericsson.se>
On 02/12/15 10:03, Bernard Aboba wrote:
> Comments below.

Thanks Bernard for clarifying. Does this mean that if you only setup a 
data channel (i.e. no audio or video) the component would be "RTP"? Not 
that intuitive IMO, but as long as it is clear it should be OK.

And, I think this (ICE component) should be clarified in the spec.

>
>> 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:23:19 UTC

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