karlheyes / icecast-kh

KH branch of icecast
GNU General Public License v2.0
298 stars 106 forks source link

Wildcard mount listener_remove #333

Closed kschouw closed 3 years ago

kschouw commented 3 years ago

Hi Karl, hope you are well.

I just had a quick question regarding wildcard mounts and authentication, I currently have the following config defined:

<relay>
    <local-mount>/ice/{{stream_name}}_{{quality}}.{{codec}}</local-mount>
    <mount>/ice/{{stream_name}}_{{quality}}.{{codec}}</mount>
    <server>{{stream_server}}</server>
    <retry-delay>5</retry-delay>
</relay>

<mount>
    <mount-name>/ice/{{stream_name}}_{{quality}}.{{codec}}</mount-name>
</mount>

<mount>
    <mount-name>/ice/{{stream_name}}_{{quality}}_*.{{codec}}</mount-name>
    <authentication type="url">
        <option name="listener_add" value="http://test.com/add"/>
        <option name="listener_remove" value="http://test.com/remove"/>
        <option name="auth_header" value="icecast-auth-user: withintro"/>
    </authentication>
    <fallback-mount>/ice/{{stream_name}}_{{quality}}.{{codec}}</fallback-mount>
    <fallback-override>1</fallback-override>
</mount>

There is a relay pushing into the static mount point /ice/{{stream_name}}_{{quality}}.{{codec}} and then I have a wildcard mount point where all users will be directed to /ice/{{stream_name}}_{{quality}}_*.{{codec}} which has a fallback to the static mount if nothing is being pushed.

When I connect on the wildcard mount lets say /ice/{{stream_name}}_{{quality}}_001.{{codec}} the listener_add works perfectly and in my case a small piece of audio is played and then the fallback mount is loaded. Now when I disconnect I never get the listener_remove request being sent.

Is this intended behaviour? I'm not sure if internally the user is totally removed from the wildcard mount and then added back when audio is played again?

Thanks for your help, Kyle.

karlheyes commented 3 years ago

Yes, the auth is looked up on exit so if the listener has fallen back then you will see the situation in the above case. Ideally, for other reasons, the listeners should not actually be moved, instead the stream should remain active and fed from the fallback as you may have 2 different auths for different streams but a common fallback. The question for that sort of change is breaking backward compatibility,

Originally the auth was attached to the listener so the original auth was called on exit but that ended in confusion in cases with people reloading the xml a lot.

karl

kschouw commented 3 years ago

Thanks Karl, that clears things up.