We have an externally hosted SIP provider. Inbound and outbound calls work fine. Calls between extensions at one site get no audio between each other.
I’m working with a technician from the SIP provider. They usually work with Cisco and usually fix this problem with the following example configuration
#show run | inc nat
ip nat outside
ip nat inside
no ip nat service sip udp port 5060
ip nat inside source list 5 interface FastEthernet4.3605 overload
ip nat inside source static udp 192.168.7.5 5060 interface FastEthernet4.3605 1025
ip nat inside source static udp 192.168.7.6 5060 interface FastEthernet4.3605 1026
ip nat inside source static udp 192.168.7.7 5060 interface FastEthernet4.3605 1027
Does anyone know how I would convert this to Mikrotik? The VLAN on FastEthernet4 is irrelevant on this network.
Here is what I’ve tried.
It’s impossible to fix the issue efficiently without diagnosing the cause. Do you have any SIP traces? I would expect your provider to of gathered these.
I would suggest gathering a SIP trace either side of your router, using the below instructions, opening it in Wireshark and filtering out everything BUT the sip and RTP (Filter- sip||rtp) and posting it here if you don’t have any sensitive traffic.
/tool sniffer set file-limit=200000KiB file-name=Inside.pcap filter-interface=Inside
start
(Make a test call, one external, one internal)
stop
(Save the .pcap somewhere)
/tool sniffer set file-limit=200000KiB file-name=Outside.pcap filter-interface=Outside
start
(Make a test call, one external, one internal)
stop
(Save the .pcap somewhere)
I’m not a Cisco expert but the code you have shown appears to only be a basic NAT setting. I’m not sure why it’s done per phone IP, rather than a global rule on the ‘outside’ interface. It also shows the SIP Helper as disabled which is advised.
Yes we did try a packet capture, but I didn’t think of trying to capture on the external interface. I’m not real well versed in Wireshark (I’ve used it once or twice a year for the past 10 years) so I captured with the following settings but the SIP provider said they didn’t see a lot of the expected RTP traffic in the capture even on a internal to external (working correctly) call. The SIP provider assumed that the Mikrotik was not capturing the data correctly.
/tool sniffer
set file-limit=40000KiB file-name=IPPhoneCap3 filter-ip-address=172.16.0.20/32 memory-limit=40000KiB
Should I filter by interface instead of the IP of the SIP phone?
Also it is only the internal to internal calls that we have problems with. Internal to external and external to internal work as they should.
I generally try and capture as much as possible but obviously in a high traffic environment it may be better to filter it by IP to minimize the size of the pcap.
I usually recommend an internal and external packet capture in case the router is manipulating the traffic in anyway.
Do you know what platform your SIP provider is using? Some platforms E.G Kamailio will try to route the voice traffic locally if it can - maybe something is going wrong here.
Here is the LAN configuration. I’m not doing anything special here.
/interface bridge
add admin-mac=Removed auto-mac=no mtu=1500 name=bridge-local
/interface wireless
set [ find default-name=wlan1 ] band=2ghz-b/g/n country="united states" disabled=no distance=indoors frequency=2437 l2mtu=2290 mode=ap-bridge ssid=Removed wireless-protocol=802.11
/interface ethernet
set [ find default-name=ether1 ] name=ether1-gateway
set [ find default-name=ether2 ] name=ether2-master-local
set [ find default-name=ether3 ] master-port=ether2-master-local name=ether3-slave-local
set [ find default-name=ether4 ] master-port=ether2-master-local name=ether4-slave-local
set [ find default-name=ether5 ] master-port=ether2-master-local name=ether5-slave-local
set [ find default-name=ether6 ] master-port=ether2-master-local name=ether6-slave-local
set [ find default-name=ether7 ] master-port=ether2-master-local name=ether7-slave-local
set [ find default-name=ether8 ] master-port=ether2-master-local name=ether8-slave-local
set [ find default-name=sfp1 ] name=sfp1-gateway
/interface wireless security-profiles
set [ find default=yes ] authentication-types=wpa2-psk eap-methods="" mode=dynamic-keys supplicant-identity=MikroTik wpa2-pre-shared-key=Removed
/interface bridge port
add bridge=bridge-local interface=ether2-master-local
add bridge=bridge-local interface=wlan1
/interface ethernet switch port
set 0 dscp-based-qos-dscp-to-dscp-mapping=no
set 1 dscp-based-qos-dscp-to-dscp-mapping=no
set 2 dscp-based-qos-dscp-to-dscp-mapping=no
set 3 dscp-based-qos-dscp-to-dscp-mapping=no
set 4 dscp-based-qos-dscp-to-dscp-mapping=no
set 5 dscp-based-qos-dscp-to-dscp-mapping=no
set 6 dscp-based-qos-dscp-to-dscp-mapping=no
set 7 dscp-based-qos-dscp-to-dscp-mapping=no
set 8 dscp-based-qos-dscp-to-dscp-mapping=no
set 9 dscp-based-qos-dscp-to-dscp-mapping=no
All 3 phones are hard wired - Ports 2,3 and 7. All computers (3-5 in think) are wireless. Nothing else is plugged into the switch. Not really a high traffic environment, I just thought it would be easier for me to read with my limited Wireshark abilities. After thinking about it though, with the phone being directly connected, capturing the entire port probably wouldn’t add much (just broadcasts).
I believe the SIP provider mentioned Mitel as the platform. He did say that they usually try to route the calls locally.
I am hesitant about posting a capture publicly unless that SIP provider is ok with it, but maybe capturing the entire port will give them something else to look at.
Yes I tried that too. It’s at the bottom of the firewall config in the first post. I also disabled h323 because the SIP provider suggested disabling h225 which as far as I can tell is a subset of h323.
I will retry the packet capture with port filter instead of IP filter and see if I get anything different.
The difference is that in internal calls, phones will try to establish a direct connection between them via a RTP reinvite, to bypass the PBX.
You could start by disabling RTP reinvite on your PBX. This will force all phones to work via it (as in external calls).
And then start analyzing, why a direct phone to phone conversation is not possible (some port to ports 5060/5061 on your LAN).
BTW, enabling the SIP helper for ports 5060 and 5061 with Direct Media = yes might help.
Thanks for the suggestion docmarius. SIP helper was enabled when this issue was first brought to our attention. Looking at the suggestions here on the forums and on other sites as well as our SIP provider, many of the first suggestions are to disable it. Unfortunately it doesn’t seem to matter either way in my situation.
Yes I was able to run a capture again and sent it to the SIP provider (he was going to pass it on to one of their engineers). Now there is a hold up on the customers end… possibly indefinitely. If they want me to continue working on it at some point I will post back any new findings. Thanks for your help.
Just thought I would post an update. The ISP changed the DSL modem and all of the SIP calls started working correctly. Sorry I don’t have the models. I believe the new one is an Arris.