[Giagnocavo]Michael::Write() - VoIP http://www.atrevido.net/blog/ Something about .NET. Michael Giagnocavo Fri, 10 Oct 2008 00:25:14 GMT newtelligence dasBlog 2.3.9074.18820 mggUNSPAM@telefinity.com mggUNSPAM@telefinity.com http://www.atrevido.net/blog/Trackback.aspx?guid=9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c http://www.atrevido.net/blog/pingback.aspx http://www.atrevido.net/blog/PermaLink,guid,9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c.aspx http://www.atrevido.net/blog/CommentView,guid,9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c.aspx http://www.atrevido.net/blog/SyndicationService.asmx/GetEntryCommentsRss?guid=9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c Every now and then I read an article on VoIP security. These articles almost always go over the obvious stuff such as lack of encryption, eavesdropping and ensuring you firewall your networks and so on. While certainly major issues, especially for a corporate deployment, there are still some other interesting issues.

One thing that keeps getting mentioned is the possibility for VoIP peering. Peering allows VoIP providers to send calls directly to each other (possibly over the Internet, maybe over [semi-]private connections). The main idea is cost savings, since the call doesn't need to go out over the public telephone network (PSTN).

To accomplish this, they'll set up a shared database mapping telephone numbers to VoIP providers. So, when a VoIP provider attempts to place a call, it'll consult this directory first. If it finds the number in there, it'll send it direct to the provider instead of over the PSTN. All the providers sign some sort of contract to say they'll be careful with the database and not populate it with invalid entries. Let's just assume the VoIP provider is trustworthy and hires trustworthy people (this is a stupid assumption, but I've had a peering company tell me this, as the security problems are too obvious without this assumption).

This system actually holds true inside of a VoIP provider's own network. A provider will want to terminate directly to a customer instead of out via the PSTN then back into their own network. So they'll probably have a directory of their own numbers so they can route those directly.

Well first off, now every peering member's security is bound by the security of every other member. If just one "trustworthy" peering provider gets compromised (not a hard task - more on that later), they can pollute the shared directory and hijack phone numbers. Being able to redirect a financial institution's phone number sounds like a profitable attack. An attacker can simply route the call to their system, then pass it through to the PSTN to avoid detection by users. Note that none of the security technologies available can prevent problems with a subverted, trusted, directory.

But it gets easier...
Many providers let you port your existing number to them when you sign up. From my limited experience, I've seen some of them immediately activate the number for you, so you can get started and going with their network while the port happens. A port can take a bit of time (and for now, let's assume the porting system is secure), so this sounds like a reasonable approach.

Wrong. First off, the new customer's number will probably go right into the provider's internal database, so all calls from that provider will go to the customer attacker. Depending on the size of the provider, this could be a pretty decent attack in and of itself.

But now, suppose the peering contract didn't specify not provisioning ports-in-progress, or if it did, the implementation people messed up. Now ALL the VoIP providers have been compromised, by a single provider who was agressive in their porting tactics.

Eventually it'll probably get resolved, but even a few hours or days of compromising a valuable phone number can be a significant attack.

What's the threat?
As a consumer, in general, I'd not worry too much about people trying to tap my line, just like I rarely worry about the safety of my wired Internet connection. But similar to intercepting credit card info versus hacking a company's database, this is a much juicier target. An attacker who pulls this off gets access to bulk information. Thus, I think the threat of something like this happening is much higher than having my individual calls monitored.

