Archive | api RSS for this section
June 17, 2013  

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

June 1, 2011  

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.

December 3, 2009  

Looking for PHP (or RoR) rock star for dev lead on exciting new (funded) VoIP-centric web app

Looking for a contract PHP (or RoR) rock star for dev lead on exciting new (funded) VoIP-centric web app. I expect it will be no more than 6 weeks work. Email erik@sipthat.com for info.

March 10, 2009  

VoIP Quality of Service (QOS) for small business, where is it?

Is your VoIP quality the pits?

VoIP and SIP Trunking over best efforts Internet can cause SMBs to jump off the VoIP bandwagon rather quickly.  Most small phone systems today do not have any built-in QOS (Quality of Service) monitoring, and those that do are likely not doing anything more than the typical MOS (Mean Opinion Score) based on historical packets.

MOS results are great when we are trying to see what the results were after the problem was detected and can certainly help with understanding some trends, but it does not do much to help SMBs understand why the QOS they are receiving from their current provider is sub par.

The truth of the matter is, the quality of service the ITSP (Internet Telephony Service Provider) is delivering can be high but there are factors that degrade that quality between the SMB’s LAN and the ITSP’s switch(s).

What can be done about it? Depending on your budget and technical acumen, something can be done or nothing can be done.

Most ITSPs who provide SIP Trunks or Hosted VoIP for business will not provide much more than a service status. Either the service status is “Active” or “Inactive”. This is not because they are intentionally holding back, they simply do not have the tools to be able to deliver more information to their users without breaking the bank. VoIP network tools are expensive and are generally not all that easily extensible.

There are some QOS monitoring tools that are fairly cheap and easily accessible. Some are even free!

VoIP Spear (free and paid) is a great little service created by Henry Fernandes at Toepoke Software. VoIP Spear uses ICMP packets (ping packets) to monitor remote connections. We have been using the service for a couple of months now and have made good use of the historical MOS data that the service provides. The only downfall is that uses ICMP. Most routers these days have ICMP echo turned off by default, mostly due to security concerns and potential inaccuracies. That being said it’s a great tool for acquiring remote MOS data and Henry tells me they are working on an API.

But what about ongoing call testing? Some say the only real way to determine QOS is to run periodic call tests that can report on call quality, connectivity issues, bandwidth, latency, delay, jitter etc. Again, tools exist but are expensive and are generally made to run at the top level of the network for network engineers, not SMB owners. Some router/switch vendors like Adtran do have some devices that will deliver on some MOS scoring and alerting but they again are not cheap, generally they start at $1200 (US) for the basics, which puts it out of range for many Canadian SMBs.

This begs the question, “SMBs should not have to concern themselves with QOS, their service should just work, right?”

Yes, it should just work, much like the legacy telephone networks have for the last hundred years. Why should the business owner be forced to accept dropped calls, broken conversations, 1-way audio, and the like, just because it’s VoIP.

The truth is, they won’t switch if they think the lines might drop or the quality might be sub par. Which might explain why so few SMBs have made the jump to VoIP-based systems and service in North America.

What can be done to increase adoption of VoIP for SMBs in Canada? The first remedy is fairly straightforward, ISPs need to increase broadband to small businesses and provide some application prioritization without dramatically increasing price. Considering ISPs want to deliver their own digital voice/VoIP offers, this might be a ways off.

What about better tools, integrated into the PBXs?

One could integrate some of the QOS monitoring/testing bits directly into the phone systems that are sold and by using open standards, provide a secure interface so the Internet Telephony Service Providers would be able to show QOS to their users via their user portals and the like. This would obviously require the pbx vendor to integrate the client piece and the ITSP would presumably host the web components.

This will allow VoIP service providers to show QOS data and provide controls around that for their own customers. Call testing details could be provided in real-time without spending tens of thousands to extend their current toolset to their users in a manner they will understand. This proactive self-support approach would also reduce inbound support for the service provider and would presumably help sell more PBXs for the vendor.

My rant for the week.

May 20, 2008  

Outlook Calendar Gets A Voice

Lypp for Outlook is nearly complete. Here are the highlights:

  • Lypp account optionally created on download/install
  • Integrates with Outlook address book and Exchange global contact store
  • Sync with Outlook contacts and Lypp contacts
  • Create Conference Call and Calendar event at same time.
  • Schedule outbound calls or dial-in Toll Free calls or combination of the two.
  • Edit/modify existing call/meeting.
  • Create recurring Calls/Meeting
  • Right click on contact to create call

