Community discussions

MikroTik App
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

The VoIP odyssey

Sat Dec 30, 2023 6:49 pm

Hello community,
lust but not least I turn to all of you, after my 3/4 year VoIP odyssey.

Quite at the beginning of 2023 I migrated my complete home network from a virtual machine running pfsense, later opnsense behing an AVM FRITZ!Box to a complete mikrotik system. Last but not least I ended up installing a CRS326-24G-2S+ as my edge router and main switch. And then the journey began:

Just to inform you about my other VoIP setup: I own a Auerswald ComPACT 5020 VoIP, that worked pretty well behind the first setup with FRITZ!Box and pfsense. After using RouterOS on my edge router the problems started: Sometimes no calls from outside to my local landline accounts running on the Auerswald were possible. But sometimes everything worked pretty well. (Very nice to debug such situations ;) ). So after trying around millions of options and settings, I figured out that the FRITZ!Box received an OTA updated, which removed the official support for pppoe tunneling (the fritzbox worked as a bare modem). After sniffing some traffic, I found out that SIP invites from outside that exceeded the pppoe MTU were somehow dropped by the fritzbox since they removed the pppoe passthrough support. After replacing the Fritzbox with a bare vigor dsl modem, the strange problems were gone .... almost. (Finding this problem took me already 6 months)

Now, the internal phones are still sometimes not reachable from the outside. I will outline my current configuration and some other steps I've already done, to check whether I might have overseen something.

Basics:

The Auerswald is reachable at 10.0.0.4
The external sip connection listens at 5064 (udp)
The rtp ports reach from 49152-49408

Current setup, works most of the time. Sometimes a restart of the Auerswald is necessary to get it back working
/ip/firewall/service-port/set sip ports=5064,5060
The disregarded sip-helper seems to extend the udp timeouts to keep the ports open through NAT. But this works not always. Maybe one problem with connection tracking might be, that the German 1&1 provider sends sip invites from two different IP-Addresses. If the connection tracking was set-up with the wrong one, an incoming INVITE might be dropped.

DSTNAT approach, did not work
So I finally ended up setting up dstnat rules, the same way I've done for other appliances like my webserver and so on:
/ip firewall nat
add action=dst-nat chain=dstnat comment="XXX TEL" dst-port=5064 in-interface=pppoe-out1 log=yes log-prefix=\
    "> SIPNAT IN" protocol=udp to-addresses=10.0.0.4 to-ports=5064
add action=dst-nat chain=dstnat comment="XXX TEL" dst-port=49152-49408 in-interface=pppoe-out1 protocol=udp \
    to-addresses=10.0.0.4 to-ports=49152
This was the way I set-up the "port forwarding" in the older pfsense installation. Somehow this does not work on RouterOS. I'm still not sure why, because even after restarting the incoming SIP-invites get logged, but no phones ring. With the sip-helper approach instead they do (sometimes :? )
One thing someone may answer is whether an outgoing connection from the Auerswald might block the port when the connection is tracked by the connection tracking? I didn't find that out by reading the docs. In pfsense there was moreover a setting to remove the port randomization with masquerading, with RouterOS I think there's no randomization, thatswhy that might not be a problem?

This were my last tries regarding the VoIP problem. The whole story within the first 6 month which consisted of complex firewall constructs, packet sniffing, adding rules to prevent ip fragementation and so on I will leave out here, because the FRITZ!Box was the problem. But I'm still kind of confused. I understand that the sip-helper does maybe a bad job, I often read advisory on not to use this feature. Maybe the two different source addresses 1&1 sends packets from might be a big problem with that. :( But what am I doing wrong with the static dstnat firewall rules? Why don't they work. And is there an option to maybe rewrite the source address on incoming invites to only one static address of the first 1&1 server?

I'm at the end of my tether :D
 
pe1chl
Forum Guru
Forum Guru
Posts: 10551
Joined: Mon Jun 08, 2015 12:09 pm

Re: The VoIP odyssey

Sat Dec 30, 2023 7:59 pm

Deploy IPv6.
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey

Sat Dec 30, 2023 8:27 pm

I have. But as far as I know the Auerswald does not support IPv6
 
pe1chl
Forum Guru
Forum Guru
Posts: 10551
Joined: Mon Jun 08, 2015 12:09 pm

Re: The VoIP odyssey

Sat Dec 30, 2023 10:08 pm

It is astonishing that the markets that traditionally suffer the most from IPv4 NAT are often ones lagging behind in IPv6 implementation!
VoIP is one example of that. Mobile telephony providers is another.

