Archive | sip RSS for this section

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!

WebRTC, SIP and Open Standards

Patience, not something we are good at.

Some of the SIP proponents out there are not very happy about a recent JavaScript Object Rationale Draft that was published on the IETF RTCWEB mail list ahead of the WebRTC Expo in Atlanta.  Full disclosure, I am one of the authors of that draft.

So, what’s all the hub-bub? Some of the reasoning seems to be..

  1. SIP and XMPP are the standards, everything else should take a backseat.
  2. The current WebRTC model should be the priority, stop asking for changes, you are just getting in the way of progress.

I understand the reasoning, I used to be one of those SIP advocates and I still believe that SIP has its place. To say that SIP and XMPP should rule all is just a bit much.

The one thing I am rather sure of is that SIP will not be the signalling protocol that ultimately ends up powering web communications.  It’s just not practical.  This doesn’t mean that SIP won’t be part of WebRTC, it just means that eventually we will move towards a more web-centric model.

To be clear, we are not against SDP in WebRTC.   In fact, we believe that any API proposal should have both a lower-level Object model and also provide real support for SDP at a higher level.

To that end, we have created a new Object-RTC draft proposal that outlines this model in detail, which also supports SDP Offer / Answer.  Yes, you can have have your cake and eat it too. This draft is about JavaScript, SDP (not baked into the browser) and the Open Web.

The question is, “When is the best time to submit the Object RTC proposal to the IETF and accompanying API docs to the W3C?”

We are not hell-bent on derailing the current progress being made in the respective working groups (contrary to what others may think).  So potentially, you may not see the Object RTC draft in the wild before the conclusion of the next IETF meeting in Berlin, only a few short weeks away.

Here’s to making marked progress on v1 in Berlin so we can get on with 2.0.

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

SDP the WebRTC Boat Anchor

I originally created the last blog post on why I have a really strongly dislike for SDP in WebRTC / RTCWEB. I was asked by Justin Uberti to repost my sentiments to the RTCWEB IETF mailing list. This is that summary, which I will be posting to the mailing list, apologizes in advance for the length.

I’ll try to compile my various points as to why I think we need a lower level RTCWEB API that does not include SDP.

My issues with SDP can be summarized as:

  1. unneeded – much too high level an API
  2. arcane format – legacy and problematic
  3. offer/answer
  4. incompatibilities
  5. lack of API contact
  6. doesn’t truly solve goal of compatibility to legacy systems

Some will argue we need a higher level exchange “blob” like structured data (like SDP) to get two browsers talking to each other and that it makes it simple and it’s advantageous. I think they are horribly mistaken on this front.

SDP isn’t just an opaque blob; it’s offer/answer but I’ll get to offer/answer problems later.

To address a first point: do we need such an exchange SDP “blob” format in the first place? All media can be done without SDP given an intelligent stream API. No opaque blob is necessary at all. An API already exists to create these streams (albeit somewhat lacking if we remove the SDP ‘blob’). This API helps “simplify” creating this blob for later exchange. But the blob is truly not needed. Each side could in fact create the desired streams, pass in the appropriate media information such as codecs and ICE candidates and chose the socket pair to multiplex upon. Yes, it’s a bit more low level but it certainly can be done (and cleanly).

The larger issue, should it be lower level? Yes, in my opinion it should be. Some might say it will be too complicated for “web developers”. Nonsense! Web developers are a smart bunch. Libraries like jQuery, Promises, Node, WebGL, etc are a testament to their capabilities. The argument that it would be too difficult doesn’t wash with me. Obviously, wrappers can and will be created to simplify access for those who want higher level access. Already a half-dozen companies are vying for position as “simplified” access to RTCWEB above what the current “simplified SDP” is doing already.

For us to decide that JavaScript developers are not smart enough is pure crap. It’s just not a valid argument to me. JavaScript is rapidly becoming the de-facto programming language of the open web. JS developers are a smart capable group, do not underestimate them.

The API needs to be at lower level. A lower level API will increase compatibility by setting the barrier to entry lower to what is needed to be RTCWEB compliant. A lower level API will allow for more innovative thinking when building new technologies and combinations of ideas. This will not be the case if we limit ourselves by mandating SDP in WebRTC.