Even though I am not so much a Windows guy anymore I have been using the Lypp for Outlook Add-in through Parallels and I have to say, it makes my life soooo much easier. Now I can schedule my calendar events and my calls (even 1 to 1) at the same time, no more swivel chair.

Hmm, now if only someone would mashup the Lypp API with Google Calendar…

May 20, 2008  

37signals + Lypp Mashup Canceled

Due to the fact that there are not nearly enough active applicants to constitute a fair contest we are canceling the 37signals + Lypp mashup contest.

more…

by erik | sipthat.com

January 28, 2008  

Ribbit vs. Lypp

VS  

I have had a few people ask me to describe the differences between Ribbit and the Lypp API. 

——– 

UPDATE: Ike Elliot has some good points about the un-evolution of VoIP 

The one thing I might say to Ike is, "you're right, in more ways than one". VoIP has not really come all that far and sometime it complicates life more than it needs to. I think I can help you in one way though Ike, check back in a week and you will see what I mean.

——– 

UPDATE: Garrett Smith adds some food for thought

Garrett mentions "Lypp appears to be a solution for mobile professionals that aggregates AIM / AOL, Google Talk / Jabber, iChat MSN and Yahoo! Messenger contacts and allows for group or conference calling via your cellular handset. It also does not leverage the IP network, in favor of the wireless network and or PSTN." I can see why Garrett would think that, the current site says nothing about our Next Generation Conference Calling service, VoIP API or Rails plugin. Keep your ear to the Rails Garrett, that is soon to change 🙂

As a developer Garrett had some comments on the APIs. Garrett mentions that he could not really use either API which I found a little disconcerting. Our goal is to make sure that anyone who understands XML or Rails can use this API. The Lypp API is published here: lypp.com/api and can be accessed by simply sending an email to api@lypp.com requesting a key.

——– 

UPDATE: Luca Filigheddu with some thoughts of differentiation

Luca makes a good point here about the importance of differentiation.

——– 

UPDATE: Moshe Maeir makes a great anaolgy. 

Yes, you are correct Moshe. We are bootstrapping this venture and our poultry investment over the pat year is lunch money when compared to what Ribbit has raised but I think I would still prefer to be driving a Chevy 🙂

——– 

UPDATE: Thomas Howe reflects on the differences and makes some good points.

Thomas is a smart guy and I have a great of respect for what he is doing in the voip mashup space and what he has done in the past. His comments on my initial post are well taken. On the last comment, I am not opposed to softphones, not at all. It's just that I have seen softphones deployed in almost every scenario imaginable and the take rate in the business community has been low. Mostly due to technical network issues like double firewalls and zero-tolerance VPNs. All that aside, I am very positive about the future of  softphones and firmly believe you will see one in the Lypp lign-up, when the time is right.

——–

UPDATE: Andy chimes in by ringing the bell. <ugh>

I think Andy might have slightly missinterpreted my intentions when writing this post but hey, a little spice never hurt anyone 😉

——–

First let me begin by saying I know Ted Griggs and I respect him greatly, he has a great track record for building innovative companies that push the boundaries of technology and communications.

I was the initial designer, sales guy, visionary, president, co-founder and COO at Xten (Counterpath) which since inception has dominated the SIP softphone SDK space. In other words, I think I may know a thing or two about building softphones.

Fyi, Ted and I will be presenting on behalf of our respective companies at Wireless Innovations in April.  

With that out of the way, here is why, when I started down this path, I did not choose to reinvent the softphone at the edge of the network.

The edge of the network is a nasty place. Bandwidth issues, carrier packet shaping, lack of end user control and costly redundancy solutions make it nearly impossible to deliver a predictable and reliable telephony service.

Much like turning on the lights when you get to your office, that phone on your desk had better work as expected.

In saying that many professionals use Skype and other softphones, like X-PRO, X-Lite, eyeBeam etc to make calls over the net everyday. But you can bet when it comes time to make the calls that really matter they are not using a softphone on the open Internet, at least not after it suffers major packet loss more than once during a call of significance.

This is also why traditional telephony will be around for decades to come. The PSTN still rules the roost. Setting aside for a moment the unwillingness of the carriers to allow other providers to simply stand up a service that will cannibalize their revenues, reliability and Quality of Service (QoS) is still a major issue.

