[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] [BEHAVE] [Fwd: draft-lowekamp-mmusic-ice-tcp-framework-00 draft submitted]
Rémi Denis-Courmont wrote:
On Friday 31 October 2008 01:04:03 ext Adam Roach, you wrote:
Because I know many of the parties interested in ICE TCP are somewhat
more active on the BEHAVE list than they are on MMUSIC, I wanted to
cross-post Bruce's announcement here.
Looks good base to me.
Thanks.
I am not sure if SSH tunnels really fit there, though.
Why not? If I have a SIP client behind a firewall, I can use a SSH
server as a perfectly good forwarding relay for TCP connections. I can
get a passive candidate with an SSH_MSG_GLOBAL_REQUEST "tcpip-forward",
and know when it's been connected when I get a SSH_MSG_CHANNEL_OPEN
"forwarded-tcpip"; and I can get an active candidate pretty much
automatically -- to try the candidate, I all I need to do is allocate a
new sender channel with a SSH_MSG_CHANNEL_OPEN "direct-tcpip" and start
running my checks over it.
Or, from a commandline perspective (using the OpenSSH client), I get a
passive candidate like this:
ssh adam at myrelay.example.com -R 5555:localhost:4444
(Where 5555 is the port I advertise in my SDP, and 4444 is the local
port I'm actually listening on)
...and an active candidate like this:
ssh adam at myrelay.example.com -L
localhost:1234:the-other-guy.example.org:4321
(Where 4321 is the port I received in the SDP, and 1234 is the local
port I'll actually send traffic to).
As far as the remote party knows, this is just another set of TCP ports
(with the exception of the indicated priority).
The best part is: this is already widely deployed. And the key thrust of
the document is: we can solve this problem by using what's already out
in the field.
/a
_______________________________________________
mmusic mailing list
mmusic at ietf.org
https://www.ietf.org/mailman/listinfo/mmusic