IAX Weirdness

General Help
1

Hi Guys
VERY long term freepbx user here. Setting up a new site a week back we went with V16 and found a LOT of stuff was broken. The system wasnt stable and didnt behave as expected. We lost all network connectivity overnight a few times and we were having weird IAX issues. So, Long story short. We rolled back to V15 and all is well, mostly The weird IAX issue persists…

We have Site A, a long established site, everything works here except the phone for their roaming gnome, and that’s a Grandstream Issue. This site has about 20 phones, 4 sip trunks to VOIPfone and is sat behind a PF box on gigabit fibre.

Site B is in the middle of no-where. Fibre is promised but the best install date is “before xmas” so they are sat on a LEO satellite system (Starlink).

The two sites are linked by an IAX2 trunk thats encapsulated in an uncmpressed VPN. A is 192.168.10.3, B is 192.168.11.3 and access to all services between networks works perfectly.

So as it stands, a call somes into site A, goes through ivr, setcid, ring groups etc everything as it should, rings the phones on both sites, anyone can answer, everything works except the truckload of jitter on Site B but it’s liveable.

Site A can call all of Site B’s phones, this all works, and Site A can transfer calls. In short, going A-=>B works perfectly

Going B to A or the trunks, it goes wrong. There’s no audio, and more than that there is no sign of anything audio stream like in the traffic. I can see IAX control data but no stream. Moreover looking at either ends at the phone/trunk level there is also no sign of rstp streams. The call progresses as it should, the call is connected and bar the lack of any audio in any direction its working. There are no errors I can see anywhere in the console or logs, codecs all match along the path. Destination/Source phone model is not a factor (They have GS, Yealink, Aastra, Poly and a Cisco on my desk which all behave the same.

It feels like there is a negotiation issue setting up the audio streams to the target phone/trunk.

A second PJSIP channel going from B to A fixes it, albeit with no jitter buffer, so it’s choppy as hell. So the phones on either end do seem to work.

Adding a system recording to misc destintions on Site A works and gives me the recording on both networks, so initiation doesnt seem to be the issue, although I dont understand why I get that audio stream just fine.

I’ve checked codecs, traffic inside and outside the tunnel, briefly tied to punch IAX through Starlink’s CG-NAT (Didn’t work) and I’m now out of ideas. I’m going to attempt to route through our server farm later and see it it really is a site A issue but I just have run out of ideas.

2

Could you summarise your post a bit? You’ve got like five or six variables here. What do you want us to comment about?

3

I’m after ideas for what can be causing this one way audio issue on IAX2 which isn’t supposed to have issues like this, in fact, if you have two way audio coming from A to B then given my understanding of IAX B to A should be fine.

I’ve just brought up another trunk to our server farm, and the same issue. I can call site B just fine, but calls from Site B seem to only consist of control traffic, no audio and no sign of audio streams.

4

Can the phones all communicate with each other at both sites? It does not look at first like an IAX issue (everything runs over the same port) but that there is no RTP to actually send over the trunk in some cases.

1 Like
5

Yup, and that’s my thought too, it doesn’t feel like IAX but I’m stumped what else it can be. All internall calling at Site B is fine and calls from Site A are fine. it’s really, really weird. By stream I mean the stream inside the trunk, not a separate stream. So doing a packet capture I can see the audio stream inside the trunk.

Looking at the firewall logs nothing is slamming into the firewall trying to route outside the VPN or trunk.

Its driving me insane.

6

So you see RTP but it’s silent?

7

I can’t see enough data to know if the actual stream is there or not, silent/missing looks the same from a capture. Comparing it with known good implies it’s not there but assumption is the mother of … A good connection generates thousands of packets. The bad one I see packets that co-incide with the console (IAX2 set debug on) and no more.

I just can’t work out why its fine one way. I have the option to shelve this until the fibre is in but I really don’t see it being a Starlink issue as its wrapped in a vpn. The only thing I win with fibre is I can move the SIP trunks I need from Site A

I’ll also need IAX over Starlink to actually work myself in the near future. I guess if I can poke it at my leisure its less stressy.

8

I’m personally not a big fan of IAX and haven’t used it in a very long time. If you decide to change over to PJSIP then I could help you more (and you’d probably see more help from others on the forum as well).

9

Issue there is jitter buffer. If I can get a pjsip trunk going with the jitter buffer it should be good. Just working through setting up chan_sip but for obvious reasons pjsip would be preferable.

10
11

Yeah, see @comtech link and add the jitterbuffer function as a dialplan hook. Don’t go down the road of chan_sip; it’s a dead end.

12

Well, not ideal but its resolved with chan_sip for now. Site A has a few devices that do not work at all with PJSIP so it won’t be going away there until those devices are gone (GSM Gateway and a door entry system). Its all working perfectly and being chan_sip I can use my PRTG scripts too. I can get a lab setup here after events season is done and dig way deeper into what is going on and try and see what made 16 play up so badly. I’m not comfortable with the hooks just yet, I need to read up some more and maybe do a tutorial/videos on my YT channel when I do sus it out as it seems a common ask. This was a need it fixed now type situation, if any of you in the UK have had dealings with CQC you’ll understand :wink:

I had always assumed IAX2 was near bomb proof, you live and learn.

13

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