Comment Re:Without background processes, VOIP not so much. (Score 1) 51
I am assuming this is xferring ONLY YOUR PHONE CALLS THAT ARE INBOUND to your iCall PRO number. Meaning, that it can in no way intercept a call from someone to you over a landline or cell-to-cell system TO YOUR CELL PROVIDER'S # and route it over VOIP. This would SO be a security concern if they COULD , much less DID attempt it. It is both illegal and almost (for cell to cell calls) impossible.
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.
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.
