3CX and Mikrotik - Sip trunk outbound audio cuts randomly

[shivanuo]

Hi,
i wanted to ask to see if someone had this issue and managed to fix it. This is most likely a router issue, i had SEVERAL issues like external extensions not being able to register on UDP OR being able to register but randomly dropping and never reconecting, i fixed this by switching to TCP for the external extensions.

The SIP trunk registration was having a similar issue, i had to set a mangle rule to "passtrought" everything going to the sip trunk ip. This seem to have fixed it.

Now the severe issue im having is the outbound audio cuts randonly, be at 5 seconds so it has not even finished playing the IVR audio, or 30, 2min or it may never happen. It is only the outbound audio that cuts, the inbound always work. And everything that i do seem to make matters worse.

Right now, the sip alg is disabled, the UDP timeout on router is set to 35 sec, the UDP stream timeout to 5m, the 3CX is set to manage audio on the sip trunk, on network the nat-keepalive is set to 30 secs, the option to send media to ip and port of register is enabled.

The sip trunk media udp port range is 13000-18000 not sure if that has anything to do with something.

And the 3CX firewall check passes.

 

[AWS2P]

You can try asking @Edi Kojsi , he has a very deep knowledge of Mikrotik routers, surely this is the man who can help you to set yours like it should.

 

[cobaltit]

Did you follow this guide?

https://www.3cx.com/docs/mikrotik-firewall-configuration/

 

[shivanuo]

Did you follow this guide?

https://www.3cx.com/docs/mikrotik-firewall-configuration/

Yes i did.

 

[YiannisH_3CX]

From your description it does look like you are having issues with your router/firewall. However since the issue is intermittent it is much harder to track down the cause of the issue.
One thing you can try is to bypass the Mikrotik entirely and see if the issue can be replicated. Next on the list is leave a trace running using t-shark to see if you can catch the issue. Then open it using wireshark and see if you locate the cause of the dropped audio.

 

[complex1]

Which type of MikroTik router are you using?
Are you running latest firmware (6.45.1 stable)?
Are you using the default Firewall rules?
Is fasttrack enabled?
Are you using QoS rules?

 

[shivanuo]

Which type of MikroTik router are you using?
Are you running latest firmware (6.45.1 stable)?
Are you using the default Firewall rules?
Is fasttrack enabled?
Are you using QoS rules?

Hi,

1. a RB750GR3.
2. Yes it is 6.45.1
3. It is default, but im using 2 wan failover setup, nothing special just 2 gateways with diferent distance and 2 masquarade one for each wan interface. I did add a few other port routing all TCP for other applications.

4)fasttrack is disabled, but enabling it makes no diference.
5)Im running a hotspot on the router that why i disabled fasttack so the queue to limit traffict would work.

Other than having a hotspot running on a vlan, 2 wans whiout load balance and 2 networks it is petty much default. There is nothing advanced going on. The 3CX server, the ATA and all extensions are on the same network.
i did not mention this, but i also have a simple ATA (an HT503) connected to a copper line, this is working perfectly so far, this is why i belive it has to be routing issue.

What i did now, that SEEMs to be working or at least helping, remember how i said i need to enable a Mangle rule to passtrough all conections going to the sip trunk IP or it would not register, or it would register and losse registration after a while and become unreacheable? I change that rule to FORCE routing all traffic going to the sip trunk IP via the WAN 2. Not sure if it fixed the issue but it seems to be doing something, before doing that most of the time i could not even finish hearing the IVR.
WAN 1 is a cable modem on bridge mode and it does have a voip line, i wonder if that may cause conflict.

The thing that i really dont know, is that the SIP trunk provider uses port range 13000-18000 for UDP media this is the part i dont understand how the sip trunk to the 3cx communication works. As 3cx uses a completely diferent port range for UDP media.

 

[complex1]

Hi,

The RB750Gr3 should do the job well, I think.
What I want to suggest is enable fasttrack, temporary disable the mangle rules you use for the QoS and also temporary disable the Queue Tree rules.
If possible disable also the hotspot.
Restart the router and check with Torch the outbound traffic.
Also check if the audio quality on outbound calls are good, not drop-outs.

Your cable modem on bridge mode is IMO not a good choice, in stead, use it as a modem... no NAT.

 

[shivanuo]

Your cable modem on bridge mode is IMO not a good choice, in stead, use it as a modem... no NAT.

Hi ill try what you said.
The bridge mode on the cable modem disables the nat and directly passes the public ip on to the mikrotik router.

