RTCConnection: archaeology

In Peter's proposal "A proposal for splitting RTCTrack into RtpSender and RtpReceiver.", the RTCConnection object is used in the RTCRtpSender and RTCRtpReceiver constructors: 
http://lists.w3.org/Archives/Public/public-orca/2014Jan/0000.html

When this proposal was edited into the 29 January Editor's draft (see http://ortc.org/wp-content/uploads/2014/01/ortc.html), this left unresolved references to RTCConnection objects in Section 4 (RTCRtpSender),  Section 5 (RTCRtpReceiver) and Section 8 (Data Channel). 

In the 13 February Editor's draft, the references to RTCConnection were replaced by references to RTCDtlsTransport: 
http://ortc.org/wp-content/uploads/2014/02/ortc.html

At least for the the Data Channel (Section 9), this appears incorrect (there is no linkage to the RTCSctpTransport object defined in Section 10), but I am wondering whether this is necessarily what we want for RTCRtpSender and RTCRtpReceiver either. 

While in a browser implementation only DTLS transport would be used, in a server (node.js) implementation, alternative transports would be handy.  For example, in a WebRTC gateway, the WebRTC-facing side would support DTLS transport, but the legacy-facing side might want to support an alternative transport (e.g. SRTP/SDES).  

Given the current spec, the only way to support this would be by using alternate constructors for RTCRtpReceiver and RTCRtpSender, which seems a bit funky.

Received on Tuesday, 18 February 2014 18:06:45 UTC