W3C home > Mailing lists > Public > public-webrtc@w3.org > May 2016

Re: Issue 651: addTrack/addTransceiver: need to be async?

From: Cullen Jennings (fluffy) <fluffy@cisco.com>
Date: Mon, 23 May 2016 17:03:08 +0000
To: "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <B65DA416-E6E3-402F-8859-A9D7F485B7DC@cisco.com>

It seem to me that generating the cert can be one of this things done while “connecting”. So this state can be entered before the certificate is generated. I don’t think we need to expose a state change for when the certificate creation is completed.



On May 17, 2016, at 10:03 AM, Bernard Aboba <Bernard.Aboba@microsoft.com<mailto:Bernard.Aboba@microsoft.com>> wrote:

https://github.com/w3c/webrtc-pc/issues/651


In the situation where an RTCPeerConnection is constructed without supplying certificates created via generateCertificate(), certificates need to be created and this may happen some time after the RTCPeerConnection is constructed.   As a result, methods that depend on the creation of certificates such as createOffer() are Promise-based, so that certificate creation can be guaranteed to occur before they return (since this is needed to calculate fingerprints, for example).

Currently however, addTrack() and addTransceiver() are synchronous.   This raises questions about the state of the RTCDtlsTransport objects referenced in RTCRtpSender/RTCRtpReceiver objects created by these methods.

Details:

addTrack returns an RTCRtpSender:


    RTCRtpSender                addTrack(MediaStreamTrack track,

                                         MediaStream<http://w3c.github.io/webrtc-pc/#dfn-mediastream>... streams);


addTransceiver returns a transceiver:


RTCRtpTransceiver           addTransceiver((MediaStreamTrack or DOMString) trackOrKind,

                                               RTCRtpTransceiverInit init);


The RTCRtpSender includes read-only attributes for RTCDtlsTransport objects:


partial interface RTCRtpSender {

    readonly attribute RTCDtlsTransport  transport<http://w3c.github.io/webrtc-pc/#dom-rtcrtpsender-transport>;

    readonly attribute RTCDtlsTransport? rtcpTransport;

};


As does the RTCRtpReceiver:


partial interface RTCRtpReceiver {

    readonly attribute RTCDtlsTransport  transport<http://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-transport>;

    readonly attribute RTCDtlsTransport? rtcpTransport<http://w3c.github.io/webrtc-pc/#dom-rtcrtpreceiver-rtcptransport>;

};


Here is the RTCDtlsTransport interface:

interface RTCDtlsTransport {

    readonly attribute RTCIceTransport       transport<http://w3c.github.io/webrtc-pc/#dom-rtcdtlstransport-transport>;

    readonly attribute RTCDtlsTransportState state<http://w3c.github.io/webrtc-pc/#dom-rtcdtlstransport-state>;

    sequence<ArrayBuffer> getRemoteCertificates();

             attribute EventHandler          onstatechange;

};


Currently, when addTrack()/addTransceiver() methods return, the RTCDtlsTransport objects may not necessarily have certificates.   If not, does RTCDtlsTransportState remain “new” until the certificate is created, at which time it can begin negotiation and transition to “connecting”?

Should addTrack()/addTransceiver() use Promises?  Or should applications assume that certificate creation is not assured until createOffer() returns?

Received on Monday, 23 May 2016 17:03:40 UTC

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