Imagine being able to create streams as desired and mix and match the “pin connections” of the streams however needed via mixers, and then allowing for final rendering. So long two peers agree to communicate (via ICE) and access to sensitive assets like cameras/microphones are granted, why shouldn’t the manipulation of the streams be up to the programmer?

Please don’t box us into a model that is “SDP”. Let us manage the streams, when they are created, where they are sent and how they are mixed. Let’s face it, the web browsers are becoming sandboxed OSes, so grant API toolsets we can actually control at the raw level. Media engines are well-understood things with many reference implementation to use as a starting point for a good JavaScript API.

That’s the API we need. I not only prefer it but I think its vital to the success for WebRTC. There’s no SDP offer/answer needed. There’s no shortage of really smart people out there who would know how to produce a great API proposal. There’s no security threat introduced by managing streams with a solid API.

The SDP format itself is arcane and rooted in old world legacy reasoning. One of the primary goals was to be within a really tiny packet MTU. It’s difficult to extend and the parse rules are all over the map.

To be clear, I’m not suggesting we dump SDP in favour of something else, like JSON blobs or JavaScript structured data with unspecified exchange formats. I’m pointing out the obvious. Of all the formats to choose, SDP is truly obtuse. I have to ask: If it was so wise to not include any signaling at a stack level for RTCWEB, and why is it wise now to include signaling at the media level? That’s what SDP is – a media signaling protocol.

RTCWEB intentionally did not dictate a stack signaling protocol – and thank you! This ensures RTCWEB isn’t tied to SIP, XMPP/Jingle or perhaps Skype on the IE browsers. That allows for untold possible signaling scenarios, from silo websites using simple web sockets to supporting other future protocols (like Open Peer).

But SDP is a signaling protocol, just at the media level. Boo! You are forcing all protocols in the future into an offer/answer model. Despite what some might say, it’s not the only model. For example, Open Peer is stateless between peers. Each side provides its expectations of what it can send and what it expects to receive and a connection is formed based on that information. Further, we do not renegotiate streams, at least not in the SDP sense.

I would agree with Microsoft’s argument that SDP creates a brittle protocol. Changes in the future will force renegotiations as a reaction to what’s going on locally into a need to maintain a paired state to the remote side (including the complexities should both sides simultaneously renegotiate). If you get into multiple party handshakes, it can be hell. We made a conscious decision to be stateless/independent in Open Peer, based on our expertise and history when working with SIP. With SDP offer/answer, I’ll be forced to use this unnatural state machine just to support offer/answer and forever hamper our ability to dynamically change offers until fully accepted in a round trip from the remote party (not to mention the complexities in group conversations). Offer / answer will add untold headaches, but I don’t want to complain just because it’s “harder” for us. It’s not just programming difficulties; it breaks our concept of a good P2P on the wire signaling protocol.

The browser vendors have to create an API anyway – from the “initiator” side to be able to get an SDP blob. But the receiver side gets all sorts of implied logic and behavior when it receives this blob. Whatever untold elements exist in the SDP, it must understand (or reject even though it might be compatible). Some might say “wonderful” as it makes it all free/easy. But like the saying goes, free has a cost. The cost is a loss of control over what behaviours are wanted by the receiving party. The remote browser has to support all features that exist in the SDP, no matter how crazy and who is to say the SDP is going to the browser anyway? You’ll get versioning issues across SDP, all bundled into the offer / answer state machine.

Since I control my own JavaScript, I won’t get wonky unsupported/requested features, right? Not so. Interoperability is ridiculous in SIP today, it will get much worse with SDP in WebRTC.

People will take raw SDP from devices and cram it into other packages that will end up going to/from browsers. What was once a controlled contract from the JavaScript layer will become a mess when we think of compatibility. It will happen because it’s the path of least resistance for the developers inject themselves into various protocols and gain browser compatibility. I dread the support nightmare with Open Peer when people bridge into SIP and we then receive no end of complaints about various incompatibilities between an Open Peer device talking to a SIP device; all because of junk crammed into SDP from these devices which isn’t mutually supported. This stuff might not even be part of our specification, buggy, and not asked for by us from the JavaScript layer. It won’t be our doing but it won’t matter. We’ll get the blame since it works “over there” and have to spend countless hours and devote precious resources to proving the culprit and we’ll either be unable to resolve the issue for the end user or create horrible work around patches. The user will think horribly of our protocol because the compatibility experience will be poor.

