Subject: Re: [MBONED] GregB: Your old AMT gateway

From: Toerless Eckert <[email-masked]>
Date: Wed, 22 Apr 2020 04:26:12 +0200

mboned,

Wrt today's discussion about what the best ways forward are to enable
multicast streaming for anybody (not sure if i should endorse Lenny's
age discriminating notion that we can reach everybody if we can reach
grandma's ;-):

Of course i think that the gold standard is reception directly in browsers
without anyhing else. Alas, the APIs to support UDP with multicast
may be difficult to get through the industry, i haven't followed what the
current state is.

Plugins seem to be going downhill, APIs seem to be removed from browsers.

RTCweb of yours truly IETF WG does not explicitly support IP multicast
and even if it did, i would still be worried if it would be any good
for streaming with DRM. AFAIK its really only real-time (RTP), and most
of the browser infra that connets to DRM is probably built around HTML5,
which is streaming - but i am heavily guessing.

As Jake also pointed to, there are industry standards such as in cablelabs
whereby TCP? ABR video treams are packaged into multicast, and then
on home-gateways converted back into ABR stream. AFAIK this ultimately
means that you can receive on a browser in the home what looks like
just a normal unicast video stream except that the server is on the
home gateway - e.g.: in cable networks.

This concept is not new. In fact, Greg Bumgardner did something similiar
early in the work on AMT, and i am sure there would be a lot older
examples to be found if i wouldn't be that forgetfull. And this
goes along the lines of commercial "agent/relay" solution as we saw
in Verizons presentation today.

Aka: Have a program on the receiver device that is both an
 AMT-gateway/SSM-receiver on the network side and then for local
side a TLS or (in Gregs build) RTSP server. Then the URL from
the browser passed to that agent will tell the agent which
SSM channel to join, and if AMT i needed also the relay information.

Of course, on Android, a "trusted" local server may be something
that could be difficult by googles security model, it surely would
be even more difficult by the iOS security model i think, but of
course one could always think about building the agent for
Windows or MacOS and then put it on such a system in the home
(not to speak of the hoe gateway, but thats more difficult for
grandmas's to put new software on).

Cheers
    Toerless

On Tue, Apr 21, 2020 at 01:52:06PM -0700, Greg Bumgardner wrote:
> Ha, ha, ha. My what?
> 
> ....
> 
>  I obviously have not looked at any of this stuff in years.
> 
> The Java-based browser plugin relied on JNLP support in the browser. I
> don't believe any modern browser supports that now. The plugin itself was
> dependent on a JNLP package server I had running on Google's old App Engine
> service. It might still be running though I would be surprised if it was.
> I'm not sure the old appspot service exists - was likely phased out for
> Google Compute.
> 
> There is also a standalone RTSP server app that will stream unicast to an
> RTSP client/media player. To make that work, you need a media server
> generating a multicast stream and obviously, an AMT server that has access
> to it. The RTSP server (with embeded AMT Gateway) requires an SDP document
> that describes the media stream for the player and the relay IP address for
> the server. At the time, I was running a VLC server on a machine at ISC to
> generate a multicast stream and accessed that through a relay router that I
> think Dino had deployed at the time. VLC can generate an appropriate SDP
> document but the document must be modified with some extension entries that
> describe the AMT setup.
> 
> The RTSP server code is pretty simple and not difficult to use, just needs
> to be compiled. Creating a test environment is likely much more
> complicated. I can probably locate some example SDP documents required to
> configure the AMT gateway within the server. The actual AMT gateway code
> can be separated from the RTSP server code and used on it's own. The entire
> implementation was broken down into a number of independent Java packages.
> 
> The code can be accessed via js4ms.org. I just checked and that URL still
> works (I've been paying for that domain name out of pocket for years). At
> the time, I was using Ant, then Maven, to generate binaries and upload them
> into a repository, but I'm not sure any of that works now.
> 
> I can't believe I remember this much. If you have additional questions I'll
> have to look things over to see what jogs loose.
> 
> -g.b.
> 
> 
> On Tue, Apr 21, 2020 at 12:20 PM Toerless Eckert <[email-masked]> wrote:
> 
> > GregB:
> >
> > Do i remember correctly that your old AMT gateway implementation did
> > support receipt of AMT or native and converting it into a unicast
> > stream, e.g.: for delivery to local browser ?
> >
> > If so, wasn't that stuff made public back in the day somehwere ?
> > Lenny or Jake might want to play around with it ...
> >
> > Cheers
> >     Toerless
> >
> 
> 
> -- 
> Greg Bumgardner
> Eugene, OR

-- 
---
[email-masked]