edit: i did torch to test it out as it is now, once the call is established i see one UDP conection going from one of the 3CX media ports to one of the sip trunk media trunk, this one seem to be petty much stable with constant 50 RX and TX packet rate.

and a second one randomly appearing and disapearing constanly on the port next to the first one, if i remember well 2 UDP media conections are used per call right?

 

[shivanuo]

Yeah i was on torch and i did see it happening, the TX just dies and goes to 0. But this is as minimal as i can go, hotspot was disabled, fasttrack was enabled, i only have 1 mangle rule to do a "passtrought" to the sip trunk ip, whiout that it just does not register, that ALONE makes no sense.

 

[complex1]

There are two things I do not understand in your configuration.

• Why do you use the UDP range 13000-18000? Don’t you use a supported provider?
• Why is your Mangle rule so important?

I use the RB4011 and use only two dst-nat rules to connect 3CX with the internet.
I do use two Mangle rules only for QoS outbound traffic, but this is not really necessary because my internet speed is 250/25Mb.
If I disable the Mangle and Queue Tree rules everything stay working.
So I think you have to re-check your NAT, Mangle and Queue Tree rules. NAT is the most important one.

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=5090,5060,5061,5001 in-interface-list=WAN protocol=tcp to-addresses=[3CX Server LAN IP]
add action=dst-nat chain=dstnat dst-port=5090,5060,9000-10999 in-interface-list=WAN protocol=udp to-addresses=[3CX Server LAN IP]

 

[shivanuo]

Ive disabled the 13000-18000 i did enable it because it was on the setting my sip provider gave me, but is really not needed. Yes it is not supported on 3CX so i used generic sip.

Im not going anywhere at this point so im going to do this, ive replaced the router for another one, of another brand and ill be checking if anything works ok. If no problems arrise im going to factory reset the Mikrotik router and try it out with just the default config and the port routing in nat. if that dosent work there is either a bug in software or hardware fault.

 

[cobaltit]

So just some slight confusion it looks like there. 3CX uses 9000-10999 and your provider uses 13000-18000. What that means is that 3CX sends traffic from or expects traffic from 9000-10999 and your provider sends/expects traffic in their range. On basic configurations you only need to port forward the 3CX range on your firewall. Only if you are restricting outbound traffic by port ranges would you need to do anything in your firewall for your provider.

Another firewall is always a good way to test.

 

[shivanuo]

Ok this still happens with another router, altrought a bit less frecuent, i dont know what to do anymore.

What else could be? it is strange the audio drops ALWAYS in the same way, the outbound. Maybe, just maybe, 3CX is doing transcoding for the outbound to my sip trunk and this is failing somehow?
There is any way that i could check this?

Whats worse, people is telling me this started to happen when i switch from other PBX system that i had running on a VM on the server to 3CX, thats one of the reasons of why i switched to 3CX. I cant tell if this is 100% accurate, but at least no one told me of this issue before, thats for sure.

My sip provider gave me the configuration for asterisk

[NOMBRE_USUARIO_SIP]
type=friend
username=NOMBRE_USUARIO_SIP
context=SUCONTEXTOENTRADA
canreinvite=no
fromuser=NOMBRE_USUARIO_SIP
secret=SIP PASSWORD
host=
insecure=invite
dtmfmode=rfc2833
disallow=all
;;;;CODECS SERVICIO IPT TRUNK
allow=ilbc
allow=g726
allow=gsm
;;;;CODECS SERVICIO ATI TRUNK
allow=alaw
qualify=yes
sendrpid=yes
trustrpid=yes

I got this working with codecs G.711 A-law,GSM-FR and iLBC .

 

[shivanuo]

Also ive been reading the 3CX Media server logs and i have a lot of warnings

