Brief

All posts tagged Brief

Taking apart WebRTC camera resolution constraints part II. Photo courtesy of Flikr user Chia Wei Ong

Note: See February 2016 update here.

{“editor”, “chad“}

Last October I did a post on some quirks I found when applying camera resolutions constraints with getUserMedia. Surprisingly I found the resolutions that were returned were sometimes different than what you ask for, even if you make your constraints mandatory. Firefox didn’t support programmable video resolution constraints at all.

That was a while ago, so earlier this summer I checked my getUserMedia camera resolution finder again. This time Chrome 36 passed all my tests:

Ask Chrome 30 Chrome 36
1280×720 pass: 1280×720 pass: 1280×720
960×720 pass: 960×720 pass: 960×720
640×480 pass: 640×480 pass: 640×480
640×360 fail: 320×180 pass: 640×360
320×240 pass: 320×240 pass: 320×240
320×180 fail: 160×88 pass: 320×180

Constraint handling has clearly changed, but how? I could not find any coherent documentation on this, so I decided to update my resolution scanning code and re-run my analysis to empirically determine how mandatory constraints are handled.  If you choose to read-on below, you’ll see much has been fixed, but there are still a few nagging issues. ...

Continue Reading

We probably talk about existing telephony stuff too much here, but the reality is there are billions of phone about there that want to be connected to the web like nearly everything else. This is especially important for any business that wants to link its website with its internal phone system.

If you are a modern enterprise or contact center, odds are you connect your phone system to the PSTN using a SIP trunk. This approach is light years ahead of previous technologies, but what about allowing callers to come in from the web with WebRTC? Often this means buying your own gateway or connecting your website to a hosted API provider. Is there something like a WebRTC trunk? ...

Continue Reading

photo credit Flicr user mattallen89 (CC license)

photo by Flickr user mattallen89 (CC BY)

WebRTC promises to greatly simplify the development of multimedia realtime communications, without the need to install an application or browser plug-in. It enables this by exposing a media engine and the network stack through a set of specialised APIs. Application developers can use these APIs to easily add realtime communication to web applications. The defined use cases that have been identified in the early stages of the standardisation have a wide range of applicability. Many of the initial applications focus on communications between applications running on web browsers, but it is expected that WebRTC will also allow for interoperability with several existing communications protocols. For that and other reasons, the signalling interfaces have been determined to be out of scope, thus allowing the service providers to choose the best suited protocol or signalling mechanism for their users. ...

Continue Reading

bouquet

WebRTC JavaScript Libraries

Looking over the past few years of WebRTC growth, and the landscape of emerging WebRTC solutions, we see quite a number of  WebRTC-centric JavaScript (JS) libraries on the scene. Indeed, not long after browser vendors began shipping WebRTC implementations, a bouquet of WebRTC signaling libraries bloomed.

Each delivers a JavaScript API surface in the browser, which provides signaling services that complement the WebRTC media services. This abundance of options begs a few questions:

  • What is the real purpose of the JS library?
  • Do I need one for WebRTC?
  • What should I consider when evaluating this component of a WebRTC solution?
  • What makes a good JS library, what makes bad one?

These are the nagging questions that I wrestled in my own early research into WebRTC. At this point, I have certainly not personally used every WebRTC JS library out there, but have certainly tried quite a few. In this post I’ll attempt to address these questions, and my own thoughts on what is in a WebRTC JS library. ...

Continue Reading

The first post we published on webrtcHacks was ‘A Hitchhiker’s Guide to WebRTC standardization’ (July 2013) where we gave some initial insight on activities in the 3GPP around WebRTC and  IMS. Since then the situation has certainly evolved (well, probably not as fast as some would have expected). Since we regularly receive emails asking about the status/progress on WebRTC standardization within the 3GPP, we spent some time with our friend Antón Román, CTO at Quobis and author of the popular post ‘Anatomy of a WebRTC SDP’ to summarize the current status of the ‘WebRTC access to IMS’ effort. ...

