Disruptive Telephony

Video: Great WebRTC Tutorial and Demonstrations by Cullen Jennings

2013-06-18T15:30:53-04:00

Want to understand more about WebRTC and where it is going? Want to see some demos of new WebRTC apps? At the recent INET event in Bangkok, Thailand, Dr. Cullen Jennings, one of the co-chairs of the IETF's RTCWEB Working Group, gave an excellent presentation that walks through the basics of WebRTC and provided some demos as well:

The presentation is about an hour and is followed by a question period. Well worth watching if you want to understand the current state of WebRTC and how it may impact telecommunications today.

Note, you can also view the video directly on YouTube to better see it in a larger size or on a mobile device.

P.S. For more information about WebRTC, see the links off of my WebRTC/RTCWEB page.

If you found this post interesting or useful, please consider either:

Moving Beyond Telephone Numbers - The Need For A Secure, Ubiquitous Application-Layer Identifier

2013-05-29T12:48:33-04:00

Do "smart" parking meters really need phone numbers? Does every "smart meter" installed by electric utilities need a telephone number? Does every new car with a built-in navigation system need a phone number? Does every Amazon Kindle (and similar e-readers) really need its own phone number?

In the absence of an alternative identifier, the answer seems to be a resounding "yes" to all of the above.

At the recent SIPNOC 2013 event, U.S. Federal Communications Commission CTO Henning Schulzrinne gave a presentation (slides available) about "Transitioning the PSTN to IP" where he made a point about the changes around telephone numbers and their uses (starting on slide 14) and specifically spoke about this use of phone numbers for devices (slide 20). While his perspective is obviously oriented to North America and country code +1, the trends he identifies point to a common problem:

What do we use as an application-layer identifier for Internet-connected devices?

In a subsequent conversation, Henning indicated that one of the area codes seeing the largest amount of requests for new phone numbers is one in Detroit - because of the automakers need to provision new cars with navigation systems such as OnStar that need an identifier.

Why Not IPv6 Addresses?

Naturally, doing the work I do promoting IPv6 deployment, my first reaction was of course:

"Can't we just give all those devices IPv6 addresses and be done with it?"

The answer turns out to be a bit more complex. Yes, we can give all those devices IPv6 addresses (and almost certainly will as we are simply running out of IPv4 addresses), but:

1. Vendors Don't Want To Be Locked In To Infrastructure - Say you are a utility and you deploy 1,000 smart meters in homes in a city that all connect back to a central server to provide their information. They can connect over the Internet using mobile 3G/4G networks and in this case they could use an IPv6 address or any other identifier. They don't need to use a telephone number when they squirt their data back to the server. However, the use of IP addresses as identifiers then ties the devices to a specific Internet Service Provider. Should the utility wish to change to a different provider of mobile Internet connectivity, they would now have to reconfigure all their systems with the new IPv6 addresses of the devices. Yes, they could obtain their own block of "Provider Independent (PI)" IPv6 addresses, but now they add the issue of having to have their ISP route their PI address block across that provider's network.

2. Some Areas Don't Have Internet Connectivity - In some places where smart meters are being deployed, or where cars travel, there simply isn't any 3G/4G Internet connectivity and so the devices have to connect back to their servers using traditional "2G" telephone connections. They need a phone number because they literally have to "phone home".

While we might argue that #2 is a transitory condition while Internet access continues to expand, the first issue of separating the device/application identifier from the underlying infrastructure is admittedly a solid concern.

Telephone Numbers Work Well

The challenge for any new identifier is that telephone numbers work rather well. They are:

easily understood - people in general are very comfortable with and used to phone numbers (assuming they have access to phone networks)
ubiquitous - phone numbers are everywhere and are available globally
well defined - they have a fixed format that is well known and standardized
easy to provision - they can be entered and configured very easily, including via keypads, speech recognition and more

For all these reasons, it is understandable that device vendors have chosen phone numbers as identifiers.