All your trouble (and that of the many other persons fighting with these issues) would be over when you could just use IPv6.
But I know. I have a VoIP provider that still doesn't support it, and a VoIP phone that can only work either in IPv4 or in IPv6 (for all the accounts it has to be the same).

These people are clueless.
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey

Sun Dec 31, 2023 1:36 pm

I also thought about that. That the Auerswald does not support IPv6 is okay in my opinion, because the appliance is pretty old. I mainly use this one because there are several analogous W48 phones with dialplate connected. I already though about switching to analoge grandstream adapters.

But why many providers does not support ipv6 I really can't get. I also dont understand why 1&1 does not stick to the standard and send invites from two different IP addresses. I think their systems are made to work with a fritzbox where the phone server is installed directly on the box. I also don't understand why they don't support SIP over TCP. That would have solved my earlier IP fragmentation problem.

But is there anybody here who has configured ROS for SIP passthrough and can maybe share his firewall rules?
 
lightmanster
just joined
Posts: 14
Joined: Tue Aug 29, 2017 11:04 am

Re: The VoIP odyssey

Sun Dec 31, 2023 1:48 pm

Hi

I use same MT device at several places with voip. The problem is 9 out 10 times not nat aware sip devices together with sip proto.
Device put there local private ip in the SIP header. The public hosted VOIP server dont know how to reach the private ip in header. It doesnt look at the IP header. Sometimes you can tell the PBX to ignore SIP header ip and tell that the device is behind NAT (asterisk does have that setting)
Use wireshark to see whats realy going on. SIP is L7 layer thing. So ALG will help you if you implement it well.

David Attias has done a wonderfull seminar about sip problems. Have a look at US MUM https://www.youtube.com/watch?v=tM7wyKdnIKA

Hopefully it will bring answers.
 
pe1chl
Forum Guru
Forum Guru
Posts: 10551
Joined: Mon Jun 08, 2015 12:09 pm

Re: The VoIP odyssey

Sun Dec 31, 2023 3:27 pm

I already though about switching to analoge grandstream adapters.
When you are considering buying something new, stay away from Grandstream!
They don't understand IPv6 at all. I made a support ticket 10 years ago, and another one this year, and they still have
not implemented dual-stack! That is why I cannot use IPv6 with my Grandstream 2160 phone. It can be configured to
use IPv6 but then it does not support IPv4 anymore.
 
lightmanster
just joined
Posts: 14
Joined: Tue Aug 29, 2017 11:04 am

Re: The VoIP odyssey

Sun Dec 31, 2023 3:31 pm

I doubt IPV6 will solve your problems. Problem is AFAIK at L7 instead of L3.
 
User avatar
mkx
Forum Guru
Forum Guru
Posts: 13154
Joined: Thu Mar 03, 2016 10:23 pm

Re: The VoIP odyssey

Sun Dec 31, 2023 3:48 pm

I also don't understand why they don't support SIP over TCP.

Because TCP is unfit for real-time protocols. Sometines it's better to drop a packet (and live with garbled sound for a fraction of a second) than to introduce longer delay with muted sound (necessary for TCP to retransmit) and then deal with ever increasing delay (or somehow shorten it). If available bandwidth is much higher tgan required for VoIP service, then these problems are not so grave, but SIP was concieved in times when 100s of kbps was deemed luxury.

