W3C home > Mailing lists > Public > public-orca@w3.org > February 2014

RTCConnection: archaeology

From: Bernard Aboba <Bernard.Aboba@microsoft.com>
Date: Tue, 18 Feb 2014 18:06:17 +0000
To: "public-orca@w3.org" <public-orca@w3.org>
Message-ID: <3d8e4235c96f451aaeada9abfbca8aa7@SN2PR03MB031.namprd03.prod.outlook.com>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:39:24 UTC