I wasn't thinking of connecting over the Internet, but that's a feature some people will want to have.
In theory, there should be three ways to connect.
Access Point mode.
Infrastructure mode.
Via the Internet. Which is where I guess opening ports would be important.
Right now at least, only infrastructure mode seems to be working. Internet mode doesn't exist without hacking around a bit. No one seems to have had success with AP mode.
(This is for the benefit of anyone who is - once again - asking why the 536 can't just be reached from the Internet by default.)
Internet connectivity would be the same as infrastructure mode. In infrastructure mode, your scanner connects to an existing wi-fi network (the 'infrastructure') and makes (connections to) itself available for any devices on that same wi-fi network.
Your wi-fi network, by design, has protection to keep stuff in your local area network away from stuff outside your local area network (aka the internet). Otherwise anybody on the planet could connect to any of the devices on your wi-fi and do whatever they wanted to them.
One of the ways that this is achieved is by blocking 'ports', aka source/destination addresses on devices connected to the internet, from being accessed from across the boundary between your local network and the internet (or vice versa). A number of 'ports' are passed through this boundary by default, such as port 80 (for http, which is how you access websites) and port 443 (for https, the secure version of http). Less-often-used ports are left closed/inaccessible by default, to prevent your devices on your local network from being attacked. For example, you wouldn't want someone to be able to use the port normally allocated to QuickTime streaming, for making a remote desktop connection to your computer, where they could do anything to the machine as if they were sitting in front of it.
The scanner, which if I am not mistaken uses the Realtime Streaming Protocol (RTSP), needs the RTSP ports in your firewall unblocked if you want to be able to use it outside of your home network. If I recall the issue correctly when the 536 first came out and the wi-fi dongle was being messed with by us new users, it was discovered that while RTSP uses a standard, common port for control (554), the ports to be used for the actual streaming video (or in our case audio) and the metadata (i.e. the scanner's screen's text) does not stay the same every time. On one occasion the port might be 50536 (that seems to be common at least for the first run of the client), but on another occasion it might be 6090, or 24318, etc. This hampers your ability to tell your firewall to pass traffic destined for that port to your scanner, because the port continuously changes with each RTSP session.
Even if you were to open your firewall completely and let all traffic pass through, your router still wouldn't know what to do with it once it hit your home network, until you tell it "stuff on port xyz is supposed to be for the scanner". That relies on port xyz never changing (so you don't have to change the rule every time you start a new RTSP session), and
also the IP address of the scanner not changing (unless you want to change the IP address on the rule every time the scanner powers on and gets a new IP address from the network).
If RTSP could be made to always use a specific (set of) port(s) for its work, then you could
forward those
ports (aka port-forwarding) in your firewall/router and it would (theoretically) work. However, part of the RTSP specification is that the data ports (for audio and metadata) are negotiated each time an RTSP session is begun. So on one session it might say to the connecting client (your Android device, or iOS device, or RH-536mkII, or ProScan, or whatever) "today we're using 8006 and 9006" and on the next session it might say "This time we're gonna use 828 and 49152".
It stands to reason - at least to me - that whatever initiates the RTSP session from the scanner side (be it the scanner or the wi-fi dongle) could be coded to use a specific port (or set of ports) every time. Or have it be configurable in the scanner, so the user would have to say "my RTSP data ports will be 50536 and 50538". That way they would know what ports to open up in their firewall and forward to the scanner. Theoretically speaking - at least, in my knowledge of the workings of the protocol - that would make it possible to use the Siren app outside your home network. That's what people are doing when they're connecting VLC to the scanner and then streaming VLC out of their home network to the internet - they can configure VLC to use the same port for audio every time, and inside the network, it doesn't matter if the ports for RTSP between VLC and the scanner change, because the two of them talk on one side of the firewall without having to worry about punching ports open. The downside of using VLC is that you don't get control of the scanner - just the audio - because you're not linking the scanner itself to the internet, just the instance of VLC.
Hope all this makes sense. I'm sure that Uniden and the maker of the dongle firmware are continuing to work on this - but remember the issues that were had with getting the dongle alive in the first place. Communication and collaboration between a minimum of three parties (Uniden execs like UPMan, the engineers in Uniden Japan, and the builders of the code in the dongle) can't be an easy thing to coordinate.