The Billing / Provisioning Conundrum

The last bullet above points to a larger issue that will be a challenge for any new identifier. Utilities, telcos and other industries have billing and provisioning systems that in some cases are decades old. They may have been initially written 20 or 30 (or more) years ago and then simply added on to in the subsequent years. These systems work with telephone numbers because that's what they know.

Changing them to use new identifiers may be difficult or in some cases near impossible.

So Why Change?

So if telephone numbers work so well and legacy systems are so tied to those numbers, why consider changing?

Several reasons come to mind:

1. Security - There really is none with telephone numbers. As Henning noted in his presentation and I've written about on the VOIPSA blog in the past, "Caller ID" is easily spoofable. In fact, there are many services you can find through a simple search that will let you easily do this for a small fee. If you operate your own IP-PBX you can easily configure your "Caller ID" to be whatever you want and some VoIP service providers may let you send that Caller ID on through to the recipient.

2. OTT mobile apps moving to desktop (and vice versa) - Many of the "over the top (OTT)" apps that have sprung up in the iOS and Android devices for voice, video or chat communication started out using the mobile devices phone number as an identifier. It's a simple and easy solution as the device has the number already. We're seeing some of those apps, though, such as Viber, now move from the mobile space to the desktop. Does the phone number really make sense there? Similarly, Skype made the jump from desktop to mobile several years ago and used its own "Skype ID" identifier - no need for a phone number there.

3. WebRTC - As I've written before, I see WebRTC as a fundamental disruption to telecommunications on so many different levels. It is incredibly powerful to have browser-based communication via voice, video or chat... in any web browser... on any platform including ultimately mobile devices. But for WebRTC to work, you do need to have some way to identify the person you are calling. "Identity" is a key component here - and right now many of the WebRTC systems being developed are all individual silos of communication (which in many cases may in fact be fine for their specific use case). WebRTC doesn't need phone numbers - but some kind of widely-accepted application-layer identifier could be helpful.

4. Global applications - Similarly, this rise of WebRTC and OTT apps has no connection to geography. I can use any of these apps in any country where I can get Internet connectivity (and yes, am not being blocked by the local government). I can also physically move from country to country either temporarily or permanently. Yet if I do so I can't necessarily take my phone number with me. If I move to the US from the UK, I'll probably want to get a new mobile device - or at least a new SIM card - and will wind up with a new phone number. Now I have to go back into the apps to change the identifier used by the app to be that of my new phone number.

5. Internet of Things / M2M - As noted in the intro to this post, we're connecting more and more devices to the Internet. We've got "connected homes" where every light switch and electrical circuit is getting a sensor and all appliances are wired into centralized systems. Devices are communicating with other devices and applications. We talk about this as the "Internet of Things (IoT)" or "machine-to-machine (M2M)" communication. And yes, these devices all need IP addresses - and realistically will need to have IPv6 addresses. In some cases that may be all that is needed for provisioning and operation. In other cases a higher-level identifier may be needed.

6. Challenges in obtaining phone numbers - We can't, yet, just go obtain telephone numbers from a service like we can for domain names. Obtaining phone numbers is a more involved process that, for instance, may be beyond many WebRTC startups (although they can use services that will get them phone numbers). One of the points Henning made in this SIPNOC presentation was the FCC is actually asking for feedback on this topic. Should they open up phone numbers within the US to be more easily obtainable? But even if this were done within the US, how would it work globally?

7. Changes in user behavior - Add to all of this the fact that most of us have stopped remembering phone numbers and instead simply pull them up from contact / address books. We don't need a phone number any more... we just want to call someone, the underlying identifier is no longer critical.

All of these are reasons why a change to a new application-layer identifier would be helpful.

So What Do We Do?

What about SIP addresses that look like email addresses? What about other OpenID or other URL-based schemes? What about service-specific identifiers? What about using domain names and DNS?

Henning had a chart in his slides that compared these different options ("URL owned" is where you own the domain):

