Hi all,

Been having a problem lately, speratic, and finally found the issue. When I make a outbound call to someone, my PBX send invite with SDp information to VoIP carrier. The SDP includes the UDP port to use on inbound for audio.

Somehow, Mikrotik does not keep that NAT alive and I get oneway audio.

I have captures that clearly shows that the RTP comming back to the mikrotik from the carrier, but does not show it going from mikrotik to the VoIP phone.

I read that there was issues with NAT keepalives and UDP. Is there a fix for this?

Thanks

i have similar issue in the pass, if i have for example

ITSP ---- Internet----Router---PABX(Asterisk)---SIP-DEVICE

The call was initiated by SIP Device via asterisk and routed to ITSP for example. On the ITSP side, the user could receive my audio, but not the opposite. It's more the SIP issue, that the call initiation established via asterisk but the media content transferred from SIP Phone (on LAN side) to ITSP (on Internet Side) directly. The reverse traffic could not be made, because in NAT situation my SIP Phone did not request the packet directly to the ITSP (the Asterisk did) and the router will not forward the packet to my SIP Phone back.

As simple workaround i just need to configure the asterisk to handle the media content as well. So i don't have to worry about one way voice connection caused by kind situation.

In my situation, mt does not send rtp from itsp to asterisk. Im thinking of having asterisk use specific ports for rtp and use port forwarding.

Why is this happening with mt and not any other router? A 20$ works better in this situation...


Sent from my iPhone4 using Tapatalk

I've experienced this issue as well!

Only Mikrotik-NAT destroys SIP. (Even with STUN!)
Any other router I tried for NAT worked without a hassle.

sup5, what was your solution? Remove the MT and replace with a 20$ router? LOL

I have spoken to alot of people that have asterisk server and MT and they all said to implement a seperate Firewall like PFSense.

I tested a bunch of 20€ routers against mikrotik NAT.
and all of them worked well. only mikrotik didn't work properly.

In the end we set up a SIP-proxy for SIP-NAT and abandoned IP-NAT completely.

We run thousands of SIP sessions through hundreds of Mikrotik routers with no problems. I do recommend that you disable the SIP NAT helper though.

We run SIP through mikrotik, too.
But we didn't get it to work properly behind a Mikrotik router configured to do NAT.

It can work just fine even with NAT. I find it's not a Mikrotik issue but rather an issue with understanding of SIP, RTP, STUN, UDPTL, etc.

Man reading the same old thing in every post about sip nat issues cries me to tears
and i start slashing my wrist when a mod says " just enable sip helper it works thats it"
that just makes me wanna murder my neighbours cat!

I would like to hear someone say a CLEAR expalination of what SIP HELPER DOES
my understanding that other manufactors use SIP ALG aparently modifiying the header so that the packet finds its way to the correct destination, correct me if im wrong.

So what DOES SIP helper do then? all i can gather from putting little comments together after reading the forums was
yeah yeah it umm yeah.... just mumble full cone mmm yeah nat, something ports

Please if there is a clear explaination, preferable from someone who is able to translate it into an explaination
please i would love to hear you talk with us, in fact ill shout you a coffee/beer

My understanding is Sip just has a hard time finding its way back to an interanl device behind a nat, and seems to have more trouble when double nat is uses server to client, the packet contains a destination of the router but not the local address if im correct.


Please dont be shy to talk more, i would love to hear more and an END ALL discussion about this
Mods I'm not here to say MAKE YOUR S%@T work!!, but please this is an open ended conversation
with an aim to have and END ALL Discussion, and maybe even a sticky!!!! on boy yes a sticky of the SIP resolution.


Im willing to accept that routeros hasnt got the ability to make a true Sip ALG fine okay, maybe we can still shine the light on the topic and clearly outline this, cuz im tired of readying " it just works " Gee wiz it does not JUST work!

Yes, your understanding is correct.

First, here is a good, general article on the connection tracking (conntrack) in iptables: http://people.netfilter.org/pablo/docs/login.pdf

