Let the hive mind of Engadget get that for you.
"I own an iPhone 3G and I'm looking for a decent speaker / alarm clock for it. I am going to listen music in a mid-sized room, so I want nice quality speakers with solid bass. I also want to use it as an alarm clock, so it would be great if there is such a feature. The price can be low-mid to mid-high range. I was looking at the Klipsch iGroove SXT; it's powerful, slick and the reviews are good, but it doesn't have an alarm clock feature. It's no deal breaker if I can set it up from the iPhone, but I'm not sure. Thanks!"
What it CAN do (within the SDK parameters) is allow you to do the following:
Just like Grand Central, you go to iCall's site and get an iCall Pro account -- that also has an incoming number (this is standard with iCall Pro).
Then, using their web interface, forward any calls to your iCall PRO number to the (in the US) AT&T cell # on your iPhone. The friend then calls the iCall # -- NOT THE AT&T CELL NUMBER.
The call automatically gets xferred to the cell service if you are not at a hotspot.
Your iPhone rings and you answer what is a call that actually came into their pool of numbers...not AT&T's.
When you go somewhere that you have wifi, the iCall client then senses a wifi connection and offers to continue the call using VOIP. This, they CAN do cos the caller called the iCall Pro incoming phone number to begin with, so iCall puts the caller on hold for a microsecond, disconnects from the AT&T network and connects it to the VOIP over WIFI network back to the iCall app on your iPhone--thus the cell-minute charge stops.
Neither you nor the caller SHOULD hear a thing -- other than minor clicks or garble for a microsecond.
That is the only thing they can do. They CANNOT intercept a call that you placed using the AT&T network seamlessly. They CAN offer to redial the user on the other end of the call on iCall's VOIP WIFI network, but the user on the other end must have either call-waiting or must hang up. That is why the menu says "iCall has detected an INBOUND call in process...". It is simply that they know cos the caller called their pool of #'s.
Simple, really.
What I am NOT sure of is whether Apple's SDK allows them to terminate a voice over cell call -- or whether Apple's T&C's cover this. Not a biggie...but I would be surprised if they allow apps to do this.