> >>>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.
How is it better to require more work down the road (someone has to write a
draft, etc.) than build an extensible specification? It may not be likely
that anyone will need the functionality, but it really does not require any
more work to provide up front and you may reduce the work later on.
What reason is there for not making an extensible solution (besides "it is
unlilkely anyone would ever use it")?
> 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.
You were the one who mentioned it. ;-) It is analogous to the proposed
rtcp_client_port attribute in the RTSP Transport: header.
> >>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?
In the absence of a destination= attribute (which is far and away the most
common case as you may have inferred), the server sends to the same address
as the foreign end of the RTSP connection. Disallowing the destination=
parameter pretty much eliminates the possibility for DoS abuse (hey server,
go flood this IP address with UDP data). The possibility is more than idle
speculation -- a very similar DoS issue for online gaming servers was
recently discovered and published online (I forget which site but I can
probably find the article again if desired). A few fat video stream makes
online game servers' response packets look like child's play.
--
There is nothing new under the sun, but there are lots of old things we
don't know yet.
-- Ambrose Bierce
Attachment:
pgp00016.pgp
Description: PGP signature