Icecast - Nov 2018 - Tracking Listeners with Key and other parameters

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

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>

Good morning,

On Tue, 2018-11-27 at 12:00 -0500, Alex Hackney wrote:
> 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,
> 
> On 11/27/2018 5:13 AM, Philipp Schafft wrote:
> > 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.
> 
-- 
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/20181129/d9abc219/attachment.sig>