The truth is there is no easy solution.

Telephone numbers are ubiquitous, understood and easy-to-use.

A replacement identifier needs to be all of that... plus secure and portable and able to adapt to new innovations and uses.

Oh... and it has to actually be deployable within our lifetime.

Will there be only one identifier as we have with telephone numbers?

Probably not... but in the absence of one common identifier we'll see what we are already seeing - many different islands of identity for initiating real-time communications calls:

Skype has its own proprietary identity system for calls
Apple has its own proprietary identity system for FaceTime calls
Google has its own proprietary identity system for Hangouts
Facebook has its own proprietary identity system used by some RTC apps
Every WebRTC startup seems to be using its own proprietary identity system.
A smaller community of people who care about open identifiers are actually using SIP addresses and/or Jabber IDs (for XMPP/Jingle).

And in the meantime, Amazon is still assigning phone numbers to each of its Kindles, the utilities are assigning phone numbers to smart meters and automakers are embedding phone numbers in cars.

How can we move beyond telephone numbers as identifiers? Or are we already doing so but into proprietary walled gardens? Or are we stuck with telephone numbers until they just gradually fade away?

RELATED NOTES: Some additional pointers are worth mentioning:

The Internet Society (my employer) has a team focused on the broader subject of online privacy and identity (beyond simply the telephone numbers I mention here) and the links and documents there may be of interest.
There's a new Internet Draft out, draft-peterson-secure-origin-ps, that does an excellent job on the problem statement around "secure origin identification" as it relates to VoIP based on the SIP protocol and why there are security issues with what we think of as "Caller ID".
Chris Kranky recently argued that telcos are missing the opportunity of leveraging telephone numbers as identifiers in the data world.

You can listen to an audio version of this post on SoundCloud:

If you found this post interesting or useful, please consider either:

Further Thoughts on the Google Voice / Google+ Hangouts Integration

2013-05-24T09:09:30-04:00

My post this week about Google Voice ringing into Google+ Hangouts generated a good bit of commentary, not only on the original post but also out on Hacker News, Reddit, Google+ and other areas. Given the range of responses, I thought I'd reply to a couple of points and also expand on some further related topics. So here goes...

"DUH! This is nothing new/disruptive. You could do it forever with GTalk/Gmail!"

A common response was to point out to me that Google Voice had been integrated with GoogleTalk / GMail for quite some time and so this integration was really nothing new.

Okay, fair enough. Point taken.

I'll admit that I never keep GMail open in a web window and so while I do recall that this integration was there in the past, I never personally used it.

Similarly, in Google+, I've taken to logging out of the GoogleTalk/chat sidebar because I found it was sucking up CPU cycles on my Mac. For whatever reason, the new Hangouts sidebar doesn't seem to consume as much CPU cycles and so I've left it running there.

So yes, the integration may have been there in the past and now it is there in Hangouts - and people like me are actually now noticing it. :-)

Ringing G+ Hangouts BEFORE Ringing Other Devices

There were a couple of comments that it seemed like calls to a Google Voice number rang the Google+ Hangouts first and then rang the other devices connected to the GV number. In my own testing there does seem to be about a 3-second delay between when the call starts ringing in Google+ Hangouts and when it starts ringing on my cell phone and Skype. Now, this may be a fact of Google giving priority to their own application - or it may just be an architectural fact that when they fork the call out to the different numbers it is faster to connect to their own service while the calls to my cell and my Skype numbers have to go through various PSTN gateways. Either way, there does seem to be a degree of delay before all devices ring.

Delay In Answering

A couple of people noted that there was a delay from the time you hit "Answer" to when the call was actually established. I've noticed this, too, although not consistently. I think part of it may be with starting up the Hangouts component inside of your browser - particularly with getting the video going, since that seems to be required for the Hangouts component. It may also be just the paths through whatever systems Google is using. It's certainly something to monitor.

