[VoiceOps] Call established before audio path

[Carlos Alvarez]

I've learned over the years that humans can break the best-made
systems.  I too have had the receptionist with a finger on the button.
Turns out this company would get a hundred calls first thing in the
morning, so she'd sit there with headset on and finger on the answer
button.  The solution to this was for us to answer, wait half a
second, then ring the receptionist.

Back in the analog days I always included a 1-second delay between
answer and media.  Even in the early PRI days they often needed some
settling time before media would pass.  Now as a matter of standard
everything we do includes a half second wait between answer and any
other function.

I had a funny echo problem in a call center (funny only because the
days I spend trying to fix it were billable)...  We went through
everything technical, and all my people were frustrated.  I went to
the site and watched them work.  Turns out almost all the women would
put the headset band behind their head to avoid messing up their hair,
which put the ear pad at an angle relative to their ears.  They'd turn
it to max to make up for that.  In this position, the ear pad was
pointed directly at the microphone, which happily picked up the sound
and repeated it.


On Mon, Jun 16, 2014 at 9:16 AM, Peter E <peeip989 at gmail.com> wrote:
> +1 for that answer, David. It went beyond accurate and was "accurate with style."
>
>
>
> On Jun 16, 2014, at 10:07 AM, "Hiers, David" <David.Hiers at adp.com> wrote:
>
> That handles the IVR case, sure, but the harried, highly-caffeinated receptionist with a headset that can strike the "answer" button like a cobra remains a persistent challenge.
>
>
> David
>
>
> -----Original Message-----
> From: VoiceOps [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ryan Delgrosso
> Sent: Friday, June 13, 2014 09:41
> To: voiceops at voiceops.org
> Subject: Re: [VoiceOps] Call established before audio path
>
> Ive seen this pretty regularly, often times it happens when there are multiple sip servers in the path, and the final 200ok with SDP takes a second to get to the endpoint. Especially when something that does symmetric latching is in the path. Its not uncommon for symmetric latching to cause this as the called audio will start flowing the moment it sends the 200ok, but the 200ok still has to be received by the caller and it has to begin sending audio for the latch to take and have the audio routed both ways.
>
> The answer is typically a 0.5 second delay at the start of your prompt to insulate against this.
>
>> On 6/13/2014 9:07 AM, Brian Taylor wrote:
>> We have customers who are reporting that when people call into them
>> that the beginning of the greeting is not being heard.
>> It appears that the phones think the call is ready before there is a
>> complete audio path. We see this the most on calls that come in from
>> the PSTN. Long distance or toll free calls are the worst.
>> We have a Broadworks system that uses Lucent 5010 (Telica) switches
>> for the connections to the PSTN.
>> The symptom seems to be very similar for all of our PSTN connections,
>> to multiple carriers.
>>
>> I'm just curious if anyone has any experience with this problem, or if
>> anyone has any suggestions to get to the bottom of the issue.
>>
>> Any assistance or inspiration would be greatly appreciated.
>>
>> Thank you,
>> Brian Taylor
>> Socket Telecom, LLC
>> brian at socket.net
>> _______________________________________________
>> VoiceOps mailing list
>> VoiceOps at voiceops.org
>> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
>
> This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops
>
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops