Set up Obi212 as FXO for FreePBX, intermittent incoming audio issue

General Help
1

I’m in the process of rolling out a few FreePBX 14.0.5.25 (Asterisk 13.22.0) systems using OBi212s as FXO gateways. So far I’ve been able to successfully make & receive calls via the OBi212 FXO, but I am having persisting issues with incoming call audio dropping for 5-10 seconds intermittently. It seems to only be happening for the incoming call audio (from the PSTN) as the outside caller can hear me throughout the outage.

MY testing so far has all been done locally within the LAN and I’ve disabled SIP ALG in my router in the event it was causing issues.

OBi / FXO-side settings we have tried:

  • Using the LAN port instead
  • T38Enable Off
  • Using PJSIP and port instead (same issue)
  • Force g729 codec instead
  • Increase SilenceTimeThreshold
  • DetectFarEndLongSilence Off
  • DetectCPC Off
  • SilenceDetectSensitivity to Low
  • Disabled registration
  • Adjusted MTU size

On the FreePBX-side:

  • A chan_sip trunk is configured to Asterisk using UDP.
  • Turned on / forced G729 codec to test (in the event the issue was bandwidth-related)
  • Added autoframing to SIP trunk config
  • Added all our local / VPN-accessible subnets to the local network in Asterisk SIP Settings
  • Removed registration
  • Disabled T38

I am having the same issue at every location so i suspect there is an important (and hopefully obvious) setting i am missing somwehere. My configuration at each location is identical - FreePBX is installed on a physical Gigabyte BRIX, Ubiquiti Edgerouter / VPN, OBi212, netgear gigabit switches / WAP.

I’ve noticed that the packet counters on the OBi continue to show traffic during the dropped audio so it leads me to believe the issue is on the FreePBX-side or network related.

Not sure what additional info I can add that would be helpful. Sorry for my ignorance, I’ve been trying to figure this out for the better part of the week and am unsure where to look at this point.

It seems like the dropped audio problem happens more quickly when calling / receiving calls from cellular phones than from pots lines but this may be a coincidence.

Thank you very much for any help you can provide!

2

Just to be sure that we’re working on the correct issue, please confirm that you are reasonably certain that the problem relates to the OBi212. For example, are calls using a SIP or other trunk ok (no dropped audio), or if you don’t have any other trunks, are calls from one extension to another ok?

I would try capturing all traffic for a failed call by running tcpdump on the PBX. Move the file to your PC and examine it with Wireshark. Codec should be set back to ulaw (or alaw if appropriate) as it is easier to analyze. First determine whether incoming RTP during the drop is missing, bad (e.g. wrong codec, packet size, sequence number, timestamp, port, etc.), or simply silent.

If it’s missing, try a continuous ping from PBX to OBi and see whether packets are lost during the dropout. If silent, try monitoring the analog line to see whether the incoming audio drops out. You can do this with a “butt set” if you have one, or an earphone in series with e.g. a 1 uF capacitor. You may be able to do it by setting LineInUseCurrentThreshold for the Line port to a very low value, e.g. 4 mA and listening with a standard analog phone in parallel with the OBi.

Also, some background information would be useful:

Is the OBi connected to a copper pair from the carrier’s central office? If not, provide details (cable MTA, fiber ONT, ATA from a VoIP provider, etc.) Is this the same at all your sites?

Provide details on all networking equipment between the PBX and the OBi. If the Netgear switches are anything but dumb, describe any special settings (VLAN, QoS, etc.)

What country is the OBi in?

What kind of device(s) do you have on the extension side (IP phone make/model, SIP app, etc.)?

About how often do the dropouts occur? Do they happen at regular intervals, e.g. exactly every 10 minutes? Are both incoming and outgoing calls affected?

3

Hello,

Thank you for the reply. I apologize for the length of this response in advance.

