[Live-devel] Proxy Server REGISTER option

[Ross Finlayson]

> 1. Do you think the naming convention (registeredProxyStream-N) for REGISTERED streams will adequately support most users / use cases? This has been convenient in my particular case and allows me to proceed  with my current efforts, however, I'm not sure it is the best approach. Would having an option that allows the stream name to be specified in the REGISTER command make sense? Default behavior would then fall back to Proxy Server parsing the URL into prefix/suffix as originally implemented.

Having an optional parameter in the "REGISTER" or "REGISTER_REMOTE" command is an interesting idea.  I might include this when I write up my forthcoming IETF Internet-Draft that specifies these commands.  Having the default behavior be to use the back-end URL's suffix, however, would be problematic, as we discovered.  (Another issue to consider is: What would the proxy server do if it received two separate "REGISTER" (or "REGISTER_REMOTE") requests for different back-end URLs with the same URL suffix?)  Note that - if desired - one could subclass "RTSPServerWithREGISTERProxying" and easlly reimplement the virtual function "implementCmd_REGISTER()" however you wish.


> 2. A small item to note. During the course of my testing (using several different client implementations)  I found a problem when trying to REGISTER_REMOTE since it is not explicitly list in the OPTIONS list from Proxy Server. Some client's (3rd party applications) may fail with "Method Not Allowed". For me it is not an issue...I simply use a client implementation that does not retrieve the OPTIONS list before sending the REGISTER_REMOTE command.

That was an oversight in our implementation of "OPTIONS"; it will be fixed in the next release of the software.


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20131009/89b8d300/attachment.html>