> I agree with you. But I am working with a kind of proprietary RTSP
> superset which need this (they use OPTIONS to keep-alive sessions),
> and I am not responsible for these choices. :)
Even though you might feel that you're "not responsible for these choices" made
by the developers of this cli
On Sat, Aug 11, 2012 at 2:15 AM, Ross Finlayson wrote:
> That's what I did, and I put in it additional parsing code for the
> Session header and could retrieve the corresponding session with a
> Lookup.
>
>
> But there's no guarantee that an "OPTIONS" request will even contain a
> session header.
> That's what I did, and I put in it additional parsing code for the
> Session header and could retrieve the corresponding session with a
> Lookup.
But there's no guarantee that an "OPTIONS" request will even contain a session
header. And even if it does, there's nothing session-specific that y
On Fri, Aug 10, 2012 at 10:55 PM, Ross Finlayson wrote:
> I would like to know if that would be interesting to make all RTSP
> requests handling in RTSPServer session-aware; an example of flow would
> be, for a request XXX currently unaware of session (OPTIONS for
> instance)
>
>
> No, because the
> I would like to know if that would be interesting to make all RTSP
> requests handling in RTSPServer session-aware; an example of flow would
> be, for a request XXX currently unaware of session (OPTIONS for
> instance)
No, because the "OPTIONS" command - for listing the RTSP commands that the
s
Hi Ross,
I would like to know if that would be interesting to make all RTSP
requests handling in RTSPServer session-aware; an example of flow would
be, for a request XXX currently unaware of session (OPTIONS for
instance):
- detect presence of Session header
- if present:
- call RTSPServer::R