BTW, all telco voice technologies since beginning of digital era (i.e. 2G - that's GSM for Europeans - and forward, and including 5G) use unacknowledged mode (similar to UDP) to transmit voice data, so no retransmissions over the air. There is additional technology involved though: FEC (Forward Error Correction) adds redundant information to payload, which allows to reconstruct payload of damaged packet on receiver side ... voice data is then divided into 3 classes, most significant portion gets most FEC bits, least significant portion gets none. Which means that in case of damaged packet, chances are that significant part can be reconstructed to its original and thus playback will sound decently enough.
This is the only way to avoid excessive pauses and/or long delay (the later kills duplex communication experience).
 
pe1chl
Forum Guru
Forum Guru
Posts: 10551
Joined: Mon Jun 08, 2015 12:09 pm

Re: The VoIP odyssey

Sun Dec 31, 2023 4:07 pm

We recently got a new Mitel VoIP system at work (I was not involved in its selection) with phones that are fully self-configuring.
It uses SIP over TCP (port 5060). I was surprised as well, but they probably do that to solve all NAT issues.

The phones connect to some central server, get recognized as belonging to our company, receive their configuration (probably including the fact the are going to use TCP) and then connect to our provider.
 
User avatar
Amm0
Forum Guru
Forum Guru
Posts: 4468
Joined: Sun May 01, 2016 7:12 pm
Location: California
Contact:

Re: The VoIP odyssey

Sun Dec 31, 2023 11:05 pm

It uses SIP over TCP (port 5060). I was surprised as well, but they probably do that to solve all NAT issues.
FWIW...that the SIP signaling using TCP, the RTP audio is likely still UDP...

With some cloud PBX, the SIP ALG may not be helpful (or may be neutral or needed too). If OP is still having troubles, sometimes worth it to disable the SIP ALG:

/ip/firewall/service-port/set sip disabled=yes

or enable it:

/ip/firewall/service-port/set sip disabled=no
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey

Mon Jan 01, 2024 2:46 pm

With the SIP ALG it partially works. Most of the time incoming calls work pretty well. But only most of the time. I think it has something to do with the timeouts of the connection tracking.
Therefore I wanted to try it with SIP ALG disabled and installing stating firewall rules, ant this somehow didn't work.
I will experiment a bit around with the NAT settings of the auerswald, maybe I can fix this.
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey

Mon Jan 01, 2024 3:06 pm

Thank you for the nice video:
Regarding this video I also found out, why my static firewall rules probably didn't work: As he says, a full reboot of ROS is necessary when changing settings related to the SIP ALG. So probably deleting all active connections was simply not enough!

Now I fine-tuned the configuration of the auerswald and disabled all nat traversal features in the PBX system. I will check if this solved the trouble and report later in this post here!
 
User avatar
rextended
Forum Guru
Forum Guru
Posts: 12652
Joined: Tue Feb 25, 2014 12:49 pm
Location: Italy
Contact:

Re: The VoIP odyssey

Mon Jan 01, 2024 3:31 pm

CRS326-24G-2S+ as my edge router and main switch
It's all wrong from the start, if you use a product created to be a switch as a edge router.

Try this, and use static DHCP lease for VoIP phone, with renewal each 10 minutes, instead of fixed address inside the phone.
/ip firewall connection tracking
set loose-tcp-tracking=no tcp-established-timeout=30m udp-stream-timeout=2m udp-timeout=30s
/ip firewall service-port
set sip disabled=no sip-direct-media=yes sip-timeout=10m

Check the pppoe actual MTU (and if your "ISP" do not support 1500, ask "ISP" to fix that shit...),
and consequently configure correctly the VoIP phone, if you can do that

add on the phone static dhcp lease the correct dhcp option MTU if the configuration interface can not set correctly the MTU (do both for be sure)
/ip dhcp-server option
add code=26 name=Interface-MTU-1500 value=0x05dc
add code=26 name=Interface-MTU-1492 value=0x05d4
add code=26 name=Interface-MTU-1480 value=0x05c8


And whatever happens, you have to provide a complete /export, maybe you made mistakes elsewhere...
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey

Mon Jan 01, 2024 5:21 pm

It's all wrong from the start, if you use a product created to be a switch as a edge router.
Why is using a CRS as an edge router a bad idea? It's running RouterOS

I've also sticked to the SIP ALG video and make use of this. Currently it works pretty well. I think the nat traversal and stun options of the auerswald messed up in combination with the SIP ALG.

I will check whether it keeps running over the next days
 
User avatar
BartoszP
Forum Guru
Forum Guru
Posts: 3095
Joined: Mon Jun 16, 2014 1:13 pm
Location: Poland

Re: The VoIP odyssey

Mon Jan 01, 2024 6:14 pm

It's all wrong from the start, if you use a product created to be a switch as a edge router.
Why is using a CRS as an edge router a bad idea? It's running RouterOS
...
Just because switches are switches and routers are routers. Both types of devices are designed to do different things fast.
Switches do switching and routers do routing.

You can use a truck with a tarpaulin to transport people but using a bus seems to be a better solution even if both types of vehicles share the same type of steering wheel, wheels and driver's driving license type needed to drive these vehicles.
 
User avatar
robtor
Frequent Visitor
Frequent Visitor
Topic Author
Posts: 95
Joined: Sat Dec 09, 2023 3:27 pm
Location: Germany, Hessen
Contact:

Re: The VoIP odyssey  [SOLVED]

Tue Jan 09, 2024 10:19 pm

So to close this thread here, I have my lastly setup now running for about two weeks without any problems. The SIP ALG works pretty well, but with all nat traversal options within the PBX system disabled! Now I don't have issues anymore!