VoIP Security - Peering http://www.atrevido.net/blog/PermaLink,guid,9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c.aspx http://www.atrevido.net/blog/2008/10/10/VoIP+Security+Peering.aspx Fri, 10 Oct 2008 00:25:14 GMT Every now and then I read an article on VoIP security. These articles almost always go over the obvious stuff such as lack of encryption, eavesdropping and ensuring you firewall your networks and so on. While certainly major issues, especially for a corporate deployment, there are still some other interesting issues.<br> <br> One thing that keeps getting mentioned is the possibility for VoIP peering. Peering allows VoIP providers to send calls directly to each other (possibly over the Internet, maybe over [semi-]private connections). The main idea is cost savings, since the call doesn't need to go out over the public telephone network (PSTN). <br> <br> To accomplish this, they'll set up a shared database mapping telephone numbers to VoIP providers. So, when a VoIP provider attempts to place a call, it'll consult this directory first. If it finds the number in there, it'll send it direct to the provider instead of over the PSTN. All the providers sign some sort of contract to say they'll be careful with the database and not populate it with invalid entries. Let's just assume the VoIP provider is trustworthy and hires trustworthy people (this is a stupid assumption, but I've had a peering company tell me this, as the security problems are too obvious without this assumption).<br> <br> This system actually holds true inside of a VoIP provider's own network. A provider will want to terminate directly to a customer instead of out via the PSTN then back into their own network. So they'll probably have a directory of their own numbers so they can route those directly.<br> <br> Well first off, now every peering member's security is bound by the security of every other member. If just one "trustworthy" peering provider gets compromised (not a hard task - more on that later), they can pollute the shared directory and hijack phone numbers. Being able to redirect a financial institution's phone number sounds like a profitable attack. An attacker can simply route the call to their system, then pass it through to the PSTN to avoid detection by users. Note that none of the security technologies available can prevent problems with a subverted, trusted, directory.<br> <br> <b>But it gets easier...</b> <br> Many providers let you port your existing number to them when you sign up. From my limited experience, I've seen some of them immediately activate the number for you, so you can get started and going with their network while the port happens. A port can take a bit of time (and for now, let's assume the porting system is secure), so this sounds like a reasonable approach. <br> <br> Wrong. First off, the new customer's number will probably go right into the provider's internal database, so all calls from that provider will go to the <strike>customer</strike> attacker. Depending on the size of the provider, this could be a pretty decent attack in and of itself.<br> <br> But now, suppose the peering contract didn't specify not provisioning ports-in-progress, or if it did, the implementation people messed up. Now ALL the VoIP providers have been compromised, by a single provider who was agressive in their porting tactics.<br> <br> Eventually it'll probably get resolved, but even a few hours or days of compromising a valuable phone number can be a significant attack.<br> <br> <b>What's the threat?</b> <br> As a consumer, in general, I'd not worry too much about people trying to tap my line, just like I rarely worry about the safety of my wired Internet connection. But similar to intercepting credit card info versus hacking a company's database, this is a much juicier target. An attacker who pulls this off gets access to bulk information. Thus, I think the threat of something like this happening is much higher than having my individual calls monitored.<br> <br> <p> </p> <img width="0" height="0" src="http://www.atrevido.net/blog/aggbug.ashx?id=9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c" /> http://www.atrevido.net/blog/CommentView,guid,9b1f6230-dfb8-4ed2-b1e0-d216786b6d4c.aspx Security VoIP http://www.atrevido.net/blog/Trackback.aspx?guid=7f03299e-3674-444c-acb7-aa79c7e71993 http://www.atrevido.net/blog/pingback.aspx http://www.atrevido.net/blog/PermaLink,guid,7f03299e-3674-444c-acb7-aa79c7e71993.aspx http://www.atrevido.net/blog/CommentView,guid,7f03299e-3674-444c-acb7-aa79c7e71993.aspx http://www.atrevido.net/blog/SyndicationService.asmx/GetEntryCommentsRss?guid=7f03299e-3674-444c-acb7-aa79c7e71993 Managed code? In MY softswitch? It's more common than you think.

A while back, I tried creating a mono plugin for Asterisk. The goal being that'd you'd be able to write in-process apps in decent languages, rather than resorting to C. Well, there were no standards of how functions operated (i.e., who's responsible for memory), and my requests to standardize these were met with hostility. (Actually, when I asked why they didn't refactor some stuff, like the multi-thousand-line switch statements, I was told "refactoring doesn't exist for C"... sigh.) But the real showstopper was that we couldn't figure out how to get Asterisk to play nice with mono as far as threads go. I had a very active Asterisk developer work on it with me, and he pretty much told me it wasn't going to work. Oh well.

