I think this has been going on since we adopted the FreePBX system earlier this year. I finally was able to visit with someone who would go a little deeper than “you’re phones are messed up.”
We have four analog lines. Our FreePBX will connect two incoming calls to each other, and never alert us that someone is trying to reach us. I assume this is abnormal behavior, but I’m not sure what to do about it.
Line 1, 2, and 4 are from Century Link. Line 4 is our fax line, 1 and 2 rollover to each other (via CenturyLink), Line 3 is from Mediacom (part of a promotional when we bought our internet package from them) that has no rollover. My plan uses Line 3 as the default for outgoing calls.
This is not an instance where an incoming and outgoing call collide, nor is it an instance where both are parked in the same spot. This happens before our phones even ring. I know you probably need logs, I’m not sure how to access more than the last 1000 or so lines without crashing my browser.
First thing to do is absolutely verify that each of your FXO lines are wired correctly, no ‘split-pairs’ and ‘ground-start’ v ‘loop–start’ circuits are appropriately signaled.
Given that, to reduce ‘glare’ (when two circuits are inappropriately connected due to a race condition that can happen on loop-start circuits) make sure all incoming circuits are enumerated as per your Supplier’s ‘failover’ policy, and yet your outgoing circuits are enumerated in the absolute reverse order.
I have had that problem before also - what FXO card are you using? Some of the older cards did this to me, but I switched to Sangoma cards until Digium got their act together (AEX410) and then I could use both reliably.
If your FXO’s are loop start (which they almost certainly are) then polarity should not matter, but poorly designed hardware might need a specific map of white/blue (or blue/white) or red/green (or green/red) to tip/ring (tip is 0v, ring is (hopefully) -48v)
Basically apart from all that B.S. theory, try reversing the wires pair by pair.
@GSnover , I am using this card: Sangoma A20002DE PCIe 4 FXO w A200 with Echo Mod (that I bought on Ebay). I have two servers, a primary and a backup. Both have had this trouble (identical servers with different cards of the same model).
@dicko Switching the wires makes sense to me. I can do that. One at a time, but how to test something so sporadic? I suppose just wait and see if the complaints stop…
My Analog FXO ports are set up with Kewl Start signaling, I’m not sure if that is helpful. I have traced each wire back to where it goes into the demarkc and the orange/ orange stripe pair plugs into the green/red pair on the demarc and so on. Each solid / stripe pair is paired with a separate line at the demarc. I tested the lines with a regular phone to make sure they work - but that’s not to say I don’t have the orange / orange stripe pair reversed.
All circuits run both directions (we can call out on all and call in on all), so can you explain what you mean by “enumeration?” Is failover the same thing as rollover? I don’t have tip-ring, I have RJ-11 connectors.
Thank you for your guidance. I am looking forward to getting this straightened out. I will dive into the logs tomorrow to see if I can find anything, but will be on vacation for few days and changing something right before I leave concerns me greatly.
You actually do have tip-ring it’s just now colloquially red-green (or yellow-black), please see how your calls come in on DAHDI, and how you are calling out over DAHDI , g0 is low to hi G0 is hi to low , glare happens when g0 overlaps G0 , the call path is now undefined
If wikipedia, and O’Reilly, are correct that is still loop start for a seize, so will suffer from glare. Ground start is designed to minimise or avoid glare, but must be implemented from PSTN end. The fact that kewlstart works at all suggests that earth start is not being offered.
I think I would expect all PSTN operators to offer ground start on some of their business tariffs. However serious business users will be using ISDN, so there may not be a demand for ground start lines any longer.
If you are using analogue lines you are also likely to find difficulty detecting when the caller has hung up, and when the callee has answered.
As I hope is already clear, this is common behaviour for analogue lines, especially loop start ones, to the point where it has a term, “glare”,which long predates VoIP, to describe it. All analogue lines normally used directly with telephones are going to be loop start - if you can get dial tone by picking up the phone, it is loop start.
How is this glare if two inbound calls get bridged? Unless there is some call flow that automatically sends some calls back out to the pstn, possibly with an ext number in a ring group?
@david55 Thank you for your comments. If I understand you correctly, this behavior is not desired, but expected in certain instances. I understand that my problems may be an issue with my telephone company. We did not have this problem before changing PBXs from our older AVAYA to the FreePBX system. Is the newer hardware more sensitive to this behavior?
@dicko You helped me get started with the DAHDI groups a few months ago (thank you). In Connectivity>Trunks>dahdi Settings, Line 3 is set as G0, Line 2 is set as R0, and Line 1 is set as g0. I have confirmed that calls come in on Line 1 when dialed directly, line 2 when line 1 is busy or if it is direct dialed, and line 3 and 4 only when they are direct dialed. We are not having glare issues on outbound and inbound calls (thanks to your aforementioned help) as long as all four of our lines are not busy. Right now, the problems occurs only when two callers are calling at the same time. Is this what you’re asking, or is there a config file I could look at somewhere?
My comments were certainly based on the assumption that they were routing the call back to the PSTN, as that seemed to me to be the only sensible explanation of the symptom. Especially if that is not the case, I think we need to see the logs, to understand what is actually happening.
I would encourage you again to double check for ‘split pair’ wiring of your lines where the tip of one line is paired with the ring of another.(It could be before your mpoe . i.e. the telco ) . What was on the telco blue pair?
With the calls bridging before the PBX sees the call, I don’t see a way that this isn’t a wiring problem. I accidentally punched down and bridged two tips together when I was wiring a building back in the '80s and caused a situation similar to this.
IMO, this thread is going nowhere because no real troubleshooting has been done.
Approximately how often does this occur?
About how many calls do you receive per day?
How are calls normally answered (IVR, ring group, queue, etc.)?
Can you cause this trouble at will, e.g. by calling in from two mobile phones at the same time?
Have any employees experienced the trouble when calling in?
You can view 5000 lines in Chrome without issue. Or, copy /var/log/asterisk/full to your PC and use an editor to select the desired section.
OK. Thank you. I am working on getting the logs together now. This problem occurs almost daily. Calls are normally sent to our reception ring group, then to an IVR for clients to leave messages. I have not been able to duplicate this problem, but employees have complained that they experience what sounds like a hangup when they call in from time to time.
I am offsite right now, so I cannot physically inspect the cabling. As I said the logs are coming. Is there a way I can remove the caller ID name and the extension name from the file?
[2021-06-07 12:48:30] VERBOSE[24234][C-00000093] pbx_builtins.c: Goto (ext-group,420,1)
Ring group 420? Is that where the stoners hang out?
[2021-06-07 12:48:44] VERBOSE[24234][C-00000093] app_dial.c: Now forwarding DAHDI/2-1 to 'Local/71@from-internal' (thanks to PJSIP/451-00000199)
And one of them sent the call to the parking lot? 451 appears to be a Zulu extension. If it’s mobile, perhaps this happens accidentally when taking the phone out of the pocket? If it’s desktop, does the layout make it easy to do by mistake?
This is no longer looking like glare. It looks like you are unparking a call which isn’t the one you parked, and this unpark is result of call forwarding set on the actual extension device at PJSIP/451, not something within FreePBX. You also need to find where the call gets parked in parking lot 71, Maybe another destination device is call forwarding to your park a call extension?
Ring group 420? Is that where the stoners hang out?
Pretty naive here. That’s kind of funny. I’ll tell my reception team that I gave them that group number, they’ll probably get a kick out of it.
I would like to get SangomaConnect / Zulu set up, but one thing at a time. 451 is an actual Sangoma S505 phone, not a softphone. How do I fix that?
Would you explain “unparking a call that I didn’t park?” If a call isn’t parked, how can it be unparked. I think I’m missing some terminology. What does “where the call gets parked in parking lot 71” mean? I have three slots set up, do you mean slot 71, 72, or 73? Are they parking two calls together?