If you have port forwarding on your router for TCP and UDP for your Slingbox private IP Address and Port, it is a direct connection between the Slingbox (server) and the Slingplayer (client).
The Sling Finder ID is used an an alternative for Dynamic DNS (DDNS), so you don't have to keep looking up your router's public IP address.
Btw, just curious. Why would you need to use a SSH tunnel? The SlingStream is already encrypted.
I understand how the finder works, and that it is an alternative to DNS (dynamic or otherwise). It is working fine, but I just prefer to be in control.
Call me paranoid but I prefer that my providers (mobile and home) don't know I'm slinging... whether the data is encrypted or not, port 5001 kinda gives it away. When tunnelled, they just see packets going over port 22 (or whatever other port I decide to accept SSH connections on).
On a PC, I open an SSH connection (using dynamic DNS), enable port forwarding and tell slingplayer to connect to localhost:5001 and nobody can tell I'm a slingin'.
This should not be difficult to add to the client; I am stunned it is not there already.
You know you can change your Slingplayer's port from the default 5001 to something else like 443, 80, 22, 8080 or whatever you want. The stream from the Slingbox is already encrpted, so they wouldn't be able to tell what you're streaming anyways. The only thing they will be able to tell is the amount being streamed. Which is usually more important to them anyways, and there's no manner of encryption can block that.
You might want to explore the interface, its pretty new so it might actually exist somewhere.
For me, Slingplayer Mobile for iPhone does allow you a choice of using Sling Accounts, IP Address, or Finder ID.
Its just a convoluted number of clicks though, so here's a few screenshots with arrows to demonstrate it.
The screen with the Green and Purple circles is the "start screen" if you're not logged into Sling Accounts.
You might wanna check if its available for you, since Slingplayer Mobile for Andriod is brand new.
The feature you're looking for might just be as convoluted to find as its on mine.
Thanks; I am even more upset now I see the iPhone app has it. The only connection option I can find on the android is to connect via your sling account; when I first used it, it barked at me because my PRO wasn't registered on my account (never had any need to before).
You can't even use the finder id directly in the app.
I realize you can change the port, but I don't know if the SB protocol is entirely encrypted or just the payload. If it's just the payload, the ISP can detect the traffic type.
The only thing they will be able to tell is meter how much is being streamed. Which is usually more important to them anyways, and there's no manner of encryption can block that.
Not strictly true; certain ISPs have blocked/slowed specific protocols such as bittorrent so, if the entire packet is not encrypted, who knows what they might do in future.
You might want to double check that. It's very possible they just don't make it as apparent. In fact unlike the iPhone client, the Slingplayer Desktop 2.0 will not allow you to add a direct IP address connection without being logged into Sling Accounts. Whereas, the iPhone client will not allow you to add direct IP address connections while you are logged into Sling Accounts. This disjointed functionality across Sling clients drives me crazy.
One work around that I found is to add a Slingbox contact into the directory while logged into Sling Accounts on Slingplayer Desktop 2.0. It will allow you to create a Slingbox entry with a direct IP Address to "127.0.0.1:5001". Since the directoy is stored on your Sling Account, when you login into it on your mobile client the entry will be available to you.
As far as the SlingStream 2.0 technology, only the data or the "payload" as you call it is encrypted. There are't any routeable packets that can be fully encrypted anyways. Even if you obfusticate the original service by encapsulating its packets with a tunnel like SSH or SSL, the outlying packets passing over the public network still require header information to be unencrypted. Otherwise routers will not be able to pass it.
If you're worried about being throttled, a lot of it is moot point these days. Most of today's P2P traffic is encrypted anyways, so ISPs have resorted to using a methodolgy of metering traffic. If you hit a particular threshold then automated traffic shaping techniques are applied to unidirectional packets. And that's only if your service provider thottles you at all.