
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">

<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>

</head>

<body dir="ltr">

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<span style="font-size: 12pt;">> </span>However, common sense suggests that the server should choose a value that was in the range specified by the client.</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

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

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<br>

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

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

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

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

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.<br>

<br>

> Why don’t you use our RTSP server implementation instead?</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

<br>

</div>

<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">

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.<br>

<br>

Derrick N. Guerrero</div>

</body>

</html>