Outbound call disconnects after 32 seconds using click to dial

[Marie]

Customer's scenario:

• using click-to-dial button in Salesforce to call number
• connector asked if I was to make this call, I choose Yes.
• connector calls my softphone, I answer and call starts to dial out.
• I'm calling our office number as well as my personal cell number to test both.
• The call connects, the pop up is present and accurate
• At 32 seconds without fail, connector I guess, hangs up the call.

My questions:

Maybe it has something to do with default ring time....How long is the default ring time an a normal inbound call?  Do we have to set up Find Me/Follow Me to change length of default ring time which seems to be about 30 seconds?

[Darren Schreiber]

There are some "magic" numbers in VoIP that are very telling:

1) Calls that drop at 30 seconds. The way VoIP works, we send a packet to the phone saying "please start ringing" (an INVITE). The phone replies that it's ringing. It then sends us a packet back that says "the person you are ringing has answered!". We send back an OK indicating "OK, we now know that both parties are on the line - let them speak!".   If one of the last two messages has any sort of problem (typically the OK), there is a retry interval for 30 seconds (by default). If the retries continue to fail, the call will disconnect. This sounds like your issue. I'd check your softphone and make sure RPort and media timeout settings are correct.

2) Calls that drop at 10 or 15 minutes. This are magic times when a lot of carriers check to see if a call is really still up. If the SIP signaling port has become closed by a firewall/router, but media is still flowing, the signaling which checks if the call is still up will fail (even though the call IS actually up) and the call will drop. This is almost always a firewall/router issue.

3) In terms of firewalls and debugging, there's a magic rule on debugging audio vs. call connectivity as well:
* If the call connects, but has no audio or one-way audio, your problem is almost definitely firewall related and is related to ports UDP 16384-32768 or the RTP ports specified in the GUI of your phone

* If the call fails to connect at all, your problem is almost definitely signaling which is port 5060 or 7000 depending on your configuration.


Based on your description, I think it's #1 above. Posting your softphones settings, especially the advanced / network tabs, would be a good starting point.

[Karl Stallknecht]

This is great general information for all of us, Darren. Thanks!

[Marie]

Thanks for the info Darren.  Customer did try changing the Bria4 Preferences>Calls>Other> enable activity timers etc with no luck.  

We will try making some changes to Bria4>Account settings>Advanced>Timer settings etc.

[Darren Schreiber]

Definitely turn off the RTP inactivity timer. That's a nasty feature they started shipping and it's on by default. It should be off.

[Karl Stallknecht]

Ugh sorry I should have read this more closely earlier! We had a similar issue with a client using Bria and went back and forth with 2600hz on it via Zendesk. Our behavior though was that calls would only get dropped if making more than one simultaneous call. Also, it didn't matter whether it was incoming, outgoing, API initiated, etc. When we disabled RTP Timeout / Media Timeout the problem was solved.

[Darren Schreiber]

To be clear, the problem with the simultaneous call scenario is that the calls are still actually "attached"/up on the softphone, even when not being used by the user. Thus, the call that was on hold had "no audio". The RTP timeout would kick in when nobody was talking, and bye bye caller.

[Karl Stallknecht]

So then why would this happen in Marie's case with only one simultaneous call?

[Darren Schreiber]

There are two RTP streams - one going to you, and one going from you. If the person pushes mute to listen to someone talk, boom, you might have 15 or 30 seconds or inactivity, and the call is hungup. (Hence why this feature seems incredibly dumb)

I'm sure there's some way to make our servers behave nicely with it, like periodic RTP packets, but again, seems dumb to us. VoIP specifically has a feature to reduce bandwidth consumption which allows NOT sending audio when there is none, and we utilize that. It's indicated in the headers that we're using it, and the phone accepts it, but then doesn't respect it. (This is also why other providers don't have this issue - they don't use this feature).

[Karl Stallknecht]

Gotcha, thanks!

[Marie]

Thanks so much Karl!  This fixed the customer's issue.  Thanks for taking the time to read and posting this fix!