News on RouterOS v7 ?
Thanks.

News on RouterOS v7 ?
Thanks.

It's not directly listed in IP>Firewall>Service Ports under 7.2rc3.

But have you tried using the "sip" ALG there with your RTSP port listed? ALG really deals with SDP, so the "sip" ALG may not care it's actually RTSP.

It's not directly listed in IP>Firewall>Service Ports under 7.2rc3.

But have you tried using the "sip" ALG there with your RTSP port listed? ALG really deals with SDP, so the "sip" ALG may not care it's actually RTSP.

Nope, it SIP ALG needs at least some SIP BEFORE fixing the SDP fields (which is used by BOTH SIP and RTSP) – so overloading the SIP ALG is NOT a workaround here.

I don't deal with cameras that often, but avoid ever needing ALG for anything... But get that not always possible.

What I do know is OpenWRT does support an ALG for RTSP. Seems it's a kernel patch that's likely missing in the kernel that RouterOS uses: https://openwrt.org/packages/pkgdata/km ... elper-rtsp But obviously a missing kernel patch isn't fixable by an MT admin.

-------- Original message --------
Subject: hello there (regarding RTSP helper)
Date: Mon, 28 Mar 2022 16:39:41 +0300
To: support@mikrotik.com


hello there

we definitely need RTSP helper (alg)

openwrt has it. but we love routerOS

could you please add it to ROS?

viewtopic.php?p=920991#p920991


thanks and regards

MikroTik support #[SUP-78171]: hello there (regarding RTSP helper)
Mon, 28 Mar 2022 17:59:00 +0300 (EEST)
Artūrs C. (Jira) <support@mikrotik.com>


—-—-—-—
Please REPLY ABOVE THIS LINE ^ (for faster response, use our support portal).

Hello,

Thank you for contacting MikroTik Support.

We do not have any plans to add such a feature at the moment, but if more users will request it, we will see how this can be implemented.

Best regards,
Artūrs C.

MikroTik support #[SUP-78171]: hello there (regarding RTSP helper)
Mon, 28 Mar 2022 17:59:00 +0300 (EEST)
Artūrs C. (Jira) <support@mikrotik.com>


—-—-—-—
Please REPLY ABOVE THIS LINE ^ (for faster response, use our support portal).

Hello,

Thank you for contacting MikroTik Support.

We do not have any plans to add such a feature at the moment, but if more users will request it, we will see how this can be implemented.

Best regards,
Artūrs C.

they seem to be counting posts in forum imho

so your users/friends can register and post their request in this forum topic

thats all i know.

customer services do always count calls, tickets, emails, forum posts etc.

and report to their supervisors... you get the idea...

the more demand they receive from customers for a feature, the more priority it receives in implementation.

dunno about forum rules, i try to be nice and friendly, thats all.

they also should be tolerating unless it becomes spam.

There must be a very good reason why this "basic" feature is not added to the Linux kernel for over 15 years. So there is no simple toggle "enable RTSP helper".

A little bit in general about requests like: Please implement "four_letter_combination" feature. Without a single word on what exactly is assumed by this letter combination, followed by several +1 posts.
It is immediately a red flag and most likely will be ignored.
And stating that this "few letter combination" feature is needed by thousands of users, but at the same time agitating to ask your grandma to make an account and add +1 post adds another red flag.
There must be at least some description of when and how the requested feature is expected to be used, in most cases solution is already possible with existing RouterOS functionality.

Regarding this particular RTSP helper, which is supposedly such a basic feature.
By doing a quick search it was first implemented in 2003 since then there is very little information. There are some forks in GitHub, but that's it. There must be a very good reason why this "basic" feature is not added to the Linux kernel for over 15 years. So there is no simple toggle "enable RTSP helper".

So should we waste the resources to research this protocol and write the helper just for a few grandmas +1?

From this topic, there is only one genuine post that can be taken into account and that is by jhbarrantes about the actual use case by Movistar.

So should we waste the resources to research this protocol and write the helper just for a few grandmas +1?

Without a single word on what exactly is assumed by this letter combination

is already possible with existing RouterOS functionality.

not added to the Linux kernel for over 15 years

but most of them relying on this implementation.

Without a single word on what exactly is assumed by this letter combination

