Re: A proposal for solving non-muxed RTCP *and* ICE freezing

On Wed, May 28, 2014 at 1:57 PM, Bernard Aboba
<Bernard.Aboba@microsoft.com>wrote:

>  Some questions:
>
>
>
> 1.       RTCP ICE and DTLS transports.  Currently
> createAssociatedTransport  returns an RTCIceTransport object for the RTCP
> ICE transport.   One reason to have an RTCIceTransport object for RTCP is
> to use it to construct other objects – such as an RTCDtlsTransport object
> for RTCP.   This leads me to wonder where in the API RTCP-related objects
> would be used.  For example:
>
> a.       Should the RTCRtpReceiver and RTCRtpSender objects take an
> optional transport argument in their constructors of RTCDtlsTransport
> rtcpTransport?
>

That's a good point.  We did overlook this a bit.  We need to make sure 1.
 the JS creates a separate DtlsTransport to wrap the associated
IceTransport (created with createAssociatedTransport) and 2.  The RTCP
packets flow over the create DtlsTransport.  I think we can make #2 happen
in the implementation no matter what we do for #1, but question is: what's
the cleanest way to make it clear to the JS developer that they need to
create a DtlsTransport?  Having a constructor argument is one way, having
an RtpSender.setRtcpTransport is another, and having a
DtlsTransport.createAssociatedTransport is another, and magic implicit
behavior is yet another.  I think we need some code samples to decide which
one is cleanest.


  b.      In the receiver and sender should there be a (nullable) readonly
> attribute for RTCDtlsTransport rtcpTransport?
>
​Same as "a", I think.​

>  c.       Should the RTCRtpListener constructor have an optional
> transport argument for the RTCDtlsTransport object associated with RTCP?
> Should there be a (nullable) readonly attribute for the RTCDtlsTransport
> object associated with RTCP?
>
​What would the RtpListener do with RTCP?

> ​
>
  2.       RTCIceComponent type.  RFC 5245 Section 15.1 defines the
> component-id as an integer ranging from 1 to 256.   So I am wondering if
> the component identifier should be an enum or an unsigned short.
>
​But where does that number actually get used anywhere?  Just in the SDP,
right?  If so, then the shim can worry about it being 2.  The API doesn't
need to.​



>   3.       Use of ICE components.   Currently RTCIceCandidate does not
> include the component-id.  Should it be added?
>
​
I would say definitely not.​
​
​  The RTCIceCandidate is used to communicate information to/from the
IceTransport.  But the IceTransport already knows which component it is, so
the it's unnecessary and even confusing.  The only time you would want it
is in the signalling, but the app can figure out how to do that.  No need
to clutter the API.  Plus, most people doing rtcp non-mux will be using
some legacy signalling which will have a slot for component, and wouldn't
use this object directly for signalling anyway.​

​​

>
>
> dictionary RTCIceCandidate {
>
>     DOMString               foundation;
>
>     RTCIceComponent         componentid;
>
>     unsigned long           priority;
>
>     DOMString               ip;
>
>     RTCIceProtocol          protocol;
>
>     unsigned short          port;
>
>     RTCIceCandidateType     type;
>
>     RTCIceTcpCandidateType? tcpType = null;
>
>     DOMString?              relatedAddress = "";
>
>     unsigned short?         relatedPort = null;
>
> };
>