Google Voice Call Does Not Ring The Hangouts App on iOS

In my own testing, I found a curious omission. When I call in on my Google Voice number, it does not ring on my Hangouts app running on my iPad. It rings Hangouts on my web browser... but nothing happens in the mobile app. Now, my iPhone rings - but that is because it is also connected to the Google Voice account. I didn't try removing that number from Google Voice and then seeing if the Hangouts app on the iPhone would ring. At least for the iPad, nothing happens. It would be great if this did work so that I could receive the calls on that mobile device.

XMPP...

Multiple people pointed out that my final remark about maybe some day getting SIP support was probably unrealistic given Google "dropping" XMPP support. I was admittedly away on vacation and at a conference last week and so I missed this point in all the announcement about Hangouts coming out of Google I/O. I wrote about this yesterday, though: Did Google REALLY Kill Off All XMPP/Jabber Support In Google+ Hangouts? It Still Seems To Partially Work

Although, as pointed out in a comment on Google+, this "partial" XMPP support may just be a factor of the continued GoogleTalk support - and may fade away when Google finally pulls the plug on that.

This is definitely an area where it would be helpful if Google could provide a few clarifications.

That's all I have right now for a quite update and response to points. Thanks for all the great comments and I do look forward to seeing where Google is going with all of this.

You can also listen to an audio version of this post:

If you found this post interesting or useful, please consider either:

Did Google REALLY Kill Off All XMPP/Jabber Support In Google+ Hangouts? It Still Seems To Partially Work

2013-05-23T13:00:35-04:00

Did Google really kill off all of their support for XMPP (Jabber) in Google+ Hangouts? Or is it still there in a reduced form? Will they be bringing back more support? What is really going on here?

In my excitement yesterday about Google Voice now being integrated with Google+ Hangouts, I missed a huge negative side of the new Hangouts change that is being widely reported: the removal of support for the XMPP (Jabber) protocol and interoperability with third-party clients.