Developers will sneak in additional features our protocol doesn’t want or isn’t compatible to support across devices by turning on features locally in SDP for their website, where these new bits get thrown into the SDP bundle and then sent to the remote party unaware any new feature which it won’t support (at least nor properly). That local website might be very happy with their new feature working as it will work “for them” but they’ll break federation to other sites. Some clever piggybacking (inside SDP) features will be hidden from the protocol layer that transport it, which could bring down the services across domains.

What will happen when browser vendors attempt to add features? They’ll add it, but another problem that will emerge. All new features will likely end up be expressed in the SDP somehow. Those things will break services and testing with a limited set of RTCWEB compliant browsers and devices will be insufficient. This will explode compatibility problems well beyond anything the browser vendors could imagine. Basically, it will become very risky to innovate at the browser level.

To those who think that SDP will help remove silos are wrong. SDP will not stop the creation of any new silos between the browsers nor will it remove any that already exist. Both sides need to have the same signaling engine regardless. Forcing media signaling doesn’t suddenly make two ends “more” able to talk. It seems like a stretch to expect that both sides would use the same JavaScript to run the media engines if they already need it for signaling?


With the stream primitives only, I can build whatever state machines that are needed for the particular features I need (from none when I’m just swapping codecs, to more complex when I want to do dynamic re-pinning i/o to untold mixers). Now, throw SDP in there and we have to baseline all that into a common understanding of what it means, disallowing me from doing it because its unsupported in the SDP or force me to have a hybrid where I transport this SDP with all my additional information and have to coordinate my state machine with the browsers offer/answer state machine.

In Open Peer, we setup new streams (on same sockets) and quick-swap behind the scenes if the media must change. This greatly simplifies our model for us. Would I impose our model on anyone else? No. I’m not advocating a stateless SDP model either. Again, I’m saying no media signaling is required at all.

An API only would lower the bar of browsers being able to interoperate at the media level, since they only have to be compatible at the lower stream level. This removes the concerns about SDP compatibility issues (including the untold extensions that will happen to handle more powerful features and all that it implies and complex behaviours associated with SDP offer/answer, including rollback and ‘m=’ stability). Further, steams are easy to make compatible even if individually their API sets aren’t up to par to their counterparts across browsers and devices.

This also solves an issue regarding the data channel. There is no need for the data channel to be tied to an offer/answer exchange in the media at all. They are separate things entirely (as well they should be). For example, in Open Peer’s case the data channel gets formed well in advanced of media to maintain our document subscription/notification model between peers and media channels are open, closed and swapped as required.

With an API only, those who still want to do full on SDP offer/answer can do SDP. They just have to wrap the JavaScript APIs (and there are plenty of companies that will do exactly that). Those who want stateless SDP-like exchanges can do exactly that if they want. Those who want to negotiate something entirely different can do that.

There are those that would argue that the JavaScript APIs build the SDP hidden behind the scenes and the SDP can be treated as an opaque type and thus the appropriate low level API already exists. But they are missing the point. The moment the SDP is required the future is tied to offer/answer and we import all the issues surrounding SDP and its compatibility.

The moment we use SDP we have to address one fundamental issue. Is the SDP blob meant to be transported in full format only to the destination “as is” or is it okay to mess with the SDP by intermediates? This is extremely important. SDP is a not just a format. It is an extendable specification. This mean it will be extended in unknown ways and as such those extensions can affect behavior and add/change or remove functionality.

The protocol we have written won’t use SDP (unless forced by RTCWEB). We’d prefer to transport the information exchange ourselves via a more palatable and future thinking method than what SDP allows (in fact, we do use a JSON format on the wire). This means we’d likely parse and tear apart the information contained inside the SDP and then reassemble a new SDP on the remote side. But that would be a very BAD idea for us to do in practice and likely force us to use the SDP format forever and deliver this SDP blob inside our JSON format “as is”.