Yes, the problem seems to be specific to the Obi212. At the main location we have an FXO DAHDI card with 12 analog lines terminated from two different providers. Those don’t seem to have the problem. For example, I placed a call from a remote site, dial the access code to access one of the FXO ports at the main location and we don’t experience audio dropout. The same goes for local to local calls, either within the same site or site to site. These seem to work fine.

Remote sites are tied together using IAX trunks and all endpoints are Yealink phones (T41S, T46S a few T48S) connected to their corresponding FreePBX server at their location. All endpoints are using PJSIP, with the exception of the OBi boxes. That being said, trying PJSIP to the OBi didn’t make a difference.

We will try the capture test you describe, thank you. We are using ulaw already and watching the call status screen in the OBi box I don’t see anything strange (no codec shift, excess late packets or pause in counters, etc.) when the dropout occurs, but the capture will undoubtedly be a better analysis tool.

We will also try the ping test and we do have a butt set.

3/31 Update - The OBi is reachable throughout the audio drop and the ping times are consistent (~16ms). Will do packet capture next.

Yes, the OBi212s are each connected to a copper pair from the CO. Provider is Telus and we’re located in Canada. These are standard residential loop start lines. Two of the sites have fiber internet and a Telus installed ONT at those locations, so the line in these cases comes in on fiber and out of the ONT on a standard RJ-11 cable and plugged into the OBi212.

All locations have a Ubiquiti Edgerouter 3 Lite router. All are connected via IPSec VPN tunnels and every site has a VPN connection to every other site (6 sites total). We have deployed equipment (OBi212, FreePBX and phones) at 4 or the 6 remote sites so far and they have all experienced this issue.

Main location (DAHDI card):

  • FreePBX is running on a PC (Core 2 Duo E7400 @ 2.8GHz, 120GB SSD, 4GB RAM).
  • A mixture of managed and dumb switches are used. Dumb switches to add connections in a room without requiring an additional drop. Ex: Netgear GS716Tv3, GS724v4, GS105, GS108
  • The managed switches have some LAGs for NAS to file server connections, no other settings enabled.
  • Devices here are connected to one of two managed switches in separate buildings.
  • Overall LAN traffic here is what you’d expect for a small business with a couple file servers, NAS, etc.

Remote locations (OBi212):

  • FreePBX is running on Gigabyte BRIX 1900s (Celeron J1900 @ 2GHz), 4GB RAM with 120GB SSDs
  • At the remote locations the Netgear switches are dumb switches. Ex: Netgear GS105, GS108, GS116NA.
  • Overall LAN traffic in remote locations is minimal. Some wireless cameras are present (ad hoc viewing, no continuous recording)
  • Router eth1 port connects to a Netgear switch (8 or 16 port). The Obi212 and FreePBX are connected to the same physical switch all but one location.

As for the audio dropouts, they appear to be completely random. We’ve had them happen almost immediately, with the longest wait being around 11 minutes. Typically, it happens within the first few minutes of a test call. The amount of time until the next one varies, sometimes seconds later, other times it may be several more minutes.

The person using the Yealink phone will hear the change in the audio to complete silence when it occurs. During this time the Yealink phone cannot hear the remote caller, however the remote caller can still hear the Yealink phone without issue. Dropouts tend to be 5-6 seconds, but some are longer.

We have not experienced one-way audio dropouts in the reverse direction (where the Yealink couldn’t be heard by the remote caller). This has not happened in any test call.

4

Hello,

Another update… we ran a tcpdump and noted the times where audio dropouts occurred on a short call and a 15 minute call. We have noticed that while the dropouts themselves appear to occur at random times, they always last 10 seconds.

The first call the dropout occurred around 42 seconds in.
On the 15 minute call the dropouts were as indicated below:
4:36 gone, 4:46 back
6:58 gone, 7:08 back
8:02 gone, 8:12 back
9:48 gone, 9:58 back
10:48 gone, 10:58 back
12:31 gone, 12:41 back
13:20 gone, 13:30 back