RTSP is one of those protocols designed in the early days of the commercial Internet — 1996 — before NAT became a common thing. Its creators therefore felt free to continue the old assumption of a symmetric network: all clients are potentially servers, and vice versa. NAT breaks RTSP. Without some kind of help to get the port numbers and such sorted out, a client can make an RTSP connection, but the returning media streams cannot transit the router.

This is because RTSP behaves much like classic active-mode FTP: the client connects out to the server, tells it what it wants, and the server then connects back to the client on a separate port number — or pair of port numbers in the case of separate video + audio streams — to send the requested media streams. In the case of FTP, it's only one file at a time, but with media streams, you could have a security appliance pulling a dozen of them in parallel, so there isn't a simple rule you can hard-code like "forward port 20 back to the client when it connects out on port 21" as there was with active-mode FTP.

There were more examples of this type of protocol decades ago, but most have been replaced by something designed to work with NAT interference. Classic example: FTP first went passive-only, then got replaced in virtually all functional cases by either SFTP for read/write use cases or HTTP for read-only cases. Result? Now we don't need "FTP helpers" on our NAT routers.

The thing about RTSP is that it's Ⓐ used in a lot of broadcast-grade IPTV type applications, where there's tremendous inertia against moving to something that doesn't have RTSP's problems (e.g. HLS streaming); and Ⓑ used in a lot of embedded devices like IP cams, AirPlay streaming receivers, etc, where it can't be reasonably replaced at all. If you want to wait another decade or so, the need for RTSP will dwindle to about the popularity of fountain pens and AM radio, but like all tech that was once widespread, it will never go away entirely.

A big problem with implementing an RTSP helper is that it's a fairly complicated protocol. For one, it's basically an extension of HTTP/1.0; not nearly so bad as HTTP/1.1 or its follow-ons, but still nontrivial. For another, you can think of RTSP as the "VCR buttons" protocol for controlling other protocols, so some knowledge of SDP, RTP, and other streaming media formats and protocols is required in order to work out how to perform the desired "helper" actions.

The only practical advice I have for y'all at MikroTik is to look into Live555. The library is LGPL, but if that's a non-starter, I do believe the library's author — co-inventor of RARP + TFTP network booting and prior owner of "live.com" before Microsoft bought it off him — will be happy to offer you a buy-out for closed-source commercial use. If you can use it, it'll save you a tremendous amount of time in building the feature. They've got a pre-built RTSP proxy server which may be what your customers actually need.

Or, get containers working again so we can spin up a Live555 Proxy Server on our own.

is already possible with existing RouterOS functionality.

Sadly, I do believe that is not the case here. RTSP proxying requires digging deep into the protocol and rewriting things.

not added to the Linux kernel for over 15 years

An RTSP helper is no more appropriate for inclusion in the kernel than is an HTTP proxy. This is very much userland type code.

but most of them relying on this implementation.

Yes, that is the one we were looking at and one I was talking about.

Yet again we come to the conclusion that by "implement RTSP helper" people mean different things. That is what I was talking about initially because a post "implement xyz" can mean one thing but +1 for such a post could mean something completely different.
RTSP proxy is the user space application and not something that we should be focusing on. When KVM, docker, or whatever other virtualization methods will be added back to the RouterOS, then all these proxies, servers, etc could be running there. AFAIK RTSP proxy will not be able to solve the NAT problem anyway.

Regarding RTSP helper which is the actual connection tracking module. We will look into this and this one is the one I was talking about there must be a very good reason why after 15 years it is still not a part of the Linux kernel.

Regarding RTSP helper which is the actual connection tracking module. We will look into this and this one is the one I was talking about there must be a very good reason why after 15 years it is still not a part of the Linux kernel.

An RTSP helper is no more appropriate for inclusion in the kernel than is an HTTP proxy. This is very much userland type code.

Regarding RTSP helper which is the actual connection tracking module. We will look into this and this one is the one I was talking about there must be a very good reason why after 15 years it is still not a part of the Linux kernel.

An RTSP helper is no more appropriate for inclusion in the kernel than is an HTTP proxy. This is very much userland type code.

Most of the commercial video broadcasting services does include optional packages for RTSP for the aim of configuration purposes like bandwidth management etc. It's a typical service domain ie does not fit natural for use in a router.

https://github.com/aler9/rtsp-simple-server

Yet again we come to the conclusion that by "implement RTSP helper" people mean different things.

RTSP proxy will not be able to solve the NAT problem anyway.

there must be a very good reason why after 15 years it is still not a part of the Linux kernel.

