headers
Lionel Orry | 10 Aug 2012 10:00
Picon

Make all RTSP requests potentially session-aware

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::RTSPClientSession::handleCmd_XXX()
        - default implementation of handleCmd_XXX() is to call
          RTSPServer::RTSPClientConnection::handleCmd_XXX()
            - implementation in RTSPClientConnection as usual
- if absent:
    - call RTSPServer::RTSPClientConnection::handleCmd_XXX() directly

That way, if one needs a special handling of such a request in a session
context, he can override RTSPServer::RTSPClientSession::handleCmd_XXX().

What do you think about it?

Regards,
Lionel
Permalink | Reply |
headers
Ross Finlayson | 10 Aug 2012 22:55
Favicon

Re: Make all RTSP requests potentially session-aware

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 server supports - applies to the server as a whole, rather than to a particular session.

If you want to redefine the handling of the "OPTIONS" command, then the way to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"), and reimplement the "handleCmd_OPTIONS()" virtual function.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |
headers
Lionel Orry | 11 Aug 2012 00:46
Picon
Gravatar

Re: Make all RTSP requests potentially session-aware

On Fri, Aug 10, 2012 at 10:55 PM, Ross Finlayson <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 "OPTIONS" command - for listing the RTSP commands that the
> server supports - applies to the server as a whole, rather than to a
> particular session.
>
> If you want to redefine the handling of the "OPTIONS" command, then the way
> to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"),
> and reimplement the "handleCmd_OPTIONS()" virtual function.

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.

Thanks anyway,
Lionel
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel@...
> http://lists.live555.com/mailman/listinfo/live-devel
>
Permalink | Reply |
headers
Ross Finlayson | 11 Aug 2012 02:15
Favicon

Re: Make all RTSP requests potentially session-aware

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 you could/should be doing to handle it, because the only thing an "OPTIONS" response should contain is a list of request names that the server handles.  And that has nothing to do with session-specific state.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |
headers
Lionel Orry | 11 Aug 2012 02:37
Picon
Gravatar

Re: Make all RTSP requests potentially session-aware

On Sat, Aug 11, 2012 at 2:15 AM, Ross Finlayson <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.   And even if it does, there's nothing session-specific that
> you could/should be doing to handle it, because the only thing an "OPTIONS"
> response should contain is a list of request names that the server handles.
> And that has nothing to do with session-specific state.

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. :)

Lionel

>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel@...
> http://lists.live555.com/mailman/listinfo/live-devel
>
Permalink | Reply |
headers
Ross Finlayson | 11 Aug 2012 11:40
Favicon

Re: Make all RTSP requests potentially session-aware

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 client, I hope that you contact them, asking them to fix their clients so that they adhere to the standard, which is to use RTCP "RR" packets (or, failing that, RTSP "GET_PARAMETER" requests) as keep-alives.

But if you can't do that, then - because all of the important member variables and member functions of "RTSPClientConnection" and "RTSPClientSession" are "protected" rather than "private" - you should be able to reimplement the "OPTIONS" handler to parse the session id and use it to look up the "RTSPClientSession" object (and then do whatever you want with it).  You'll get no help from me on this, though.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel@...
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |
headers
Ross Finlayson | 11 Aug 2012 11:40
Favicon

Re: Make all RTSP requests potentially session-aware

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 client, I hope that you contact them, asking them to fix their clients so that they adhere to the standard, which is to use RTCP "RR" packets (or, failing that, RTSP "GET_PARAMETER" requests) as keep-alives.

But if you can't do that, then - because all of the important member variables and member functions of "RTSPClientConnection" and "RTSPClientSession" are "protected" rather than "private" - you should be able to reimplement the "OPTIONS" handler to parse the session id and use it to look up the "RTSPClientSession" object (and then do whatever you want with it).  You'll get no help from me on this, though.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |
headers
Lionel Orry | 11 Aug 2012 02:37
Picon
Gravatar

Re: Make all RTSP requests potentially session-aware

On Sat, Aug 11, 2012 at 2:15 AM, Ross Finlayson <finlayson <at> live555.com> 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.   And even if it does, there's nothing session-specific that
> you could/should be doing to handle it, because the only thing an "OPTIONS"
> response should contain is a list of request names that the server handles.
> And that has nothing to do with session-specific state.

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. :)

Lionel

>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel <at> lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
Permalink | Reply |
headers
Ross Finlayson | 11 Aug 2012 02:15
Favicon

Re: Make all RTSP requests potentially session-aware

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 you could/should be doing to handle it, because the only thing an "OPTIONS" response should contain is a list of request names that the server handles.  And that has nothing to do with session-specific state.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |
headers
Lionel Orry | 11 Aug 2012 00:46
Picon
Gravatar

Re: Make all RTSP requests potentially session-aware

On Fri, Aug 10, 2012 at 10:55 PM, Ross Finlayson <finlayson <at> live555.com> 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 "OPTIONS" command - for listing the RTSP commands that the
> server supports - applies to the server as a whole, rather than to a
> particular session.
>
> If you want to redefine the handling of the "OPTIONS" command, then the way
> to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"),
> and reimplement the "handleCmd_OPTIONS()" virtual function.

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.

Thanks anyway,
Lionel
>
>
> Ross Finlayson
> Live Networks, Inc.
> http://www.live555.com/
>
>
> _______________________________________________
> live-devel mailing list
> live-devel <at> lists.live555.com
> http://lists.live555.com/mailman/listinfo/live-devel
>
Permalink | Reply |
headers
Ross Finlayson | 10 Aug 2012 22:55
Favicon

Re: Make all RTSP requests potentially session-aware

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 server supports - applies to the server as a whole, rather than to a particular session.

If you want to redefine the handling of the "OPTIONS" command, then the way to do this is to subclass "RTSPClientConnection" (not "RTSPClientSession"), and reimplement the "handleCmd_OPTIONS()" virtual function.


Ross Finlayson
Live Networks, Inc.
http://www.live555.com/ 

_______________________________________________
live-devel mailing list
live-devel <at> lists.live555.com
http://lists.live555.com/mailman/listinfo/live-devel
Permalink | Reply |

Gmane