Posts Tagged voip

WebRTC Interoperability

I’ve spent many years of my career working on interoperability in communication systems.  Back in the dark ages, I did SS7 interoperability testing.  During my CLEC days, I ran a test lab that tested optical, telephony, and ATM/Frame Relay equipment.  I’ve spent many years working on interoperability issues with SIP, starting with the SIP call flows (RFC 3665 and RFC 3666) and then SDP Offer answer (RFC 4317).  I’ve also been to many SIPits (SIP interoperability events run by the SIP Forum), testing voice and video interoperability.

WebRTC poses some interesting interoperability challenges, but I am hopeful we will get it right.

There are four different areas of interoperability: browser, protocol, codec, and offer/answer. Lets go through them one by one.

Browser interoperability is about aWebRTC application or site working the same regardless of which browser the user is using.  In the past browser interoperability was just a browser/server issue, but with the peer-to-peer media and data channel flows of WebRTC, this is now a browser/browser issue.  The good news is that there are only a handful of browsers, so the interop  matrix is not too large.  The bad news is that there are signs of discord already in pre-standards implementations.  For one thing, all browsers must utilize the same APIs, or else WebRTC will be a major headache for developers.  Of course, libraries can hide this complexity from developers, but this will slow down deployment and produces some needlessly bad user experiences.  If we see one browser vendor using their own APIs instead of using the standard ones from the W3C, then we will know that someone is playing company games at the expense of the Internet users of the world.  Hopefully this won’t happen, but it if does, users will and developers will likely move away from that browser.

Protocol interoperability is a major concern for WebRTC.  In the past, browsers didn’t implement many protocols – everything used HTTP (Hyper-Text Transport Protocol).  Today, browsers are doing more, including WebSockets, and will soon move to the next version of HTTP, 2.0.  With WebRTC, the browser RTC Function has to implement multiple protocols including RTP, ICE, STUN, TURN, SCTP etc.  These protocols define “bits on the wire” and “state machines” that ensure that interoperability works.  For browser-to-browser media and data channels to work, browsers must implement these protocols and carefully follow the standards.  If they don’t the whole industry will suffer.  There are some issues today with the pre-standard WebRTC browser implementations.  For example, one browser today implements a proprietary STUN client that will not work with standard STUN servers.   Browser vendors will need to take protocol interoperability very seriously, and recognize that this is something new for them and that they need to follow industry best practices and approaches.

Codec interoperability is about ensuring that media sessions don’t fail because there is no common codec supported on both ends of the session.  There are so many codecs in use, and every vendor and service provider seems to have their own favorite one.  Fortunately, we should be able to avoid this for audio codecs.  The IETF has recently finalized the Opus audio codec for speech and music, published as RFC 6717 this month.  It really is a fantastic codec, much better than all the rest, making it an easy choice as one mandatory to implement (MTI) codec for WebRTC. Opus is also available as open source.   The other MTI codec is G.711, also known as PCM, which provides interoperability in the VoIP and telephony world, and is also needed for interworking with the telephone network.  Video codec choice is much more difficult.  While H.264 is widely used today, there are no open source implementations or royalty-free licensing available for browsers or implementors.  As such, it is very difficult to see how it could be chosen as a MTI video codec.  Google’s VP8 video codec is proposed as an alternative, and is available in open source.  However, there is much uncertainty about the licensing status of VP8.  Should WebRTC deploy without common video codecs, this again could result in interoperability delays.

Offer/answer interoperability is perhaps the least understood, but most important area.  Offer/answer refers to the negotiation of codecs, parameters, and settings for the media session or data channel between the two browsers.  Even if both browsers use common APIs, standard protocols, and common codecs, if they are unable to successfully negotiate and configure their media or data channel, the connection will fail.  WebRTC uses Session Description Protocol (SDP) to do this offer/answer exchange.  The pre-standard WebRTC implementations are, frankly, a mess in this area.  Their SDP is not standard, and not interoperable with anything else. It will take a lot of work to get this right, and we all must insist that browser vendors support standard offer/answer negotiations.