How do you deal with NAT then, if it is not on the router itself? Unless something can translate this into UPnP requests mapping ports dynamically (which will be in fact a very nice and clean solution) I cannot see how these will things can operate NAT (see previous perfectly-elaborated response from @tangent) Regards!

Just to be clear, are we talking about the end user ie consumer market or the business side?

Like... never?
viewtopic.php?t=172168#p922283

• Utilizing DSP for IP Telephony Applications in Mobile Terminals (Helsinki University of Technology)
• RTP, RTCP, and RTSP - Internet Protocols for Real-Time Multimedia Communication (CRC Press)
• Nat Traversal for Video Streaming Applications (Researchgate)
• Citrix Application Layer Gateway for RTSP Protocol (Citrix ADC Appliance)

• RFC7604 - Comparison of Different NAT Traversal Techniques for Media Controlled by the Real-Time Streaming Protocol (RTSP)
• RFC7826 - Real-Time Streaming Protocol Version - 2.0
• RFC7825 - A Network Address Translator (NAT) Traversal Mechanism for Media Controlled by the Real-Time Streaming Protocol (RTSP)
• DRAFT - Controlling Session Initiation Protocol (SIP)-Established Content Delivery Channels Using the Real-Time Streaming Protocol (RTSP)

Is why, viewtopic.php?t=172168#p922606

Is why, viewtopic.php?t=172168#p922606

And even a "pure and simple" L3 helper might need different profiles depending on the purpose ie iptv (manual or preset isp profiles), the ability to change port numbers, enabling RTSPU and so on, etc...

Yes, which is why I keep trying to talk y'all out of this nonstandard kernel module. Not only can this be done in userspace, with a bit of help from standard RouterOS firewall rules, it will have wider scope if done that way.

+1 to Tik support on this.

RTSP NAT Traversal needs to be implemented at Layer 7 by the app/device vendor using STUN, TURN and ICE not at the router.

This way P2P connectivity can be established even behind CGNAT

The real solution, stop whining and get on IPv6.

+1 to Tik support on this.

With 7.4beta4, they've given you the tools to solve it, using Containers.

RTSP NAT Traversal needs to be implemented at Layer 7 by the app/device vendor using STUN, TURN and ICE not at the router.

That's one way to achieve it, but as long as you have a single public IP, you can also do it with an RTSP proxy (a.k.a. RTSP ALG) at the source NAT point so the proxy can make similar connections outbound and relay the reply streams to the host that asked for them.

This one looks plausible. I tested building it under the Docker Desktop cross-compilation tool chain, and it does build for ARMv7, requiring ~60 MB of storage space. That's as far as I took it, because I don't need it here, so I don't have a good test case for configuring and evaluating it.

This way P2P connectivity can be established even behind CGNAT

If that's going on, then I think the RTSP proxy linked above will not work without an underlying L3 tunnel out to somewhere sane. (e.g. VPN, SSH SOCKS proxy, etc.)

The real solution, stop whining and get on IPv6.

It isn't a panacea: big mobile carriers often give you IPv6 and CGNAT. Fun!

RTSP NAT Traversal needs to be implemented at Layer 7 by the app/device vendor using STUN, TURN and ICE not at the router. At router level, you should ensure to do NAT correctly using Netmap to ensure STUN works seamlessly as the ports of the internal device IP will match the port of the public facing IP – This way P2P connectivity can be established even behind CGNAT without port forwarding directly.
viewtopic.php?t=176358

Doing NAT correctly using netmap instead of src nat:
viewtopic.php?t=176358

RTSP NAT Traversal needs to be implemented at Layer 7 by the app/device vendor using STUN, TURN and ICE not at the router. At router level, you should ensure to do NAT correctly using Netmap to ensure STUN works seamlessly as the ports of the internal device IP will match the port of the public facing IP – This way P2P connectivity can be established even behind CGNAT without port forwarding directly.
viewtopic.php?t=176358

Claiming it only will take a "simple" NAT or ALG helper to solve it is unfortunately not the whole truth. RTSP is a complete echo system that span all the way from L3 to L7 thus it usually requires a lot more.

Please read:
viewtopic.php?t=172168#p922606
viewtopic.php?p=940575&sid=21a1f1cc1ad5 ... c9#p922681
viewtopic.php?p=940575&sid=21a1f1cc1ad5 ... c9#p932486
viewtopic.php?p=940575&sid=21a1f1cc1ad5 ... c9#p932706
--

