[rtmpdump] Akamai authentication support

Martin Storsjö martin at martin.st
Sat Jul 23 23:37:19 CEST 2011

On Sat, 23 Jul 2011, Howard Chu wrote:

> Martin Storsjö wrote:
> > Hi,
> > 
> > Some time ago, I had to push a stream to Akamai, and thus I looked into
> > the two patches that were posted last year, that both achieve this.
> > Unfortunately, they do that in two completely different ways, so I'm not
> > sure which one is better, or if both of them should be integrated.
> > 
> > I'll repost polished up versions (fixed some out of bounds reads and
> > memory leaks) of them shortly, but I'll try to explain the differences
> > between them first.
> > 
> > The first one is by Sergiy, originally from May 2010, the other by David
> > Keeffe from July/August 2010.
> > 
> > Both of them implement some kind of challenge/response authentication. By
> > default, the FMS servers at akamai don't let you connect at all.
> > 
> > If adding flashver=FMLE/3.0\20(compatible;\20FMSc/1.0) to the rtmp url,
> > the server will close the connection indicating that you need to
> > authenticate with the adobe mode of authentication. On the second
> > connection attempt, the client indicates which user it will try to
> > authenticate as, the server closes the connection again (and supplies a
> > challenge at the same time). On the third connection attempt, the client
> > provides the username, the challenge received on the last attempt, and the
> > response to the challenge. This authentication scheme is what FMLE uses
> > (in the version I tried at least).
> Sounds messy, but if it's "standard" across Adobe servers, I guess it 
> would be good to have it.

Yes, it seemed to be quite standard determining from his mails (IIRC he 
submitted it as generic authentication support for FMS, not specific to 

> > The second way of authenticating with these servers, as implemented by
> > David Keeffe, requires you to add conn=S:encoder:<username>  to the
> > rtmp url. When this is added, the server lets the client in directly, and
> > then sends the challenge and allows the client to respond to the challenge
> > - all inline within one session.
> Sounds better, but is it specific to Akamai, or valid across other servers
> too?

I'm not sure, it does sound kinda hacky/nonstandard, but you never know. 
It has the upside of both being more straight-forward (requiring no 
reconnections), and the patch is much smaller. I'll try to mail David and 
ask where he got the specs or what he reverse-engineered for that one.

> > Also, worth noting, when publishing to akami, the stream id given as
> > playpath might contain a %i - FMLE changes this into a 1 (probably
> > allowing several bitrate variants of the same content or something such),
> > the user has to expand it manually with librtmp (this took me ages to hunt
> > down...).
> > 
> > I don't have access to publishing to akamai myself at the moment
> > unfortunately, I guess you want access to something such to test the
> > patchsets before either of them can be merged.
> Agreed. And I don't have anything to test with here either. These 
> patches are going to site idle until someone steps up who can verify 
> their functionality.

Yeah. Hopefully someone can offer you an account to test run it on (I can 
sure help out a bit too).

> Side note - using the "OpenSSL compatibility" wrapper for GnuTLS is
> problematic, since it has its own, different, license separate from the rest
> of GnuTLS. We can't accept any code that uses that wrapper.

Ah, I see, yes, that's definitely a problem. David's patch use it for both 
base64 and md5, while Sergiy's only uses it for md5 (it has a small 
reimplementation of base64 for the gnutls case).

Would it be better to simply use the gcrypt functions for md5 and base64 
directly instead? Sure, there are gnutls builds that use nettle instead of 
gcrypt, but hopefully someone steps up to fix support for that if they 
want to use rtmpdump on such setups.

// Martin

More information about the rtmpdump mailing list