When I stopped really being involved with Asterisk, I had seen a couple big Asterisk developers leave to start FreeSWITCH. It was mainly an idea at that point, to do things right and build a scalable, clean system. Well, fast forward a few years and FreeSWITCH has really come far. You can go read their site for more details, but it's a more flexible, scalable, and vastly cleaner VoIP platform. That's why, at v1.0.1, it already supports UDP, TCP, TLS, SRTP, IPv6, wideband codecs, and more. Oh, and it runs cross-platform, including Windows.

But the really great thing about FS is that it was designed to be modular from the beginning. And, it was designed to allow people build apps into it. It has some nice out-of-process extensibility, think Asterisk Manager and AGI, without the suck. [I wonder how many * flames I'm gonna get?] But also of interest, they designed an app API from the start. It's written in C++, and SWIG friendly so you can quickly add other languages (Javascript and Lua seem to be the most popular).

Well, the thought of running interpreted stuff in-process disgusted me, so I immediately set out to try to add Mono support. Much to my surprise, the FS team was extremely supportive. They helped me figure out all the bits of FS and the API I needed. In fact, one of the project leads told me, "Hell, if you're gonna write mod_mono, we'll give you checkin support right now.". A short bit later, we had mod_mono working!

Not satisfied with doing just apps, I turned to doing a full integration. A bit of SWIGwork later, and I had the entire FreeSWITCH header files SWIG'd and C# accessible. I found a few APIs that didn't import (varargs stuff, I think), but the FS team helped add some different methods to work around that.

The Mono side was pretty straightforward. We write a C/C++ module for FS that gets Mono up and running. Then it kicks off mod_mono_managed, which actually loads modules, runs initialization code, etc.
The biggest problem I ran into was a problem between SWIG and Mono. Mono would attempt to free strings with g_free, crashing on Windows. I wrote a SWIG-C# post-processor to tweak the SWIG code to avoid it; I'm not sure it's accurate, but we haven't noticed issues so far. A few things we ran into were quickly cleared up by the awesome people #mono. This week we'll be testing and make sure it's fixed in Mono 2.0.

So, the bottom line is that you can write any sort of module for FreeSWITCH, from simple apps and API functions, down to a full codec or endpoint, all in managed code (though, the interop might not be pretty sometimes). I've tried some simple stuff out in C#, F#, and Javascript (JScript .NET), and it all works fine. The code is in the FS SVN, under /freeswitch/src/mod/languages/mod_mono and mod_mono_managed. It's not part of the official build yet, so there may be a bit of work involved in getting it going. But I have heard from other people that they've gotten it working. Some info is here: http://wiki.freeswitch.org/wiki/Mod_mono -- Right now, we've only tested on Mono 1.9.1, but we're going to only support 2.0 as of very soon. (F# only supports 2.0, so earlier versions are irrelevant to my interests :).)

This is exciting for us, as it allows us to build *safe* applications that run in-process with the switch. But, unlike the embedded scripting languages, we get top-notch performance and access to complete libraries. We're combining this in-process approach with out-of-process (Event Socket, outbound) to get a robust and very scalable system. For our particular application, we have several GB of decision data that we keep in RAM on separate servers (which is in turn sync'd to SQL Server 2008, via a proprietary change replication system). For obvious reasons, we didn't want that memory being stuck in the FS process. Having Mono on both sides allows us to share code between the different systems, while still getting optimizations for both environments.

You can email me: mgg AT a t r e v i d o _ net or use the chat widget on the on my site if you have questions or problems getting it going.

I'll post a follow up once it's in the official build.