The reason why it’s bad to disassemble/reassemble the SDP is because it can be arbitrarily extended at will without knowledge of what is going on internally. New features could be added to the SDP without it being understood. This might sound like a beneficial feature but it’s actually dangerous.

With an API, it’s a contract. You don’t change the contact arbitrarily because it has implications. An API can be extended, but with the current API you know exactly what you get thus you can predict behavior. SDP is not such. It can be changed arbitrarily and there’s no guarantee the two will match. Intermediates can and will mess with the SDP (as demonstrated in the SIP world). If you allow 3rd party people like me to modify it, we’ll lose the additional “features” in the name of transforming SDP into something palatable/compatible. But we really shouldn’t, as it’s way too dangerous; that means SDP will be imposed at the signaling protocol layer on us even though we don’t want it.

If you allow modifications, SDP is a compatibility nightmare. I was the original author of the popular softphone client (X-Lite) and I understand the compatibility issues that happen with SDP/SIP. It was modified many different ways and extended over and over, and in crazy ways. People couldn’t even get basic things like ICE right, let alone all those crazy things they did to SDP across venders. It was a mess. Everyone extending it in every which way imaginable and it created a nightmare of issues; the formats just weren’t compatible.

As a side note, SBC (Session Border Controllers) vendors probably love SDP. That means job security. They would constantly rewrite SDP between end points to ensure ‘compatibility’. This is what RTCWEB has to look forward to if we adopt SDP permanently. Yes, be very afraid.

If browsers use SDP, they inherit this mess and explode it. And compatibility issues won’t be limited to browser SDPs. There is a huge swath of legacy systems that will deliver a mess of SDP to the browsers and SBCs that will manipulate the SDP in untold ways. This will reintroduce the problems with SIP into the world of RTCWEB. The browsers will be locked to those legacy systems and they will drag the browser back like a ball and chain and it will limit the browser’s ability to innovate.

I can’t stress this enough: SDP is not required for compatibility. In fact, it’s a hindrance to it. I think the SIP vendors think if the browsers use SDP they will gain lots more compatibility. They won’t. They are better off writing a JS library that talks the SDP they understand if they want SDP, rather than trying to mix/match browser SDP into the mix. SDP that is likely offered by RTCWEB will not be compatible anyway with many (perhaps most) legacy systems out there. Many of these systems still don’t support the latest ICE specifications and it’s been a long time standard. Imagine RTCWEB being tied down by these systems later and breaking millions of end points during a casual update of the browser.

SDP binds things that don’t need to be bound. We can negotiate all the streams independently. Maybe we want 6 video streams then suddenly want to change that to zero. Why do we need to preserve six dead video media SDP lines? With SDP, we force them all bound to this SDP bundle that has to be negotiated together. It’s wholly unneeded and doesn’t allow flexibility of the streams.

I’m going to take a draft example of what I mean:

Nothing wrong with the draft in an SDP/SIP mindset but I’m going to take it from a totally different non-SDP angle. I have to say, the ideas presented are very good. I appreciate FEC, and synchronizing streams is cool. But SDP isn’t needed to do it. Let me as the programmer worry about how to manage streams and the features on the streams and associations between the streams via an API only.

Point 4, 5 and 6 in the specification all have to do with the complexities of having to describe the intentions of mixing in SDP. So no comment beyond “don’t use SDP”.

As for 7.1 – “this is because the sender choses the SSRC” – only true because we are forced to use SDP and the assumptions is that it’s SIP. We could have the receiver dictate what the sender should use in advance of any media. In our case, we establish in advance what we want from all parties before even “ringing” the other party. We do not have SSRC collisions as we reversed the scenario allowing the receiver to pick the expected SSRC. Coordinating the streams is a problem with SIP because of how they do forking/conferencing but not for Open Peer. We do not fork like they do. We negotiate each location independently and statelessly. This specification forces this issue on Open Peer. If SIP has problems with streams arriving early to their stateful offer/answer then let them worry about “how” they intend to match the streams at a higher SDP layer and get this draft out of the RTCWEB track on the SIP track. To be clear, the proposal seems entirely reasonable and intelligent for SIP/SDP. But it’s way to SIP centric for general purpose.

