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

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?

b.      In the receiver and sender should there be a (nullable) readonly attribute for RTCDtlsTransport rtcpTransport?

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?

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.

3.       Use of ICE components.   Currently RTCIceCandidate does not include the component-id.  Should it be added?

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