Occasionally, it is suggested that perhaps offer/answer would be easier if we didn’t use SDP.  We all know and hate SDP, and it is ugly and awkward to use.  However, it has taken over a decade’s work and experience to make it work, and any replacement would likely take that many years to get to work.  And, in addition, since much of the standards-based VoIP and video world uses SDP, it would need to map to SDP as well.  I can’t see this helping interoperability in any way.  Previous efforts to replace SDP failed (anyone remember SDPng?) and I think anyone advocating replacing SDP needs to explain why a new effort wouldn’t meet a similar end, and why this effort wouldn’t take a decade.  Also, the complexities of offer/answer relate to the complexities of negotiating an end-to-end session, and the actual syntax of the descriptions are a very small part of the complexity.

So WebRTC definitely has some interoperability challenges ahead of it.  Fortunately, there are

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web Book Cover

WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web

many experienced engineers who are participating and helping with the effort.  As long as the browser vendors take this seriously and don’t play games, I think WebRTC will have good interoperability, which will benefit web developers and web users alike.

If you are interested in WebRTC, you might like my new book “WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web” published this month by Digital Codex LLC.

, , , , ,

2 Comments

The State of SIP

Today, Eric Krapf’s NoJitter published an interview with me “Where Do We Stand With SIP? An Interview with Avaya’s Dr. Alan Johnston”.

I talk about the state of Session Initiation Protocol interoperability, and about some of the recent activities of the SIP Forum to improve things.

One activity is SIPNOC, the SIP Network Operators Conference.  The second SIPNOC will be held this June in Herndon, Virginia.  The Call for Presentations just went out.  Last year’s event was excellent, and I’m really looking forward to this year’s.

The other is the SIPconnectIT interop testing events, planned for later this year.  They will be modeled after the incredibly successful SIPit SIP interoperability test events, but with a focus on SIP trunking and the SIP Forum’s SIPconnect 1.1 Recommendation.

Perhaps see some of you at these events!

, , , , , , , ,

Leave a comment

Explaining Security

I spent all last week in Austin, Texas at the Internet Telephony Expo, ITEXPO conference.  In addition to giving the SIP and RTCWEB Tutorial and having a board meeting of the SIP Forum, I moderated a security panel at the 4th Generation Wireless Evolution 4GWE conference.  It was a great panel, with Patricia Steadman, CEO of Telesecret,a company founded by Phil Zimmermann to commercialize the ZRTP media security protocol, and a good friend and former colleague from Avaya, Andy Zmolek from LG Electronics.

As I enjoyed the cool and damp weather back in St. Louis (the opposite end of the weather spectrum from last week!), I was elated to discover that my novel “Counting from Zero” was ranked #12 on Amazon’s Computer Network Security sales list! (Of course, this ranking changes minute-by-minute, so it might very well be ranked a bit lower when you read this.)  I mark this as yet another milestone with this book, my first attempt at fiction.  To have it doing so well in a ranking filled with security text books is very exciting!

I was also thrilled to see two other books I greatly admire ranked just above me at #7 and #9:  The Art of Deception: Controlling the Human Element of Security and The Art of Intrusion: The Real Stories Behind the Exploits of Hackers, Intruders and Deceivers by Kevin Mitnick and William Simon:  I use both these books as references in my book.  I was thinking of Kevin all last week during my travels as I finished reading his newly released memoir Ghost in the Wires: My Adventures as the World’s Most Wanted Hacker.  It was an amazing read, and I highly recommend it.  Maybe I’ll post a full review here one day soon.

My original goal with “Counting from Zero” was to teach the fundamentals of computer and Internet security, but to do it in a non-traditional way.  I had written one other book on security, “Understanding Voice over IP Security”.  Its sales have not been great, compared to some of my other SIP and VoIP books.  One reason is perhaps that security books tend to be dry, and a little theoretical, not well-connected with real life.  In “Counting from Zero” I tried to invent a plot that would not only teach security, but help motivate it.  I set out to create a character, Mick O’Malley, who would initially seem over-the-top in his security, but have the subsequent action and events make him seem more normal, and the rest of us who barely give security a thought the strange ones.

I have greatly enjoyed the reviews of the book, and those complementing my characters, writing, plot, etc.  But I enjoy hearing the most that a reader learned something from the book.

If you have an interest in Internet or computer network security, my book will help explain some basic concepts and help motivate the topic.  If you have ready my book (thank you!) and learned something useful from it (fantastic!), I’d love to hear from you…

