[Live-devel] who can add some functionality to the rtsp proxy for me (for pay)

Virginia Hamm liverwurst at owal.io
Mon Dec 12 18:30:51 PST 2016


Ross said it was OK to post this!

I need to give temporary access to a running proxy to users, and not only
revoke the access when it times out, but also kill their existing streams.

There are two components here:

   1. Add and remove authorizations at runtime.
      - The authorization could piggy-back on the existing authdb mechamism
      (I already have code that uses grpc (google RPC) to create new
      username/passwords; you can reuse that code, or you can write
your own with
      your favorite IPC mechanism.
      - Alternatively, authorization could happen by generating a long,
      random URL and giving that to the user. That is, instead of the
user having
      to connect to rtsp://foo:pass@example.com:28882/proxyStream, they
      could just as well connect to rtsp://
      example.com:28882/piweuroiajsdf8weorpoajdflqopoiykdlgjloiute.
      - It does not matter whether the username/password (or url) is
      generated by the proxy and communicated to my user-facing service (which
      will subsequently forward it to the final user), or whether the service
      generates those and passes them to the proxy. They are obviously
      functionally equivalent, but one may be easier to implement than
the other.
   2. The authorization should come with a time limit, of the order of one
   minute. When this time limit expires:
      - The credentials of step 1 should be removed from proxy
      - Any sessions (so, both the rtsp TCP connection and any video
      streams being sent to the user) that were created using those credentials
      should be terminated.

Needless to say, the code should come with full tests.

Anyone interested in working on this for a fee? The only condition I impose
is that the code can be released under the LGPL (or whatever Ross tells me
is appropriate to release it under). This means that if you incorporate
anyone else's code, that use should neither violate *their* licensing, nor
should encumber the releasability (is this a word?) under the LGPL.

\/-/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.live555.com/pipermail/live-devel/attachments/20161212/04349171/attachment.html>


More information about the live-devel mailing list