[Live-devel] Problems with RTSPClient, CSeq variable and SANYO network cameras ...

[Derrick N. Guerrero]

>
> I've found out that when you run a few different instances of RTSP clients
>> in separate threads CSeq number is not increased by one with each
>> consecutive request.
>> It's because CSeq number is a static variable in RTSPClient.
>>
>
> This is a perfect illustration of why you are not supposed to run LIVE555
> library code in multiple threads.  (Have you read the FAQ entry about
> threads?  If not, then why not (because you were asked to read the FAQ
> before you subscribed/posted to the mailing list)?)
>
> Instead, you should be using a single event loop (in a single thread) -
> even to make multiple RTSP client requests.
> --
>
> From the faq,

Another possible way to access the code from multiple threads is to have
each thread use its own "UsageEnvironment" and "TaskScheduler" objects, and
thus its own event loop. The objects created by each thread (i.e., using its
own "UsageEnvironment") must not interact (except via global variables).


This is what I'm doing and haven't had a problem yet with our test servers.
What I'm more interested in is from the original post:

Does LiveMedia library conform to RTSP standard in this matter or maybe it
is a bug in Sanyo devices ?

I would think that even in single-threaded usage, if multiple RTSP client
requests are required, then the CSeq would still increase by more than one.
Also from the original post:

SANYO network cameras end RTSP session with an error "Bad Request" when the
current request's CSeq number is greater then CSeq of the previous one plus
one.


If this is expected behavior from the standard, I imagine I should make some
changes before this actually becomes a problem... If this is a bug in the
server implementation, I can make my bosses aware of it and try to steer
away from such servers.  Any advice?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20100401/3ce5f6a2/attachment.html>