> However, common sense suggests that the server should choose a value that was > in the range specified by the client.
Thanks for confirming that this violates common sense. I had looked for references to client_port and SETUP and could not find anything concrete to suggest this was a bug in the server. > You can see from the code that a RTSP client will use whatever “client_port” > value is specified by the server in a RTSP SETUP response. This is also something I had looked into and must still be missing. I found the RTSPClient.cpp reference where client_port=%hu is scanned but only sets a flag. I was looking at RTSPClient::parseTransportParams, and the scanned value only leaves this function within the serverPortNum variable, and only if a server port wasn't found. However, the server_port line is in the snippet of openRTSP logs I added, so I'm not seeing where the response client_port value is used. Could you point me to the class and method where this would be updated? The openRTSP logs in my prior snippet also continue to use the 50104-50105 ports in the Setup subsession message instead of the 64712-64713 ports noted in the SETUP response, so if this is using the value specified by the server in the response, the openRTSP diagnostics messages may need updated. > Why don’t you use our RTSP server implementation instead? My limited experience of the type of cameras we're connecting to is that they plug in a PoE cable and the camera hardware boots up "something" to provide an RTSP server on the network, with only a limited browser interface or none. If anyone knows of some standard that would allow such a system to be modified, I would look into it. I haven't had much luck searching for the Mango server agent. Derrick N. Guerrero
_______________________________________________ live-devel mailing list live-devel@lists.live555.com http://lists.live555.com/mailman/listinfo/live-devel
