[Icecast] Source client with HTTP PUT

[Philipp Schafft]

Good afternoon,

On Fri, 2019-05-03 at 12:24 -0400, Fred Gleason wrote:
> On Fri, 2019-05-03 at 13:19 +0000, Jürgen Bund wrote:
> > I’m writting a source client in c#, in which I’m sending chunks of a
> > mp3 file with http Put to IceCast.
> > My problem is, that it is not a continues stream. Each http PUT
> > request is an extra track.
> > How can I generate an ongoing stream with mp3 chunks, which I send
> > per http Put to IceCast.
> 
> Don't use PUT at all. Instead, open a TCP socket connection to the port
> that the server is running on, write all of your headers to that
> (terminating each one with a CR/LF), send a naked CR/LF to tell Icecast
> that your done sending headers and then start writing content.

***Please don't.*** This is the worst way if implementing source
clients. And there are already too many broken ones.


> You may want to check out the libshout library, which can handle most
> of the low-level nitty-gritty stuff for you 'auto-magically'.
> 
> 	https://github.com/xiph/Icecast-libshout

Wrong link, but correct idea.

This would be the correct link:

https://gitlab.xiph.org/xiph/icecast-libshout


Using libshout is the recommended way to implement a source client. It
does not only implement basic HTTP for you but also the application
level logic needed for sending stream. It also allows your software to
benefit from future development automagically.


If you want to go the PUT path (which is fine):

You basically send one PUT request for all of the stream. The individual
segments (tracks) must be muxed according to the specification of the
format you use. Most formats use simple chaining (basically when one
segment ends just send the next one). But you need to check that with
the specification of your format.

When doing the PUT request you must take care of those points:
      * Send the correct content-type. You can find a list to start with
        at: https://wiki.xiph.org/MIMETypesCodecs
      * Authorization must follow the HTTP standards including
        challenge-response. This requires a minimum of two requests (the
        one resulting in the challenge and the response. :)
      * Keep-Alive is preferred but may not be supported or not
        supported with the given operation on older servers. It is also
        a hop-to-hop property not an end-to-end property of HTTP and
        therefore might also be terminated by intermediate hops.
      * PUT should use 100-continue. Different Icecast versions have
        different levels of conformance with the standard. So
        workarounds may be needed. Also 100-continue is hop-to-hop so
        the same apply as above.
      * Chunked transfer is not supported by all Icecast versions.
        However Identity transfer-encoding is used by all of them.
        Autodetection may be needed here. Also, again, transfer-encoding
        is hop-to-hop.
      * Older versions of Icecast (which should not be used anyway, as
        those version have critical security vulnerabilities) do not
        support PUT.

libshout takes care of all that by itself for you as well as more things
like timing. Full HTTP implementations will take care of parts of it,
such as the authorization part and keep-alive.



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/20190504/97bb9946/attachment.sig>