[Icecast] Tracking Listeners with Key and other parameters

[Philipp Schafft]

Good morning,

On Mon, 2018-11-26 at 17:59 -0500, Alex Hackney wrote:
> I have an app that I've built that leverages the auth functionality of 
> icecast2 to track when listeners are added to the stream and monitor 
> what they listen to.
> 
> I've ran in to an issue where if a listener disconnects for a few 
> seconds then reconnects, I track them as a new user.

If you're workong on a mobile platform that is likely due to the network
connecting dropping for a moment.


> I can't track by ip cause there may be a few people listening from the 
> same public ip.

This is right. Using the IP for anything is likely a bad idea.


> In the docs I see this...
> 
> Other Options
> This is a list of HTTP headers provided by the client which should be 
> passed to the authencation service. Those headers are prepended by the 
> value of header_prefix and sent as POST parameters.
> 
> 
> Could I use that to track individual clients? Meaning, when the client 
> hits the app and gets the auth can I pass back the session_id and then 
> if they disconnect then reconnect I get that session_id back?

This depends on if you control the HTTP(s) request made by the "app". If
you do, you can add a extra HTTP header in the request. How that is done
depends on the framework/lib/API you use for the app.

Note that the header must be collision free with existing and future
headers. So likely you want it to start with "X-". Such as
"X-MySuperApp-Session".

Then you can configure Icecast to send that header as part of the auth
request as you already found out in the manual.



> Also how can I implement other options to be passed to the auth server?
> 
> if i have http://streaming.server.com/mount-aac.m3u?source=alexa
> 
> Is there a way to retrieve that in the post thats sent to the 
> authentication server? So I can track where they are listening from? I 
> can get the agent and that gives a little bit of detail but I'd like to 
> have a little better control over it.

This in general is a bad idea. Query strings are defined to be
interpreted by the server (here: Icecast). You must make sure your
parameters do not collide with any existing or future parameter Icecast
may have. E.g. "source" is a well defined term for Icecast and therefore
likely to become a parameter one day.

We acknowledge the problem but it is not yet solved. I would suggest you
to look at those tickets here:
      * https://gitlab.xiph.org/xiph/icecast-server/issues/2360
      * https://gitlab.xiph.org/xiph/icecast-server/issues/2361

What you can do is defining aliases of some kind and use one per
location you announce your stream. If you announce locations of M3U
files (as suggested by your example) you can also implement a M3U
generator yourself using a normal web server and use that as gateway to
the actual stream. So the M3U does include any parameter you want, but
the stream location in the M3U only contains standard parameters.


I hope that was of help to you. If you need more business level Icecast
support feel free to drop me a message off-list.

With best regards,

-- 
Philipp Schafft (CEO/Geschäftsführer) 
Telephon: +49.3535 490 17 92

Löwenfelsen UG (haftungsbeschränkt)     Registration number:
Bickinger Straße 21                     HRB 12308 CB
04916 Herzberg (Elster)                 VATIN/USt-ID:
Germany                                 DE305133015
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
URL: <http://lists.xiph.org/pipermail/icecast/attachments/20181127/739a99e9/attachment.sig>