- From: <piranna@gmail.com>
- Date: Wed, 16 Oct 2013 17:31:04 +0200
- To: Martin Thomson <martin.thomson@skype.net>
- Cc: "Anniruddh Koppal (Persistent Systems Ltd.)" <v-ankopp@microsoft.com>, "public-orca@w3.org" <public-orca@w3.org>
So what's proposed on https://groups.google.com/d/msg/discuss-webrtc/_VFJ0U6W6Wk/90uPNLQvVVoJ is not possible anyway? :-( 2013/10/16 Martin Thomson <martin.thomson@skype.net>: > I read that thread and what is proposed there is, as Harald points out, impossible. > > What didn't come up on the thread is that you can't know, a priori, the ufrag and pwd for a given peer. You can't even influence the choice the browser makes. > >> -----Original Message----- >> From: piranna@gmail.com [mailto:piranna@gmail.com] >> Sent: Wednesday, 16 October, 2013 7:25 >> To: Anniruddh Koppal (Persistent Systems Ltd.) >> Cc: public-orca@w3.org >> Subject: Re: Object RTC (ORTC) API for WebRTC >> >> 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 >> > -- "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 15:31:52 UTC