Have a nice weekend!

Doing NAT correctly using netmap instead of src nat:
viewtopic.php?t=176358

It's rather arrogant to say netmap is the "correct" way to implement NAT, full stop. It is a useful tool in some contexts, not all.

That aside, I don't see how iptables' netmap NAT method solves the RTSP problem at all. RTSP is not a typical NAT traversal problem where the responding host has to work out a way to talk back to the host that sent the request. There are many ways RTSP can work. Indeed, the core of the protocol is to negotiate precisely how the two hosts will communicate henceforth, matching desired behaviors to available services. The thing is, since RTSP was invented before NAT, there isn't a part of the protocol to signal how the remote hosts should do NAT traversal.

RTSP is a TCP-based protocol (normally) that merely sets the reply stream up, which is often UDP. It is possible to tunnel replies back over the same RTSP connection, in part to get around problems like the class discussed in this thread, but it's uncommon. We can ignore RTSP-over-HTTP for the same reason.

What may happen in normal RTSP is that it negotiates two UDP streams in reply: one for audio, and one for video. (Contrast the muxing case, where both come back inside a single MPEG-TS stream or similar.) Does netmap + STUN/TURN/etc. handle that case?

You should now see the value in having a proxy at the border: the internal client talks to the proxy, and the proxy talks to the remote service to set the stream up, which it then relays back inside to the requesting client.

Have you actually deep dived into the Linux kernel?

There's no differentiation between the two except on MikroTik.

I take it you're not Linux savvy?

And the effects of netmap for all traffic types including RTSP is straightforward:

I am able to connect to public RTSP streams from VLC without any issues ALG or Proxy crap.

SETUP rtsp://rtsp.stream:554/pattern/trackID=0 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.17.3 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=50140-50141

Have you actually deep dived into the Linux kernel?

Is that necessary to hold an opinion? Only kernel hackers need reply? No userland experience is relevant?

There's no differentiation between the two except on MikroTik.

Since that's the tool I have, and that's the owner of forum of the OS I'm replying on, I'm going to reply in that context. There's little point offering solutions for other OSes here, now is there?

I take it you're not Linux savvy?

The first Linux distro I used was distributed on 5¼" floppies. It ran on kernel 0.99pl14.

That wasn't my first *ix system. The first popular one I used was DEC Ultrix on a VAX, based on 4.3BSD. Surrounding that were assorted SVR4 variants from companies long since gone, and less well remembered than DEC.

Am I all-knowing? Of course not. But if you aren't getting your point across to one such as me, who do you suppose you're effective in communicating to?

And the effects of netmap for all traffic types including RTSP is straightforward:

Like the article you linked above — here, section "CGNAT" — this is blind assertion. The article states, "netmap algorithm + state tracking will handle what gets mapped where." Okay, but how? Everything I can pull up with web searches talks about trivial cases like mapping a public /24 to a private /24. That doesn't tell me how the article's rules work in this more complicated case, which then leads me to ask questions like the above.

Another case: Can I use netmap in place of traditional masquerading, with one public IP in front of a /24 private LAN?

And another: I have a LAN with two levels of VLAN, a restricted internal VLAN (e.g. IoT) behind a less restricted user VLAN. The restricted VLAN needs to get through the user VLAN's NAT firewall to get out to the Internet. In that situation, does netmap allow clients on the restricted VLAN subnet to pull RTSP streams from the user VLAN? (1 hop.) Does it let the restricted VLAN pull RTSP streams from the Internet? (2 hops.) If so, how?

The article you linked is entirely unlike the networks I work with. Without some understanding of how much of its voluminous advice I must take and how much I can ignore, I'm left treating it all as provisionally irrelevant. The only other option is cargo-cult imitation.

If you want me to understand, you're going to have to get beyond blind assertion.

I am able to connect to public RTSP streams from VLC without any issues ALG or Proxy crap.

I analyzed your first link, and it behaves as I said above: it negotiates separate RTP audio and video streams, apparently without using any explicit NAT traversal mechanism. (If it does, I missed it.) This is what you're showing in your screen shots, host 23.88.67.97 sending RTP on UDP 8000 and 8001. (RTP ≠ RTSP)

I'm not using RouterOS on the border of my NAT44 network here — my RouterOS boxes are all relegated to smart switch roles — so what I don't get is, why does it work? The RTSP TCP outbound is on port 554, whereas the negotiated return streams come from two different UDP ports. How does my border router know to send those returning streams back inside? Surely it doesn't just let everything from that host come back in without regard to connection tracking.

