Goodbye DeprecatedPeerConnection

[Serge Lachapelle]

Hello everyone,

We now have a new W3C editor's draft to work with. This draft, which can be found at http://dev.w3.org/2011/webrtc/editor/webrtc.html , makes it possible for us to move forward with our implementation of PeerConnection.

To keep the code base manageable, we will be removing DeprecatedPeerConnection from the API. This change will affect Canary and Dev versions soon. The newer JSEP API provides greater flexibility and allows for easier encapsulation of other protocols. A lot has been written about it.

For those that want a quick transition to the new API, we recommend using the ROAP to JSEP JS library created by one of our colleagues. It abstracts DeprecatedPeerConnection while using the newer JSEP API. It can be found here: http://code.google.com/p/webrtc-samples/source/browse/#svn%2Ftrunk%2Froap-jsep

Thanks,

/Serge

[Justin Uberti]

In addition, the samples at https://apprtc.appspot.com and https://webrtc-demos.appspot.com/html/pc1.html show how to use webkitPeerConnection00, and will be updated to use webkitPeerConection01 when it lands.

--
 
 
 

[Lorenzo Miniero]

Hi Justin,

any idea on when this will effectively change in the Canary release? will this just require a change in the JavaScript, that is, how peer connections are created and managed, or will it add some other breaking changes in PeerConnections themselves? as I anticipated a few posts ago, we'll include WebRTC as a way to remotely attend IETF meeting sessions in Vancouver next week, so I'd like to be prepared in case this happens right in the middle of it :)

Lorenzo

[Tommy Widenflycht (ᛏᚮᛘᛘᚤ)]

The plan is to remove DeprecatedPeerConnection later this week.

I don't quite understand your question but everyone who uses PeerConnection00 (with JSEP signaling) will not be affected by this.

/Tommy

--
 
 
 

--
Tommy Widenflycht, Senior Software Engineer
Google Sweden AB, Kungsbron 2, SE-11122 Stockholm, Sweden
Org. nr. 556656-6880
And yes, I have to include the above in every outgoing email according to EU law.

[Lorenzo Miniero]

Thanks for your clarification: we already use webkitPeerConnection00 (via roap_on_jsep) so I guess that will be okay.

I asked about this since, in our scenario, the peer of a WebRTC client is not another browser but our conferencing server. As such, we implemented some stuff at the media level to get this working, and so I was wondering whether or not the changes would also affect something in there as well, or just the interfaces of PeerConnection in JavaScript.

Lorenzo

[Albert Abello]

Justin, another question, the examples offered in the draft regarding to the DataChannel are still not implemented on canary right? Do you know any approximate delivery date for that?

The only ones i've been playing are the early releases of Firefox and seem quite unstable yet.

Cheers

Albert

[Punyabrata Ray]

Correct, the data channel API is not implemented and its implementation is being discussed in the standards committee. We will begin to focus on it as soon as we stabilize PeerConnection.

/Ray

--
 
 
 

[Bryan Donnovan]

Is it necessary to keep webkitPeerConnectionXX behind a chrome://flag ?  That flag adds a nontrivial hurdle to getting users to test out software that relies on WebRTC, and my own user testing would be made much simpler if the PeerConnection was always available.  

[Lorenzo Miniero]

I think keeping the flag is still a good idea. There are several security concerns related to the work the W3C and IETF are carrying on to develop a native way of sending media from your devices out in the world. Until they're all sorted out, IMHO it's probably best to let people interested in the feature enable it manually, and people who don't even know about that not to worry/care.

[Vikram Mohan Kale]

Hi all,

I have been working on a Video-conferencing engine based on this demo(see attached zip file). As you all may already know, it is based on the implementation launched by Chrome in January 2012. It uses a central signalling entity(peerconnection_server.exe) and each client then uses the IP address of the server to communicate with it. Now, with the changeover to WebkitPeerConnectionXX, the signaling is not being established correctly. Kindly suggest to me the relevant changes that I need to make in order to make. Please note that I DO NOT want to do away with peerconnection_server.exe.


Thanks

Vikram

[PhistucK]

This is just a guess, but maybe the ROAP over JSEP library can help?

http://code.google.com/p/webrtc-samples/source/browse/trunk/roap-jsep/roap_on_jsep.js

As far as I understand, DeprecatedPeerConnection was ROAP and PeerConnection00 is JSEP, so this should be some sort of a bridge.

☆PhistucK

--
 
 
 

[Vikram Mohan Kale]

Hi PhistucK, all

I did have a look into the library you suggested and also at the available demos. Let us take the demo at https://apprtc.appspot.com as an example. In this, if I understand correctly, a session is created, and a call is completed when the callee basically navigates to the URL provided at the caller side. On the other hand, with the use of peerconnection_server.exe application, there was no need to transmit URLs. One could simply connect with the server, and find the other users connected with the server and call them (which to my understanding is also the method with which most messaging or calling softwares such as Skype or MSN messenger work). Has this functionality been done away with? Is it expected that developers design their own server application and integrate it with the API?

Thanks

Vikram

[Justin Uberti]

You can still build applications just like peerconnection_server with the new API.

--
 
 
 

[Vikram Mohan Kale]

Hi

But is there a way by which the sample codes can be modified to make sure they work with peerconnection_server.exe?

Thanks

Vikram