Second, the SIP helper is a sort of ALG (Application Layer Gateway) which has to inspect the SIP commands going back and forth as well as any included SDP payloads to find the cases where the application data is mentioning an IP address or port number. The helper then needs to dynamically modify the SIP commands and SDP payload to use new IP's and possibly new ports as well as setup a NAT mapping to mangle the packets coming back. If you read C, you can look at the source for a version of the SIP helper (http://fxr.watson.org/fxr/source/net/ip ... =linux-2.6) to see what it does exactly.

You will notice that the helper does only UDP SIP, not TCP SIP. It's also important to note that the SIP helper is not a full SIP stack and cannot possibly understand all the possible variances and flavors of SIP so it doesn't work in all cases. There are many versions of the helper code, some working and some not (see http://lwn.net/Articles/230874/) and we don't know for sure what version Mikrotik has in which versions of ROS. Finally, SIP is a general purpose protocol to establish some communication session between hosts and, while we normally use it with SDP describing RTP audio streams, it can be used for many things and the SIP helper may not understand future content or streams.

Because of all of this, the SIP helper can often interpret/modify the SIP or SDP incorrectly or "fight" with NAT workarounds being executed by the SIP hosts. This is why you often hear advice to disable the helper. It's also why simply enabling the SIP helper doesn't magically fix someone's SIP problems.

Here is an example SIP INVITE message from a host behind NAT:

INVITE sip:5551234@pbx.acme.com SIP/2.0
Via: SIP/2.0/UDP 192.168.91.119:5062;rport;branch=z9hG4bK261727224
From: "Bob" <sip:4101@pbx.acme.com>;tag=64214388
To: <sip:5551234@pbx.acme.com>
Call-ID: 260225593@192.168.91.119
CSeq: 1 INVITE
Contact: <sip:4101@192.168.91.119:5062>
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: IP Phone SIP-T38G 38.0.0.30
Supported: replaces
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 310

v=0
o=- 20003 20003 IN IP4 192.168.91.119
s=SDP data
c=IN IP4 192.168.91.119
t=0 0
m=audio 11786 RTP/AVP 18 0 8 9 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:40
a=sendrecv

The parts in RED are the parts which need to be modified by the SIP helper. Now, let's assume the Mikrotik is NAT'ing this packet out via the public IP address of, for example, 66.49.33.2, and that port 5062 is already being used by another connection, so it must substitute the dynamic port 40012. The sending host of the INVITE has opened port 11786 for the inbound RTP stream, so let's assume that that port is currently available on the Mikrotik IP 66.49.33.2, so the SIP helper will not change it but it must reserve and mark that port as a related connection item. Finally, the SIP helper needs to produce the following:

INVITE sip:5551234@pbx.acme.com SIP/2.0
Via: SIP/2.0/UDP 66.49.33.2:40012;rport;branch=z9hG4bK261727224
From: "Bob" <sip:4101@pbx.acme.com>;tag=64214388
To: <sip:5551234@pbx.acme.com>
Call-ID: 260225593@192.168.91.119
CSeq: 1 INVITE
Contact: <sip:4101@66.49.33.2:40012>
Content-Type: application/sdp
Allow: INVITE, INFO, PRACK, ACK, BYE, CANCEL, OPTIONS, NOTIFY, REGISTER, SUBSCRIBE, REFER, PUBLISH, UPDATE, MESSAGE
Max-Forwards: 70
User-Agent: IP Phone SIP-T38G 38.0.0.30
Supported: replaces
Allow-Events: talk,hold,conference,refer,check-sync
Content-Length: 310

v=0
o=- 20003 20003 IN IP4 66.49.33.2
s=SDP data
c=IN IP4 66.49.33.2
t=0 0
m=audio 11786 RTP/AVP 18 0 8 9 101
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=fmtp:101 0-15
a=rtpmap:101 telephone-event/8000
a=ptime:40
a=sendrecv

Now that was a simple INVITE. It could have been a much more complex INVITE, maybe the SDP described multiple streams and had multiple Connection Data ("c=") lines. The SIP helper also has to watch other SIP commands so it's gets complex quick.

I hope this starts to help people understand the issues. SIP communications is not simple and involves a fairly deep protocol set with lots of variance in vendor implementations.