[Live-devel] SVC multi streaming transmission of separate layers

[Ross Finlayson]

> 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/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20120907/90511a5f/attachment.html>