Ticket #66 (assigned enhancement)

Opened 3 years ago

Last modified 1 month ago

Better NAT support

Reported by: zorglub Assigned to: courmisch (accepted)
Priority: lowest Milestone: Features paradize
Component: Network Version: master
Severity: normal Keywords:
Cc: Platform(s): all
Difficulty: hard Work status: Not started

Description (Last modified by courmisch)

Find a way to deal with clients behind a NAT. RTSP work 'poorly' in these setups. STUN or other UDP hole punching techniques could be used. ProtocolRollover? can be a solution for a lot of these issues (see also #65).

Change History

05/21/05 20:59:50 changed by courmisch

(In [11095]) Implement Extended passive mode (RFC2428 - FTP Extensions for IPv6 and NATs) : - explicitly NAT-friendly FTP (refs #66), - IPv6 support (closes #130).

05/21/05 23:35:59 changed by courmisch

  • keywords deleted.
  • difficulty set to hard.
  • version set to HEAD.
  • platform set to all.

05/22/05 18:12:58 changed by courmisch

  • description changed.

* Multicast should have no particular problem with NAT, so I'm removing that from the bug.

* NATP2P is meant for peer-to-peer applications. VLC has no peer-to-peer access input/output. Note that it is an expired draft RFC. I'm removing it too.

* STUN might be considered to help receive RTP packets (e.g. with RTSP from behind a NAT).

05/29/05 21:26:17 changed by courmisch

  • owner changed from fenrir to courmisch.
  • component changed from Input to Network.

06/21/05 19:56:39 changed by courmisch

  • wip set to Not started.

UPnP gateway discovery could help as well.

06/25/05 18:13:19 changed by zorglub

  • milestone changed from 0.8.3 feature freeze to 0.8.4 (provisional).

07/19/05 18:30:19 changed by courmisch

  • status changed from new to closed.
  • resolution set to wontfix.

Unfortunately, cannot be fixed, details follow :

Concerning RTSP NAT traversal, there's nothing we can do. Live.com doesn't seem to handle it :-( It's a shame, because we really ought to have such a feature. I couldn't find anyway to override the address advertised by Live.com in the SDP while not changing the local socket address. In other words, UNSAF is not possible. No use trying UPnP, no STUN, no TURN, no ICE, whatever.

The vaguely standard way of traversing NAT for RTSP is UNSAF. We could alternatively have a VLC-specific protocol (or VLC-specific RTSP-extension) that goes through NAT, but we're not Microsoft or Apple, so we won't do that, right ? It would need hacking both client and server.

The only left option seems to use RTP over TCP. Maybe we should do this automatically when private IPv4 are detected (see #266). Or bug Ross Finlayson. I just hope I'm wrong and live.com as some hidden dirty API for NAT traversal.

No other protocol seems affected by NAT (in particular our FTP access is fine). MMSH handle NAT correctly as well (TCP fallback??). Server behind a NAT is clearly out of scope, and probably not possible anyhow, anyway.

As for full DNS names in SDP, err, maybe the specs recommends it, but I fail to see how that could possibly help NAT traversal. Moreover, there's the risk that the resolver from the libc returns some garbage local hostname, instead of a valid reverse DNS name, so I think it has much more potential of doing harm than good.

Closing for now. Re-open provided you have a solution.

09/09/07 20:01:18 changed by courmisch

  • status changed from closed to reopened.
  • resolution deleted.

09/23/07 20:59:48 changed by courmisch

  • status changed from reopened to new.
  • milestone set to Features paradize.

09/23/07 21:05:50 changed by courmisch

  • status changed from new to assigned.
  • description changed.

I am removing the DNS bullet point. If someone disagrees, this can be discussed in a separate ticket.

As for RTSP, pure STUN would work, albeit only with good behaving NATs. One option would be to run a STUN server on the same port(s) as the RTSP server source RTP ports. Then it would also work for clients behind symmetric NATs. Unfortunately, this would be non-standard, and as such, of limited usefulness.

Another issue is RTCP, the typical even/odd ports separation for RTP/RTCP cannot be used when behind a NAT. One interesting solution is RTP/RTCP muxing (which is now supported in the RTP stream output), but there is no defined way to negociate it inside RTSP as yet.

07/25/08 17:52:08 changed by hartman

live555 should have a STUN capability since last week btw.

07/25/08 18:08:59 changed by courmisch

STUN sucks for RTSP: it does not work with some NATs, and it needs a STUN server to be configured. Doing hole punching directly from the client to the RTSP server would solve both of these problems (but requires protocol changes).