Disruptive Telephony

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

• http://ietf87streaming.dnsalias.net/ietf/ietf874.m3u

You can also join the Jabber chat room at:

• xmpp:[email protected]

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

• http://datatracker.ietf.org/meeting/87/materials.html#stir

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

• http://www.meetecho.com/ietf87/stir

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

• draft-peterson-secure-origin-ps
• draft-rescorla-stir-fallback
• draft-kaplan-stir-cider

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?

---

Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."

---

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

---

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:

• 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

---

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:

• 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

---

Fascinating news today out of Oracle that they have purchased Acme Packet in a transaction estimated to be around $2 billion US. For those of you not really tracking the VoIP security space, Acme Packet is probably the world's largest vendor of "session border controllers (SBCs)", devices that are used to securely and reliable interconnect VoIP networks. SBCs also provide a very important role in helping with interoperability of Session Initiation Protocol (SIP) signaling between the SIP products and networks of different vendors.

As Andy Abramson writes, the fascinating aspect of this acquisition is this:

This is an interesting grab by one of the tech world's true giants because it sqaurly puts Oracle into a game where they begin to compete with the giants of telecom, many of whom run Oracle software to drive things including SBC's, media gateways and firewall technology that's sold.

This acquisition does put Oracle VERY firmly into the telecom sector at a carrier / large enterprise level, as Acme Packet's products are widely used within that tier of companies. As the news release notes:

"The company's solutions are deployed by more than 1,900 service providers and enterprises globally, including 89 of world's top 100 communications companies."

Acme Packet has also long been recognized as a leader by analyst firms such as Gartner. People from Acme Packet, in particular Hadriel Kaplan, have also been extremely involved with industry efforts such as the SIP Forum and standards activity in the IETF.

As far as integration, Oracle already has a wide array of "communications" products, including several unified communications (UC) products that could potentially interact with Acme Packet products extremely well. Beyond all of that, though, this acquisition will have Oracle being a strong player in providing telecom infrastructure as we continue to collectively move to basing all our communications on top of IP.

Congratulations to my friends at Acme Packet and Oracle... and I wish them the best as they proceed down the path to completing this acquisition.

More information here:

• Oracle news release
• Oracle page about the acquisition
• A letter from Acme Packet CEO

---

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

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

---

If any of you will be in Chicago next week, October 4-6, 2011, for the 7th Annual Real-Time Communications Conference & Expo, I'll be there on the 5th and 6th as a speaker.

I'll be speaking twice. First on Wednesday the 5th at 4pm on "The Current State of VoIP Security", wearing my VOIPSA hat and leading off a series of talks about security. I'll be providing an overview of the main threats to VoIP and communications security in general, leading the way into the two more specific talks following mine.

I'm rather excited that my second session will be my first public appearance wearing my new Internet Society hat (if you are not aware, I've posted details about my recent move) and will of course be about IPv6... more specifically "How IPv6 Will Impact SIP And Telecom".

Due to ongoing events on the personal front, I wasn't sure that I was going to make it out there... and quite frankly there's still a chance that I won't... but I should be out there.

If you look at the conference schedule, the speakers include outstanding people involved with so many different aspects of real-time communications. It should be truly an excellent event!

P.S. You can still register if you would like to attend!

---

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

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

---

Today, Skype issued a new Skype 5.1 for Mac "hotfix" for more "security issues". The problem?

We don't know what those "security issues" are?

We don't know, for instance:

• Are they related to the remote exploit that was publicly disclosed on Friday? Or to related attacks on the same theme? (as discussed on SecNiche today)
  
  
• What is the severity of these "security issues"? Remote compromise? Denial of service? What?
  
  
• What is the priority that we should place on getting this update in place? Is it a "UPDATE NOW!" kind of priority? or a "Update when you can"?
  
  
• What kind of mitigating circumstances are there for these security fixes?
  
  
• Are there any workarounds that could be put in place at a network layer (or any other layer) to prevent attacks on individual systems? (i.e. as a safety measure until the individual clients are all updated?)

We need to know this kind of information.

Particularly as Skype looks to try to move more into the "business" or "enterprise" market space, this level of NON-disclosure is unacceptable.

In comparison, take a look at any of the recent Microsoft security bulletins, like, oh, this one, and you can see the kind of information that a security professional is looking for. Now, sure, Skype doesn't necessarily need to go to the level of detail that Microsoft has... but something more than just "Security issues" is necessary.

