Hi from Sprint - it works great for me, I've been testing for a couple of weeks. This is actual back-end call routing as opposed to VOIPing the call through the app on the phone.
yep, that's my understanding. If you actually sign up for GV as your Sprint number, it acts just like your Sprint number. No forwarding involved.
Also, you get to keep your GV number for..I believe 6 months is the plan. It behaves the same way as your Sprint number during that time. That's my understanding right now anyway.
I worked on the Sprint side of this a bit, had the same question early on and the answer I got was that it didn't change minutes of usage calculations...so...nNo change to how numbers behave from a billing perspective. If you're calling a mobile number and have AMA, it goes in that bottomless bucket. If you're calling a landline, it uses Anytime minutes. Same story for shared lines-- no change to how minutes are used.
Yeah I'm absolutely implying something by my comment. I understand the time:value relationship and can expect some degree of RCA to go away if rebooting a server solves a problem for X amount of time, where X is less than a few days. But if you're spending the time opening an alarm, calling people to a bridge, agreeing to bounce a server, and then bouncing it, at some point that equation comes out in favor of actually doing some sysadmin/RCA and making it so you're not bouncing a server every 48/72 hours.
It also looks really JV to see those alerts day in/day out. Like, come on. We can't just fix the problem?
I'm not going to pretend I know what Mach is, but around here, (big company that you're familiar with), rebooting/bouncing the servers is pretty much how issues are dealt with. "Response times outside of SLA: bounced the server." "Database connections timing out: bounced the server." "Users experiencing high load times for pages: restarted JVMs. Then bounced the servers."