Icecast-Server issueshttps://gitlab.xiph.org/xiph/icecast-server/-/issues2023-06-07T08:36:00Zhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2476Support for linking well known IDs from metadata2023-06-07T08:36:00ZPhilipp SchafftSupport for linking well known IDs from metadataIt would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also ...It would be nice if Icecast could auto link data when there is a well known ID for it. This is the case with e.g. MusicBrainz.
There should be a boolean setting that can be used to turn this off (e.g. for legal reasons).
This may also be implemented on top of #2475 by adding defaults to it.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2475Content resolver support2023-06-07T09:04:02ZPhilipp SchafftContent resolver supportAs there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially...As there is not yet been a content resolver set up for Icecast and/or the foundation I would like to suggest the following:
Icecast should be extended with a set of settings used to generate URLs for content resolver requests. Initially there should be support for generating links to documentation. Other types (such as fetches) might later be added.
The I suggest to allow a template style URLs as values with `%`-prefixed parameters to be substituted.
As a reference "`ise-uri-template`" (`82ebe8fa-8b04-415a-ba90-16267465ef71`) defines:
> A URI template for accessing a resolver. This should not be used directly but my using one of the relations derived from it. Such templates are meant to be attached to contexts to allow easy access to resolvers without the need to set direct URIs on every tag.
>
> Templates are used as is with the following variables replaced by correctly URI encoded values. If a given value is not available this template is not available.
>
> * "%I": Any ISE of the tag
> * "%U": The UUID of the tag
> * "%O": The OID of the tag
> * "%R": The URI of the tag
>
> The use of those values is mostly safe as "%" is a special character in URIs that can only be followed by digits, or the letters "a" to "f". However some applications generate invalidly encoded Unicode URIs containing values in the form of "%uNNNN". Those are invalid by themself and therefore not valid in such templates.
I would like to extend that by providing three more substitutions:
* A generic one for the identifier (in any type/encoding)
* The name of the type/encoding used
* The name of the type/encoding used but the value `ise` for any ISE type (UUID, OID, URI).
If such parameters are added a note should be added to the code to make clear that they do not follow the `ise-uri-template` rules. However they may be added or at least reserved for `ise-uri-template` to avoid future syntax collisions.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2469HLS (HTTP Live Streaming) should be supported2023-11-28T18:36:05ZBjoern JackeHLS (HTTP Live Streaming) should be supportedplain http audio streams as Icecast supportes them currently have two major drawbacks for clients:
1) network connectivity changes lead to audio stream losses, clients will have to reconnect, audio will be interrupted
2) network modems...plain http audio streams as Icecast supportes them currently have two major drawbacks for clients:
1) network connectivity changes lead to audio stream losses, clients will have to reconnect, audio will be interrupted
2) network modems have to be busy continously because the plain audio stream is being sent all the time. The permanent activity of the modem is not energy efficient at all. Mobile devices suffer from noticable battery drain.
The solution to the above mentioned problems is HLS (https://en.wikipedia.org/wiki/HTTP_Live_Streaming). The Rocket Streaming Audio Server from https://rocketbroadcaster.com/streaming-audio-server/ does support HLS for example.
With HLS audio streams modems of client devices can stay idle most of the time, as a result of that you see greatly enhanced battery live - and network switching and even short network outages will not be a problem for clients any more.
It would be awesome if Icecast would add support for HLS, too, to overcome the shortcomings of plain audio streams, which especially mobile users suffer from considerably.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2465Add support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token...2023-03-18T10:25:42ZPhilipp SchafftAdd support for RFC 6750: The OAuth 2.0 Authorization Framework: Bearer Token UsageSupport for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Support for RFC 6750 should be added. In a first iteration this only needs to be supported by the `url` and the `enforce-auth` backend.
See also: xiph/icecast-libshout#2311Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2461Converting URL auth to use string renderer.2023-02-27T11:48:36ZPhilipp SchafftConverting URL auth to use string renderer.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Currently the URL auth backend builds it's POST data itself. This should be migrated to use string renderer. The code from URL events can be used as a template.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2439HTTP request EOF problem2022-05-07T15:37:59ZCsaba27HTTP request EOF problemHello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$...Hello, i have a problem with icecast 2.4.99 version, after the http response the icecast doesn't close the connection.
There is an example code from PHP:
```
<?php
// ini_set("default_socket_timeout", 5);
$start = microtime(true);
$fp = fsockopen("icecast-example-host.com", 8000, $errno, $errstr, 5);
if ($fp)
{
$out = "GET /status_json.xsl HTTP/1.1\r\n";
$out .= "Connection: Close\r\n";
$out .= "Host: icecast-example-host.com:8000\r\n";
$out .= "User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/100.0.4896.127 Safari/537.36\r\n";
$out .= "\r\n";
fwrite($fp, $out);
// stream_set_timeout($fp, 5);
$line_count = 0;
while (!feof($fp))
{
$line_count++;
echo $line_count . " " . fgets($fp);
# echo fread($fp, 1024);
}
fclose($fp);
}
else
{
echo $errstr . " (" . $errno . ")" . PHP_EOL;
}
echo PHP_EOL . " " . round(microtime(true) - $start, 4);
```
Run in console and check the execution time (request time).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2435URL Auth does not post good port2022-04-07T17:32:54ZRa LawaURL Auth does not post good portHi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the cli...Hi,
URL Auth always posts the first listen-socket port configured in icecast.xml. When both http (port 80) and https (port 443) are enabled, url auth always send port=80 in the post request.
I think, it should send port=80 when the client uses an http request and 443 when it uses an https request.
For url redirection, this would help to produce an url which depends on method used by the client. Redirection to an https url when client uses an https url and http otherwise.
Currently I use an other method to know which method is used. I patched url_add_client to send also tlsmode to the post request.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/24322.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared t...2024-01-20T23:54:11ZTom Zet2.4.99 beta 3 - OPENSSL - still support for TLS 1.0 and TLS 1.1 - compared to 2.4.4The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01...The current **2.4.99 beta 3** still offers TLS 1.0 and TLS 1.1. The SSL test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.28.01_PM](/uploads/dfa1d62d8672e72cf0bcb167575ddbff/Image_2022-03-18_at_11.28.01_PM.jpeg)
On a Debian sid System with `OpenSSL 1.1.1n 15 Mar 2022` the icecast has been compiled with `./configure --prefix=/home/zumbi/icecast-2.4.99-beta-3 --with-curl --with-openssl`
The following ciphers are configured in the xml. at the end I excluded `!TLSv1:!TLSv1.1`.Even if standard in openssl, this cyphers has not been ignored.
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:!TLSv1:!TLSv1.1</ssl-allowed-ciphers>`
While on a productive Debian 11 with `OpenSSL 1.1.1k 25 Mar 2021` and **icecast 2.4.4** the test on https://www.ssllabs.com/ shows the following result
![Image_2022-03-18_at_11.30.33_PM](/uploads/43b55bf7d48f5dcda944f398c48200b5/Image_2022-03-18_at_11.30.33_PM.jpeg)
The following ciphers are configured in the xml
`<ssl-allowed-ciphers>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256</ssl-allowed-ciphers>`
I tried to change the source code in the file `src/tls.c` on row 91 from `TLS1_VERSION` to `TLS1_3_VERSION` but get a compile error
**Original code**
```
#if OPENSSL_VERSION_NUMBER < 0x10100000L
ctx->ctx = SSL_CTX_new(SSLv23_server_method());
ssl_opts = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3; // Disable SSLv2 and SSLv3
#else
ctx->ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_set_min_proto_version(ctx->ctx, TLS1_VERSION);
#endif
```
**Compile (make) error**
```
In file included from tls.c:18:
tls.c: In function ‘tls_ctx_new’:
tls.c:91:45: error: ‘TL1_3_VERSION’ undeclared (first use in this function); did you mean ‘TLS1_3_VERSION’?
91 | SSL_CTX_set_min_proto_version(ctx->ctx, TL1_3_VERSION);
^~~~~~~~~~~~
```
**Proposal**
1. Change the code this way, that TLS 1.0 and 1.1 (and older) are not offered anymore. Only offer TLS 1.2 and newer. Same way as in 2.4.4
and/or
2. Implement an option as used in advanced webservers like nginx, that the TLS version can be set in the config.
Example for nginx `ssl_protocols TLSv1.2 TLSv1.3;`. Even if the icecast developers move from openssl to another solution, such a option will be helpful and shows best practice.Icecast 2.5 rc1Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2422Programmatically set the fallback-override value2021-10-31T22:11:44Zisaac-codeProgrammatically set the fallback-override valueAs advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fall...As advised Mr Philip, I am creating this issue.
I have been able to programmatically create a mountpoint and also update the fallback mount on the new online radio I am building.
But after the stream stops the mount switches to the fallback, but immediately the mountpoint is back, I cannot programmatically switch back to the mountpoint
Switching back to the former mountpoint is only possible when the fallback-override value is set to 1, but I cannot achieve that because there is no way to programmatically achieve that, which is weird.
P.S. I want users to create mountpoints via an exposed endpoint, so I don't create it manually inside the icecase.xml filehttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2401Allow `icy-metadata` and `icy-metaint` in default CORS configuration2022-02-26T18:35:51ZEthan HalsallAllow `icy-metadata` and `icy-metaint` in default CORS configurationI noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the respons...I noticed that many of the public streams I've encountered have a wide-open Access-Control-Allow-Origin policy, but do not allow access to request the `Icy-Metadata` header nor allow access to read the `Icy-MetaInt` header in the response. This prevents any clients that honor CORS (i.e. browsers) from requesting or reading icy metadata.
This patch is to allow cross-origin access to the `Icy-MetaData` and `Icy-MetaInt` headers by default. Also, this patch inserts the `Access-Control-Allow-Headers` and `Access-Control-Expose-Headers` into the default XML configuration so that icy metadata works by default. Users can opt-out of it like they can with `Access-Control-Allow-Origin: *`.
The main use-case is to enable browsers to read icy metadata via a cross-origin request. I'm building a client side library that does that here: [icecast-metadata-js](https://github.com/eshaz/icecast-metadata-js). The inline metadata offers immediate metadata updates with no noticeable latency, which is really valuable in certain contexts, like for broadcasting police / fire scanner metadata, or ad insertions, etc.
[0001-feat-add-icy-metadata-support-for-cors.patch](/uploads/fb696baa19b3dfe8419021d66d52e2a3/0001-feat-add-icy-metadata-support-for-cors.patch)https://gitlab.xiph.org/xiph/icecast-server/-/issues/2379Consider adding fallback support for WolfSSL2024-01-21T02:16:56ZUnit 193Consider adding fallback support for WolfSSLHowdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is full...Howdy,
WolfSSL has an OpenSSL compatibility layer, so if a distribution can't offer Icecast linked with OpenSSL, using WolfSSL might be a possibility. I've made and tested a minimal patch, and with git master of WolfSSL Icecast is fully functional.
Would you consider adding support for it? It was mentioned that this might be more fitting for the 2.4 series.
Example patch attached (note this is not the version I was testing).
[icecast-wolfssl.patch](/uploads/5690621487ec0fc7ee689d161032b5ef/icecast-wolfssl.patch)
~Unit 193Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2378There should be a stats value indicating how if a stream is in a stable state2022-02-27T20:06:54ZPhilipp SchafftThere should be a stats value indicating how if a stream is in a stable stateThere should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flap...There should be a stats value that indicates if a stream has been proven stable. That is at least connected for a given minimum amount of time and sending data. This could be used by the fallback logic to avoid switching 'back' to a flapping stream.Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2365Discussion on the handling of portless Host:-headers2020-10-11T15:59:37ZPhilipp SchafftDiscussion on the handling of portless Host:-headersKarl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port eve...Karl updated Icecast in 64d2fc1faa46cf98b0576521c4975d3ae43ff252 to ignore Host:-headers that do not include a port. This was done due to the fact that winamp and foobar2000 do send invalid Host:-headers. They do not include the port even if non-default ports are used. When this header is used this results in invalid playlists to be generated. (Other (future) uses such as vhosting may also be affected).
foobar2000 seems to have fixed this. This was the result of a quick test with @laama. Thanks to him.
Winamp 5.53 1898 Beta from 2008 as well as Winamp 5.8 as downloaded today are still affected.
The following solution and workarounds come to mind:
* Nullsoft fixes their software. (Judge yourself if this is going to happen.) This is the only solution. It is the only correct way to do this.
* Keep ignoring Host:-headers that do not include a port. This may break legitimate clients.
* Try to match Host:-headers against listen sockets. This may break vhosting.
* Implement a way to list valid vhosts and set default vhosts per listen socket.
* Ignore Host:-headers without a port but implement a per listen socket default vhost setting.
Note that we can not accept/reject Host:-headers without port based on if we listen on a default port socket or not without type="virtual" listen sockets. This will otherwise break all kinds of redirects.
This ticket is mostly for discussion.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2361Remove RAWURI values from URL auth2018-11-27T09:57:57ZPhilipp SchafftRemove RAWURI values from URL authCurrently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the res...Currently the URL auth system transmits the RAWURI value if available as "mount"-parameter. This includes query strings. However it does not include POST parameters (therefore is inconsistent).
This should be deprecated and only the resource the user connected to should be included.
It must be discussed if it should transmit the original resource name (before `<resource>` processing) if they differ.
See also: #2360.https://gitlab.xiph.org/xiph/icecast-server/-/issues/2357Alias for <role type="anonymous" deny-all="*">2018-11-13T09:03:30ZPhilipp SchafftAlias for <role type="anonymous" deny-all="*">@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they...@ePirat suggested that it would be nice to have an alias for <role type="anonymous" deny-all="*"> that only accepts matching options as well as deny-options. His main reason was to help users not to in-correctly use allow-all="*" as they may not understand that it actually *is* the opposite of deny-all="*".
Maybe this should be more generalized and a kind of access profiles should be used like:
* deny-all
* listener
* source client
* admin
See also: #2353Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2353Rename auth backend "anonymous"2023-03-09T14:07:53ZPhilipp SchafftRename auth backend "anonymous"Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in use...Currently the backend that matches all users is called "`anonymous`". This is technically correct by the way how it works and what it initially was meant to be used for. However that name might be misleading as to not match logged in users.
I suggest that it should be renamed. The name "anonymous" would become an alias to ensure older configurations can still be read.
What new name should it have?Thomas B. RückerThomas B. Rückerhttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2352`<resource>` should allow `<authentication>`, and `<http-headers>`2018-11-05T08:07:15ZPhilipp Schafft`<resource>` should allow `<authentication>`, and `<http-headers>``<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)`<resource>`s should allow to set resource specific `<authentication>`, and `<http-headers>`.
This depends on: #2349 (for refobject and to-be-written lists)Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2351Multiple ACLs per Role2020-10-18T16:15:17ZPhilipp SchafftMultiple ACLs per RoleIcecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #...Icecast should support multiple ACLs per role.
This is useful with matching in ACLs. It allows to authenticate a user and after that decide what access that user has based on matching.
Depends on: #2349 (for to-be-written lists), and #2350 (for matching).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2350Common matching frame work2019-01-22T06:31:38ZPhilipp SchafftCommon matching frame workCurrently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users so...Currently the following parts of Icecast do client and client-status matching:
* `<resource>`
* `<role>` (auth)
* `<header>` (child of `<http-headers>`)
* `<event>` (child of `<event-bindings>`)
We also expect the following new users soon:
* `<acl>` (child of `<auth>`)
A common framework should be written to allow implementing matching.
This depends on #2349 (for refobject).Philipp SchafftPhilipp Schaffthttps://gitlab.xiph.org/xiph/icecast-server/-/issues/2349Icecast should use libigloo2022-03-16T01:46:29ZPhilipp SchafftIcecast should use libigloocommon/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/common/ is currently made into libigloo. Icecast should use libigloo. This ticket is about adding libigloo and using it as replacement to common/Philipp SchafftPhilipp Schafft