Can I infer that my border router has an RTSP helper built into it? There is no visible setting for it in the configuration GUI, but that isn't diagnostic; the router's from a company that's famous for candy-coating all its internal power, presenting little through its GUI.

(Yes, one of these days I need to replace it with a RouterOS device. There are reasons I can't, but yes, one day.)

As for netmap on RouterOS, I still don't see why it's any solution. The client (VLC) doesn't send anything out to the server on UDP ports 8000-8001, and the client-side ports are random besides. At what point is the NAT mapping established?

Here's one of the SETUP requests I captured:

Code: Select all

SETUP rtsp://rtsp.stream:554/pattern/trackID=0 RTSP/1.0
CSeq: 4
User-Agent: LibVLC/3.0.17.3 (LIVE555 Streaming Media v2016.11.28)
Transport: RTP/AVP;unicast;client_port=50140-50141

What is it about netmap that lets the router know my client computer is listening on UDP ports 50140 and 50141, so it should send UDP packets on those ports to my computer? Surely learning that fact requires some sort of deep packet inspection and/or a proxy?

Bottom line, it's virtually impossible to implement a general RTSP "helper" since there isn't just one "standard". Quite the opposite there are many different ones including proprietary solutions and they all differ depending of intended application.

Bottom line, it's virtually impossible to implement a general RTSP "helper" since there isn't just one "standard". Quite the opposite there are many different ones including proprietary solutions and they all differ depending of intended application.

with NAT/masqerade. Where RTSP is used by the client to tell the server on what ports it expects incoming content UDP steams from the server.
Many commercial SOHO routers provide an ALG/helper to sniff UDP port numbers from outgoing RTSP and forward incoming streams to said ports from WAN to the respective LAN client. Kind of a dynamic WAN->LAN dstNAT for a specific UDP stream.

Repeat after me: There Are No Standards, Not Even for IPTV.

That's the whole point, stop using masquerade and src nat and replace it with netmap, and you're good to go for 8/10 RTSP cases. Re-read my previous replies.

The main reason some SOHO boxes have specific GUI settings for specific providers like MoveStar,Orange etc, is they use special VLANs and/or DHCP options for IPTV and some require specific client MACs on the IPTV interfaces, require additional IGMP settings, etc. This of course would have to be setup additionaly at the appropriate layers on MikroTiks.

And every freakin distributor loves to lock in the end user with their specific solution aka "triple play" and likes. And besides VLAN and other related stuff, all using specific port numbers, transport initialization, multiple streams using different transports and sometimes even proprietary application level protocols, So not much of a standard...

Repeat after me: There Are No Standards, Not Even for IPTV.

Sniffing the Transport field in the outgoing RTSP request as defined in RFC2326 is enough to have all those IPTV solutions working.
Transport: RTP;unicast;client_port=12345
OpenWRT manages to handle all those IPTV services with just that.
So I'm happy to to agree to disagree

The main reason some SOHO boxes have specific GUI settings for specific providers like MoveStar,Orange etc, is they use special VLANs and/or DHCP options for IPTV and some require specific client MACs on the IPTV interfaces, require additional IGMP settings, etc. This of course would have to be setup additionaly at the appropriate layers on MikroTiks.

And every freakin distributor loves to lock in the end user with their specific solution aka "triple play" and likes. And besides VLAN and other related stuff, all using specific port numbers, transport initialization, multiple streams using different transports and sometimes even proprietary application level protocols, So not much of a standard...

This is why @darknets endlessly repeated solution of bypassing connection tracking by using netmap (which was specfically designed for being stateless for stateless routing) works... for an ISP border router were connection tracking is disabled, all routing stateless and hence nothing else than netmap is possible. And also not desirable as the ISP customers would like the get all packets coming from the public Internet.

In a CPE/SOHO router almost everone else than @darkent likes to have connection tracking enabled for NAT, so no netmap. Who knows (or cares) if he ever gets the difference...

Bro, what are you smoking?

Netmap is NOT stateless. I use it on ISP BNGs and also in my personal home router for /32s and the same thing for normal home users who are my clients.

The new RTSP helper in 7.5b4 works fine for me and solved my problems with Reolink cameras.

set rtsp disabled=no ports=554,8554,7236