Comments on draft-ietf-mmusic-rtsp-nat-00.txt

Magnus:

I have a comment on 3.2 Symetric RTP.

As Tom Marshall pointed out ealier, a RTSP/RTP based streaming server
normally uses a single RTP port (let's call it X) to send RTP packets to
many (potentially hundreds) of clients. Now Symetric RTP asks these clients
to send an RTP packet with their individual client SSRC in the payload to
this port X on the server host. Since each client randomly generates client
SSRC, there is some chance (as high as 10^-4 according to RFC1889, section
8.1) that two clients may end up with same SSRC, in which case the server
may send RTP packets to wrong clients. I did study the SSRC collision
detection scheme in RFC1889 and found it irrelevant because it only applies
to multicast RTP sessions. I don't think destination IP can help here since
prior to the establishment of binding  our server doesn't know clients
public IPs. Besides, the two collided clients may well be behind the same
NAT and hence probably share public IP.

I hereby suggest that the binding RTPs to add, in a fashion defined below,
client's RTSP sessionID in addition to client's SSRC in those binding RTP
packets. Notice RTSP sessionIDs are generated by the server and hence can be
made unique amongst all clients of that server.

The session ID happens to provide other niceties:

1. One client only has to make sure that its client SSRCs are unique amongst
the RTP tracks it has in the session (if it happens to have more than one
track)
2. Since RTSP session ID can be 64 bytes or longer, it offers added
protection against stream hijacking or brute force attacks (since now the