We are still reviewing the wireshark captures and I’ll let you know if we see anything curious in them, however it does appear that UDP packets are still being received during the audio drops, just not being heard.

5

Wow, that’s the strangest symptom I’ve heard in a long time. I’m completely stumped. We’ll have to wait until we see what the RTP looks like during a dropout. Is the OBi running the latest firmware?

This is not unreasonable if you were pinging from headquarters over the VPN. But if you were pinging from the PBX in the branch with the OBi (which I assume is what the OBi is registered to), I’d expect less than 1 ms. I don’t have an OBi212, but my OBi110 (a very similar older model) shows ~0.5 ms ping time on the LAN.

6

They were all running the same version (3.2.1) but we have updated two to the latest (3.2.2) and loaded the available third party firmware on another one. The issue still occurs unfortunately.

The ping amount cited was indeed through the VPN. Locally it’s as you’ve mentioned.

We’ve taken a look at the packet capture and really don’t see anything different during the audio drops that raises an eyebrow. But to be completely honest we’re not well versed in understanding RTP and what we’re looking for, beyond the presence and timing of packets.

Thanks for your continued help!

7

Does the RTP play normally? If you have trouble doing this, In Wireshark, select an RTP packet from OBi to PBX, select Telephony -> RTP -> Stream Analysis. From there you should be able to Play or Save the streams as an audio file.

Or, make a .tgz file from the .pcap and upload it here. To avoid posting any private info that may be in the SIP, set the Wireshark display filter to “rtp” (without the quotes) and select File -> Export Specified Packets. Save the displayed packets under another name. Open the new .pcap file in Wireshark to confirm that only RTP packets are present.

Or, make a .tgz from the audio file and upload it here.

1 Like
8

Hi Stewart1,

Thank you for the information, we can definitely prepare this. One thing we’ve noticed is the result of our tcpdump capture produced UDP packets, not RTP. When I filter on rtp protocol there is nothing listed. The UDP packets present are between the Obi, FreePBX and Yealink endpoints.

9

Normally, Wireshark figures it out from the SIP packets. If you were examining the .pcap file with another program, you may be able to tell it which packets are RTP, e.g. by port numbers.

If Wireshark doesn’t display the packets as RTP, the likely problems are:

  1. tcpdump started after the call was initiated, so the SIP is not present.
  2. tcpdump capture was filtered e.g. by port numbers, so the SIP is not present.
  3. tcpdump was told to capture only a limited number of bytes per packet, so the SDP was not captured.

In Wireshark, you can select an RTP packet that was erroneously classified as UDP, right click, choose Decode As, change Current to RTP, click OK. Packets in that stream should then be shown as RTP.

1 Like
10

Hi Stewart1,

Yes, we are using Wireshark. The capture was started at the moment of the call, so we will perform another capture and review it as you’ve described, thanks. The tcpdump was run with no filters, file output and packet size 65535 so it’s probably the timing as you’ve identified.

11

Hi Stewart1,

I think we’ve solved this. We performed a few captures using your instructions and RTP packets and the audio stream were present. Looking at the stream, there was silence in the area we heard it for the one direction.

We took a look at the packets in that area, and prior in 3 test calls there were RTP Event packets that were transmitting DTMF. It looks like the Obi was incorrectly detecting voice or music as DTMF, and since we were using RFC2833 it would then remove the packets from the stream.

We have changed the Obi to use Inband and made the change on the trunk in FreePBX as well. I did find another Obi user in searching that had the same issue with an Obi2xx and they ended up using an Obi1xx instead, which eliminated the problem.

Very strange that earlier devices don’t have the issue. In our testing the firmware version made no difference either, but we didn’t try anything prior to the shipped version of 3.2.1.

In any event we had a 15min call with no dropouts. In looking at the data there are no more erroneous DTMF packets from the Obi to the FreePBX, so hopefully this is resolved.

12

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.