[Icecast] Tracking Listeners with Key and other parameters

[Alex Hackney]

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.

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

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?



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.

Thanks!

Alex

[Philipp Schafft]

Good morning,

Post by Alex Hackney
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.

Post by Alex Hackney
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.

Post by Alex Hackney
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.

Post by Alex Hackney
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]

Good morning,

I do have control over the headers. The webapp is built in php.

Ok.

So the ideal path would be.
1) Client hits my web app for the m3u file.
http://webapp.com/station-aac/listen.m3u
2) I create a session id and send that back with the icecast server path(s)
http://east.icecastserver.com/station-aac
http://west.icecastserver.com/station-aac
3) Client makes request to icecast and the url auth sends the request
for auth back to the app where we log the session id again from the
header as starting a session
http://webapp.com/listener_joined
4) App returns the ok to icecast and the server begins the stream.
5) If the client drops and reconnects to icecast it already has the
session in the header for the icecast path and we're good to go.

Yes.

As far as source goes, since im sending the client to the web app first
for the header and server path, I can take that query string there or
just have a uri for the source.
http://webapp.com/station-aac/listen.m3u?source=alexa
OR
http://webapp.com/station-aac/alexa/listen.m3u
http://webapp.com/station-aac/android-app/listen.m3u
http://webapp.com/station-aac/whatever/listen.m3u

Yes. But again, it's not a good idea to have that session string in
there, at least not with a non-namespaced parameter.

Thanks for your help.

No problem.


With best regards,

Post by Philipp Schafft
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.