On that note, I do need in the API is an ability to dictate the SSRC when I create an RTP stream for sending (should I care to do that).

7.2 Multiple render

Again this is an issue of SIP/SDP. We can control the SSRCs to split them out to allow multiplexing easily on the same RTP ports with multiple parties/sources. If given the primitives to control the streams just, this specification could be used to dictate how to negotiate issues in their space.

7.2.1 I’m feeling the pain. How about just giving me an API where I can indicate what streams are FEC associated.

7.3 Give me API to give crypto keys to RTP layer. Let me handle the fingerprint and security myself beyond that.

8. Let’s just say politely that I would not want to be the developer assigned to programming around all this stuff.

Again, a perfect illustration why I don’t want SDP.

Media is complicated for good reason as there are many untold use cases. The entire IETF/W3C discussion around video constraints illustrates some of the complexities and competing desires for just one single media type. If we tie ourselves to SDP we are limiting ourselves big time, and some of the cool future stuff will be horribly hampered by it.

To conclude, can I work around SDP? Sure, just like browsers can patch around IE 6.0. But believe that having a more media stream centric API without the SDP offer/answer will simplify your release and increase compatibility, allow for newer and stronger protocols and more importantly allow many future capabilities that others can’t imagine if you don’t attach the boat anchor that is SDP.

Microsoft feels so strongly against the current RTCWEB path they decided to go the way of counter proposal with CU-RTC Web. I can’t comment on their specification (yet) but I can understand their strong sentiment.

For those who don’t know me, I’m the Chief Architect at Hookflash and author of the new P2P protocol, Open Peer. I used to be the CTO/ Chief Scientist at Xten, now CounterPath, and I’m the original author of the X-Lite/X-PRO/eyeBeam SIP softphone clients. I wish I had given my feedback earlier on this subject. To be honest, following and participating in the standards tracks requires huge time devotion to which I’ve not had enough of and perhaps I thought (naively so) the smart people in the IETF would naturally make the wisest choices, in the best interests of all! As you can tell, I am not at all happy with where we sit today. RTCWEB / WebRTC & SDP… brutal.

NOTE: Will be cross posted to RTCWEB IETF mailing list.

From the Sidelines, My Introduction into RTCWEB

I’ve been following the RTCWEB standardization for a while now from an architecture and technology standpoint. For the most part, I’ve been quiet and I’ve assumed a rather neutral stance in regards to the RTCWEB process when it comes to Open Peer, but my opinion has changed and I can no longer maintain a neutral standpoint.

There are many companies taking stances who all need to have a say in what happens because they want to make sure their technology does not get left out in the cold when RTCWEB comes into reality, as most people think this technology will be huge with consumers and businesses. The big guys with SIP, XMPP and Skype have various established offerings and they are married to existing technology that is difficult to change. They need to make sure that RTCWEB closely follows, or at the very least, does not hinder their own technology from functioning otherwise they will get left behind. The process of adapting existing systems to a new standard is understandably costly.

Thus, I have to ask, who am I with Open Peer to come along and push back against these tides as a new protocol when I have much more flexibility in our implementation than existing deployed systems? Further, the Open Peer protocol particularities didn’t even exist until recently and it has been under revision as Hookflash tested the implementation. We’ve just recently published our specification and source code and we’ve just undergone a significant update based on internal and external feedback from our initial implementations.

To be honest, architecting, designing and implementing a brand new protocol with such an ambitious scale for a small company has kept me extremely engaged and busy. I could listen to what’s happening from a 1,000-foot high perspective, but unfortunately that has also been a factor in my personal ability to participate. I don’t think it’s a great secret for those already involved that it takes immense devotion of time resources to follow the details, let alone participate in these long drawn procedures in ratifying a specification complex as RTCWEB that spans two organizations, namely the IETF and W3C groups. This is unfortunate that such time commitments are so huge as I think having those on the front lines much more actively involved would be healthy, but I digress.

In reality though, Hookflash is in a unique position with Open Peer. I am working on this protocol with a clean slate and a future thinking sense. I do not have the old technology shackles and I didn’t have to design with legacy deployed services in mind which would no doubt confound my decision making process. Likewise, I’ve had the experience of these legacy systems to help avoid their pitfalls (specifically as the original author of the X-Lite/X-Pro SIP softphone client for CounterPath years back with SIP).

