Monday, September 29, 2008 2:28 PM/EST
In an effort to resolve the mystery surrounding the poor talk time performance of the Treo Pro smart phone I've been reviewing, Palm sent me a second unit that was waiting for me when I returned from my recent vacation. While I was able to prove that the GSM radio works properly in this second device, I still found the Treo Pro provided terrible talk times when connected at 3G speeds.
Once again, I could only squeeze out about 2 hours and 40 minutes of talk time when connected at the faster rate on the AT&T network -- significantly below the 5-hour rating Palm claims for the device in its specification sheets. And this time measurement occurred with the phone set to autoconnect to the best available network -- not forced to 3G. (By way of comparison, the Nokia E71 got about 4.5 hours when forced to 3G and over 12 hours when set to autoconnect.)
Understandably, Palm's representatives are more than a bit concerned about my findings. They said Palm would never release a phone with battery performance that poor into today's marketplace. They also claim (and some cursory online research seems to confirm) that no other reviewers have experienced performance this poor. Yet I've seen it on two Treo Pros now.
To try and figure out if the performance was related to something in particular with the AT&T network or the cell around eWEEK's San Francisco offices, Palm sent out an engineering team last week to scan the environment and run its own tests on the network.
I haven't gotten the full report on their findings (and probably won't for a couple more days), but early indications are that the Palm engineers also experienced unusually high battery consumption when performing tests in the lobby of our building -- but not when testing from the sidewalk right outside. Unfortunately, the team did not come up to our 9th floor offices to get a full measure of the network conditions where I conduct each and every battery test we perform.
With the Treo Pro available for sale from the Palm Web site as an unlocked device (as of Friday, Sept. 26), perhaps we will start to see word soon as to whether users are experiencing results similar to what I'm seeing. In the meantime, I will continue to wait for Palm's findings.
One way or another, however, the review will be online later this week.
Friday, September 26, 2008 6:52 PM/EST
Free and open just met free and closed. But the introduction of the two will come with a price tag on it.
This week during Digium's Astricon conference in Glendale, AZ, Digium and Skype announced Skype for Asterisk - granting Asterisk PBX users the ability to leverage Skype for both outbound and inbound calling.
Users on an Asterisk-based VoIP system will be able to place calls to Skype users for free from their desktop phones. Likewise, Asterisk users will be able to receive calls from Skype users on their desk phones.
Users can also gain some benefits of least cost routing, as administrators can configure Asterisk to route international calls via SkypeOut to save a little coin on long distance bills. Telephony administrators can buy and manage the allocation of SkypeOut minutes to Skype users via Skype's Business Control Panel.
The partnership could also ease the integration of voice services into a company's web site. For instance, web site administrators could place a button the company web site to call the company, triggering a Skype call (or Skype download and install) to the company that can be routed into the corporate phone system - to a receptionist, sales person, or whoever else may be appropriate.
The Skype for Asterisk integration occurs through an add-on channel driver module that needs to be installed on an Asterisk server (running either Asterisk 1.4 or 1.6). This connector will not be open source and will be for-pay, as the software will be available for purchase directly from Digium or from some Asterisk system integrators. Although pricing has not been announced as of yet for the connector, expect the price to be based on how many concurrent channels will be needed to bridge between the Asterisk implementation and the Skype network.
PBX integration for Skype calls is not new, as companies like VoSKY have offered appliances that provide Skype trunks to PBX implementations for a couple years now. However, Digium representatives claim that the Skype for Asterisk integration will scale much better, and is expressly designed to handle multiple concurrent Skype channels.
Skype and Digium are staging product availability for the time being. Interested parties (whether you are a company using Asterisk or a system integrator reselling it) can register for the private, stage one of the beta here. Later on, there will also be a public beta - but there is no announced time frame for that yet.
Digium's CEO Danny Windham encouraged me to sign up for the private beta and write about the process, so I hope to be testing the integration soon.
Friday, September 12, 2008 9:55 PM/EST
I had been hoping to get eWEEK's review of Palm's new Treo Pro smart phone online this week, but testing took an unfortunate right turn, leading us to return the device and wait for a replacement before we could finish the tests. Although I am bummed about the delay, I had a lot fun troubleshooting the issues -- even though I didn't come to a satisfactory conclusion as to what the real problem was.
In a nutshell, the device was getting pretty terrible battery performance on eWEEK Labs' talk time tests -- almost half of what I expected given Palm's published specifications. In my first talk time test, with the radio set to auto-select the best network, the battery only lasted about 2.5 hours, while the specs claimed 5 hours. According to the device indicators, the call was placed over the 3G network. Although the 2.5 hours would be an absolutely terrible result for a 2G phone, it still is poor compared with the 3G results we've seen recently from the iPhone 3G or the Nokia E71.
I didn't think the problem was caused by background applications eating up CPU time because I had done a hard reset on the phone right before testing. Any background services running after that I felt were fair game, since they are automatically loaded on a freshly restored device. The restore also disabled the Wi-Fi and Bluetooth radios. And I didn't think it was the battery, either, since I'd used the device over Wi-Fi plenty in the preceding days, without noticing anything out of the ordinary.
To ensure the battery wasn't draining because the phone was thrashing between 2G and 3G networks, I forced the connection to 3G and tried again. And again, the battery died after 2.5 hours.
Confused and looking for answers, I enlisted Palm's help for troubleshooting at this point. After I explained the tests and everything I had tried in an attempt to resolve the problems (and what I was seeing from Palm's competitors in identical tests, to boot), the company told me that the AT&T network wants to give priority to the 3G network. When faced with a strong 2G signal and a somewhat weak 3G signal as reported by the device, the network nonetheless commands the handset to utilize 3G -- unless the device is manually forced the other way or the 3G signal drops below some unstated threshold. Since Palm's device gets really good reception (the company's claim), it would almost certainly stick to the 3G network better than other devices would, and that extra love to the 3G network would mean worse overall battery performance.
Palm also told me some information that contradicts its claims about AT&T's network a bit -- telling me that not all SIMs are created equal, as some may default home to a 2G network over a 3G (or vice versa). And then I was asked to try the test using the SIM used in the Nokia test. (Note: eWEEK Labs does not have testing accounts with the various GSM-based operators. Instead, we test using the SIM sent to us with the phone.)
Something still didn't seem right with these arguments, since ultimately the Treo Pro's 3G numbers were still pretty poor. Figuring Nokia's PR firm wouldn't be wild about me testing another product on its dime, I tried something else to see if the battery was the culprit. I tried the talk time test again, this time forcing the radio to 2G, figuring that if the result was in the same ballpark, it had to be the battery.
Instead, I found there was something very wrong with the 2G radio. The phone would report an EDGE connection and show the received signal -- four bars in the place I conduct the tests -- but no traffic would actually pass to or from the device. I couldn't place a call, nor could I receive one. No dial tone, no ringing -- nothing. Just to make sure there wasn't a problem with the local cell, I grabbed my gen 1 iPhone and made a call, then downloaded an application from the App Store. I tried placing a call with the Treo Pro again -- nothing.
Not a cell problem, apparently.
I'm guessing there are a bunch of problems with our test unit, and perhaps what I've seen -- the bad talk time performance and the lying 2G indicator -- are just symptoms. The radio problem would not explain the bad battery performance on the test where I forced the connection to 3G. I could see a comatose 2G radio causing the problem when the radio is set to auto-select -- there would be thrashing because the signal detected does not equal the actual traffic that gets through -- but the 3G test was just as bad and there shouldn't be any thrashing in this case.
I guess I will never know what the real problem is. Ultimately, there's something wrong with the phone, and I need to get a review done. Palm is sending another one, and we'll get the review online as soon as we can.
Wednesday, September 10, 2008 3:06 PM/EST
I don't have a work-provided cell phone, but I frequently want to use my personal phone for work. However, I use a personal number on the phone, so I am loathe to give it out to people I don't know that well. Many times I have asked that my cell number get used only in a specific instance, but that request often gets ignored, and suddenly I'm getting cold called.
To solve this dilemma, I've been using Google's GrandCentral for about a year, and I like it well enough despite some obvious flaws it has when used with an iPhone. I can give my GrandCentral number out, and the service looks for me at my desk, my lab bench, my cell phone, and (occasionally) my home number. And with the GrandDialer application that showed up in Apple's App Store a few weeks ago, I can now also easily place outbound calls through GrandCentral without giving up my iPhone's CallerID info.
However, GrandCentral leaves a lot to be desired. Foremost, I can't check my GrandCentral voicemail from my iPhone, because 1) the iPhone doesn't support Flash, which GrandCentral uses for its visual voicemail functionality and 2) the iPhone won't let me download WAV files as the alternative method of message checking. I also can't move in-progress calls between lines.
At the ShowStoppers show in San Francisco last night, I ran across Newber, a new GrandCentral clone designed specifically to work with the iPhone (although I see no reason why support won't be added for other devices in short order). In beta right now, Newber gives the user one phone number to give out - and like GrandCentral, Newber will find you on your iPhone or any landlines you may have pre-programmed. Newber also claims that their software lets you to transfer in-progress calls between your various lines, and Newber will also utilize the iPhone's locationing technology (GPS or the WiFi/cell tower triangulation for Gen 1 iPhones), to identify your lines that are nearby.
No word on what, if any, voicemail services will be available through Newber, but the company is promising better dialing options down the road, allowing users to automatically dial every number you have on file for a contact - to find them with just a click of a button.
The downside, when compared to GrandCentral, appears to be cost. While GrandCentral remains free at this time due to Google's never-ending beta cycles, Newber looks like it will cost $5 a month/2 cents a minute - although I am unclear whether those charges are either/or or cumulative.
Monday, August 18, 2008 6:33 PM/EST
In a column I wrote for eWEEK's print edition (PDF) a couple months ago (Vol. 21, July 7 cover date, page 51) and in one of Ziff Davis Enterprise's Virtual Trade Shows, I speculated on what changes affecting wireless networks would be made in the next iteration of the Payment Card Industry standard. Now, I can stop speculating because the PCI Security Standards Council today, Aug. 18, released the changes we can expect to see implemented in Version 1.2, (PDF) which should be formally released by October.
In a nutshell (for those choosing not to RTFA), I was guessing that the new standard would:
1) stop recommending WEP (Wired Equivalent Privacy) in favor of WPA (Wi-Fi Protected Access)/WPA2, but not ban the use of WEP;
2) stop requiring administrators to hide the SSID (service set identifier) broadcast; and
3) strengthen their requirements regarding the use of wireless analysis tools.
Let's just say, I like being right. However, the standard did set a somewhat unaggressive timeline for the abolition of WEP, a step I did not anticipate. Organizations using WEP and beholden to PCI have just under two years from right now to implement a modern wireless security standard (only nine-and-a-half years after the protocol was first broken!)
Here are some excerpts of the changes that pertain to wireless networks (source here in a PDF):
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
‐ Clarified that the requirement applies to wireless environments "attached to cardholder environment or transmitting cardholder data"
‐ Removed references to WEP in order to emphasize using strong encryption technologies for wireless networks, for both authentication and encryption
‐ Removed requirement to disable SSID broadcast since disabling SSID broadcast does not prevent a malicious user from determining the SSID, as the SSID is broadcast over numerous other messaging/communication channels.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
‐ Wireless must now be implemented according to industry best practices (e.g., IEEE 802.11x) using strong encryption for authentication and transmission
‐ New implementations of WEP are not allowed after March 31, 2009
‐ Current implementations must discontinue use of WEP after June 30, 2010.
Requirement 10: Track and monitor all access to network resources and cardholder data
‐ Clarified that logs for external facing technologies (for example, for wireless, firewalls, DNS and mail) must be copied to an internal log server
‐ Provided flexibility and clarified that three months of audit trail history must be "immediately available for analysis" or quickly accessible (online, archived or restorable from backup).
Requirement 11: Regularly test security systems and processes
‐ Provided more guidance on use of wireless analyzers and/or wireless intrusion detection or prevention systems.
Thursday, July 17, 2008 2:58 PM/EST
As we all know, Apple's got this thing called the App Store that was opened up to users who bought new iPhone 3Gs or upgraded their existing iPhones to software Version 2.0. Six days after the AppStore launch, I've settled in with a core set of applications that are quickly becoming a part of my everyday routine. Below is a quick list (complete with a grade) of what I am running at this moment.
On the iPhone right now:
Remote (A+) -- I had been looking for a good solution for controlling my iTunes without having to look at the PC. After trying out a bunch of paid solutions over the last few years, thanks to Apple, I've finally gotten a nice solution for free. I can redirect iTunes to remote speakers with Remote. Love it. (free)
Pandora (B+) -- I've been listening to Pandora for a couple years now, and have built up some finely tuned music profiles. Now I can take those custom channels with me wherever I have network connectivity, which is great. Unfortunately, Pandora can't run as a background process, so if I want to check my e-mail, I lose Pandora. Even worse, when I go back, I lose the song I was on. (free)
Facebook (C+) -- Decent for creating a new status update, checking in on contacts or starting a chat. Not so good for more rich media-based activities at this time. (free)
Twittelator (B-) -- I'm fairly new to Twitter, so I am sure that this opinion will change as I get more familiar with this app and the service as a whole. But after an afternoon trying Twittelator versus the free version of Twitterific, I found I liked the layout and organization of Twittelator better. (free)
Jott (B+) -- One of many voice recording solutions available in the App Store, this one will send your voice note out to Jott's servers, which convert the recording to text (it takes a couple minutes). Then I can make the text a note or a to-do item. (free)
AIM (B) -- An AIM client ... Decent for quickly logging in and firing off a quick note to a Buddy List contact or for quickly changing my status. Not good for staying online continuously so others may reach me. (free)
SportsTap (A) -- An application that provides quick access to sports scores, statistics, transactions and standings. Choose the sports league you want, then quickly drill down to find fairly up-to-date accounts of what is going on. (free)
Yelp (B) -- Find restaurants near where I am right now, with the ability to drill down into Yelp's extensive collection of user reviews and ratings. The location integration works pretty well, even without GPS, but category searches have turned up some funky results. Like, if I'm looking for Vietnamese food, don't tell me about the Italian restaurant down the block. (free)
New York Times (B) -- A reader for the eponymous newspaper. Looks good on screen, but I've found it a little sluggish -- particularly over the EDGE (Enhanced Data for Global Evolution) network. (free)
Shakespeare (INC) -- The complete works of Shakespeare, right on your iPhone. I can't say I have actually used it all, but I like having it there anyway. I figure it will be good to have when I am waiting at the airport or standing around on the pavement while my girlfriend goes into the Hallmark store. (free)
Mocha VNC Lite (INC) -- I tend to use Remote Desktop more often than VNC, but nonetheless, I figure this will come in handy sooner or later. (free)
Speed Dial (A-) -- In the absence of an integrated voice-activated dial feature for the iPhone, I've been using this little app instead. Speed Dial presents you with a Brady Bunch interface (three by three squares), allowing you to assign a contact to each of the squares, which then display the photo you have on file for that contact. It takes only two presses to dial one of your Brady contacts -- one to open the app, the other to dial. Unfortunately, if you assign one contact's cell phone to one square, then that contact's work number to another square, both squares show the same photo. ($0.99)
Still in iTunes, but not synced to the phone:
Handmark Pocket Express (C-) -- An aggregator pulling together news, sports, weather, financial reports, entertainment, travel and horoscopes into one application. Unfortunately, many of the core applications are still not online. I wanted to use it to check on a flight arrival, but it just pointed me to a Web app. Thankfully, that worked. This one is on my chopping block, and usually lives in iTunes but not on the iPhone, unless I think I might need it that day. (free)
SpeechCloud Voice Dialer (D) -- A voice dial application that uses the network -- it tells you up front that it works OK over 3G or Wi-Fi, but is inconsistent over EDGE. Since I have an iPhone Classic, this is a problem, since I am most likely to use this app in the car and away from Wi-Fi. Over Wi-Fi, I found the name recognition to be passable, but the app can't deal with contacts with multiple numbers assigned. It will pull up all the numbers you have on file for that user, causing you to have to press a button for the right number. (free)
Friday, July 11, 2008 2:46 PM/EST
378 days ago, I spent a chunk of a day waiting in line for the privilege of being one of the first people to carry a brand-new iPhone. Three days later, I actually got to use it, as I was one of the unlucky few (thousands?) to become ensnared in Apple and AT&T activation hell.
With 378 days gone by, millions of iPhones sold, untold profits reaped, and with the next generation hardware and software coming online on the same day, you would think Apple and AT&T would have gotten their act together a little better. Because this year the launch is global, activations were supposed to be done as part of the sales (instead of staggered until the buyer got home), and new device sales and old device upgrades or reactivations will be taking place simultaneously -- the companies had to get it right this time to handle the increased volume of activations. Right?
Uh, wrong.
Proving that AT&T and Apple learned nothing from last year -- or simply didn't care about short-term aggravations for their users -- the activation system and most of Apple's software delivery system has again crapped out. This year, the lucky ones are the ones who haven't gotten anywhere at all in the upgrade process (or those who wisely waited a few days before buying a new iPhone).
Choosing to avoid standing in line this year, I stuck with my first-generation iPhone hardware. That way I could reap the benefits of the new integrated software features and fruitful bounty of the App Store without needing to dish out for new hardware and a more expensive data plan.
I actually started my odyssey with Version 2.0 software July 10, as I jumped at the chance to try out the seemingly gold version (1,2_2.0_5A347) that Apple Watch's Joe Wilcox mentioned was available yesterday. The upgrade to iTunes 7.7 and Version 2.0 went fine, and I was really starting to enjoy some of the new features -- particularly the Exchange ActiveSync and the App Store (Pandora, Yelp and iTunes Remote applications in particular). But when a slightly different version was officially released today (1,1_2.0_5A347), I needed to make sure I was on the public release in order to conduct my review.
When I got into the office, I discovered Cameron Sturdevant had been unsuccessfully attempting to upgrade for over an hour. Downloading iTunes 7.7 was a trial for him, and once he finally was able to install it, iTunes would either error out or tell him he already had the latest firmware.
I tried a different tactic, choosing the Restore option from iTunes. iTunes immediately downloaded the 2.0 gold code and installed it on my iPhone, and I was feeling pretty smart. But after the 10 minute wait for the install to complete, the iPhone got to the reactivation stage -- where it has remained ever since. Cameron is also hung in the same state, since I had given him the 1,1_2.0_5A347 code via sneakernet.
In a disturbing throwback to last year, all we can do with our iPhones is place a 911 call (although this year, the iPhone proudly proclaims this news in seven languages).
In hindsight, it seems like sheer hubris that Apple thought the activation would go smoothly given the problems AT&T had last year, and the large number of things Apple was trying to have happen in a 24-hour period. Apple could have avoided much of the crush by releasing the 2.0 software to existing iPhone users next week. Instead, it almost seems like Apple's execs forgot to account for the fact that they designed the iPhone to reactivate whenever a new software version is installed (or an existing one is restored, for that matter.)
Or as eWEEK Labs Executive Editor Jason Brooks put it so succinctly, "They could have built a network that scales."
In the meantime, eWEEK Labs and our bricks continue to wait.
Again.
* Update(1:01pm): Three is the magic number for activation. Last year, three days. This year, only 3 hours. My anger is somewhat mollified, but the scars from last year still burn, apparently.
Tuesday, June 10, 2008 7:05 PM/EST
When I read Joe Wilcox's Microsoft Watch missive on Apple's use of DRM on AppStore applications for the iPhone, I have to admit, my initial (and continuing) reaction was: "So what?"
What exactly is the reason for the DRM?
It is not to keep people from using the application on other (non-Apple) devices, as this is a nonissue. Since the application is specifically written for the iPhone, which runs an operating system that no one else uses, it's not like you can directly port it over to an AT&T Tilt or BlackBerry.
Maybe the DRM is there to enforce a software license, so, for example, a user can't move the app from their old 4GB iPhone to their brand new 3G iPhone. I don't know whether or not this scenario is true, as the AppStore hasn't come out. But in the past, Apple has not gotten in the way of moving Fairplay-protected content to multiple devices -- as long as the devices are synced to the same iTunes account. And moving it to a device maintained under a different user account would, presumably, violate the software license anyway -- so does it differ in any way from Microsoft Activations and Genuine Advantage?
One may ask that, since no other device can accept an iPhone app, why bother having the DRM then?
Well, I'm sure Apple has its reasons, and here's my guess as to the public one it will offer: It wants to protect the iPhone experience.
Apple implemented the whole SDK and AppStore system so it could control what gets on the iPhone -- and what goes on under the covers. It wants to ensure that applications aren't going to hog CPU, unduly drain the battery or block the core functionality (making a call) of the device at inopportune times. The company has created the whole development ecosystem around the iPhone - and ensured that Apple is the final arbiter of what goes on the device -- in order to protect this experience (and yes, take a cut off any profits that arise from applications).
Without the DRM, Apple quickly loses control of the ecosystem once people start cracking open applications and modifying them to suit their needs. Apple can no longer provide that level of assurance that the battery is not going to run down or the core functionality won't be sluggish due to a runaway process. And while I am surely aware that Fairplay has been broken before, and surely will be again, some protection is better than nothing as far as Apple is concerned.
You know what? I'm comfortable with this level of assurance even if it is (that accursed) DRM providing it. I did not like my iPhone as much when I cracked it because certain applications just killed the device performance and caused crashes. I know that I have different expectations about the ways I can use and consume software versus the ways I can consume media (open-sourced software not withstanding), and I'm not going to take a knee-jerk reaction that DRM = Evil until it passes some litmus test where my rights of fair use are being revoked. With the knowledge we have at hand, I don't feel we've reached that point.
My concerns instead are around what the DRM itself does to the performance of my iPhone. I've heard persuasive evidence that iPod batteries drain faster when playing Fairplay-protected content than when playing a regular MP3. If I spend a lot of time in the DRM-protected AppStore application, will these same symptoms be in effect on my iPhone? Does it even matter, if all the standard applications on an iPhone are likewise protected? Because in that case, the battery drain due to DRM is the norm rather than an exception.
And how does this affect custom applications created by enterprises for in-house use? Does the DRM apply here, and if so, isn't that a good thing, since enterprise developers may appreciate a little more security wrapped around their intellectual property?
Tuesday, June 10, 2008 9:00 AM/EST
In response to last month's interview with Digium CEO Danny Windham, a reader recently contacted me to give his two cents on Digium's newfound interest in small businesses looking for an easy-to-manage-and-deploy telephony system.
The gist of this reader's note (and I am both paraphrasing and assuming a few things based on what he wrote me) was that, while he was happy with Digium's products and support, he felt that the company -- particularly when it comes to the training courses -- was too focused on the hardest-core developers who installed the application from source, managed it the old-fashioned way (via the text configuration files), and had the most know-how to creatively use the software and develop it toward any number of ingenious new purposes. Those customers who just wanted an affordable phone system that they could manage via a GUI were somewhat marginalized and forced to at least explore other options (like Trixbox).
This type of impression is precisely what Digium is trying to combat via last year's acquisition of the Switchvox interface and appliances. Take, for example, a note I received last week from Digium's PR representatives regarding an upcoming Switchvox announcement:
"... Digium will announce a new product for SMBs that completes Asterisk's transition from developer-focused software to easy-to-use communications system for businesses."
The announcement did not quite live up to this type of billing, however, as it did not concern a fundamental change in the way Digium approaches its users, but instead spoke of a new middle tier in the line of Switchvox appliances.
The new AA300 appliance ($4,240 list price) is geared to support up to around 150 users, in a 3U half-depth, rack-mountable appliance that can be installed in a Telco rack. (Digium already offers the AA350 and the AA60 appliances for larger and smaller deployments.) The appliance features the same ease of deployment, management and configuration featured in these other Switchvox appliances -- but the announcement is hardly as compelling as the PR team made it out to be.
Ultimately, my reader wanted to see Digium allocate some of its development manpower toward enhancing the open-source FreePBX management GUI (the powerful GUI that comes bundled with the Trixbox distribution) -- which is maintained by a comparatively smaller cadre of developers. This, over time, would put more power and flexibility in the hands of those who also want a GUI.
Unfortunately for this reader, Digium seems unlikely to spend its development dollars in this specific direction, but the company is taking steps to give GUI contributions back to the community. Right from the start with the Switchvox application, Digium claimed it was planning to contribute some of the Switchvox code back to the open-source community -- and now it appears the company is ready to start making good on that pledge. I didn't get a whole lot of details from Digium's representatives about the code in question, but it sounds like some of Switchvox's reporting capabilities will be the first elements to be set free.
And in the meantime, the reader will be giving the free version of Switchvox a look.
Monday, June 09, 2008 5:44 PM/EST
Forgive me if I've missed this somewhere, but I just realized that I don't recall hearing anything about voice-activated dialing support in the next revision of either the iPhone hardware or software.
Given that Apple is based in California, and California has a new hands-free law going on the books in July, it seems imperative that this feature get fast-tracked ASAP.
Can anyone confirm whether or not this feature is on the immediate road map as a built-in feature or whether a third-party software developer will need to release a product to the App Store?
|
