Hi Folks!
Noob here.
I have a Cisco SPA112 that is set up as an extension for a Polycom analogue conference room speaker phone. It works well… for a while. Sporadically, about 30 or 40 minutes into a call, the people on the other end of the call can’t hear us. The Polycom still things it is connected, but the audio is no longer heard.
How would I go about debugging this? Should I be searching for a specific error in the freepbx log file?
Thanks for your thoughts!!
Jim
A slightly more verbose description if your system will help you. OS FreePBX version etc.
Sorry - should have done that with the first post:
Sangoma Freepbx ISO. Current release is FreePBX 15.0.16.78.
What else would be helpful?
how you made an sip to fxs port an ‘extension’ of an analog conference phone. Do you mean the conference phone is plugged into the ATA? If so are the otherend’s LAN or WAN? If WAN, do LAN extensions experience the same?
Conference phone is plugged into the ATA. The other end is LAN to the freepbx server. Both are on the same LAN segment, no routing or bridging between the ATA and the freepbx box.
Calls work fine, inbound and outbound, for the first 30 minutes or so. Then outbound audio is muted, while inbound audio still works.
Almost always a NAT problem
It’s certainly possible, but what has me puzzled is no other extension has the issue, and the ATA connected conference phone works fine for the first 30 minutes or so.
I would expect NAT issues to apply to all extensions on the lan, and I would expect them to manifest for the duration of the call, not only after 30 minutes.
Is there a way I can verify NAT is confusing things?
Thanks for your help!
Jim
There are lots of sip ‘timers’ , personally I never needed to adjust them. Perhaps someone else can kick in here ?
There are a ton of posts about this - search for ‘30 minutes’ in the search bar at the top right of the screen and you’ll see that there are a bunch of timers that need looked at, including some that have to do with NAT associations.
OK so if I’m reading all this correctly, the call is happening and then outbound audio stops working. Which would mean the RTP packets leaving the network out the router are not being received by the other side. Conversely, the inbound audio continues to work. The RTP packets that would be entering the network through the router and thus firewall/NAT rules being processed for those packets.
So how is this a NAT problem for @jbresee? I mean it could be a NAT problem but that would be on the other side that can’t get the audio. Because if this was truly a NAT issue with jbresee’s side, then the inbound audio would die.
@jbresee are you able to replicate this with another device? Have a call last over 30 minutes and have the outbound audio die on it while the inbound continues to work?
Nope - only the conference phone connected to the ATA.
Every other phone works as expected.
Set up FreePBX to record these calls. When trouble occurs, see whether audio from the conference room continues to be recorded.
If so, the trouble is with your trunk or conference bridge; post details about the provider(s) involved, whether your PBX is supplying a conference bridge, etc.
If not, bridge a single-line analog phone on the SPA112 port. When trouble occurs, pick up the analog phone. If you can be heard through that, the Polycom is at fault.
If you get here, running a tcpdump capture on the PBX should show whether the SPA stops sending RTP, the RTP goes silent, etc. Report details and we can suggest how to troubleshoot further.
Stewart,
Thanks so much for the debugging ideas! I’m going to bridge the ATA ports if I can find analogue phone kicking around.
Other info:
Zoom or Google Meet are the conference bridge providers. The issue occurs on both. The PBX is not providing a conference bridge.
The VOIP provider is Flowroute
The ATA is set up as a PJSIP extension
I’ll post back what I find with the ATA bridged.
Set up a test conference like this:
You can call in periodically from another extension to see if it’s still working. When it fails, test with the analog phone and listen to the recording.
If it doesn’t fail, it’s pretty likely a problem on the trunk side and you can retest using a dummy two-participant meeting.
This topic was automatically closed 31 days after the last reply. New replies are no longer allowed.