Mono in FreeSWITCH - Experience in embedding Mono http://www.atrevido.net/blog/PermaLink,guid,7f03299e-3674-444c-acb7-aa79c7e71993.aspx http://www.atrevido.net/blog/2008/09/02/Mono+In+FreeSWITCH+Experience+In+Embedding+Mono.aspx Tue, 02 Sep 2008 02:04:38 GMT <i>Managed code? In MY softswitch? It's more common than you think.</i> <br> <br> A while back, I tried creating a mono plugin for Asterisk. The goal being that'd you'd be able to write in-process apps in decent languages, rather than resorting to C. Well, there were no standards of how functions operated (i.e., who's responsible for memory), and my requests to standardize these were met with hostility. (Actually, when I asked why they didn't refactor some stuff, like the multi-thousand-line switch statements, I was told "refactoring doesn't exist for C"... sigh.) But the real showstopper was that we couldn't figure out how to get Asterisk to play nice with mono as far as threads go. I had a very active Asterisk developer work on it with me, and he pretty much told me it wasn't going to work. Oh well.<br> <br> When I stopped really being involved with Asterisk, I had seen a couple big Asterisk developers leave to start <a href="http://www.FreeSWITCH.org">FreeSWITCH</a>. It was mainly an idea at that point, to do things right and build a scalable, clean system. Well, fast forward a few years and FreeSWITCH has really come far. You can go read their site for more details, but it's a more flexible, scalable, and vastly cleaner VoIP platform. That's why, at v1.0.1, it already supports UDP, TCP, TLS, SRTP, IPv6, wideband codecs, and more. Oh, and it runs cross-platform, including Windows.<br> <br> But the really great thing about FS is that it was designed to be modular from the beginning. And, it was designed to allow people build apps into it. It has some nice out-of-process extensibility, think Asterisk Manager and AGI, without the suck. [I wonder how many * flames I'm gonna get?] But also of interest, they designed an app API from the start. It's written in C++, and SWIG friendly so you can quickly add other languages (Javascript and Lua seem to be the most popular). <br> <br> Well, the thought of running interpreted stuff in-process disgusted me, so I immediately set out to try to add Mono support. Much to my surprise, the FS team was extremely supportive. They helped me figure out all the bits of FS and the API I needed. In fact, one of the project leads told me, "Hell, if you're gonna write mod_mono, we'll give you checkin support right now.". A short bit later, we had mod_mono working!<br> <br> Not satisfied with doing just apps, I turned to doing a full integration. A bit of SWIGwork later, and I had the entire FreeSWITCH header files SWIG'd and C# accessible. I found a few APIs that didn't import (varargs stuff, I think), but the FS team helped add some different methods to work around that. <br> <br> The Mono side was pretty straightforward. We write a C/C++ module for FS that gets Mono up and running. Then it kicks off mod_mono_managed, which actually loads modules, runs initialization code, etc. <br> The biggest problem I ran into was a problem between SWIG and Mono. Mono would attempt to free strings with g_free, crashing on Windows. I wrote a SWIG-C# post-processor to tweak the SWIG code to avoid it; I'm not sure it's accurate, but we haven't noticed issues so far. A few things we ran into were quickly cleared up by the awesome people #mono. This week we'll be testing and make sure it's fixed in Mono 2.0. <br> <br> So, the bottom line is that you can write any sort of module for FreeSWITCH, from simple apps and API functions, down to a full codec or endpoint, all in managed code (though, the interop might not be pretty sometimes). I've tried some simple stuff out in C#, F#, and Javascript (JScript .NET), and it all works fine. The code is in the FS SVN, under /freeswitch/src/mod/languages/mod_mono and mod_mono_managed. It's not part of the official build yet, so there may be a bit of work involved in getting it going. But I have heard from other people that they've gotten it working. Some info is here: <a href="http://wiki.freeswitch.org/wiki/Mod_mono">http://wiki.freeswitch.org/wiki/Mod_mono</a> -- Right now, we've only tested on Mono 1.9.1, but we're going to only support 2.0 as of very soon. (F# only supports 2.0, so earlier versions are irrelevant to my interests :).) <br> <br> This is exciting for us, as it allows us to build *safe* applications that run in-process with the switch. But, unlike the embedded scripting languages, we get top-notch performance and access to complete libraries. We're combining this in-process approach with out-of-process (<a href="http://wiki.freeswitch.org/wiki/Event_Socket">Event Socket</a>, outbound) to get a robust and very scalable system. For our particular application, we have several GB of decision data that we keep in RAM on separate servers (which is in turn sync'd to SQL Server 2008, via a proprietary change replication system). For obvious reasons, we didn't want that memory being stuck in the FS process. Having Mono on both sides allows us to share code between the different systems, while still getting optimizations for both environments.<br> <br> You can email me: mgg AT a t r e v i d o _ net or use the chat widget on the on my site if you have questions or problems getting it going. <br> <br> I'll post a follow up once it's in the official build.<br> <br> <p> </p> <img width="0" height="0" src="http://www.atrevido.net/blog/aggbug.ashx?id=7f03299e-3674-444c-acb7-aa79c7e71993" /> http://www.atrevido.net/blog/CommentView,guid,7f03299e-3674-444c-acb7-aa79c7e71993.aspx FreeSWITCH VoIP http://www.atrevido.net/blog/Trackback.aspx?guid=c116e749-d9bd-4275-9c14-0197556b711e http://www.atrevido.net/blog/pingback.aspx http://www.atrevido.net/blog/PermaLink,guid,c116e749-d9bd-4275-9c14-0197556b711e.aspx http://www.atrevido.net/blog/CommentView,guid,c116e749-d9bd-4275-9c14-0197556b711e.aspx http://www.atrevido.net/blog/SyndicationService.asmx/GetEntryCommentsRss?guid=c116e749-d9bd-4275-9c14-0197556b711e 3

