One Way Audio on WAN Fail-Over


#1

Im having a issue with WAN Fail-Over and One Way audio on calls being passed through the PBX.

Setup. Ubiquity USG-Pro-4, Primary WAN (Public IP Spectrum) , Backup WAN (Kick Ass, Unifi LTE, AT&T Cellular NAT’D Connection).

Sip Provider is Intermedia

When the primary internet fails the Gateway automatically switches over to the Backup Connection, When this occurs Inbound and Outbound calls have 2 way Audio and the office is still surfing the net.

The problem arises after hours when the calls are sent to an answering service. One way audio, Caller audio is getting to the Answering service but not to the other way around.

What is the difference between a call being generated by a phone on the PBX and a call being passed through the PBX?

Any ideas on what could be going on here or what i could do to fix it?


#2

So the calls in and out of the pbx to the handset is always fine, just when the call is miraculously going to an answering service that a problem occurs? does this also happen if the phone behind the pbx calls the answering service?


#3

If the call involves a physical device attached to the PBX audio works both ways. If the call is just “passing through” the PBX, on fail-over connection 1 way audio.

On fail-over I can call the extension (that forwards to the answering service) and the call connects just fine.

Random caller > PBX > Handset = Good Audio

Handset > PBX > Extension forwarded to 9 Digit external = Good Audio

Random caller > PBX > Extension forwarded to 9 Digit external = 1 Way audio

I also tried setting up the inbound rule to call forward directly to the 9 digit number with no change in behavior.


#4

The call in any part of the telephone system is the following unless you have “direct media” allowed on an extension.

External SIP Service --> telephone system --> handset - Reception call leg of RTP
Handset --> telephone system --> external SIP Service - Transmission call leg of RTP

A call is made up of send and receive ports within the RTP minimum and maximum ports available from the telephone system.

One thought is:
If “direct media” is enabled on an extension - then this might be the issue that you are experiencing - disable it…

Second thought is the nat settings on the trunk / pbx–>sip --> nat --. check the sdp is checked and you need to use dydns as a hostname - that way the IP will be transmitted correctly to the SIP service else it will try to answer on the external IP entered into the sip header which could be the problem…

Use DYNAMIC DNS instead of an external IP for that setting as this will resolve nat issues.


#5

So, The problem i have is that the Fail-Over 4g connection is a NAT’D connection (cgnat). Would that still be a valid return path? I will have to see if i can force a Dynamic update on fail over. I know my port forwarding isnt going to work, but if that solves my issues… I will look at the Direct Media settings as well.


#6

So, further information. Yesterday this customers primary internet connection was down so i enable the backup connection (It has been disabled due to this weird issue). Fired up the backup connection, audio great inbound/outbound to handsets. Some time during the day the internet came back online, network switched over and everything was good again. Until the afterhours route took over. No audio, now on the primary connection. I logged in to find someone has assigned a static IP in the NAT section of the sip settings. I cleared this out as this was not listed as required and the PBX restarted, primary intenet has 2 way audio on the after hours route.

My question is… If i put the dynamic dns name in that hostname/ip box on the PBX and even if that hostname resolves to the CGNAT would that fix my one way audio issues? Or should i just leave that box empty?


#7

Need to understand the NAT. When on Spectrum there is one public IP and presumably static? When on AT&T, is it a static routable IP? How does the UCM know which IP is in use and how does it alter its messaging to tell the other end how to reach it via the IP in use at the time?

I assume SIP ALG is disabled in the USG?

Have you taken a capture of the problem scenario?


#8

The Spectrum IP is Public, but not static.
The AT&T is not static, i don’t believe routable, I’m fairly confident that it is behind AT&s NAT.

Sip Conntrack is ON… I thought i disabled that but guess i didn’t on this customer. Could that by my problem?

Im not a SIP Guy, Still very Green, but i assume there is some sort of keep-alive going out from the PBX to the Provider, thus creating the “tunnel” for inbound/outbound data streams.

I have not taken a capture of the situation. What sort of Capture would that be? Wireshark or something Specific to the PBX.

As for how the PBX knows the public IP has changed… I have no clue, shouldn’t it be handling that on its own?


#9

So, there are no static IPs. As the UCM sits behind the firewall it has no idea of what the public IP is…unless something, somewhere tells it. As far as a keep-alive, perhaps, again a setting and it may depend on what kind of keep-alive.

The UCM has no idea of what its environment is unless someone programs it so that it does know and subsequently knows how to communicate to the various devices - both internal and external.

Despite the cost, a static is always better as once an IP changes, there is a period that ensues where something must inform the other devices of the change and that change is then communicated to the DNS servers around the world so that providers and remote devices know how to find it.

So, we work with what we have:

  1. Get a FQDN. Look in your router and see if it supports DDNS and if so, if there are any specific DDNS providers it wants to use. If so, go to that provider and get a subscription for a DDNS account and select your FQDN, again being careful to select a domain the router supports from the provider.
  2. Once obtained. setup the router with the provider and the purchased FQDN. I use the router for this purpose as if it is the one handling the failover, what better, faster device to let the DDNS provider know of the change so it can then relay the new IP associated to the FQDN to the DNS servers.
  3. Input the FQDN into the external host field in PBX settings, SIP Settings NAT.
  4. Check the box for the SDP just undernearh
  5. Lower down on the page, input the local LAN subnet and any remote LAN subnets that may be connected via VPN.
  6. I cannot speak directly to the USG and the SIP issue, I briefly looked at the WIKI and decided that after seeing that many posts with questions, I did not have the time nor a device to test with, I will have to leave that up to you.
  7. If you are not port forwarding and using the firewall to only allow the provider and other known IPs, then you should do so. There is no need to rely on a keep-alive to maintain a pinhole in the firewall and I do not know what the UDP port close timeout is.
  8. What kind of SIP trunks are you using?
  9. As your ATT failover is on the router and you mention the internet is still up, the question then becomes what QoS or other means are you using to insure that the normal data traffic does not trample the voice traffic? I assume you have a minimum of 200Mbs with Spectrum, but far less with ATT.
  10. Yes, in the UCM, Maintenance, Troubleshooting, network capture. This is a Wireshark capture and allows one to see the messaging.

I have a similar setup but I have static IPs on both Spectrum and ATT wireless, but I still use a DDNS FQDN to advise of the change. While my router is not a USG and I am not using an answering service, I have no issues with the failover.


#10

Thanks. Already have a Dynamic DNS setup for other uses, I will setup the UCM to use that as the host name and see what happens.

All of these things would make sense to me if the system either crashed and burned on failover or never worked at all, its just VERY odd that when a external call comes in that gets routed back out we loose audio, But i can have have multiple successful calls inbound and outbound to physical handsets going on with no issues.


#11

And therein lies why one needs to run a capture. Just because you have some settings, the other end does as well be it a phone, provider, etc… It takes two to tango.

I can only say that I had experimented with VZ and ATT wireless cards for sometime. I never could get it to work the way I wanted and I never had the time to devote to digging in to the messaging as it requires captures at both ends at the same time. I finally decided to get back to it, but instead of dealing with the unknown of the non-routable dynamic IP that comes as the default, I elected to use a static routable IP for $3 a month extra. Since then, I have not had any issue, but in all fairness my Spectrum connection seems to be pretty reliable except when they work on the lines late at night.


#12

If the primary route works in/out/after hours route, and the fail-over works for direct in/out you would think the PBX to be configured ok. Run a wireshark scan and test.