Letting Us Know?

Additionally, why again is Skype issuing a "hotfix for security issues" without telling anyone about it? Just like they did back in April?

Once again the hotfix is mentioned only on Skype's Garage blog. Nothing on Twitter on either @skype or @skypesecurity. Nothing on the Mac blog (although they finally updated that blog about the issue on Friday). Nothing on the Security blog.

And once again, the "Check for Updates..." feature in Skype 5.1 does not show a new update available:

So apparently the only way we can get this hotfix for unknown "security issues" is to go to Skype's main download site and download it!

C'mon Skype! You can do better than this!

Recommendations for Skype

So rather than just rant, let me offer these suggestions to Skype for what they should do when they have a "security hotfix":

1. Provide More Info - Saying it is simply "security issues" doesn't cut it. We need to know things like:

• what is the severity of the security issue? if an attacker could compromise the Skype client, what could he or she do?
• how easy is it for an attacker to execute an attack? can the attacker be remote? do they have to be a contact?
• are there mitigating circumstances that would make an attack less likely?
• are there workarounds that could be put in place at a larger level than just the client?
• what is the potential exposure of NOT upgrading?

Skype should look seriously at tools like the Common Vulnerability Scoring System (CVSS) used by many software/hardware providers (see also the CVSS FAQ). And while perhaps the full CVSS process may be too heavy for a smaller organization like Skype, the document at least gives insight into the type of questions security professionals want.

Similarly, the Cisco Security Vulnerability Policy and associated links is worth a read. Again, it may be too heavy a system for a smaller company like Skype... but then again perhaps in all of the new hires Skype is looking to do they could hire some folks specifically to work on this process.

2. Let People Know About The Security Hotfix - Skype has a "security" blog and specific @skypesecurity Twitter account. They should be used to communicate the availability of security hotfixes. Security professionals associated with companies using Skype could then know that they need to subscribe/follow those sites to know when there are new issues needing attention.

3. Make The Security Hotfix EASY To Obtain - Make the "Check for Updates..." process work from the beginning. The blog post or other update should be able to state that Skype users can simply go up to "Check for Update..." to download/install the new version. Perhaps this means that the blog post has to be delayed until the new version is uploaded to whatever update servers Skype has... but so what? Wait a bit - or improve the internal process so that these uploads happen faster. The end result will be that MORE people will update sooner, which, I would think, should be the goal.

Those three steps would help people feel a whole lot better about Skype's concern for security - and would also make sure that Skype users are better protected. It would also help Skype's reputation, brand, etc.

And it would stop people like me from writing blog posts like this. ;-)

Seriously, Skype... security matters... and even more, communication about security matters. We all know that with any system there are security issues... no system is perfect and attackers will always try to compromise systems. We get that. It is how you react and communicate about those security issues that is so incredibly critical.

What is the point in issuing a hotfix that addresses a security vulnerability... if you don't tell anyone that the hotfix is available?

Tonight Skype published a blog post saying that back on April 14th they released a "hotfix" for this problem in Skype for Mac version 5.1.0.922. That's great... it's good that the fix is out there, but...

how were we Mac users supposed to know about it?

Hmmm... let's see... Could we find out about the Skype for Mac hotfix...

• ... using the "Check for Updates" feature? Nope, doesn't work for me. Maybe it works for others out there, but not for me.
  
  
• ... from the Skype for Mac Release Notes page? Nope, that page STILL hasn't been updated, three weeks later, to indicate that a new version is out. Nothing on there at all about 5.1.0.922.
  
  
• ... from Skype's Twitter account? Nope, no mention of a hotfix back on April 15th, although they did talk about the fact that Skype was mentioned twice on 30 Rock and that there was Skype call on the Rachael Ray show.
  
  
• ... from Skype's skypesecurity Twitter account? Nope, no mention.
  
  
• ... on Skype's Mac blog? Nope. Last post there was April 14th, the day before this hotfix came out.

No mention of a "hotfix" for Skype 5.1 for Mac OS X on any of those communication vehicles.

In The Garage?

Ah, but wait... Skype did mention the hotfix, over on the Skype Garage blog, which is all about "Experiments and pre-releases". Here's a screen capture of the notice:

So they posted news of this important "hotfix" on a blog for "experiments and pre-releases", didn't tweet it out, and didn't update release notes or put it anywhere regular Mac users would find it.