I love Microsoft products (except DRM-crippled products... more on that later). So, it hurts me when MS doesn't play its full potential. Area of this time: VoIP.

I've been doing VoIP full-time for over a year and a half. Not exactly a long time, but not too short in this market. I think a lot of people miss the most important part of VoIP. The use of packet-switched versus circuit-switched goes way beyond being able to use cheaper transit and hardware. The real power that IP brings is that the shift can move from hardware to the software. As VoIP platforms become available, the power shifts because voice is finally something every developer can control. This goes back well before the current wave of VoIP-craziness and super-inflated company valuations.

Microsoft was here quite some time ago. NetMeeting was released in 1996 and had a decent API (Well, I've not used it, but the docs seem to indicate a lot of power). Messenger continued this (well, except I don't think the API allows you to do anything interesting). So Microsoft was certainly there back then; this isn't a completely new territory.

Software means no needing to spend $$$$ on all sorts of features. For instance, many vendors sell a “voicemail module“ at a decent price. What exactly is a voicemail module? Isn't it nothing more than a simple IVR + recording function? Sigh.

Skype
Hence, you might now understand why I think Skype is silly, or more to the point, MS screwed up again. Messenger (and NetMeeting before that) has had all Skype's features for years (including PSTN connectivity). The *only* thing Skype did was allow audio to be proxied. Yes, that's their only interesting feature. Had MS simply done that, perhaps Skype would never have surfaced. I remember the first time I heard about Skype. Someone IM'd to tell me to download it so we could voice chat instead of IM. I was really puzzled and pressed the Audio button in Messenger and asked “Like this?”.

Apart from the audio proxy problem, many users just didn't know that audio chat in Messenger exists. I don't know people can miss this, but whatever... Just like some folks are pretty amazed at what Netmeeting can do... even more so when I say it's from 96. Microsoft simply failed to market these features. Now they have to play “catchup” and do announcements like “VoIP will be in Messenger Live!”... That's just.... lame.