At Gaboogie we steered away from the softphone or using any VoIP at the edge of the network in our initial plans. We made that decision early on because we believe VoIP at the edge is still not ready for prime time. If you don’t believe you obviously have not tried a best efforts VoIP service in Canada. I have not found a single best efforts offering that does not drops calls, drop packets and well… just generally suck.

So what is Lypp then?

The Lypp API was built to support advanced conferencing and was meant for critical calls for companies that require a dependable service. That does not mean a developer could not use it for more typcial telephony integration, which in fact some are already doing. Using the API directly via XML or by way of the Ruby on Rails plugin developers can add traditinoal telephony and/or conferencing capabilities to their apps in as little as a couple of hours.

We have constructed a very robust network that is redundant and dynamically scalable to handle billions of minutes of call volume per month. Our call back methodology (been around forever) keeps the VoIP in the core of the network. If your landline or cell phone is on, so is our service. Our customers do not suffer from call quality or reliability issues in the same way best effort VoIP service users might.

Developers leveraging the Lypp API can expect a higher degree of call reliability and call quality, more of the time, than any other best efforts VoIP service in North America, period.

Best efforts VoIP, whether you are using a Polycom VoIP handset and an Asterisk PBX or you are using a Ribbit inspired softphone, will likely not match up with the reliability you have come to expect from the legacy telephone networks. However the feature set of POTS (Plain Old Telephone Service) pales in comparison to what VoIP can offer.

Some day we will have the kind of IP infrastructure that will make the edge of the network near bullet proof, but in my humble opinion, we are still a ways off. When we do get there Gaboogie will be ready to leverage its SIP network to the absolute maximum.

October 9, 2007  

Lypp's VoIP API to be showcased at Under the Radar

We're excited to announce that Lypp will be presenting at the Under the Radar Mobility conference, on November 15th at the Microsoft Campus in Mountain View. We'll be showcasing our own application and some innovative things people are doing with Lypp's brand spanking new VoIP API.

 

October 4, 2007  

Not every VoIP API is built the same

What makes one VoIP API different from another?

Having spent a significant amount of my working life immersed in IP Telephony and Voice over IP, I eventually found myself becoming frustrated by the lack of infrastructure at the edge of the network, moreover the issues that surrounded our inability to ensure QOS (Quality of Service) on a VoIP phone call.

Best-efforts VoIP is not quite what it is cracked up to be, creating a decent experience for the residential, SOHO or even Enterprise users has become somewhat of an art form.

In the meantime the mobile world was innovating at a rapid pace, bringing the cellular telephony on par it would seem with the traditional office or home phone in terms of volumes of usage. I am not sure about the rest of you but my mobile phone seems to have become affixed directly to the side of my head, surgery may be required.

For me, the perfect VoIP API would take advantage of all the good things that VoIP brings but not rely on the edge of an IP network to deliver a good experience. At the same time it would also need to take advantage of the growing mobile user base and not be device-specific, meaning proprietary software is not required to be installed on the device.

The answer for me pointed away from IP endpoint software and towards the core of the IP network leveraging existing mobile and legacy wired networks. I think this is what gets me so excited about the Lypp VoIP API. It does not require IP connectivity to any endpoint and certainly does leverage our tendency as humans to move around.

The one thing that really left me scratching my head about the various VoIP SDKs, APIs, and Developer Toolkits out there were how terrible they were written. With the technology we have in front of us now we should be capable of building flexible, very extensible APIs that leverage ActiveResource and REST to provide a Web 2.0 approach to integrating and building VoIP applications and features.

Another pet peeve of mine was the overly difficult manner in which APIs were made to integrate with the VoIP switches. In most cases you needed a degree in IP networking and equal experience in SIP (Session Initiation Protocol) in order to pull that off.

Lypp’s API is bundled with wholesale termination provided by the nation’s largest VoIP network partners including Level 3, XO and Global Crossing, making deployment of said telephony features a snap.

So that’s my rant. I don’t mean for this to sound like a sales pitch but I can’t help it! I really am excited bout this VoIP API and what it means for the growth of IP Communications.

I would love to get your feedback on the Lypp API and the Lypp.com service <- built on the API. Email me or leave a comment. 

%d bloggers like this: