Programmable Voice

  1. Home
  2. Docs
  3. Programmable Voice
  4. FAQ
  5. Why does Call Progress unexpectedly return an Operator Intercept?

Why does Call Progress unexpectedly return an Operator Intercept?

At times you may wonder why a particular call gets an Operator Intercept.  While there are many reasons here are some possibilities:

Sip Carrier Issues

Your sip carrier may be down, or it could not find a route to the destination number.  If it is down, consider using our SIP trunking services as a backup.  VoiceElements can be configured to send a call to multiple destinations: If your carrrier returns an error, VoiceElements can attempt the call at alternate locations for you automatically.  If the carrier does not have a route, it is possible that it is a new phone number that has just been provisioned and the routing between carriers has not completely solidified.  Using alternate carriers can mitigate this.

Early Call Progress

Many years ago when a call would fail you would hear what is known as a TRI-TONE.  A TRI-TONE is 3 Tones in succession using frequencies 950, 1400, and 1800.  Sadly, as VoIP and cell phone service came into being the use of the TRI-TONE has waned.  Now messages are played by the carrier to the caller without the accompanying TRI-TONE.  They do this without actually connecting a call.  For example, you may hear:

  • The number you have reached is not is service.
  • We are unable to place your call at this time.  Please try again later.

In addition to this there is a concept of Early Audio.  Early Audio establishes an audio path between you and the called party before the call is actually connected.  This is very important in doing call progress work.  The reason is that a call may be answered and “Hello” is said, long before the carriers pass along the message that the call was answered.

As you can see from this call flow, the called party says hello 0.5s before the OK arrives on the wire:

TimeCallerMessageCallee
0.0s|———– INVITE ———–>|
0.1s|<———– TRYING ———–|
0.2s|<—– SESSION PROGRESS —–|
0.3s|(Audio Starts)|
1.0s|(You hear Ringing)|
4.0s|(You hear ‘Hello’)|
4.5s|<—– OK —–|
4.6s|—– ACK —–>|

Call progress does not return “HUMAN” or “MACHINE” to your application until the OK is received and we know for sure that the call is CONNECTED.

When a “not in service” message is played by a carrier, call progress determines that it POSSIBLY has a machine because of the length of the spoken message.  It then waits for up to 5 seconds (configurable) for the OK to arrive.  In the case of these OPI spoken phrases, the OK never arrives, and so call progress returns OPI after 5 seconds.

Generally speaking, carriers return the OK for a CONNECTED call within 500ms of the first utterance.  Sometimes the OK even comes before the “Hello”.  Sadly, there are some low-quality carriers that don’t deliver the OK for much longer that 5 seconds.  This is particularly bad, especially for Call Progress, because the OK is a very important signal that is needed to determining the outcome of call progress.

If you see in your HMPServer.log this message:

HmpSip::MaximumTimeTimer – Timer Fired With EarlyCallProgress. Returning OPI

Then you know that the server has a call that did not get the OK within the configured timeout (5 seconds).  If you are certain that the number is a good number, then this is a clue that your carrier is not behaving as it should and is not delivering the OK promptly.  In these cases we suggest that you switch to a more reliable carrier.  You can also open a trouble ticket with your carrier, but getting them to make a change can be difficult.

 

 

 

Was this article helpful to you? Yes 13 No

How can we help?