Continue Reading

As I mentioned in my ‘WebRTC meets telecom’ article a couple of weeks ago, at Quobis we’re currently involved in 30+ WebRTC field trials/POCs which involve in one way or another a telco network. In most cases service providers are trying to provide WebRTC-based access to their existing/legacy infrastructure and services (fortunately, in some cases it’s not limited to do only that). To achieve all this, one of the pieces they need to deploy is a WebRTC Gateway. But, what is a WebRTC Gateway anyway? A year ago I had the chance to provide a first answer during the Kamailio World Conference 2013 (see my presentation WebRTC and VoIP: bridging the gap) but, since Lorenzo Miniero has recently released an open source, modular and general purpose WebRTC gateway called Janus, I thought it would be great to get him to share his experience here. ...

Continue Reading

Gustavo Garcia Bernardo

Gustavo Garcia Bernardo

WebRTC and its peer-to-peer capabilities are great for one-to-one communications. However, when I discuss with customers use cases and services that go beyond one-to-one, namely one-to-many or many-to-many, the question arises: “OK, but what architecture shall I use for this?”. Some service providers want to reuse the multicast support they have in their networks (we are having fun doing some experiments with this), some are exploring simulcast-based solutions, others are considering centralised solutions like MCUs/mixers, and a bunch of them are simply willing to place the burden on the endpoint by using some variation of a mesh-based topology.   The folks at TokBox (a Telefónica Digital company) have great experience with multiparty conferencing solutions.  I thought it would be great to have my friend Gustavo Garcia Bernardo (Cloud Architect at TokBox) to share here his take on the topic.

At TokBox, Gustavo is responsible for architecture, design, and development of cloud components. This includes Mantis, the cloud-scaling infrastructure for the OpenTok, which uses the WebRTC platform. Before joining TokBox, Gustavo spent more than 10 years building VoIP products at Telefónica and driving early adoption of WebRTC in telco products. In fact, I’ve known Gustavo for 8 years now and the first time I met him it was preparing a proposal for a European Commission-funded research project on P2PSIP. Since then we’ve been collaborating in the IETF doing some work in the context of P2PSIP, ALTO and SIP related activities. A couple of years ago, while I was working with Acme Packet (now Oracle), we worked together designing and launching Telefonica’s Digital TuMe and TuGo.  Lately we have both shifted our focus towards WebRTC. ...

Continue Reading

As detailed in previous posts on webrtcHacks, the Internet Engineering Task Force (IETF) has worked for the past few years to standardize the “on-the-wire” protocols that make up the WebRTC engine. It is coming up on 3 months since IETF 88 in Vancouver, where the IETF was to have settled the matter of a mandatory-to-implement (MTI) video codec. The process resulted in no consensus, and the task of finalizing WebRTC 1.0 drags on with MTI video codec(s) in question.  A recent straw poll among IETF participants shows how divided the issue remains. ...

Continue Reading

As WebRTC implementations and field trials evolve, field experience is telling us there are still a number of open issues to make this technology deployable in the real world and the fact that we would probably do some things differently if we started all over again. As an example, see the recent W3C discussion What is missing for building (WebRTC) real services or Quobis‘ CTO post on WebRTC use of SDP.

Tim Panton, contextual communications consultant at Westhawk Ltd,  has gone through some of these issues. During the last couple of years we had the chance to run some workshops together and have some good discussions in the IETF and W3C context. Tim’s expertise is very valuable and I thought it would be a good idea to have him here to share some of his experiences with our readers. It ended up as a rant. ...

Continue Reading

For the last year and a half I’ve been working with a number of customers helping them to understand what WebRTC is about, supporting them in the definition of new products, services, and in some cases even developing WebRTC prototypes/labs for them. I’ve spent time with Service Providers, Enterprise and OTT customers and the very first time I demoed WebRTC to them, after the initial ‘wow moment’ almost all of them complained about the ‘call setup delay’, as in some cases represented tens of seconds. ...

Continue Reading