Tag Archive | Skype

Vancouver WebRTC – Meetup 2 @PlentyofFish

With more than 40 members and growing, Vancouver WebRTC now has a new venue! Chris Simpson from PoF rallied to get us into their new presentation lounge, the “Aquarium”, thanks Chris!

IMG_4459-1 IMG_4456-1IMG_4458-1

Our next event is on June 25th from 6-8pm and we have a great evening planned with Omnistream and Perch presenting!

Come check it out!

Hookflash, Google and Microsoft lead on ORTC / WebRTC 1.1 Public Draft

webrtc1.1_logo

The first ORTC Public Draft Specification has been published, authored by Hookflash, Microsoft, and Google. (http://ortc.org/wp-content/uploads/2014/08/ortc.html ) This specification extends WebRTC 1.0 with new functionality to create a WebRTC 1.1 API with exceptional flexibility and no loss of compatibility.

Like WebRTC, ORTC (Object Real-time Communication) enables plugin-free real-time communications for mobile, web and cloud, but is specifically tailored to provide the direct control needed to enable advanced multimedia and conferencing features.

“We heard developers say that they wanted more direct control over the technologies available in WebRTC. At the same time, we didn’t want existing developers to have to start over with a new API. ORTC is our proposal for how we can accomplish both of these things – a new set of APIs for direct control, that builds off the existing WebRTC 1.0 API set. As an evolution of the existing API, we consider this WebRTC 1.1” comments Justin Uberti, Google Tech Lead, WebRTC. “We’re grateful to Hookflash for their work to get ORTC off the ground. They have been instrumental in making this cross-industry collaboration happen, and we look forward to continuing our work with them.”

This newly published public draft has come a long way since the W3C ORTC Community Group was formed in mid-2013. As it has progressed from an initial set of ideas to a fleshed-out draft complete enough for implementations, several companies have gotten closely involved, with Microsoft and Google now joining Hookflash as authors of the emerging specification.

“We have been working hard to get the ORTC API to the point where it can be implemented. This would not have been possible without the initial and continuing work of Hookflash”, commented Bernard Aboba, Principal Architect, Skype, “We also are excited by the ORTC API’s support for advanced video features such as SVC (Scalable Video Coding) and simulcast. The Javascript Object API approach has made these advanced video technologies more accessible, which has been difficult in the past.”

The W3C ORTC Community Group now numbers more than 60 participants.

“We believe the contributions to WebRTC 1.1 / ORTC will allow web communications technology to become ubiquitous and transcend nearly all communications technologies that came before it” says Hookflash Co-founder, Erik Lagerway, “We are honored to be working with some of the brightest minds at Google, Microsoft, and the other contributing members in the ORTC CG to mature WebRTC into a universal go-to toolkit enabling communications across the globe.”

For more information on ORTC, see:
W3C ORTC Community Group
ORTC.org – History and FAQs
WebRTC.is – ORTC & WebRTC news

Hookflash enables real-time social, mobile, and web communications for integration of voice, video, messaging with federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc.

Developers can register at (http://fly.hookflash.me) to start using the Hookflash RTC service and toolkits today. For more information on Hookflash RTC toolkits and White Labeling please visit Hookflash http://hookflash.com.

Come and work at one of the coolest companies in the space! We’re now hiring for these development positions: iOS, Android, Node.js & C++ send us your resume: jobs@hookflash.com.

Hookflash – Trent Johnsen
855-466-5352 Ext: 1

SDP inside WebRTC is bad for SIP

WebRTC Hamster Car

For those who don’t know, SDP is an old school standards-based text format (pre-1998) for describing media, codecs, state and networking information offered by devices for use in real-time communications and more recently as the proposed format for with WebRTC. I’ve written in the past about my disdain for SDP. To me, using SDP inside the browser for WebRTC seems akin to requiring all new computers use the graphics processing unit from the Commodore 64 for all future graphics engines. As cool as it might have been in its day, it is not exactly up to the task anymore and should be left to the realm of nostalgia.

It seems the idea for using SDP from within WebRTC was to allow SIP vendors to take SDP from their devices and shove it into the browsers and immediately be able to communicate between browsers and SIP devices and to offer the JavaScript guys a simple API to program against. Sounds great, right?  Wrong.  The browser’s SDP and the SIP device SDP is already diverging in their compatibility. Be it Trickle ICE, CODECS, security, or newly proposed “features”, realistically few SIP devices are going to be compatible out of the box or remain compatible for long using SDP. Likewise, providing a simple API for JavaScript developers could have been accomplished by providing a JavaScript library, similar to the way jQuery works to abstract and simplify DOM manipulation (and many other things). In other words, the primary reasons for using SDP in the browser are negated.

My original thinking was that the SIP guys would really love SDP in the browser since SDP is the primary media description format they use. But I must recast my opinion to say it’s really bad for the SIP folks as well. Here’s why…

  • An increasing need for Session Border Controllers: As it stands, the SDP that comes from SIP devices will need to be re-written and perhaps even put through some kind of Session Border Controller (SBC)/Proxy to maintain compatibility. SIP devices could face update cycles tied to browser updates. There are some companies in the industry who sell proxies that would greatly benefit from compatibility issues (as their role is to fix them) but I would hate to think that the IETF/W3C has been usurped by those vendors to push a solution that is not to benefit the entire internet industry and end users.
    .
  • SIP feature-creep: One thing I do know about SIP vendors is they love to add their own extensions to SIP to add their favourite competitive features they offer with their devices/networks. This allows them to claim “support” for something their competition does not support. To that end, I’ve noticed a continuous stream of feature requests to the browser vendors from the SIP world (and I’m certain the alignment to a SIP vendor’s own preferred feature is pure coincidence).

All the demands being put onto the browser vendors to add feature after feature truly scares me. As I foresaw, the innovation of features is tied to the release cycle of each browser binary being built, upgraded and rolled out to end users on each platform. Instead of features being added by by the programming language available inside the browser (JavaScript) which is dynamically updatable, features are now going to have to crammed into the browser binary because of modifications required to the SDP. What could have been simple change in JavaScript on a webpage is now tied by the innovation curve of the IETF/W3C tracks and each browser implementing these features equally across all platforms (and let’s not forget to including mobile in that list).

The irony is that if the SIP vendors had insisted that the browsers only offer a good core media/RTC engine, they could have implemented many of the features they now demand from the browsers vendors themselves without waiting for Google, Mozilla, Opera, Microsoft and Apple and the rest of the industry to agree. Talk about a SIP vendor’s dream in being able to offer some unique feature for their network! But now they have to wait and wait and hope and whatever ends up being released in the browsers will work for them and not introduce even more problems and incompatibilities to their networks.

Browser vendors will become the choke-point.

Worse, browsers vendors will be reluctant and cautious to change SDP for fear of “breaking things” within existing networks if the SDP / WebRTC becomes used broadly. If SIP vendors could understand that writing SDP in the JavaScript layer was in their own best interest, they would get behind the idea of dropping SDP entirely from the browser layer and instead agree to generate their network compatible SDP from within the JavaScript layer exclusively.

Microsoft argued so strongly against SDP and offer/answer, they have not agreed to support WebRTC and instead produced a competing specification called CU-RTCWeb. Their proposal starts from the premise of having a good media engine/RTC controllable at a lower layer would be far better for the industry and they have (so far) not released their Internet Explorer browser with WebRTC support. Whatever your feelings about Microsoft or their particulars of their proposal, they are right about SDP offer/answer and without their market share being onboard, it will hurt WebRTC’s adoption rate, especially in the Enterprise. Apple is sitting on the sidelines giving no indication their position while the industry sorts this out. I’d love nothing more for the industry than to have all vendors on the same page and agree to implement “something” usable, but it seems the SDP offer/answer model is not helping and in fact hindering that effort.

Where do we go from here?

As much as I hate to say it, I think we need to hold off on releasing WebRTC as it is until we have a lower level API. SDP offer/answer is not going to cut it for the initial release, this first version of the standard needs to live on for at least a few years. We must deprecate the current WebRTC API in favour of a more suitable low-level replacement API. The revision should focus instead on the extensions that can be added in the JavaScript layer and only put the necessary hooks in the browser at the most basic level for a media and RTC engine to be controlled. Let’s not hamper innovation!

If we need compatibility with the current WebRTC API it would be easy to create a JavaScript shim that supports the current API and allows a more long innovative approach. If there is interest in creating such a shim, I would be more than happy to be part of that development effort.

Cross-posted to IETF RTCWEB Mail list

Written by Robin Raymond
Edited by: Erik Lagerway

Google’s open WebRTC media stack ported to QNX / Blackberry 10

WebRTC on QNX

The WebRTC media stack has been ported to QNX / Blackberry 10 as reported hy Hookflash in this Press Release below.

This does not mean that WebRTC browsers will now begin communicating with Blackberry apps written using the Open Peer SDK, well… not today anyhow.  What it does mean is Blackberry 10 developers can write apps using this new SDK to enable P2P voice, video and messaging, across Blackberry and iOS platforms using their own user identity model or mashed up with social identities.

In the sample app (pictured above) running on a production Z10 and a Alpha Z10 device, Facebook was used to map IDs.

Here is the Press Release…

BlackBerry Live 2013, Orlando Florida – May 13, 2013 – Hookflash announces beta availability of Open Peer Software Development Kit (SDK) for BlackBerry® 10, providing developers with an effective way to integrate high quality, secure, real-time, voice, video and messaging into their own BlackBerry 10 applications.

“The Open Peer SDK for BlackBerry 10 enables a completely new generation of communications integration on the BlackBerry 10 platform,” explains Hookflash co-founder Erik Lagerway. “The Hookflash team has worked tirelessly to build this toolkit and port the WebRTC libraries to BlackBerry 10. BlackBerry developers and enterprise customers can now integrate high quality, real-time, peer-to-peer (P2P), voice, video and messaging into their own BlackBerry 10 applications. People just want good quality voice, video and text communications embedded in whatever they’re doing. Open Peer enables progressive developers in medical, finance, gaming, travel and many other verticals with this next evolution of integrated P2P communications on BlackBerry 10 smartphones.”

“BlackBerry is committed to our app partners through an open ecosystem, strong platform and commitment to supporting innovation and invention,” said Martyn Mallick, VP of Global Alliances and Business Development at BlackBerry. “We are pleased to have Hookflash bring Open Peer to BlackBerry 10, enabling developers to add rich peer-to-peer communications in their apps, and enhance the customer experience.”

The Open Peer SDK for BlackBerry 10 is the most recent addition to the Open Peer, open source family of real-time P2P communications toolkits. The BlackBerry 10 SDK joins the existing C++ and iOS SDKs already available. Mobile developers creating applications across multiple platforms can now leverage the suite of Open Peer toolkits to deliver real-time P2P communications for all of their applications. The Open Peer SDKs are available in open source and can be found on Github (http://github.com/openpeer/).

Hookflash is a globally distributed software development team building “Open Peer”, new “open” video, voice and messaging specification and software for mobile platforms and web browsers. Open Peer enables important new evolution of communications; Open, for developers and customers to create with. “Over-the-top” via the Internet, where users control their economics and quality of service. “Federated Identity” so users can find and connect without limitations of service provider’s walled gardens and operating systems and “Integrated”, communications as a native function in software and applications. Hookflash founders, lead developers and Advisors previous accomplishments include; creators of the world’s most popular softphones, built audio technology acquired and used in Skype, created technology acquired and open sourced by Google to create WebRTC, and engaged inWebRTC standards development in the IETF and W3C.

Developers can register at (http://hookflash.com/signup) to start using the Open Peer SDK today.

For more information and an Open Peer/WebRTC white paper on please visit Hookflash http://hookflash.com

Press Contact:
Trent Johnsen
Hookflash
Press@hookflash.com
855-HOOKFLASH (466-5352) ext 1

Hookflash enables real-time social, mobile, and WebRTC communications with “Open Peer” for integration of voice, video,  messaging and federated identity into world leading software, enterprise, applications, networks, mobile and computing devices. Hookflash and Open Peer are trademarks of Hookflash Inc. BlackBerry and related trademarks, names and logos are the property of Research In Motion Limited. BlackBerry is not responsible for any third-party products or services. Skype is a trademark of Microsoft. Google is a trademark of Google. Other company and product names may be trademarks of their respective owners.

(full disclosure, I work for Hookflash)

New CU-RTC-Web Prototype – Roaming

CU-RTC-Web - Roaming

 

The crew at Microsoft is forging ahead with their “CU-RTC-Web” specification as a counter proposal to the new WebRTC / RTCWEB  proposed standard in the W3C and IETF. My colleague Robin Raymond and I certainly align with Microsoft on some issues, more specifically around SDP but it would have been good if this work took place inside the IETF.

I really can’t see Microsoft changing their tune anytime soon, which means that Enterprise web application developers will likely need to support both WebRTC and CU-RTC-Web if they are to be a plugin-less solution enabling RTC across all browsers. Not ideal.

WebRTC is live. Flash, take cover!

Update 2: To the hundreds/thousands of repetitive spam tweets / twits, “Will WebRTC replace / kill Skype”, the answer is NO!! It will not. WebRTC is using broken Jingle in the browser, it does not support chat and can only make and receive calls., there is no buddy / contact list to speak of etc etc. NO it will not replace Skype. Stop with the spam tweets already, please!

Update: It seems to me that until all the browsers are on board, native clients will be required to make this go. Which is not outside the realm of possibility, considering Google has open sourced the GIPS audio and video engine along with WebRTC.

Something to remember, WebRTC is not RTCWEB! It may sound silly but it’s true. WebRTC is a Google-centric project using Google code etc.  RTCWEB is essentially an IETF effort, a working group driving towards open real-time communications on the web. They are not the same, which can be rather confusing.

— Original Post —

Google has been busy it would seem, last night WebRTC appeared to the public for the first time. This has some pretty serious implications for Flash, which was the de-facto technology one had to use to get real-time communications in a browser, that has now been circumvented, at least to a certain degree.

The sessions are not run by a signaling protocol per se, not Jingle, no XMPP, not SIP not anything we have seen before. All the session management looks to be coming from libjingle. Which, to me means Jingle is in the browser.

A few early comments:

1. Where does Google stand on websockets? Google have said they will block it if an exploit emerges.

2. Chrome, Opera & Firefox are the supported browsers. Where does Safari and IE land? My guess is that Microsoft will not be in any hurry to implement this considering their recent Skype acquisition.

3. Web-cam captures from HTM5 has not been ratified, although this is likely not as serious as the former points.

Skype's email to me re: Skype for Asterisk

I just received this email from Skype’s PR firm…

Hi Erik,

Here is Skype’s official comment regarding Skype for Asterisk.  You can attribute this to Jennifer Caukin, spokeswoman for Skype.

“Skype made the decision to retire Skype for Asterisk several months ago, as we have prioritized our focus around implementing the IETF SIP standard in our Skype Connect solution. SIP enjoys the broadest support of any of the available signaling alternatives by business communications equipment vendors, including Digium.  By supporting SIP in favor of alternatives, we maximize our resources and continue to reinforce our commitment to delivering Skype on key platforms where we can meet the broadest customer demand.”

Thank you,
Cassie

Call me crazy but if I have to pay to integrate Skype into my phone system, where I already have a phone service that I am happy with, why would I do that? Maybe I just want to be able to make/receive Skype calls on my SIP-enabled desk phone? If it doesn’t hit the PSTN why do I have to pay? Seems like an odd approach for a company that has a long history of working around POTS, much to the delight of their users.

Integration with SIP is great, don’t get me wrong, but it would be nice if Skype talked SIP and was ‘still’ free. Seems like a massive oversight on behalf of Skype or am I missing something?

%d bloggers like this: