Running into a weird issue that I haven’t before. Got a box setup on vultur. Phones at an office registering using pjsip to the system via a fqdn and using the responsive firewall.
Calls made to the system via an external caller work great. Calls made out from a phone in the office to an external caller work great. Echo tests from extensions to the pbx work great. BUT
With a couple of particular extensions, if one extension dials another extension the callee cant hear the caller but the caller can hear the callee. I’ve double-checked asterisk sip settings and think that everything is right. I’ve worked with a similar setup a few different times and not run into an issue like this… I suspect its a nat issue since most of the time one-way audio is but I can for the life of me figure out where/why it’s happening.
I’ll see your Coke and raise you a beer. If setting Local Networks doesn’t help, try turning off Direct Media for the extensions – a SIP ALG or NAT traversal setting in the client may cause pjsip to determine that the extensions can communicate directly, though they actually cannot.
the call was between extension 221 and 222. 221 initiated.
I’ve also noticed a few times when a call is placed between extensions, sometimes when one side hangs up, the other doesn’t follow. It acts as if the call is still going. It isn’t frequent. not sure if that helps.
This is not an ordinary call between extensions – it is an intercom call to an extension that has two active registrations (ports 9906 and 54807). It appears that the system implements this by setting up a conference bridge, making auto-answer calls to both registrations and bridging the three devices together. That way, the human at either destination device should be able hear and speak to the caller. I don’t understand what went wrong but suspect it’s not related to SIP, NAT or any other low level networking problem. You should be able to confirm this by making a regular (non intercom) call to extension 222, which I’m guessing will result in two way audio.
In the intercom call, there were several errors and warnings related to the conference that might be related to the failure. Posting the regular Asterisk log instead of the console output would help, as it would contain ‘verbose’ and ‘debug’ entries useful for following the dial plan.
I don’t use multiple registrations myself (in my experience it usually results in poor workflow) so haven’t observed this before. I hope that with the complete log, one of the wizards on this forum can spot the problem.
In this call, there were no replies to the INVITEs sent to port 54807. Possibly, Dana has only one device on 222 but the NAT association was somehow lost and when reestablished, the local router assigned a different source port. If that’s the case (you don’t actually use multiple devices on the same extension), setting Max Contacts to 1 (with remove_existing) should eliminate the trouble. You could also consider a shorter registration expiry and/or setting the firewall to disable source port rewriting, called ‘consistent NAT’ on some platforms.
That’s almost certainly related. If a three way conference is set up and one party disconnects, there are two devices remaining so the bridge is not taken down.
GOOTTCHA. Ok. That makes sense now. I did notice that there were 2 registrations and thought that was kind of weird. Knowing what you’d said helps a lot now. Thank you very much for taking the time to look at it. I should have posted the actual log. Not sure what I was thinking when I grabbed it from the console.
Yeah, we are using pfsense on a netgate device at this location. I know by default it does port rewriting, so I’ll see about getting that configured.
I’ll make a few adjustments and see what we can make happen.
So, the issue only seems to be with intercom calls now. Went through and tried with and without direct media, no change. Made sure all networks were listed in Asterisk SIP settings. Set up pfsense to no do port rewriting.
Everything works right now except intercom calls??? Lol
willing to up the anty here a little bit haha, case of beer if we can figure it out.
Do you think stun severs could help in this instance?
Not sure where the multiple registrations are coming from. When the extensions are created, in asterisk info, there are “matching” extensions but they are with 99xxx (the x’s match other extension numbers.) and those are being referenced in the call. What are the 99xxx extensions? Would they be for WebRTC?