- From: <piranna@gmail.com>
- Date: Wed, 16 Oct 2013 16:25:13 +0200
- To: "Anniruddh Koppal (Persistent Systems Ltd.)" <v-ankopp@microsoft.com>
- Cc: "public-orca@w3.org" <public-orca@w3.org>
For what I saw in the spec (the .connect() method), seems that it's only necessary to have one endpoint connection data to establish the connection, sending back the other endpoint connection data internally like it's suggested for WebRTC at https://groups.google.com/forum/#!topic/discuss-webrtc/_VFJ0U6W6Wk, isn't it? This is a cool feature... :-) Also, is there any way to get a list of currently active DataChannels on a RTCConnection? 2013/10/15 Anniruddh Koppal (Persistent Systems Ltd.) <v-ankopp@microsoft.com>: > Reposting to public-orca. > > > > > > Regards, > > Anniruddh > > ________________________________ > From: Anniruddh Koppal (Persistent Systems Ltd.) <v-ankopp@microsoft.com> > Sent: Monday, October 14, 2013 11:22 AM > To: public-orca-contrib@w3.org > Subject: Object RTC (ORTC) API for WebRTC > > > Hi All, > > > > Below are some of my comments/suggestions to the ORTC specification – > > > > · For RTCConnection, should there be an ‘onerror’ event too ? > > · For RTCConnection.connect/close, once an established connection > is closed by user and later if they try to connect again, should the > process start from scratch like exchanging track information etc. or try to > re-establish connection with available data ? > > · For RTCCOnnection.removeStream, should the linked RTCTracks be > stopped and removed too if this stream is the only stream they are linked > to? > > · For RTCTrack, should there be a ‘pause’ method too ? > > · For RTCTrack.remove(), how should the track be ‘un-removed’ or > perhaps enabled again if the user wishes to ? > > > > > > Please share your views. Thanks. > > > > > > Regards, > > Anniruddh -- "Si quieres viajar alrededor del mundo y ser invitado a hablar en un monton de sitios diferentes, simplemente escribe un sistema operativo Unix." – Linus Tordvals, creador del sistema operativo Linux
Received on Wednesday, 16 October 2013 14:26:01 UTC