[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MMUSIC] RTSP and NATs
inline.
Tom Marshall wrote:
On Mon, Feb 03, 2003 at 06:45:54PM -0500, Jonathan Rosenberg wrote:
Tom Marshall wrote:
STUN does not allocate the addresses. It merely tells the client what a
regular, off the shelf NAT has allocated to a user. Since regular,
off-the-shelf NATs do not know anything about RTP port pairings, two
separate STUN requests will result in a nat allocating two bindings
which are most likely not consecutive (or follow the odd/even rule).
THis is dealt with through an SDP extension that allows a client to
provide a specific address and port for SDP
(http://www.ietf.org/internet-drafts/draft-ietf-mmusic-sdp4nat-03.txt).
This draft again assumes that RTP is the only transport choice:
rtcp-attribute = "a=rtcp:" port
What if there were some other UDP based transport that required two UDP
ports (perhaps even "RTPng")? You would need yet another draft to address
it. Why not make the solution generic instead?
Well, if thats so, I would have rather had such a debate in the context
of the above draft. Anyway, I know of no other media stream that uses
UDP that uses multiple ports AND that has an algorithmic relationship
between those ports (i.e., has no way to express in the SDP which ports
are needed). Seems like a non-problem.
Prior to IPv6 there was no known way to express a numeric IP address such
that it would not fit into a 32-bit integer. Now there is, and it is one
source of poring issues. Of course this is not a problem now. Can you say
with certainty that it will never be a problem?
Seems like a bit of an over-exaggerated analogy. As I said, for any new
protocol that needs multiple ports, it should simply make sure that its
SDP parameter definitions include them. In such a case you will never
have a problem.
Anyway, the point is moot, since, based on my limited RTSP knowledge,
SDP is not used in the client addresses anyway. Thus, you can't use the
SDP draft above.
A smart ALG won't. It should know not to muck with IP addresses inside
of the RTSP message if they are not private addresses (if stun is used,
those addresses will have already been changed to public ones by the
RTSP client). Indeed, one can imagine usign RTSP to setup a streaming
media session to some third party device outside of the nat, in which
case the ALG has to know not to change the IP. I wonder if the linux
code you cite supports that.
All of the four or so RTSP modules that I am familiar with simply look at
client_port= and perform a mapping. In order to detect that a transport
spec is using STUN, the module would also need to check for a destination=
attribute.
Right. Although, I must admit confusion. If the client doesnt provide a
destination attribute, to what IP address is the media sent? It seems to
me that the destination parameter would normally be there. Or perhaps
you are saying it is there, but its not looked at by the ALG?
Which, of course, brings me to my beef with ALG - the wrong people write
them in general. Only an RTSP expert would probably know to look for
such nuances (even then...),
Indeed. I have written one of the modules referenced above and I did not
consider it. On the other hand, the destination= parameter has always been
a security risk at the server side and I am reluctant to advocate using it.
I guess I don't understand how media is delivered to the client then.
It certainly is their business if they make the equipment. It's enough of
their business that they provide an ALG for FTP. But I think it should also
be (or should have been) the business of the IETF to design a NAT traversal
protocol which allows the client to directly request mapped ports from the
NAT device. Such a protocol would reduce or eliminate the need for STUN and
friends, and it would provide a single protocol for the vendors to implement
instead of a running treadmill of RFCs.
Oh yes, no doubts there. midcom has been trying for years, and still no
success. Even then, once its done, it doesn't work for many topoligies.
The ultimate right answer is nsis, which would allow the client to
directly ask for bindings through all nats that it will need to talk to.
But, we are years and years away from such a thing seeing deployment.
But the vendors have already been given a single protocol to implement:
UPnP. It was created from the desire for NAT control at the client and
appears to have a lot of support from NAT vendors already. And this makes
me wonder why we are continuing to propose more NAT traversal solutions.
Why not either recommend UPnP or design an equivalent?
I indicated in another mail several problems with upnp. Another
practical one is that its not that widely deployed yet. So, when an
media company wants to deploy, do they wait and hope that people go off
and buy upgrades to their nat, or hope all the nat vendors fall in line?
No way. They want to be able to deploy the service now, without being
dependent on features placed into home routers.
Anyway, ietf is working on their version of upnp, which is the midcom
protocol.
Certainly. This is called "symmetric NAT". Its common but to date the
full-cone variety, which maps bindings by private IP/port alone, is
quite prevalent amongst the home NATs.
Interesting. Where can I find out more about how many home networks use
which types of NAT?
I've heard reports of studies done on the subject, but have not seen
concrete or quotable reports. I think such an analysis, especially
tracking it over time, would be a great masters project for some student
somewhere.
-Jonathan R.
--
Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave.
Chief Scientist First Floor
dynamicsoft East Hanover, NJ 07936
jdrosen@dynamicsoft.com FAX: (973) 952-5050
http://www.jdrosen.net PHONE: (973) 952-5000
http://www.dynamicsoft.com
_______________________________________________
mmusic mailing list
mmusic@ietf.org
https://www1.ietf.org/mailman/listinfo/mmusic