> Do you know a way to change the SETUPrtsp in your client code (openRTSP) to
> indicate that the two track go to two different IP (interface) for example:
> 4,0.002474,195.134.1.6,195.134.1.2,RTSP/SDP,Reply:RTSP/1.0200OK,withsessiondescription
> 5,0.004125,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.3/spatialSoc_basenh3.mp4/trackID=65536RTSP/1.0
> 6,0.004885,195.134.1.6,195.134.1.2,RTSP,Reply:RTSP/1.0200OK
> 7,0.005351,195.134.1.2,195.134.1.6,RTSP,SETUPrtsp://195.134.1.6/spatialSoc_basenh3.mp4/trackID=65538RTSP/1.0
No - this makes no sense. The IP address (actually, it could also be a domain
name) in the "rtsp://" URL that appears in a RTSP command (such as "SETUP")
refers to an address on the *server*. It is not a client address. (Note that,
in practice, because RTSP commands are sent over a TCP connection that has
already been set up, these IP addresses (or domain names) in the "rtsp://" URLs
are not actually looked at all by the server.)
If you - as a RTSP client - want to specify that the stream should be sent to a
*different* IP address from the IP address of the client, then the way to do
this - in the RTSP protocol - is to include, in the "SETUP" command, a
"Transport:" header that contains, e.g.
destination=123.45.67.89;
However, there are two big practical problems with doing this:
1/ Our RTSP client code does not support this (and there are no plans to do
so). (Conceivably, you *might* be able to implement this by subclassing
"RTSPClient", but it wouldn't be easy.)
2/ Most servers will not handle "destination=" parameters in a "SETUP"
command's "Transport:" header, because it (i.e., allowing a client to specify
some arbitrary 3rd party as being the stream's destination) is a security risk:
It makes possible 'denial of service' attacks. Our server implementation does
support this, but only if the compile-time macro
RTSP_ALLOW_CLIENT_DESTINATION_SETTING is defined (see "RTSPServer.cpp", line
1282).
But if your intention is to send the two video tracks to different interfaces
within the same client, then the best way to do this is to keep things the way
that they work now: Send both streams to the same (client) IP address, but with
different port numbers.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
_______________________________________________
live-devel mailing list
[email protected]
http://lists.live555.com/mailman/listinfo/live-devel
