Wednesday, March 19, 2008 2:16 AM/EST
At the VON.x conference in San Jose, Calif., Polycom let me play with their latest voice over Wi-Fi phone -- the Polycom SpectraLink 8002 Wireless Telephone. Intended for small-business customers, the phone is intended to be easier to set up and manage -- and cost significantly less -- than its higher-end SpectraLink cousins.
Designed to work with SIP-based voice systems, the 8002 has been certified interoperable with Digium's Asterisk Business Edition IP PBX and is expected to work just as well on any of the other Asterisk distributions available nowadays.
The 8002, which costs $349 (or $399 with a dual charger and an extra battery), weighs in at 4.2 ounces and is rated for 3 hours of talk time or 50 hours of standby time.
The Wi-Fi radio in the 8002 is only 802.11b, so the customer needs to make sure legacy protocol support is enabled on the Wi-Fi network. Built to work easily on the consumer-grade access points often found in the smallest businesses, the phone also only supports WEP and the PSK versions of WPA or WPA2 for wireless privacy. And for wireless quality of service, the 8002 supports WMM but not the SVP protocol that SpectraLink pioneered for higher-end wireless networks.
Device configuration looks like it can be done a couple of ways, but honestly it seemed like none of the Polycom people I talked to at the show quite knew the full story. Here's what I can decipher:
- The phone supports TFTP, so the SIP configuration can be downloaded directly to the phone when it joins the network.
- Wireless network configuration can be done either directly on the handset via the keypad or, alternatively, via a PC when the phone is connected to an administrator dock that is USB-tethered to the computer. It does seem that this admin dock is a different device than the charging cradle that comes with the phone.
Polycom also claimed that the 8002 offers text messaging via support for Open Application Interface v2.0, but they did not have this feature set up on the demo unit I played with, so I cannot verify this at this time.
Polycom's people also briefed me on the same video integration with Microsoft's Office Communications Server 2007 and IP application suite that Paula Musich reported on. I won't rehash, but will add a couple of additional details Polycom provided in response to my questions:
- The suite of applications will only work on Polycom's SoundPoint IP 550 and 650 phones for the time being.
- The call recording capabilities do not yet include any kind of audio notification to the participants on the call, but the feature has been requested and development is in the works.
Tuesday, March 04, 2008 4:23 PM/EST
Today, Texas Instruments (TI) announced support for Microsoft's RT Audio codec in their Voice over IP chipsets, paving the way for an influx of new devices that work with Microsoft's Office Communications system 2007 Unified Communications platform - and much greater choice for customers thinking about deploying Microsoft's platform.
As I noted previously in my review of OCS 2007, RT Audio is an adaptive codec. In high bandwidth situations, the codec is in a wideband mode, offering HD Audio quality. But in lower bandwidth situations, the codec scales back to narrow-band and standard definition voice quality automatically - which requires less network bandwidth. In both modes, I found the codec provided good audio quality without taxing my client machine's resources significantly (even with the signal processing done in software).
But With the codec integrated into TI's DSPs (Digital Signal Processors), OEMs can now rapidly produce a variety of different devices to work with OCS - from desktop phones to mobile phone to trunk gateway devices.
In the press release, TI's General Manager of Communications Infrastructure and Voice Business, Brian Glinsman said, "By working closely with Microsoft to include their wideband codec into TI's VoIP solutions, we are supporting the dissemination of unified communications solutions to the market and further enabling Microsoft to quickly meet the application demands of service providers, enterprises and SMBs."
TI's DSPs supporting RT Audio should be available mid-year.
Tuesday, February 12, 2008 4:59 PM/EST
Unified Communications products like Microsoft Office Communications Server 2007 make it pretty simple to integrate the video experience into a user's daily routine, requiring only off-the-shelf Web cameras to layer on the new communications channel.
But what quality of video are you really getting with this kind of integrated solution? Will it meet your needs and expectations?
In my tests of Office Communications Server, I learned from Microsoft's Quality of Experience Monitoring Server that video calls use Microsoft's RT Video codec. By default, I found person-to-person calls had a 352-by-288 resolution at a frame rate of 14 frames per second--when the call is placed over a LAN.
Qualitatively, the video picture looks fine in the small Office Communicator box that is normally shown on the screen. But when blown up to full screen size, I could see some slow transitions and artifacts, and I could definitely tell that the lip synchronization of video and audio was not that great.
The video quality is certainly not up to the standard of high-definition audio we get from Office Communications Server, which uses a wideband RT Audio codec on fast network connections--and sounds excellent and clean. But again, the video quality is not too bad on a small screen, especially if you don't come to the game expecting the best quality.
On the other end of the spectrum, there are some really fabulous high-definition video alternatives out there that also rely on software rendering--not hugely expensive dedicated A/V rendering hardware. But these software solutions come with their own kind of costs.
Take for example the HD video experience offered by GIPS (Global IP Solutions)--which has HD video capabilities in both its two-way VoiceEngine products and multiparty ConferenceEngine line--and uses both its own proprietary LSVX codec as well as standard codecs like H.264. Global IP Solutions first demoed at the Fall VON conference in 2007, and I got to see it up close in person last week at the company's offices in San Francisco.
In my demo, the video stream--at 30 frames per second--had a resolution of 960 by 720. This translated to a truly stunning picture--so clear that I was literally able to count the bricks in the side of a building half a block away when we pointed the HD video camera (a pretty high-end Sony HD camera, by the way--not some Webcam) out the window. And the lip synch between audio and video was practically perfect, making it much easier to carry on a conversation without getting distracted by slightly out-of-sync behavior.
The company claims it can scale up to a full HD picture as well.
Of course, the tax in this case is computational. During the demonstration, the quad-core server doing the rendering on my end of the call was clocking in at a hefty 55 percent overall utilization--something that would be even higher for full HD. The company claims to have done significant work to optimize its rendering for Intel processors, and it claims testing on AMD platforms will also be done in the coming weeks, with the expectation that rendering performance will at least be in the same ballpark.
GIPS sells its own products, or you might find its technology in other products. For instance, I know that Toktumi is working on integration with GIPS' REX softphone (which I will be reviewing soon), and yesterday, RADVision announced that it will be using GIPS codecs and features from the VoiceEngine platform as well.
Tuesday, January 08, 2008 4:19 AM/EST
The first day of CES saw some cool wireless developments (new chip sets, more 802.11n), and a major reawakening of the personal NAS space (everyone under the sun seems to have an appliance coming soon). The day was also marred by bad shoes and some unfortunate static discharge.
Of the non-visual accounts, SanDisk showed me its technology preview of a 12GB MicroSD card. Yes, it works. However, SanDisk isn't going to sell it. The company is just proving it can, and will wait until the next step up (16GB) to release a product.
And now for some pictures:
I've got a review of the Syspine version of Microsoft's Response Point coming online any day now. Here's the D-Link iteration: DVX-2000MS Appliance (top), DPH-124MS (middle) and DVG-3104MS Analog Trunk Gateway (bottom).
Mio was showing its concept design of integrated GPS and Tri-band phone. Big deal, you say? This one is two-faced, hence the name Dual-Sided NAV Phone.
Netgear announced 18 new products at CES this year. I'm going to talk about the wireless stuff in a separate post later, but Netgear also had some new NAS appliances. Lots of protocol support (Samba, NFS, Bonjour), and xRaid technology to autoconfigure the RAID, allowing online volume expansion. At top, the four-bay RND4000 ReadyNAS NV+. At bottom, the two-bay RND2150 ReadyNAS Duo.
The Nokia booth was bustling with activity every time I passed, as the booth had many display units available for hands-on play (very Apple Store). However, all that traffic was really messing with the carpet in Nokia's booth, which was shedding like long-haired cat. After scooting across the carpet to try out a phone, I got a huge static shock as I picked up the device -- causing me to scurry away before I could find out whether I had killed it.
During a chat with folks from the Wi-Fi Alliance, I was shown this sample of a new 802.11n chip set meant for mobile phones. Atheros and Broadcom aren't showing any mobile-N chips (I talked with them), but RedPine is.
Otterbox has some new ruggedized cases for the iPhone. This one, which has a hardened shell under a separate rubber skin, took me almost 10 minutes to crack open. There's also a waterproof one.
Zyxel was showing the new version of its WiMax base station for Sprint (top, middle). The booth people didn't seem wild about the fact that I kept calling it "the coffee maker." Zyxel also has a new version of its SIP phone (bottom).
At Showstoppers, I ran into Yoggie -- whose original device I quite liked last year. Now Yoggie has announced a slimmed-down, firewall-only device called the FireStick Pico.
Before my day really got started, my shoe completely fell apart even though I've only worn that pair four or five times so far. Thankfully, the good folks at Broadcom were handy with the duct tape.
Thursday, December 13, 2007 2:42 PM/EST
Updating yesterday's post about Raketu's Flash-based Voice over IP application for the iPhone, I've been trying to get an answer from the company about why on earth they would release a Flash-based program for a device that does not, and currently can not, support Flash.
Has anyone over there actually ever used an iPhone or an iTouch? This shortcoming is not news.
In lieu of an answer, I received word from Raketu that they have updated the http://iphone.raketu.com webpage to a non-Flash version by default (which is the same thing as the http://raketu.mobi link I looked at yesterday) to avoid confusion.
Just for kicks, I used my PC to take a look at the Flash version of the site, to see if anything was substantively different than the non-Flash-enabled page.
Short answer? Not really.
I could place the same kind of station to station calls as before, although the Flash version actually tells me how much it costs.
Or I could send an email (for free).
Or an SMS (for 5 cents domestically).
It is worth noting that you must configure your Raketu profile with your correct email address in order to receive replies from messages sent via Raketu. Otherwise, any replies will simply disappear into the ether - or in our case, annoy Raketu's support personnel (my default email address was support@raketu.com for some reason.)
SMS on the other hand, seems to send messages only from "839-60" instead of the mobile phone number I configured in my profile. So at this time, it does not look like anyone can respond to an SMS sent via Raketu.
*Update: According to Raketu support the SMS problem "is a problem with carriers in the USA. If you send the SMS to someone for example in London, it will pick up the correct number. Unfortunately, we cannot adjust this. If you send it to Canadian phone it works also fine...the problem is JUST US carriers."
Wednesday, December 12, 2007 6:28 PM/EST
I was pretty excited to see Raketu's announcement yesterday of a Web-based VOIP (voice over IP) service that works for Apple's iPhone or iTouch handheld devices. Visions of unlimited VOIP calls over Wi-Fi danced through my head with sudden surplusses of rollover minutes in my future. Unfortunately, the service is not quite what I expected.
When I used my iPhone's Safari browser to visit Raketu's website at http://iphone.raketu.com, all I could see was a tiny blue Lego with a couple of question marks on it. Apparently, you need Flash installed to view Raketu's iPhone site, which is pretty funny since the IPHONE DOESN'T SUPPORT FLASH!!!
Here's what the site would look like if the iPhone supported Flash:
Raketu's PR guy told me to try their mobile site, www.raketu.mobi, which provides access to their web-based platform, RakWeb. From there, I could not place a VoIP call using my iPhone (as I had hoped this meant), but rather I could use RakWeb to initiate a VoIP-enabled phone call between two different numbers. For instance, I could have RakWeb my dial my AT&T number (for my iPhone) and then my eWeek desktop phone into a two-party VoIP-enabled conference. RakWeb would dial one number, then the second. Then presto! A phone call.
Still uses my mobile minutes, though.
While I can't say I actually found the service useful at present, but it seems like a good way to connect random people together in a conversation without telling them in advance. Like taking blind dating to stalkerish extreme.
Rakweb does offer some interesting SMS options, but I can't say I've ever been prodigious enough with the texting to go beyond my standard allotment.
(On a side note, I beg you, Raketu, please code your download page to render properly in Firefox. Please?!!?!)
Tuesday, December 11, 2007 3:36 PM/EST
Cisco and Microsoft have made their moves to attract small business customers to IP-based voice communications, seriously changing the dynamic in a marketplace previously under-served by a hodgepodge of networking, open0source and lesser-known VOIP (voice over IP) companies. Specifically, the new products -- Cisco's Smart Business Communications System and Microsoft Response Point -- are intended to set small-business customers' bar of expectations for features, ease of deployment and simplified cost structure.
I just completed a review of Cisco's Smart Business Communications System. Cisco's done a lot of work here -- taking its existing technologies and repurposing them for the smaller end of the market, without making many sacrifices in terms of features. SBCS is a reseller's delight, as Cisco has simplified pricing structures and made ongoing management easier for VARs, while hiding all the complexity from the customer -- making the reseller an essential partner.
Interestingly, Cisco also owns Linksys, which also has small-business-oriented voice systems available. When I asked Cisco's Eren Hussein, senior manager for SMB solutions, about how Cisco differentiates the different technology families it has in the marketplace, he said:
"SMB as we know it is a large and diverse market. Anywhere from the corner donut store to a small brokerage is all considered within the category of small business customers. Clearly they have very different needs when it comes to their IT requirements. We feel Cisco is uniquely positioned to serve this large market opportunity with a set of products that can address the specific requirements of any small business customer. We truly see that we will position all the assets Cisco has. The Linksys products are quality products in their price span. But the traditionally branded products are for customers that truly value what their IT spend is -- customers that have an aspiration to look and behave like a larger company, to use IT to help run their business better, to have a better presentation and responsiveness to their customers. With SBCS, we are leveraging the key assets Cisco has developed over decades, purpose building it for the right fit and function to serve these customers."
Microsoft's taking a slightly different route, putting together the software, and relying on OEMs (D-Link, Quanta) to build and deliver the appliance with the software pre-installed. The end result looks to have fewer features overall than Cisco's products, but allows more customer self-reliance in managing the system, and a much lower price point.
Look for the Response Point review (on Quanta hardware) next week, and feel free to offer your comments on Cisco's SCBS below.
Tuesday, October 16, 2007 7:30 PM/EST
I've been testing Microsoft's Office Communications Server 2007 in our San Francisco labs for the last couple of weeks. We will have a review online later this month, but in the meantime I've posted some screen shots here, to go with related coverage from Microsoft's launch event in San Francisco.
My early impressions are that OCS provides a very intuitive platform for person-to-person integrated communications, as everything stems from the familiar (ribbon interface not withstanding) confines of Microsoft Office. Users should be able to quickly learn how to navigate between different communication channels, picking up how to take advantage of the new presence features to skillfully migrate communications from e-mail to IM to voice to video.
OCS is meant to be a PC-based experience, allowing the user full convergence between e-mail, IM, voice, video and conferencing, and as a result Microsoft hasn't done much to support most desktop or voice-over-Wi-Fi phones at this time. If you want to use more traditional telephony equipment, you will need to integrate OCS with it via SIP (Session Initiation Protocol trunks. Nortel is one telephony vendor that has bought in fully to Microsoft's Unified Communications strategy, and it has spent a lot of time fine-tuning interoperability between OCS and its IP PBX line. Nortel also has some interesting-looking desktop phones with large screens on the way that are tailored for OCS.
However, the overwhelming complexity of Microsoft's solution will be daunting for most companies, as the installation is pervasive, touching the central Active Directory, the Exchange deployment, (potentially) all desktop clients, and even SharePoint and SQL Server. A trusted partner will almost certainly be a must for this job, so implementers should be advised to look for channel partners with extensive experience both with Microsoft domains and their particular telephony providers (if the implementer is planning to integrate).
Our test deployment was daunting enough that Microsoft needed to come to our labs for two days to facilitate the installation, and we weren't even trying to integrate with an existing phone system. Microsoft's engineers actually prepared the entire environment beforehand using virtual machines (a total of six Windows Server 2003 virtual clients), which were then deployed on eWEEK's hardware. I added all the client machines (a mix of Windows XP and Windows Vista machines, all running Office 2007 Professional) and desktop peripherals from there. Over time, I'll try to work legacy versions of Office into the mix as well.
Even with this pre-installation and pre-configuration, it took a lot of tinkering to get the system up and running. Most of the installation problems actually involved the analog trunk gateway, an AudioCodes four-port gateway (2 FXO/2 FXS) that we used for connectivity with the PSTN (Public Switched Telephony Network), where a slight misconfiguration was torpedoing our ability to process incoming calls.
One thing that is currently missing from my OCS testbed is Microsoft's analytics component. By default, Microsoft is using its own codecs for high-definition voice support, and it is also encrypting the comm traffic around the enterprise, which will severely limit the usefulness of voice quality assessment tools with OCS. Instead, Microsoft has opened a server-side API for communications analytics to plug in for call-logging details, and it has also released its own analytics engine. Unfortunately, I have yet to obtain this code (or virtual machine) from Microsoft, despite repeated requests.
Coming on the heels of the OCS launch, I expect to see numerous announcements from Microsoft partners in the next few days that could enhance Microsoft's base solution while adding to the overall noise about OCS. Among the ones that have crossed my desk in the last few hours:
Nortel -- phones, handsets, application switches, conferencing, Converged Office
CallRex -- IP recording
Communicado -- managed communications (for enterprises, SMBs or VARs)
AudioCodes -- hybrid gateways
Tandberg -- video
Foundry -- Applications Delivery Switches
NEC -- handsets, gateways, middleware
Securent -- management and enforcing of access control policies
Wednesday, September 05, 2007 2:36 PM/EST
Thanks to Engadget's real-time blog, I've been following along with today's Apple announcements without taking the trouble of walking the four blocks to the Moscone Center. I didn't think there would be any enterprise spin to the announcements, and on the surface that thought has proven correct. But the announcement of the new iPod Touch got me thinking about Apple's burgeoning interest in mobile communications.
The new iPod Touch models (an 8GB model for $299, or 16GB for $399) look almost identical to the iPhone, just slightly skinnier. The device appears to have the same layout, and the screen has the same features and some of the same icons.
At this point, I am presupposing that the Touch runs OSX -- just like the iPhone. To reduce costs, Apple will undoubtedly be using many of the same parts in the Touch as in the iPhone -- the touch-screen, processors, storage components, etc. I'm presuming the same applies to the operating system, as Apple would benefit from having a single OS and development platform to work on for both the iPhone and the Touch.
Like the iPhone, the Touch also has 802.11b/g Wi-Fi, which could prove an excellent way to get around the unfortunate AT&T exclusivity contract with which the iPhone is saddled. The Touch also has Apple's Safari browser and the same virtual keyboard, so users can expand their connectivity to networks protected by a captive portal or log-in page.
So if the Touch indeed is running OSX, it stands to reason that the various Jailbreak applications can be easily adapted to hack into new Touch, leading to a host of unauthorized applications on the device. One application I am particularly interested in would be a SIP (Session Initiation Protocol) client application that utilizes the Wi-Fi connectivity. It would be the next logical step in Apple's evolution toward mobile communications.
However, I'm not so sure Apple will want to cross AT&T for this particular feature, however, at least not until there is a viable business model that could be attached to the capability. So while I would much prefer to see Apple actually include a widget for a SIP VOIP (voice over IP) platform, it seems more likely that the community at large will lead the way with a SIP client application, possibly something that would work with the Gizmo network.
All this hinges on one detail I have yet to be clear on. Will the iPod Touch have a microphone? If Apple is indeed using many of the same parts on the Touch as on the iPhone, then it is possible that a microphone is in there and that it can possibly be unlocked in software.
If its not in there, however, this whole argument is moot for the Touch -- although I would still love to see it for the iPhone. In truth, it may be the only application that would make me want to hack into mine.
Tuesday, September 04, 2007 4:01 PM/EST
I recently brought Polycom's SoundPoint IP 550 and 650 phones into the lab as part of a wider look at the benefits of high-definition VOIP (voice over IP). Although the G.722 codec Polycom uses to achieve HD Voice is not widely supported at this time, Polycom promised that the open-source Asterisk project would support it, so I decided to see exactly what it would take to get the technology up and working with our in-house Asterisk deployment.
Starting with Version 1.4, Asterisk supported the G.722 codec in passthrough mode only. This means that Asterisk can set up a G.722-enabled call between two endpoints that support the codec and then get out of the way, but the server cannot transcode the streams between different codecs for devices with mismatched support. And while Polycom officials are investigating adding support for other wideband codecs, G.722 is the only one supported at this time.
To enable G.722 in Asterisk (our server is based on Version 1.4.9), I simply needed to add a single line to the sip.conf configuration file (allow=g722). I then had to configure each Polycom phone with G.722 as the codec with first priority. With these changes in place, I could place calls between my SoundPoint IP 550 and 650 devices and experience all the audio quality I expected from HD Voice.
However, interoperability with legacy devices was another story. While I could place calls from a non-HD Polycom SoundStation conference phone to an HD Voice-enabled phone using G.711, I could not complete a call in the reverse direction. The Asterisk server would show an error indicating congestion on the server, and the caller would experience a fast busy signal.
It turns out that Asterisk 1.4 cannot handle the codec negotiation necessary to complete the call between an initiating caller with priority for G.722 and a receiving caller with priority for another codec. "Asterisk's codec negotiations currently treat the call legs independently, and thus never renegotiate the initial call leg based on the requirements of the secondary call legs," said Digium Director of Software Development Kevin Fleming.
Asterisk users can look to the bleeding edge for a resolution. "In the Asterisk SVN trunk, we have a G.722 codec module, so this problem would not occur, and we'll be putting that module into ABE [Asterisk Business Edition] as well," Fleming said. "We may also put it into future s800i [Asterisk Appliance] builds."
In my communications with Polycom about this issue, I learned that the company has achieved expected codec negotiations when using an SVN trunk of Asterisk. While this feature will likely not be part of Asterisk Version 1.4, users should be able to look forward to full support in Version 1.6 down the road.
|