Speech Server
Speech Server seems pretty cool. Indeed, multi-modal app development and, well, speech recognition, are pretty cool. However, instead of making a killer product that allows you to build whatever app your mind dreams of, they tied themselves to horrid hardware, essentially rendering this product way more expensive and inaccessible. Intel Dialogic? Please. SIP is only available as a 3rd party addon. I asked around to find out more about what MS's plans for VoIP application development are, and there's nothing too interesting (say, the level of what I can easily do with Asterisk and C# today) for at least another year. Maybe MS has some secret surprises, especially in light of the rising VoIP hype. Even so, I hate seeing MS have to react in these scenarios instead of leading.

Where Microsoft should be looking
People tell me that VoIP isn't MS's core market. I don't know about that. Voice communications are a huge hub of daily life. Up until now, this was relatively inaccessible to Microsoft. But with Windows 2003 having great reliability, CPUs now fast enough to easily handle several T1s of voice, packet-switched voice, cheap TDM interfaces -- it's now completely accessible. (Asterisk has proven this.)

Business
On the business side, Exchange and Live Communications Server seem to want to jump right into this market. I see no reason why there shouldn't be a Microsoft PBX product. The biggest hurdle is getting a decent hardphone vendor to play along. (Although, Microsoft absolutely rocks when it comes to interface hardware, so I'm sure a hardphone from MS would win awards.) Really, why shouldn't our IM/email/voice/etc. systems be all nicely integrated? I'm quite sure MS will get into this space, even if it takes several years and an acquisition to do so.

(Heck, if MS wasn't so damn late to the scene, they could have designed a good VoIP protocol. As is, we'll probably end up having to live with that abomination named of SIP for the next two decades or so. )

Home
Seeing how MS is so desperately trying to get into things such as your living room (Xbox and Media Center), I don't see how taking over voice seems so far fetched (I heard a rumour about Xbox offering VoIP anyways). Voice fits in perfectly with the “eHome“-digital-lifestyle that MS is trying to own.

Developers
Of course, everyone knows the path to victory lies with developers. And everyone recognizes that Microsoft is king in that arena (save the few Delphi fans who don't realise Anders now works for Microsoft). Microsoft needs to have a very comprehensive and complete set of VoIP (both Video and Voice) APIs and *services* that make it easy to integrate into both Windows and web applications.

For instance, it should be trivial for someone to write a program that allows customers to call in and check their order status via phone (trivial in dev effort, upfront costs, and service setup). Connecting a user via voice, be it via PSTN or direct-VoIP, should be easy. The littlest of VB developers :) should be able to do this without spending much time at all. And then, MS should market the heck out of it so people realise this functionality is there...

Let's see how long it'll take Microsoft to get to that point.

Microsoft and VoIP http://www.atrevido.net/blog/PermaLink,guid,c116e749-d9bd-4275-9c14-0197556b711e.aspx http://www.atrevido.net/blog/2005/12/27/Microsoft+And+VoIP.aspx Tue, 27 Dec 2005 02:07:40 GMT <p> I love Microsoft products (except DRM-crippled products... more on that later). So, it hurts me when MS doesn't play its full potential. Area of this time: VoIP.<br> <br> I've been doing VoIP full-time for over a year and a half. Not exactly a long time, but not too short in this market. I think a lot of people miss the most important part of VoIP. The use of packet-switched versus circuit-switched goes way beyond being able to use cheaper transit and hardware. The real power that IP brings is that the shift can move from hardware to the software. As VoIP platforms become available, the power shifts because voice is finally something every developer can control. This goes back well&nbsp;before the current wave of VoIP-craziness and super-inflated company valuations.<br> <br> Microsoft was here quite some time ago. NetMeeting was released in 1996 and had a decent API (Well, I've not used it, but the docs seem to indicate a lot of power). Messenger continued this (well, except I don't think the API allows you to do anything interesting). So Microsoft was certainly there back then; this isn't a completely new territory.<br> <br> Software means no needing to spend $$$$ on all sorts of features. For instance, many vendors sell a &#8220;voicemail module&#8220; at a decent price. What exactly is a voicemail module? Isn't it nothing more than a simple IVR + recording function? Sigh.<br> <br> <strong>Skype</strong> <br> Hence, you might now understand why I think Skype is silly, or more to the point, MS screwed up again. Messenger (and NetMeeting before that) has had all Skype's features for years (including PSTN connectivity). The *only* thing Skype did was allow audio to be proxied. Yes, that's their only interesting feature.&nbsp;Had MS simply done that, perhaps Skype would never have surfaced. I remember the first time I heard about Skype. Someone IM'd to tell me to download it so we could voice chat instead of IM. I was really puzzled and pressed the Audio button in Messenger and asked &#8220;Like this?&#8221;. <br> <br> Apart from the audio proxy problem, many users just didn't know that audio chat in Messenger exists. I don't know people can miss this, but whatever... Just like some folks are pretty amazed at what Netmeeting can do... even more so when I say it's from 96. Microsoft simply failed to market these features. Now they have to play &#8220;catchup&#8221; and do announcements like &#8220;VoIP will be in Messenger Live!&#8221;... That's just.... lame.<br> <br> <strong>Speech Server<br> </strong>Speech Server seems pretty cool. Indeed, multi-modal app development and, well, speech recognition, are pretty cool. However, instead of making a killer product that allows you to build whatever app your mind dreams of, they tied themselves to horrid hardware, essentially rendering this product way more expensive and inaccessible. Intel Dialogic? Please. SIP is only available as a 3rd party addon. I asked around to find out more about what MS's plans for VoIP application development are, and there's nothing too interesting (say, the level of what I can easily do with Asterisk and C# today) for at least another year. Maybe MS has some secret surprises, especially in light of the rising VoIP hype. Even so,&nbsp;I hate seeing MS have to react in these scenarios instead of leading.<br> <br> <strong>Where Microsoft should be looking<br> </strong>People tell me that VoIP isn't MS's core market. I don't know about that. Voice communications are a huge hub of daily life. Up until now, this&nbsp;was&nbsp;relatively inaccessible to Microsoft. But with Windows 2003 having&nbsp;great reliability, CPUs now fast enough to easily handle several T1s of voice, packet-switched voice, cheap TDM interfaces -- it's now completely accessible. (Asterisk has proven this.)<br> <br> <strong>Business</strong> <br> On the business side, Exchange and Live Communications Server seem to want to jump right into this market. I see&nbsp;no reason why there shouldn't be a Microsoft PBX product. The biggest hurdle is getting a decent hardphone vendor to play along. (Although, Microsoft absolutely rocks when it comes to interface hardware, so I'm sure a hardphone from MS would win awards.) Really, why shouldn't our IM/email/voice/etc. systems be all nicely integrated? I'm quite sure MS will get into this space, even if it takes several years and an acquisition to do so.<br> <br> (Heck, if MS wasn't so damn late to the scene, they could have designed a good VoIP protocol. As is, we'll probably end up having to live with that abomination named of SIP for the next two decades or so.&nbsp;)<br> <br> <strong>Home</strong> <br> Seeing how MS is so desperately trying to get into things such as your living room (Xbox and Media Center), I don't see how taking over voice seems so far fetched (I heard a rumour about Xbox offering VoIP anyways). Voice fits in perfectly with the &#8220;eHome&#8220;-digital-lifestyle that MS is trying to own.<br> <br> <strong>Developers<br> </strong>Of course, everyone knows the path to victory lies with developers. And&nbsp;everyone recognizes that Microsoft is king in that arena (save the few Delphi fans who don't realise Anders now works for Microsoft). Microsoft needs to have a very comprehensive and complete set of VoIP (both Video and Voice) APIs and *services* that make it easy to integrate into both Windows and web applications. <br> <br> For instance, it should be trivial for someone to write a program that allows customers to call in and check their order status via phone (trivial in dev effort, upfront costs, and service setup). Connecting a user via voice, be it via PSTN or direct-VoIP, should be easy. The littlest of VB developers :) should be able to do this without spending much time at all. And then, MS should market the heck out of it so people realise this functionality is there... <br> <br> Let's see how long it'll take Microsoft to get to that point. </p> <img width="0" height="0" src="http://www.atrevido.net/blog/aggbug.ashx?id=c116e749-d9bd-4275-9c14-0197556b711e" /> http://www.atrevido.net/blog/CommentView,guid,c116e749-d9bd-4275-9c14-0197556b711e.aspx VoIP