Your log shows that your server is using an out-of-date version of the "LIVE555
Streaming Media" code.
You should first use an up-to-date version of the "LIVE555 Media Server" as
your server, and an up-to-date version of "openRTSP" (using the "-t" option, to
request RTP-over-TCP streaming) as y
Dear ,
I Cannot recv the stream data on RTSP-TCP mode,The system returns
the following information.
However , in the RTSP-UDP mode is normal, Please Help Me!
Attachment is DEBUG message .
Opening connection to 192.168.1.123, port 8554...
...remote connection opened
Thanks. I have just released a new version (2012.10.01) of the code that fixes
this.
Ross Finlayson
Live Networks, Inc.
http://www.live555.com/
___
live-devel mailing list
live-devel@lists.live555.com
http://lists.live555.com/mailman/listinfo/live-dev
Hi,
We found an issue in SIPClient.cpp in function sendBye()
http://www.live555.com/liveMedia/doxygen/html/SIPClient_8cpp-source.html
line 682 reads:
"CSeq: %d ACK\r\n"
It should be changed for
"CSeq: %d BYE\r\n"
Our setup is as follow:
FreeSWITCH Version 1.2.0-rc2+git~20120730T23584
Ross,
Thanks for the quick reply. Here is the diff of the changes I propose to the
AWAITING_DOLLAR case in SocketDescriptor::tcpReadHandler1().
Rex
case AWAITING_DOLLAR: {
if (c == '$') {
#ifdef DEBUG_RECEIVE
fprintf(stderr, "SocketDescriptor(socket %d)::tcpReadHandler(): Saw
Ok cool thanks.
Matt S.
On Friday, September 28, 2012 2:04:43 PM, Ross Finlayson wrote:
I'm not quite sure how it works if fReuseFirstSource is set and one
client requests a TCP connection and another a UDP?
Aha! There's actually a bug in the current code that prevents this
from working prop
> 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.
Yes, but since the origin
I'm streaming RTP data over TCP from a network camera. Most of the time this
works fine. But about once every 30 minutes (varies a lot) this particular
camera sends some unexpected data between two RTP packets and that causes
live555 to go into a state where it thinks it's receiving RTSP data