For those unaware, Open Peer is an open peer-to-peer signaling protocol that has an initial implementation in C++ and Hookflash is in the process of writing a pure JavaScript version. The idea is to allow secure peer-to-peer signaling communication straight from browser-to-browser and capability to talk to native mobile device applications as well.

The Open Peer implementation goes beyond basic call flow signaling and even beyond peer-to-peer signaling and incorporates identity and federation concepts with strong privacy and security considerations in mind.

Having just completed the next iteration of the protocol that is going through internal testing, I plan to spend much more time actively examining the details of RTCWEB standards. Even though I’m later to the table representing a newer company with newer technology, I hope the input will be welcome to the discussion. I do understand that decisions may be too immovable to change peoples’ minds and there is an active amount of established legacy systems, but hopefully coming from a unique perspective will help bring fresh blood and deeper insight. Forgive me if I argue points already lost, but I will always explain my reasoning for wanting to push certain aspects even if I am ignored in the end.

Ultimately, Open Peer will leverage RTCWEB and the implementation will adapt accordingly to the mutually agreed standards. I’m still going to give my opinion for whatever it is worth and I hope to prove it worthy, unique and valuable.

There are many bright people involved in the process and many companies with unique corporate political angles and agendas. My perspective and motivation will be straight up front. I want RTCWEB to succeed as soon as possible, but with an equal emphasis on ensuring the technology is sound from the future perspective as well, obviously in relation to plans with Open Peer utilizing RTCWEB.

1 year ago, FaceTime will be OPEN

Anyone else remember this? FaceTime was to be OPEN, that was a year ago. Still nothing. FaceTime uses the open standards, but it is not “OPEN”, meaning nobody else can play along.

How long is it going to take before we see Apple living up to their commitments? Hopefully not long, I for one would love to see a FaceTime (and iMessage) API.

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,

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?

Open and secure alternative to Skype

Imagine a new secure P2P (Skype like) offer that also supported SIP in the client. You could use the client software on it’s own (just like Skype) or attach it to just about any VoIP service or phone system for free.

Does it make sense for consumers?
Does it make sense for business users?
Is there room in the market?
Would you use it?

Martyn Davies chimes in…

I would use it, but as a telecom industry insider, I know that I’m not the average business user or consumer. As to whether there is room in the market, I think that depends a lot on what Microsoft do with Skype now that they own it. From a business point-of-view, their efforts are focused around OCS/Lync (and software licenses), so Skype there is not adding to their central proposition. Skype has a lot of users, but produces very little revenue, since the majority just use the free services. As a Skype competitor you would have the same problems getting to the cash.

Skype was really the first company to take VoIP and make it completely trivial to install and use. To do that, they had to take some liberties and deviate from standards (like SIP), so that they could add the magic that made it work from behind firewalls, add security and self-configuration, and integrate video so seamlessly. Like Facebook, once it is clearly the biggest of its kind of services, it becomes the community that everyone must join. I can’t see that another Skype-alike has a way in, unless Microsoft significantly change the rules now.

What do you think?

SIP + RTCWEB marriage in question?

The RTC WEB sessions in Prague made it pretty clear, to me at least, that everyone knows that SIP is broken and we also know that it’s not going away anytime soon. That being said it will likely not be the only protocol to be used in conjunction with RTC WEB.

I think it’s a consensus, at least of the IETF participants of the RTC WEB BOF, that we should not be discussing signaling protocols within RTCWEB at this early stage in the process of creating a WG (working Group) in the IETF.

It’s likely the correct approach. If we pigeon hole the community into using one protocol over another we are not really doing the future of communications any great service. In the same breath I also think it is important that we do not lose sight of the fact that the business world today runs on SIP and will continue to do so for some time to come.

The one thing that stuck out is the obvious gap that exists between what we have today and what we need in order to make RTCWEB a huge success, although I do know of a few companies that can move rather quickly when presented with a challenge as well so maybe it’s not such a big deal.

Prague was great, on many levels. It will be very interesting to see the progress we make between now and Quebec.

%d bloggers like this: