At the time of this writing, SmartSDR 1.4 has not been released (full Local Area Network (LAN) full client support). Sometime next year, SmartSDR 2.0 will be release and will include Wide Area Network or WAN full client support (accessing your Flex 6000 from the Internet).
I know there are many unknowns as development of both 1.4/2.0 is ongoing. With that being said, an understanding of how and what type of networking support/architecture is going to be required to make WAN connectivity work. If this has not been decided, the development team could not move forward.
To set the stage for my questions....most of us have a single, routable IP address issued to our home router via our ISP's DHCP servers. Our home routers maintain that single, dynamic IP address and allows all of our home connected devices to communicate with the internet through that single IP. This is accomplished via common network protocol called Network Address Translation or NAT. All of the devices on the internal network are assigned non-routable IP addresses, usually in the 192.168.1.xxx range. In this network typography, UDP traffic is not broadcast to the internet from the internal home network (thank God). Therefore, the current UDP broadcasts FRS currently employs to provide radio discovery to the SmartSDR client will not work for WAN based clients. A different method will need to be (has been?) developed.
What scheme then will be used to allow discovery of our Flex 6000 radios which sits behind a network infrastructure such as this? Will the radio be required to be exposed to the internet via sitting in the router's DMZ? Will a specific range of TCP/IP ports be required to be opened?
A method FRS might chose to use is to have the 6000 radio make and maintain periodic contact with a "FRS" server. This server would then maintain the current IP address of each of our 6000 radios. Under this scheme, the client would automatically first make connection to the FRS server which would then supply the current IP address of our radio to the WAN Client. The client would then make a direct connection to the radio for the remainder of the session. This scheme is similar to how the Splashtop Remote Desktop product functions. The Splashtop Streamer is loaded on all the host PC's you might want to connect to remotely. Streamer maintain periodic contact with the Splashtop corporate server. When you start the Splashtop remote client, it first connects to the Splashtop corporate servers. After the user authenticates, the user is provided a list of their own home computers. When the user selects from the list, the remote client is provided the IP address of the host and then a connection is made directly to the host computer.
FRS might alternatively employ a fully disassociated, fully distributed scheme. Under this method, the amateur radio operator would likely be obligated to always know the current IP address assigned to their router from their ISP or make use of some sort of Dynamic DNS service.
My questions are borne from wanting to know if we will need to have any specific infrastructure in place, ready and available to accommodate SSDR WAN support. I'm not looking for FRS to disclose any trade secrets. I'm only hoping for information on general architectural direction which the development team is obviously already operating from. This information will allow all of us to be ready immediately when WAN support is released next year.