News:

On Tuesday September 6th the forum will be down for maintenance from 9:30 PM to 11:59 PM PDT

Main Menu

Absence of Busy Line Detection/Answer Supervision

Started by KevKan, January 08, 2015, 01:51:01 PM

Previous topic - Next topic

KevKan

Recently, I found I had failed to receive a busy signal on what was actually a busy line; it just continued to ring until I terminated the call.   I discovered this deficiency when I called a family member's PTSN at a scheduled time and it was not answered by them or their answering machine.  Since I knew the called party had to be at home, I tried calling on my cell phone and immediately received a busy signal.  

Is this a known deficiency or am I just becoming aware of it?  Is this an ObiHai issue?

KevKan

After checking further, I believe this is a Google Voice issue.   From the, following, it appears XMPP might not support Busy Line Detection,
                         
I made a call to this PTSN line, again in a known busy state, this time using PhonePower as the Service Provider in place of Google Voice.   When I did, I immediately received the busy signal, just as I did when using my cell phone.   However, when I used PhonePower to call a different number, also in a known busy state, I was surprised when I failed to receive the expected busy signal.  The phone just continued to ring, the same as if the call was on GV, until it was terminated.   Subsequently it was determined the second number had "Call Waiting" which must suppress a busy signal from being returned.

Anyone else experienced this?  Any comments?     

Taoman

Quote from: KevKan on January 11, 2015, 07:42:50 PM
Any comments?     

Google Voice does not support "early media." I seriously doubt it has anything to do with XMPP, your OBi device, or Busy Line Detection. Any "media" that is transmitted before the connection is actually made is not supported by Google Voice. This is why you can't use ringback tones or IVR (Interactive Voice Response) with Google Voice.

For instance, try calling the following number with your cell phone and you will get a busy signal. Call the same number thru Google Voice and you will get one ring and then a fast busy signal indicating the call could not be completed.

518-571-0000

Or if you're nostalgic, try calling the following number with your cell phone and listen to the message. Then try calling the same number via Google Voice. All you will hear is ringing. Why? GV doesn't support early media. Google doesn't want to pay for it.

631-265-0000

From freeswitch wiki:
QuoteAnother good example is what happens on a busy signal. Using the same parties from the previous example:

    Party A picks up her phone, hears dial-tone, and enters a phone number
    After a few moments, she hears a busy signal. (This is "early" media - no call has been established)
    Party A hangs up

The busy signal is an audible signal - a form of audio media if you will - that lets the calling party know that the call has not gone through. It is an unconnected call, but it still had sound. In a case of per-call billing, this call would not be billed (usually) because it was never connected. The same holds true for calls that are ring/no answer. It even holds true for calls to disconnected numbers where you hear the Special Information Tones (SIT) and a recorded message.

KevKan

Thank you Taoman for solving the mystery!   I guess the old adage. "You get what you pay for" obviously applies here!

I am sure there are other GV users who would like to know their unanswered calls are not always due to no one being available or the absence of an answering device.  Are GV deficiencies like this documented anywhere?   If so, where might I look?

I stumbled on to this problem while making twice daily scheduled welfare check calls to a 90 year old widow who lives alone.  Seconds after concluding one of these calls I had to call her back to ask a question.   When I did, the phone just continued to ring.   I immediately thought something had occurred that rendered her unconscious.  For some reason, I decided to try calling one more time, using my cell phone, before calling her neighbor.  Obviously I was relieved when I received the busy signal.   Another concern is a possible off-hook situation resulting from not turning off a cordless phone when done.  This would also lead you to believe no one was home.

Taoman

Quote from: KevKan on January 12, 2015, 02:40:02 PM

Are GV deficiencies like this documented anywhere?   If so, where might I look?

I am not aware of any Google documentation listing GV's shortcomings. There was a recent post on DSLreports that listed a few although I'm sure you are aware of most of them. Look for the post by Stewart (who is also a member of this forum):

http://www.dslreports.com/forum/r29754149-Other-Google-Voice

An issue Stewart did not mention is the latency added to the call path when forwarding your GV number to another DID (cell phone, work phone, etc). This has the potential to add sufficient lag to cause people to talk over each other. Certainly isn't experienced (or noticed) by most people but enough people complain about it to make it an issue. I had to go through a few SIP/DID providers before I could find one that worked acceptably with Google Voice.

As you said, you get what you pay for.




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.