[rtmpdump] Akamai authentication support

[Howard Chu]

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.

> The second way of authenticating with these servers, as implemented by
> David Keeffe, requires you to add conn=S:encoder:1.2.3.4:<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?

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

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.