18:50:21.540|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:19.1:Offer received. RTP connection: 192.168.80.5:5014(5015)
18:50:21.553|00000fb8| Info|msendpoint.cpp(1768): 10:[MS210002] C:19.2:Offer provided. Connection(transcoding mode): 127.0.0.1:7072(7073)
18:50:21.800|00000fb8| Info|msendpoint.cpp(2470): 10:[MS210001] C:19.2:Answer received. RTP connection[unsecure]: 127.0.0.1:12024(12025)
18:50:21.801|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:19.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.80.2:7070(7071)
18:50:44.002|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:19.2:Offer received. RTP connection: 127.0.0.1:12024(12025)
18:50:44.002|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:19.2:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7072(7073)
18:51:00.489|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:19.3:Offer received. RTP connection: 192.168.80.5:5004(5005)
18:51:00.489|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:19.3:Answer provided. Connection(transcoding mode[unsecure]):192.168.80.2:7074(7075)
18:51:00.543|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTP receiver for [email protected]:5482(C:19.4) has no assigned socket
18:51:00.543|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTCP receiver for [email protected]:5482(C:19.4) has no assigned socket
18:51:00.543|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38 receiver for [email protected]:5482(C:19.4) has no assigned socket
18:51:00.543|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38_ receiver for [email protected]:5482(C:19.4) has no assigned socket
18:51:00.746|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTP receiver for [email protected]:5482(C:19.2) has no assigned socket
18:51:00.746|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTCP receiver for [email protected]:5482(C:19.2) has no assigned socket
18:51:00.746|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38 receiver for [email protected]:5482(C:19.2) has no assigned socket
18:51:00.746|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38_ receiver for [email protected]:5482(C:19.2) has no assigned socket
18:52:31.259|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTP receiver for [email protected]:5482(C:19.3) has no assigned socket
18:52:31.259|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTCP receiver for [email protected]:5482(C:19.3) has no assigned socket
18:52:31.259|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38 receiver for [email protected]:5482(C:19.3) has no assigned socket
18:52:31.259|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38_ receiver for [email protected]:5482(C:19.3) has no assigned socket
18:52:31.263|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTP receiver for [email protected]:5482(C:19.1) has no assigned socket
18:52:31.263|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:VRTCP receiver for [email protected]:5482(C:19.1) has no assigned socket
18:52:31.263|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38 receiver for [email protected]:5482(C:19.1) has no assigned socket
18:52:31.263|00002884| Warn|rtpreceiver.cpp(440): 5:MediaProxy:T38_ receiver for [email protected]:5482(C:19.1) has no assigned socket
18:54:46.350|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:20.1:Offer received. RTP connection: 192.168.80.5:5014(5015)
18:54:46.364|00000fb8| Info|msendpoint.cpp(1768): 10:[MS210002] C:20.2:Offer provided. Connection(transcoding mode): 127.0.0.1:7080(7081)
18:54:46.615|00000fb8| Info|msendpoint.cpp(2470): 10:[MS210001] C:20.2:Answer received. RTP connection[unsecure]: 127.0.0.1:12026(12027)
18:54:46.615|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:20.1:Answer provided. Connection(transcoding mode[unsecure]):192.168.80.2:7078(7079)
18:55:08.785|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:20.2:Offer received. RTP connection: 127.0.0.1:12026(12027)
18:55:08.786|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:20.2:Answer provided. Connection(transcoding mode[unsecure]):127.0.0.1:7080(7081)
18:55:29.919|00000fb8| Info|msendpoint.cpp(2465): 10:[MS210000] C:20.3:Offer received. RTP connection: 192.168.80.5:5004(5005)
18:55:29.919|00000fb8| Info|msendpoint.cpp(1773): 10:[MS210003] C:20.3:Answer provided. Connection(transcoding mode[unsecure]):192.168.80.2:7082(7083)

 

[shivanuo]

Well, what i did now as a test is re-enable the freepbx vm and instead of having 3CX directly connected to the sip trunk, the freepbx conects to the sip trunk and and have a 3CX trunk conected to a extension on freepbx.

This seems to be working, we havent had a audio drop in a middle of a call for 2 days now. Altrought im having a diferent issue of incoming audio not always working.

Im think im done at this point, this is not working for me. If i cant find a quick fix im going to move back to freepbx.

 

[JohnS_3CX]

Is your ISP running any SIP ALG or VoIP on the modem that could be causing conflicts?

 

[shivanuo]

Is your ISP running any SIP ALG or VoIP on the modem that could be causing conflicts?

No. But this was the issue, if i use FreePBX to connect to the sip trunk and pass all calls to a extension and i have 3CX trunk connected to that extension this issue does not happen.

At first i trought it may be some issue with ports or routing but the audio is cut ALWAYS in the same direction it dosent seem possible. And if there is more than one call at the same time to the sip trunk all calls losse audio at the same time. This happened 2 or 3 times.

Problem is, i cant really "try blindly" anymore, so i leaving it as it is for now. I still suspect it was some issue with the media server doing transcoding on iblc or gsm codecs.

 

[JohnS_3CX]

I reckon since this happens often, keeping tshark running in the background will catch a couple of problematic calls. You don't have to try blindly in this case, it will do the work for you.

Then you can listen to the audio streams in wireshark and at least find out whether the PBX sends the audio so you can eliminate it as a factor and move to the next element.