And a curious thing...

THERE IS NO MENTION OF A SECURITY ISSUE!

Nothing whatsoever.

I am guessing that "Minor bug fixes" must include this security issue. And maybe the fix was simply a "minor bug fix". Maybe someone forgot to do bounds checking on some part of the chat system and as a result a buffer overflow occurred. Maybe it was some simple little fix.

But labeling it in this way gives absolutely no incentive for anyone to upgrade. Even had I seen this notice, I probably wouldn't have bothered to upgrade (unless the Check for Updates had worked). There is no urgency on this.

And... call me crazy, perhaps, but I guess I don't consider a security issue where someone could send me a chat message and gain complete control of my Mac to be a "minor bug"!

Did Skype not think that at some point the security researcher would publish his findings?

And why in the world didn't Skype communicate with this security researcher to tell him that they had fixed the bug he found and would be issuing (in fact had issued a fix)? Now maybe they thought they did... but whatever the situation was, he didn't know and out of frustration published his post today.

It Didn't Have To Be This Way

In other words...

... everything that happened today was COMPLETELY PREVENTABLE had Skype only communicated more.

Skype would not have had the negative coverage in ZDNet, CNet, ComputerWorld, Mashable, TheNextWeb, my own blog ... and many other sites, let alone all the tweeting and retweeting.

Instead of having all this negative activity, they could have jointly come out with a statement with the security researcher or at least crediting the researcher. It would have shown that Skype was serious about security and protecting us - and also serious about working with the security community.

And even after the story broke early today, Skype could have tweeted out a response... or posted the blog post earlier... they could have cut off all the discussions and concerns simply by being more transparent and providing some information - or even just communicating that they were in the process of getting an answer.

Instead, there is only one word to summarize Skype's communications:

FAIL!

The thing that kills me is that Skype employs a ton of truly brilliant engineers. They have on their payroll a couple of the leading SIP/VoIP security researchers that are out there. And these guys know how the security community works.

Knowing some of those folks personally, I have to think that the process broke down somewhere in the external communications side of the house. Because of the IPO and the "silent period", I know that people at Skype are ultra-cautious about saying anything. And maybe that's part of it, but in this case, it truly failed them.

Too bad... because none of all this communication today had to happen.

---

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

• subscribing to my email newsletter;
• following me on Twitter; or
• subscribing to the RSS feed

---

---

From the Can-We-Please-Communicate-Better Department... there is apparently an open vulnerability in the Skype for Mac client that lets an attacker send a message to a Skype user and gain remote access. As reported today by Gordon Maddern on the PureHacking blog:

The long and the short of it is that an attacker needs only to send a victim a message and they can gain remote control of the victims Mac. It is extremely wormable and dangerous.

Given that I basically live inside of Skype for Mac and use it extensively every day, this is obviously extremely concerning. Particularly because I do let anyone on Skype send me messages... and my Skype ID is easily found on my websites and many other locations (and since is rather obvious - "danyork"). I also tend to leave Skype running on a Mac in my home office that is online all the time. Mostly this provides a way to quickly catch up on chats as I have all the messages already there on that system (rather than waiting for Skype to sync up after it is launched).

Maddern indicates that he contacted Skype over a month ago about this and no fix has come out yet. In his post, he says:

Pure Hacking wont give specifics on how to perform this attack untill a patch from skype is released. However we will give a full disclosure after skype takes action or a resonable responsible disclosure time.

Which is great... except that now attackers will be out there trying to figure out what kind of "payload" he sent that created this condition. There is always the chance that someone may discover the attack.

Where is Skype's Statement?

ZDNet UK covered the story today and received this update from Skype:

Skype has just sent ZDNet UK a statement promising a fix next week. The statement reads: "We are aware of this and will release a fix early next week to resolve the issue. We take our users privacy very seriously and are working quickly to protect Skype users from this vulnerability."

What is concerning, though, is that there is no other public comment on this from Skype...

• ... nothing on Skype's blogs, particularly their Security blog
• ... nothing on Skype's Twitter account
• ... nothing on Skype's SECURITY Twitter account

It's Friday afternoon here in the US... people are about to leave their offices and some % of those who use Macs may in fact leave their computers on and leave Skype running. Are those machines vulnerable? Can someone really just send someone a message and gain control of their Mac?

Which version of Skype for Mac is vulnerable? Is this only in the newer 5.x client? Or does this impact the older 2.8 client?

