one question, if Mikrotiks SIP-ALG (SIP Helper) is enabled, I dont have to create a DNAT-Rule to open the RTP-Port-Range of my PBX.
I assume:
the ALG will catch these information (RTP-Ports) form the SIP-packets and will create “hidden” DNAT-rules
or
the RTP-streams are RELATED (in the sense of established/related) to the initial SIP-connection
I tried to catch RELATED packets in my firewall (forward-chain) when a call comes in. But there is no catch with a RELATED-passthrough-rule.
MT says:
SIP helper. Additional options:
sip-direct-media allows redirect the RTP media stream to go directly from the caller to the callee. Default value is yes.
This is unclear to me, what does this mean is a technichal manner? Is “redirect” here another word for DNAT (this would fulfill my assumtion 1). But what does the ALG if this option is disabled, but the ALG itself stays enabled?
Inside the SIP message, there are IP addresses and ports in both the own headers of SIP and its payload - the SDP used to establish and control the RTP session. So the SIP ALG still has enough to do even if doesn’t tamper with the SDP and RTP - at least it replaces the address and port in the Via and Contact uris sent by the phone to its own WAN side address and port.
Regarding the RTP, the ALG creates a tracked connection with the necessary NAT handling in advance, before the first RTP packet ever comes from either direction, while processing the SDPs from both peers. So it reserves the WAN side IP address and port for that connection and sends then in the SDP to the remote peer.
Whether this tracked connection for RTP is marked as related or not is a different thing. I never bothered to check that because switching SIP helper off is one of the first settings I do on every new router. So you may want to do it the other way round - while a call is ongoing, find the remote address:port tuple using /tool sniffer ip-address=ip.of.the.phone and print the connections which have it as either the src-address or the dst-address: /ip firewall connection print detail where src-address~“remote.ip.add.ress:port” or dst-address~“remote.ip.add.ress:port”
But you have to do then the DNAT stuff manually? UDP/TCP 5060, the RTP-Range…?
I am using the SIP-ALG only in my homenetwork and it worked out of the box. I found it quite nice, because it will create the DNAT rules to my PBX dynamically (this is at least what I think it does) and they are not open the whole time.
Not really. Since quite a few years ago, public exchanges can handle client-side NAT by storing the socket address from which the REGISTER request actually came and sending INVITEs and keepalive packets to that socket rather than the one found in the Contact header in the REGISTER message. For the RTP traffic, they also wait from where it actually comes rather than sending it to the address found in SDP, and proxy the RTP between the phones, so the phones do not need to know each other’s socket addresses. What has made this possible is a cooperative behaviour of the phones that use the same sockets for sending and receiving, which wasn’t the case since the very start as the RTP and SIP RFCs do not require this. And the phones even send RTP before connect, allowing the exchange to send them the pre-connect audio.
So you don’t need any port-forwarding (dst-nat) rules to connect a phone in your LAN to an exchange on a public address, as the phone creates a pinhole (tracked connection) for SIP using the first REGISTER message, and for each call, it creates a pinhole by sending the RTP where the exchange has asked it to (which is normally the media proxy).
When talking about the reverse scenario, i.e. a PBX in your LAN and phones in the internet registering to it, you need a port-forwarding rule for SIP even if the SIP ALG is enabled, and there is a lot of things that may go wrong. E.g. the ALG doesn’t handle the situation when the device in the LAN uses different IP addresses for SIP and for RTP.