Absence of Busy Line Detection/Answer Supervision
SteveInWA:
This may seem like hair-splitting, but let me add some explanation:
People often confuse the Google Voice service, with the Google Chat (XMPP) service used on OBi devices. Google Voice, by itself, is not, and never has been, a telephone carrier. Its primary role is an inbound call forwarding and message management system. Consumers who buy OBi devices, may believe that it turns GV into a sort of free telephone company, or they compare GV to a SIP ITSP, which is an apples-to-oranges comparison. Outbound calls made on an OBi device are placing calls as Chat clients.
Hangouts is gradually replacing Chat, and Hangouts is an independent service, not related to, nor controlled by, the Chat forwarding pseudo-phone destination setting in GV. Inbound calls will ring all logged-in Hangouts clients, as long as the user enables inbound ringing on that client.
Some of the users over on DSL Reports are using Google Chat as if it was a free VoIP trunk on a PBX, which it was never designed to support. Thus, the linked list is only meaningful, in context, that you are comparing distinctly different services. It's like comparing a motorcycle to a car. Both will get you from point A to point B, and both have their distinct advantages and disadvantages. Note that user Stewart's list, is, by his definition, a list of things he dislikes, not a list of "shortcomings" for all users.
The GV infrastructure definitely does support early media; it couldn't work without it. XMPP clients, depending on how they're designed, may not play a busy signal, but GV does, in fact, know when a line is busy or answered.
The actual problem that OBi users experience, is that by design, GV simultaneously forwards inbound calls to all configured forwarding destinations (Chat and up to six DID numbers). It will keep ringing all those destinations until it receives a call-answered signal from one of them, or approximately 25 seconds has transpired, or one of the destinations is set up to use Conditional Call Forwarding to handle the call (send it back to GV's VM). It therefore will ignore any sort of pre-answer status by any forwarding destination during the early media period, because it would impact the reliable handling of the simulring function. For example: if you have an OBi (Chat) and a POTS line and a cell phone defined as forwarding destinations, and the POTS line is busy during the simulring forwarding period, GV just ignores the busy signal, so it can continue ringing the other phones until the ring period expires, etc. Without this function, you'd never be able to use GV with more than one forwarding destination.
Remember: GV wasn't designed to be used with OBi devices, so some OBi behavior may be inconsistent with typical POTS or SIP ITSP service.
KevKan:
Thank you Steve for taking the time to provide such a detailed and clarifying response. I must admit I was one of those who was under the impression Google Voice was feature equivalent to an SIP ITSP. Not justifying my impression but I suspect most users who click on the "Approved Service Providers" on OBiTalk and see Google Voice on par with Anveo, Phone Power, etc. are likely to come away with the same impression. Hopefully they see and read your very informative response explaining the difference.
Taoman:
Quote from: SteveInWA on January 13, 2015, 06:27:31 pm
Note that user Stewart's list, is, by his definition, a list of things he dislikes, not a list of "shortcomings" for all users.
Good point.
Quote from: SteveInWA on January 13, 2015, 06:27:31 pm
The GV infrastructure definitely does support early media; it couldn't work without it. XMPP clients, depending on how they're designed, may not play a busy signal, but GV does, in fact, know when a line is busy or answered.
The actual problem that OBi users experience, is that by design, GV simultaneously forwards inbound calls to all configured forwarding destinations (Chat and up to six DID numbers). It will keep ringing all those destinations until it receives a call-answered signal from one of them, or approximately 25 seconds has transpired, or one of the destinations is set up to use Conditional Call Forwarding to handle the call (send it back to GV's VM). It therefore will ignore any sort of pre-answer status by any forwarding destination during the early media period, because it would impact the reliable handling of the simulring function. For example: if you have an OBi (Chat) and a POTS line and a cell phone defined as forwarding destinations, and the POTS line is busy during the simulring forwarding period, GV just ignores the busy signal, so it can continue ringing the other phones until the ring period expires, etc. Without this function, you'd never be able to use GV with more than one forwarding destination.
While I don't doubt what you say is true it doesn't address the OP's question. He is talking about making outbound calls using Google Voice. I trust you will agree that when making outbound calls using Google Voice that early media is not supported? Calling 631-265-0000 from a cell phone and then from Google Voice pretty much proves that point, me thinks.
SteveInWA:
That's a semantics issue. Google Voice "supports" early media; it knows that the line is busy. It just isn't directly connecting your audio to the far-end switch during early media, so you can't hear the busy signal, and it isn't simulating a busy signal. Again, this is one of those "Google Voice is not a POTS line" issues, so the user experience will be different.
Taoman:
631-265-0000 is the "payphone coin deposit" message which is a classic example of early media. When called from a standard land line or cell phone you hear the message. When called via Google Voice you only hear a ringback tone. I'm not sure where "semantics" enters into this particular example.
If we're going to talk semantics I'd suggest it should be about your use of the word "support." If you want to say "The GV infrastructure definitely does support early media" that's all well and good. But the end result for the Google Voice user is that any "media" that is transmitted before the call is actually established is not sent to the calling party which, in my view, is the point of this entire thread and what the OP was experiencing.
Navigation
[0] Message Index
[*] Previous page