TIPS Random no audio

[kameleon]

I have a 2027-U install and have two different locations pointed to it. One location is having issues with random no audio calls. The other is rock solid. There are a few differences but I can't seem to pinpoint which one is causing the problem.

Site 1: rock solid site
Comcast business class 300mb/30mb internet with static ip (this IP is whitelisted on the pbx)
Using older Unifi USG as firewall
Using a mix of old polycom and Obihai phones (7 in total)

Site 2: Random no audio
T-mobile in custom cellular router, ping stays well below 80ms even when the issue arrises. Speed wise it gets 500mb/50mb pretty much any time I test
Using new Unifi UDM SE as firewall
Using ClearlyIP 270 phones with OpenVPN client on them pointed straight to the PBX (2 phones)

When the audio drop outs happen, if the caller calls back a couple of times it will then work. It almost sounds like a NAT issue but with the VPN it shouldn't be an issue as the 10.8.0.1/24 is set in the admin panel as one of it's IP ranges. Is there something I am missing?

 

[KNERD]

You would probably have to run Homer

SIPCAPTURE

OSS SIP / VoIP / RTC Packet Capture & Monitoring. SIPCAPTURE has 67 repositories available. Follow their code on GitHub.

github.com

Or

VoIPmonitor® - VoIP monitoring software - quality analyzer - WAV recorder

VoIPmonitor® is open source live network packet sniffer voip monitoring tool and call recorder which analyzes SIP WebRTC, SKINNY MGCP RTP RTCP WebRTC Diameter T.38 protocol and predicts call quality

www.voipmonitor.org

 

[kameleon]

Ok I think this is most likely a BulkVS issue, or at least my implementation of it on my pbx. So doing some digging it is either the sip initiation gets lost or the RTP never does its thing. All my settings are correct and bulkvs support (at least the weekend support for what its worth) says everything is fine on their end. It may come down to how I have my BulkVS trunks setup. On this PBX I have 5 numbers. Initially it was only 1 and I only used BulkVS for outbound but recently added the other lines and used them for both in/out. This is when the random no audio calls started happening.

I have the main sip trunk setup and the 3 other sip trunks, one for each of their IPs, like the documentation says. However I have duplicated this for each number. I am thinking this should be easier and I might only need one entry and not one for each DID. Thoughts? Maybe @wardmundy has an idea? Should I swap from sip to pjsip or from IP auth to registration?

 

[dallas]

So doing some digging it is either the sip initiation gets lost or the RTP never does its thing.

If calls arrive without audio it won't be the sip initiation.
You need to collect the logs for a failed call and troll through the log looking for errors.

 

[kenn10]

@kameleon are you not using chan_pjsip ? You only need one trunk for Bulkvs and it is recommended you use registration over just ip-authorization. The old method of multiple trunks became unnecessary years ago but Bulkvs has not updated their documents. I have used both registration and ip-auth and both work for me with PJSIP.

 

[kenn10]

See post #4 in this thread https://www.voip-info.org/forum/threads/bulkvs-config.28143/#post-179006

 

[kameleon]

See post #4 in this thread https://www.voip-info.org/forum/threads/bulkvs-config.28143/#post-179006

Should it be just one trunk for in/out per DID or just one trunk for BulkVS period?

 

[dallas]

Just one trunk.

 

[kameleon]

Just one trunk.

So just set the caller ID in the outbound route, correct?

Also: I have created the pjsip trunk and it is working. Initially it did not like my super long password and that took a minute to troubleshoot but it is up and working now. However my random one way audio still persists. I have tons of logs and it keeps pointing to something at BulkVS is the issue, at least according to Gemini. I guess I will wait until tomorrow to call and talk to support since the weekend support was less than helpful.

 

[kenn10]

If you have 5 DID's with Bulkvs, you can use any of them on the outbound calls over the Bulkvs trunk. Otherwise, you can set one number on your outbound route for all calls.

It is a very odd situation to have dropped audio only some of the time since its all on the same trunk now. Maybe the daytime techs will have some guidance.

 

[dallas]

Post the log entries for a one way audio call. Redact any sensitive information.

 

[kameleon]

Post the log entries for a one way audio call. Redact any sensitive information.

See attached. I think I sanitized it enough The top part is a call that worked. The second is a call right after the first from the same number and it never rang on my cell but the extensions (201 and 202) did ring. Picked up extension 201 and no audio, it hung up after 6 seconds automatically. I had to hang up my cell manually as it never rang.

 

[wardmundy]

Are you redirecting UDP 10000-20000 on your routers to your PBX? Maybe one of your routers isn't handling the RTP traffic correctly.

 

[kameleon]

Are you redirecting UDP 10000-20000 on your routers to your PBX? Maybe one of your routers isn't handling the RTP traffic correctly.

My pbx is in crowncloud. I do have all the udp 10000-20000 allowed through iptables.

root@pbx1:~# iptables -L INPUT -n -v --line-numbers | grep 'dpts:10000:20000'
49    9441 1785K ACCEPT     udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:10000:20000
root@pbx1:~#

 

[islandtech]

sure you got ips white listed?
working call 67.231.0.7
failed call 67.231.5.112 and 67.231.5.79

 

[kameleon]

sure you got ips white listed?
working call 67.231.0.7
failed call 67.231.5.112 and 67.231.5.79

Yeah what's odd is neither of those are on the list of what BulkVS says to whitelist. I went on site to troubleshoot this more this morning and could not for the life of me get it to fail again. It is so strange. Maybe adding the pjsip trunk fixed it somehow, even though I didn't have the problematic DID running through it. I guess for now I'll just roll with it and monitor it some to see if the issue continues.