, , , , , , , , ,

Leave a comment

ZRTP Published Today as RFC 6189

Today ZRTP was published by the IETF as RFC 6189. This is a big deal to me for a number of reasons. Let me explain.

RFCs or Request For Comments are the publications about how the technical details of how Internet works. They go all the way back to the earliest days of the ARPANET, used to share information among a small group of researchers. RFCs are published by the RFC Editor and cover Internet fundamentals such as TCP, IP, and SMTP. My first RFC was one for Session Initiation Protocol or  SIP which was published as RFC 3261. Since then, I have published 14 others, but I’m most proud of this one.

ZRTP is a security protocol for providing privacy for VoIP calls over the Internet. It was invented by Phil Zimmermann, who invented PGP (Pretty Good Privacy) for email encryption in the 90’s. When I met him in 2005, he had an idea how to encrypt voice calls and some very rough prototype code. I helped him turn it into a protocol, and wrote the outline of the document that was published today.  I’ve been the editor of this document for the past 5 years.

I think ZRTP is the best way to secure voice and video over the Internet. The reasons are a bit technical, but perhaps I’ll attempt explain why in another post. In the meantime, Phil Zimmermann’s Zfone Project web page has some good points in it.

Oh, and there is one other reason why I’m proud of this document – I came up with the name ZRTP. RTP stands for Real-time Transport Protocol. And of course, Z stands for Phil!   It was a joke at first, but it kind of stuck.

ZRTP even makes an appearance in my techno thriller novel, Counting from Zero. The protagonist, Mick O’Malley uses ZRTP to ensure that all his voice and video communication is private, thwarting those who would like to wire tap his communications.

It has been a lot of work getting this RFC published, and I’m quite proud of the work. And over the years, I’ve become good friends with Phil, which is a real bonus.

Today I’m going to have a mini celebration – happy first birthday ZRTP, RFC 6189!

, , , , , ,

6 Comments

Botnets and SIP Phones

I came across this article the other day thanks to my friend Olle, who’s blog “VoIP Forum – Open Source and Open Standards in IP Communications” is often filled with interesting information about my industry.

Avaya SIP Phone

It is entitled “A Distributed Cracker for VoIP” and it is a real life example of how some of my interests are coming together.  The article mentions a botnet (short for a robot network – a collection of ‘zombie’ computers that have been taken over by someone), P2P (peer-to-peer) message routing, and VoIP (Voice over Internet Protocol – putting voice and phone calls over the Internet).  And BTW, “cracker” doesn’t refer to the food, it means a password cracker or breaker.

If you have read or heard about my new techno thriller Counting from Zero, all these topics will be familiar, as they all form part of the plot in the book!  The additional thing this article adds is a mention of SIP or Session Initiation Protocol, which really brings it all together for me!  For a hint why, check out my Author Page at Amazon…

My professional life over the past 13 years or so has revolved around SIP.  SIP is an Internet protocol – a way that computers establish voice, video, or other sessions over the Internet for communication.  It has been widely adopted in Voice over IP (VoIP) and also in video conferencing services.  Most telephone companies today are deploying Internet Protocol (IP) networks and running SIP over it to carry phone calls.  For the past 10 years or so, my home has never been without a “SIP Phone” on my desk.  A SIP Phone looks like a normal telephone, with a handset, a keypad, and a ringer, but instead of plugging into a telephone jack, it has an Ethernet jack and plugs into the Internet!  Wherever on the Internet I plug in the phone, it has my identity and I can place and receive phone calls.

Above is a picture of a SIP phone made by my employer, Avaya, which is used in corporate offices.  Many of you will recognize the Cisco phones that have become the staple telephone prop in television and movies – these phones are all VoIP phones, and many are also SIP phones.

The blog post “A Distributed Cracker for VoIP” is about a botnet with P2P routing that uses zombie computers to discover and attack SIP VoIP phones and systems (known as a PBX or Private Branch Exchange) by trying to guess the passwords.  And the results are sent back to a shadowy command and control center for the botnet.  I’m sure there will be more and more of this in the future.

Interesting how various interests can come together like this – something that happens a lot with the Internet.

, , , , ,

Leave a comment