But yet a few moments ago I did have a chat from an external XMPP client (Apple's "Messages" app) with Randy Resnick who received the message in a Google+ Hangout. I opened up a Google+ window in my browser and I could see the exchange happening there as well. Here's a side-by-side shot of the exchange in both clients:

So what is going on here?

Reports Of Google Removing XMPP

This issue has been widely reported in many of the tech blogs and sites. Matt Landis covered this issue very well in his post: Hangouts Won’t Hangout With Other Messaging Vendors: Google’s New Unified Messaging Drops Open XMPP/Jabber Interop which then generated long threads on Reddit and Slashdot.

The Verge in their lengthy story about Google+ Hangoutscontains this statement from Google's Nikhyl Singhal:

Talk, for example, was built to help enterprise users communicate better, Singhal says. "The notion of creating something that’s social and that’s always available wasn’t the same charter as we set out with when we created Talk." With Hangouts, Singhal says Google had to make the difficult decision to drop the very "open" XMPP standard that it helped pioneer.

The "Google Talk for Developers" pagealso very clearly states this:

Note: We announced a new communications product, Hangouts, in May 2013. Hangouts will replace Google Talk and does not support XMPP.

A Google+ post by Nikhyl Singhal has generated a large amount of comments (not solely about XMPP) and a post from Google's Ben Eidelson about how Google Messenger will be changed by Hangouts has also received many comments.

There was also a Hacker News thread about the news out of Google AppEngine that apps hosted there would not be able to communicate users of the new Hangouts app via XMPP - and providing a couple of workarounds.

A couple of Google+ threads from Matt Mastracci and Jan Wildeboer are also worth reading as is this note from Daniel Pentecost about how he has lost interop with his clients / customers.

But Is XMPP Support Still There?

I was a bit puzzled, though, by a couple of comments from Google's Ben Eidelson down in one of the G+ threads:

Ben Eidelson
+Thomas Heinen Thanks for your report of the issue. Hangouts supports basic interop with XMPP, so you can-for the time being-continue to use 3rd party clients. It does not work the same way as Talk, and so I believe the issue you're having with the XMPP bridge will not resolve in Hangouts.
Jason Summerfield
+Ben Eidelson So there is still some basic XMPP functionality under the hood? Does this mean that Hangouts will still be able to communicate with federated Jabber servers/clients, at least for now?
Ben Eidelson
+Jason Summerfield Not federated support, but supports interop with XMPP clients. Meaning you can continue to use XMPP clients to log in to Google Talk and those messages will interop with folks on Hangouts.

It was this that prompted me to call up Messages on my Mac, where I am logged in via XMPP to my GMail account, and to initiate a chat with Randy as shown above. We found we could chat perfectly fine. We couldn't initiate a callinto a Google+ Hangout from an external XMPP client - although I'll be honest and say I don't know how well that worked in the past. My own usage of external clients has entirely been for chat.

So What Is The Story?

I don't know. The statement quoted in The Verge's story seems pretty definitive that XMPP has been dropped, as does the message sent to AppEngine developers. It does seem so far that:

"Server-to-server" XMPP, used for federation with other servers / services, has been dropped.
"Presence" and status messages have been dropped (because the idea seems to be with Hangouts that you just send a message and people will get it either right then or whenever they are next online).
Within the Hangouts app, you can only connect to people with Google+ accounts, i.e. contacts on external XMPP servers no longer appear.
Google hasn't made any clear statements on what exactly is going on.

But is this partial XMPP support only temporary? Will it go away at some point whenever Hangouts fully "replaces" GoogleTalk? Or is this a communication mixup? (As happened recently with Google's announcement of DNSSEC support for their Public DNS Service?)

For me the disappointment in all of this is mostly that Google has been one of the largest advocates for the open XMPP protocol and I enjoyed the fact that I could use multiple different chat clients to interact with my GoogleTalk account. I was also very intrigued by the federation that we were starting to see between GTalk and other systems out there via XMPP.

Whereas before Google+ seemed to be an interesting social/messaging backbone to which I could connect many different apps and systems, now Google+ is looking like simply yet another proprietary walled garden - and we don't need more of those!

Hopefully we'll hear something more out of Google soon.

P.S. Here's another interesting viewpoint: Google Hangouts and XMPP – is cloud harming the Internet?

UPDATE: In a comment over on Google+, Daniel Pentecost states that Randy and I were not actually using Hangouts:

Dan, you weren't actually chatting through Hangouts. You were chatting through Google Talk which itself has a bridge into Hangouts. It only works b/c Randy is a Gmail user and still has access to Google Talk in Gmail.

Perhaps that is the case, which again then begs the question of whether this is only a temporary capability until GoogleTalk is shut down.

If you found this post interesting or useful, please consider either:

following me on Twitter;
adding me to a circle on Google+;
following me on App.net;
subscribing to my email newsletter; or
subscribing to the RSS feed.

You Can Now Call Into Google+ From Regular Phones - Google Connects Google Voice To Hangouts

2013-05-22T17:01:23-04:00

Want to hear the sound of Google further disrupting the world of telecom? If you have a Google Voice number and also use Google+ (as I do) with the Hangouts feature enabled, you'll soon be hearing this new sound if you haven't already.

UPDATE: I have written a follow-up post responding to several comments and expanding on several points.

An Unexpected Ringing

Yesterday a random PR person called the phone number in the sidebar of this blog to pitch me on why I should write about her client. This phone number is through Google Voice and I knew by the fact that my cell phone and Skype both started ringing simultaneously that someone was calling that number.

But as I was deciding whether or not to actually answer the call, I realized that there was another "ringing" sound coming from my computer that I had not heard before. Flipping quickly through my browser windows I found my Google+ window where this box appeared at the top of the "Hangouts" sidebar on the right:

Now, of course, I HAD to answer the call, even though I knew from experience that most calls to that number are PR pitches. I clicked the "Answer" button and in a moment a regular "Hangout" window appeared, complete with my own video, and with an audio connection to the phone call.

The PR person and I then had a pleasant conversation where I rather predictably determined quickly that she'd probably never actually readthis blog or she would have known that I've never written about her client's type of software. Be that as it may, the audio quality of the call was great and the call went on without any issues.

A subsequent test showed me that I also had access to the dialpad had I needed to send any button presses (for instance, in interacting with an IVR or robocall):

The only real "issue" with the phone call was that when I pressed the "Hang up" button I wound up still being in the Hangouts window with this message displayed:

The irony of course is that that phone number was never in the "video call"... at least via video. Regardless, I was now alone in the video call with my camera still running. I needed to press the "Exit" button in the upper right corner of the Hangouts window. Outside of that, the user experience for the phone call was fine.

The Future Of Google Voice?

Like many people interested in what Google is doing with Google+, I had read the announcement from Google of the new streams and Hangouts features last week and had gone ahead and installed the iOS Hangouts app onto my iPhone to try it out (marking Google's entrance into the OTT VoIP space). But nowhere in there had I seen that this connection was going to happen between Google Voice and Hangouts. I'd seen speculation in various media sites, but nothing direct.

So it was a bit of a surprise when it happened... particularly because I'd done nothing to enable it. Google had simply connected my Google Voice number to my Google+ account.

I admit that it is a pleasant surprise... although I do wish for the sake of my laptop's CPU that I could somehow configure it to NOT launch myvideo when I get an audio-only call. Yes, I can just go stop my video, but that's an annoying extra step.

It seems, though, that another feature removed from Hangouts, at least temporarily, was the ability to make outbound phone calls. Given that all signs of Google Voice were removed from Google's interface and replaced by "Hangouts", this has predictably upset people who used the service, particularly those who paid for credits to make outgoing calls. There does seem to be a way to restore the old Chat interfacefor those who want to make outgoing calls so that is at least a temporary workaround.

Google's Nikhyl Singhal posted to Google+ about the new Hangouts featuresstating these two points:

1) Today's version of Hangouts doesn't yet support outbound calls on the web and in the Chrome extension, but we do support inbound calls to your Google Voice number. We're working hard on supporting both, and outbound/inbound calls will soon be available. In the meantime, you can continue using Google Talk in Gmail.

2) Hangouts is designed to be the future of Google Voice, and making/receiving phone calls is just the beginning. Future versions of Hangouts will integrate Google Voice more seamlessly.

I'm sure that won't satisfy those who are troubled by the change, but it will be interesting to see where they go with Hangouts and voice communication.

(Note: the comment thread on Nikhyl Singhal's Google+ post makes for very interesting reading as people are sounding off there about what they'd like to see in a Hangouts / Google Voice merger.)

Will Hangouts Do SIP?

Of course, my big question will be... will Hangouts let us truly move beyond the traditional telephony of the PSTN and into the world of IP-based communications where can connect directly over the Internet? Google Voice once briefly let us receive VoIP calls using the SIP protocol - can Hangouts finally deliver on this capability? (And let us make outbound SIP calls as well?)

What do you think? Do you like this new linkage of Google Voice PSTN numbers to your Google+ account?

UPDATE #1 - I have written a follow-up post about XMPP support in Hangouts and confusion over what level of XMPP/Jabber support is still in Google+ Hangouts.

Audio commentary related to this post can be found in TDYR episode #009 on SoundCloud:

If you found this post interesting or useful, please consider either:

At SIPNOC 2013 This Week Talking About VoIP And IPv6, DNSSEC ... and Security, Of Course

2013-04-22T15:42:08-04:00

One of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

Panel Discussion: Anatomy of a VoIP DMZ
VoIP Security BOF
Panel Discussion: IPv6 and SIP - Myth or Reality?
Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.

It should be quite a good show and I'm very much looking forward to it. I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.

If you found this post interesting or useful, please consider either:

Heading to Beijing For ICANN 46

2013-04-05T16:58:48-04:00

Tomorrow morning I'm starting a trip to Beijing for the 46th meeting of the Internet Corporation for Assigned Names and Numbers, a.k.a. "ICANN". ICANN is the organization at the heart of the Domain Name System (DNS) and I'll be there specifically to take part in several DNSSEC workshops related to how to better secure DNS. I'll also attend an IPv6 workshop and some of the many other meetings scheduled for the week-long event.

These are very good technical meetings in the midst of all the other business-related meetings at an ICANN event. You can participate remotely if you are interested to do so (details are in those links).

Some colleagues of mine prepared the "Internet Society's Rough Guide to ICANN 46's Hot Topics" which gives a sense of what those of us from the Internet Society will be doing there at ICANN.

ICANN meetings are always crazy-busy and I'm looking forward to meeting up with people I know from a variety of contexts. We've got an outstanding program lined up for the DNSSEC workshop, so that will be a great event.

I've never been to China, so this should be an interesting experience. I probably won't have much time to look around, but I'm hoping to squeeze in a few hours during the week to look around (probably during some morning runs, if the weather and pollution levels will allow me to do so).

If you are going to be at ICANN 46, please feel free to contact me. I'll also of course be posting some live updates from there as well.

Here's a quick audio commentary on my trip:

If you found this post interesting or useful, please consider either:

Video Interview: Emil Ivov about how the Jitsi softphone works with IPv6 and DNSSEC

2013-03-28T09:59:38-04:00

How does the Jitsi softphone work with IPv6? And what role could DNSSEC play with VoIP? At IETF86 earlier this month, I sat down with Emil Ivov, project leader of the Jitsi Project to talk about a wide range of topics including how Jitsi got started and why it does so much with IPv6 (interesting reason!), what they are looking to do with Jitsi now, the role of DNSSEC and why they added that support to Jitsi... and much, much more... I quite enjoyed talking to Emil and the Jitsi project is certainly one that I will continue to watch - and use!

If you found this post interesting or useful, please consider either:

Watch/Listen Live - FCC CTO Henning Schulzrinne on "The End of Plain Old Telephone System (POTS)" at 5:30pm EDT Tonight at IETF86

2013-03-11T17:18:01-04:00

~~In about 15 minutes, at 5:30pm US Eastern~~ At around 6:00pm US EDT, Henning Schulzrinne, CTO of the US Federal Communications Commission (FCC) will be speaking on "The End of Plain Old Telephone System (POTS): Transitioning the PSTN to IP" at the technical plenary of the 86th IETF meeting happening this week in Orlando, Florida. You can listen or watch here:

Audio stream – either Caribbean 3 or Caribbean 4
Jabber chat: plenary@jabber.ietf.org
Meetecho conferencing (webinar)

Henning's slides are also available for download.

It should be quite an interesting session!

If you found this post interesting or useful, please consider either:

VUC Today: The Jitsi VoIP Softphone - Join The Call To Learn More!

2013-03-08T09:29:05-05:00

What is new with the Jitsi softphone these days? What new capabilities does it have as it continues to expand its support of SIP, XMPP and other protocols?

I've long been a fan and user of Jitsi, in part because it supports IPv6 and is the only VoIP softphone I know of right now that supports DNSSEC, something I'm continuing to experiment with, so I'm looking forward to today's "VoIP Users Conference (VUC) call at 12 noon US Eastern - about 2.5 hours from now.

You can watch it live via a Google+ Hangout On Air, or call in (potentially using Jitsi!) via:

sip:200901@login.zipdx.com
+1 (646) 475-2098
Skype:vuc.me

There's also an IRC backchannel where links are shared, questions are answered and other comments occur.

And for those of you using Google+, there is a Google+ Event you can join.

It should be a good show! (And yes, you can watch it / listen to it later...)

If you found this post interesting or useful, please consider either: