Better NAT support

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 (closed)).

(In [11095]) Implement Extended passive mode (RFC2428 - FTP Extensions for IPv6 and NATs) :

• explicitly NAT-friendly FTP (refs #66 (closed)),
• IPv6 support (closes #130 (closed)).

added Difficulty::hard + 1 deleted label

• 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).

changed the description

assigned to @Courmisch

added Component::Input: network streams label

UPnP gateway discovery could help as well.

changed milestone to %0.8.5-final

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 (closed)). 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.

added Status::will not fix label

closed

removed Status::will not fix label

reopened

changed milestone to %Features paradize

changed the description

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.

live555 should have a STUN capability since last week btw.

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).

added Status::will not fix label

closed

mentioned in issue #130 (closed)