- 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>
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