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

Den 17. mai 2016 19:03, skrev Bernard Aboba:
> 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?
> 

I can't imagine a reason (just now at least) for the client to need to
know whether certificates are present or not until createOffer()
completes - at which time the certificates have to exist (otherwise the
fingerprint field in the offer couldn't have been populated).

And the connection can't transition to "connecting" before an offer is
created anyway, so the consequence is that until you call createOffer,
the connection *will* remain in state "new".

If there is a reason to need to know, you've shown the interface where
the client can look. If he wants to wait for the field to be populated,
he can call createOffer() - there's no requirement that the first
createOffer() be the one used.

But as I said - I can't imagine a reason why he should care.


>  
>

Received on Tuesday, 17 May 2016 21:20:28 UTC