We need answers, Skype! I can understand that a fix may take some time, but in the meantime we need to understand what the risk is. Are there mitigating circumstances? Or actions we can take in the meantime?

How To (Maybe) Protect Yourself

So what are we to do until there is either a fix or a helpful statement?

1. QUIT OUT OF SKYPE - Obviously this is one option (and one I might pursue on that computer in my office). But that may not be practical for folks... and isn't for me in my work context.

2. CHANGE PRIVACY SETTINGS - It seems to be the biggest change we can make is to only allow chat messages from people in our contact list. This would mean that a random attacker out on the Internet couldn't just send you a message and take over your Mac. You will only get chat messages from your contacts, not random people.

In Skype 5.x for the Mac, you go to the Skype menu and then Preferences and then make sure that the settings are that only Contacts can contact you:

On the Skype 2.8 for Mac client, the layout is a bit different but the choices are similar:

Now, in these images I'm only suggesting you restrict chat messages. In the blog post about the attack, it is very clear that the attack vector is a chat message, so in theory you should only need to change the one privacy option for chat messages. Whether or not you also want to restrict calls to be from your contacts is up to you. Absent a clear statement about the vulnerability from Skype, we have very limited information to go on... but again the blog post was very clear that the attack was through a chat message with a particular payload.

Will that protect your system? I don't know... I'm guessing along with you all.

Now, depending upon how paranoid your mind operates, there is, of course, the case that an attacker could take over a Mac operated by one of your contacts, and then potentially use the Skype client on that machine to then contact you. Maybe that's possible, maybe that's not.

3. RUN AN OLDER SKYPE VERSION - Does this only affect the newer Skype 5.x for MacOS X? Could we be protected by reverting to the older 2.8 client? (which I'm still running on one of my systems)

I don't know... and I wouldn't use this as my only protection mechanism.

Give us a clue, Skype!

We don't know... and that's not a good space to be in.

What can you tell us who are Mac users, Skype?

---

UPDATE #1 - The Register also covered the story and pointed out that perhaps the attacking chat message could cause other chat messages to be sent out. Again... possible... but we just don't know.

Also, someone pointed out that Skype did have a "public statement", so my title is not accurate. Sure... they gave a statement to ZDNet UK and perhaps other media outlets... but where is that on Skype's public presence? Why not on one of their blogs or on Twitter?

---

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

• subscribing to my email newsletter;
• following me on Twitter; or
• subscribing to the RSS feed

---

If any of you will be in South Beach, Miami, next week I'll be there speaking as part of the Cloud Communications Summit and SIP Trunking Workshops. I've got a page up on Voxeo's site that shows my schedule at:

http://blogs.voxeo.com/events/itexpo-east-2011/

I know a good number of other folks from the VoIP/UC/Cloud Telecom/Voice Mashups/SIP/etc. world are all going to be down there, so I'm looking forward to catching up with some folks there.

If you are down in Miami for ITEXPO, the Cloud Communications Summit, Digium/Asterisk World or any of the other events, please do stop by and say hello... or find me down at one of the sessions I'm in (my schedule is online). You can always email me or ping me on Twitter.

---

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

• subscribing to my email newsletter;
• following me on Twitter; or
• subscribing to the RSS feed

---

If any of you will be at the Voice Biometrics Conference next week (May 4-5) in the New York area (Jersey City, actually), I'll be there speaking on Wednesday about 'Seeding the Cloud - Authentication as a Service'. I'm arriving Monday evening and will be there through early Thursday morning.

"Voice Bio Con", as it is called, is a rather comprehensive gathering of the major players in the voice biometrics / voice authentication / voice verification space. Great agenda with some excellent speakers (and yeah, I'm on that list, too). I wrote over on the VOIPSA blog about the number of case studies and real world deployments that will be discussed.

It should be a great event... I'm on that panel and will also be talking about Voxeo's voice biometric partner program where you can try out voice biometric solutions for free using our hosted platform and the hosted services from four of the major voice biometric vendors. I'm looking forward to meeting up with some friends there and undoubtedly having some great conversations and learning a good bit.

If you are at the event, please do say hello! If you want to go and haven't registered yet, there's a discount code you can use to save $200.

See (some of) you in the Big Apple...

P.S. And yes, you can safely assume that I'll be tweeting (probably both @danyork and @voxeo) and blogging from the event...

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.

---