<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"><base href="x-msg://4207/"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><span style="font-size: 9.5pt; font-family: Consolas; ">To prevent this situation, I tried adding a check to SocketDescriptor::tcpReadHandler1() in the AWAITING_DOLLAR case to prevent it from calling fServerRequestAlternativeByteHandler if the byte read was 0xFF or 0xFE. This is, of course, a hack on top of a hack.</span></div></div></div></blockquote><div><br></div>Yes, but since the original 'hack' (i.e., using 0xFE and 0xFF as special 'signaling' bytes) relies upon the fact that we don't expect these characters to appear within RTSP requests or responses, it seems reasonable to modify the code - as you did - to check for this.</div><div><br></div><div>Just to make sure we're on the same page here, please send a "diff" containing your modification, and I'll include it in the next release of the software.</div><div><br></div><div><br></div><div><blockquote type="cite"><div lang="EN-US" link="blue" vlink="purple" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div class="WordSection1" style="page: WordSection1; "><div style="margin: 0in 0in 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; "><span style="font-size: 9.5pt; font-family: Consolas; ">I’ve contacted the camera vendor to find out why they put this mystery data in between the RTP packets sometimes. But here I wanted to ask if that was even allowed per the RTSP spec</span></div></div></div></blockquote><div><br></div>No, definitely not. There shouldn't be any extra data like this appearing in the TCP stream. It's apparently a bug in the network camera.</div><br><br><div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-border-horizontal-spacing: 0px; -webkit-border-vertical-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; font-size: medium; ">Ross Finlayson<br>Live Networks, Inc.<br><a href="http://www.live555.com/">http://www.live555.com/</a></span></span>
</div>
<br></body></html>