I need to write an Icecast 2 client that will be able to stream audio from the computer (mp3-files, soundcard recording and so forth) to the server. I decided to write such a client on C#.
Two questions:
1) It will be very useful to know common guidelines (best practices, maybe tricks) I may/should/must use to seamlessly work with streamed audio (streamed over network, of course) in C#. Some general technical documentation about streaming over TCP/IP in common and ICY in particular, advices and notes on the overall architecture of the application will be very appreciated.
2) Is there any good documentation regarding the Icecast 2 streaming protocol? I couldn't find those docs on the official site of Icecast. I don't want to extract the protocol description directly from the source code of it. If the protocol is really simple and neat, could anybody provide a summary of it right here?
As far as I know, there is no protocol spec anywhere, outside of the Icecast source code. Here's what I've found from packet sniffing:
Audio Stream
The protocol is similar to HTTP. The source client will connect to the server make a request with the mountpoint, and pass some headers with information about the stream:
SOURCE /mp3test ICE/1.0
content-type: audio/mpeg
Authorization: Basic c291cmNlOmhhY2ttZQ==
ice-name: This is my server name
ice-url: http://www.google.com
ice-genre: Rock
ice-bitrate: 128
ice-private: 0
ice-public: 1
ice-description: This is my server description
ice-audio-info: ice-samplerate=44100;ice-bitrate=128;ice-channels=2
If all is good, the server responds with:
HTTP/1.0 200 OK
The source client then proceeds to send the binary stream data. Note that it seems some encoders don't even wait for the server to respond with 200 OK before they start sending stream data. Just headers, an empty line, and then stream data.
Meta Data
Meta data is sent using an out-of-band HTTP request. The source client sends:
GET /admin/metadata?pass=hackme&mode=updinfo&mount=/mp3test&song=Even%20more%20meta%21%21 HTTP/1.0
Authorization: Basic c291cmNlOmhhY2ttZQ==
User-Agent: (Mozilla Compatible)
The server responds with:
HTTP/1.0 200 OK
Content-Type: text/xml
Content-Length: 113
<?xml version="1.0"?>
<iceresponse><message>Metadata update successful</message><return>1</return></iceresponse>
Also note that both the audio stream and meta data requests are sent on the same port. Unlike SHOUTcast, this is the base port that the server is running on.
I'm going to comment here despite this question being quite old.
Icecast is HTTP compliant. This was always the case for the listener side (plain and simple HTTP1.0, RFC 1945), starting with 2.4.0 it's also true for the source client side.
To implement a source client it's a PUT request in compliance with HTTP 1.1 aka RFC2616. Some options can be set through HTTP headers, for details please refer to the current Icecast documentation.
If you send one of the supported container formats: Ogg or WebM (technically EBML), then this is all you need to know. To make it clear this covers at leastOpus, Vorbis, Theora and VP8 codecs.
Please note that while generally working fine, other formats are technically not supported. Icecast only passes through the stream without any processing in such a case.
If you need help or have further questions, then the official mailing lists and the IRC channel are the right place to go.
Looked at Icecast2 a good long while ago: best reference I could find was at http://forums.radiotoolbox.com/viewtopic.php?t=74 link (I should print that out, took me forever to figure out the proper Google spell to cast to surface that again). It appears to cover source to server and server to client.
Questions remain about just how accurate it is: I got about halfway through an Android implementation before other things consumed me, and I can't quite remember what was wrong with the communication between my implementation of that and VLC/Winamp, but honestly it was the closest thing I could find to a spec.
The best description I know is here: https://gist.github.com/ePirat/adc3b8ba00d85b7e3870
#ePirat is xpiph/icecast core committer.
Related
I need to consume a third-party WebSocket API in .NET Core and C#; the WebSocket server is implemented using socket.io (using protocol version 0.9), and I am having a hard time understanding how socket.io works... besides that the API requires SSL.
I found out that the HTTP handshake must be initiated via a certain path, which is...
socket.io/1/?t=...
...whereby the value of the parameter t is a Unix-timestamp (in seconds). The service replies with a session-key, timeout information, and a list of supported transport protocols. Due to simplicity, this first request is made via HttpClient and does not involve any additional headers.
Next, another HTTP request is required, which should result in an HTTP 101 Switching Protocol response. I specified the following headers in accordance to the previous request...
Connection: Upgrade
Upgrade: websocket
Sec-WebSocket-Key: ...
Sec-WebSocket-Version: 13
...whereby the value of the Key-header is a Base64-encoded GUID-value that the server will use to calculate the Sec-WebSocket-Accept header value. I also precalculate the expected Sec-WebSocket-Accept header value, for validation...
I tried to make that request using HttpClient as well, but that does not seem to work... I actually don´t understand why, because I expect an HTTP response. I also tried to make the request using TcpClient by sending a manually prepared GET request over a SslStream, which accepts the remote certificate as expected. Sending data seems to work, but there´s no response data... the Read-method returns zero.
What do I miss here? Do I need to setup a listener for the WebSocket connection as well, and if yes how? I don´t want to implement a feature complete socket.io client, I´d just like to keep it as simple as possible to catch some events...
The best way of debugging these issues is to use a sniffer like wireshark or fiddler. Often connect using an IE and compare IE results with my application and modify my app so it works like the IE. Using WebClient instead of HttpClient will also work better because the WebClient does more automatically than the HttpClient.
A web connection uses the header of the client and the headers in the server webpage to negotiate a connection mode. Adding additional headers to you client will change the connection mode. Cookies are also used to select the connection mode. Cookies are the results of previous connection to the same server which shortens the negotiations and stores info from previous connection so less data has to be downloaded from server. The server remembers the cookies. Cookies have a timeout and is kept until timeout expires. The IE history in your client has a list of IP addresses and Net automatically sends the cookies associated with the server IP.
If a bad connection is made to the server the cookies is also bad so the only was of connection is to remove the cookie. Usually I go into the IE and delete cookies manually in the IE history.
To check if a response is good the server returns a status. A completed response contains a status 200 DONE. You can get status which are errors. You can also get a 100 Continue which means you need to send another request to get the rest of the webpage.
Http has 1.0 (stream mode) and 1.1 (chunk mode). Net library doesn't work with chunk. Chunk requires client to send message to get next chunk and I have not found a way in Net to send the next chunk message. So if a server responds with a 1.1 then you have to add to your client headers to use 1.0 only.
Http uses TCP as the transport layer. So in a sniffer you will see TCP and HTTP. Usually you can filter sniffer just to return Http and look at header for debugging. Occasionally TCP disconnects and then you have to look at TCP to find why the disconnect occurs.
Currently I am working on a custom HTTP publisher for the Peach Fuzzing framework.
In order to determine if the server responed in an unusual way I need to examine the decrypted incoming / outgoing packages with Wireshark (or the PcapMonitor that is included in the Peach Framework) - to do that I need the SSL keys that are being generated by the C# HttpWebRequest (similar to the content of the SSLKEYLOGFILE) since I am trying to fuzz an SSL protected RESTful webservice.
If it is not possible to get the keys or if it is very difficult - is there any other way to see the raw HTTP request / response?
Thanks!
Just found a way to get the decrypted packages:
Create a loopback interface that can be monitored with Wireshark
Create a reverse proxy (I used nginx) and redirect all traffic from "localhost" to the target URL (https://)
Tell your application not to send the requests to target (https://) but to localhost (http://localhost/)
Start listening on the loopback interface and start your application
Hope this is helpful for somebody in a similar situation
I'm making a server that should be able to store some images and then send/stream them to a client upon request. I've managed to get the server to respond with an image when I request it from a web browser, but when I send the very same HTTP request to the server from my client application, I'm not sure what exactly happens (it's supposed to become a tile map server at some point, but I'm starting out easy with just a single image here).
If it's of any help, here's an output from my web browser request: http://i.imgur.com/tG04qvS.png
And here the other one is: http://i.imgur.com/GUqdawF.png
Fiddler is saying I'm returning Content-Type: text/html; charset=UTF-8 which in my head sounds horribly wrong when trying to return an image.
I've been digging around a little more and it seems the response is empty. It smells like my server isn't delivering the image properly to the client since I'm just using this piece of code to respond to the request:
if (p.http_url.Equals("/MapServer/tile/0/0/0"))
{
Stream fs = File.Open("../MapServer/tile/0,0,0.png", FileMode.Open);
p.writeSuccess("image/jpeg");
fs.CopyTo(p.outputStream.BaseStream);
p.outputStream.BaseStream.Flush();
fs.Close();
}
I'm using StreamWriter for my stream. Is that the one giving me the content_type problems?
HTTP servers map content type through other mechanisms. A Stream is too low-level to convey that kind of information; it doesn't distinguish between series of bytes for a text file or an image.
The Content-type Saga
Content Negotiation
Configuring MIME Types in IIS 7
Try building your service to return something from the System.Net.Http namespace like HttpResponseMessage. These classes have the ability to provide more information about the type of document being sent.
I would like to extract the HTTP header information using Packet.Net. I am using SharpPcap to capture the packet and need to access the User-Agent field in the TCP packet. If I understand correctly Packet.Net is used to analyze the packet captured. Help would be appreciated on this regard. I have tried to display the TCP packet with the following code but I get bytes displayed. I am using C# as development language.
private static void device_OnPacketArrival(object sender,CaptureEventArgs packet){
Packet p =Packet.ParsePacket(packet.Device.LinkType,packet.Packet.Data);
System.Text.ASCIIEncoding ASCII = new System.Text.ASCIIEncoding();
String StringMessage = ASCII.GetString(p.Bytes);
Console.WriteLine(StringMessage);
}
Packet.Net doesn't currently have http decoding support. Because http messages can be split across multiple packets, it seems like a good approach would be to first add support to allow the following of tcp connections, then add http session detection and parsing on top of the tcp data stream. Trying to parse http data on a per-packet basis might work for the headers of the data or some http messages but isn't a robust solution as it would prevent being able to get the full content of the http message that might be several kilobytes in size.
(I have a commercial library that builds upon SharpPcap/Packet.Net that adds tcp session following and http session following and decode. Post your email here if you want me to email you with more details.)
Has anyone used any in the UK, and if so, were they any good?
Clickatell is a popular SMS gateway. It works in 200+ countries.
Their API offers a choice of connection options via: HTTP/S, SMPP, SMTP, FTP, XML, SOAP, COM Object.
The HTTP/S method is as simple as this: http://api.clickatell.com/http/sendmsg?to=NUMBER&msg=Message+Body+Here (Clickatell API Guide).
The SMTP method consists of sending a plain-text e-mail to: sms#messaging.clickatell.com, with the following body:
user: xxxxx
password: xxxxx
api_id: xxxxx
to: 448311234567
text: Meet me at home
As for incoming SMSes, you would have to expose an interface through: HTTP, SMPP, SOAP or FTP. For example if you use the HTTP GET and you provide this URL to Clickatell: http://www.yourdomain.com/sms/sms.asp, then Clickatell will send you this HTTP GET with every incoming SMS:
https://www.yourdomain.com/sms/sms.asp?
api_id=12345&
from=279991235642&
to=27123456789&
timestamp=2008-08-0609:43:50&
text=Hereisthe%20messagetext&
charset=ISO-8859-1&
moMsgId=b2aee337abd962489b123fda9c3480fa
You can also test the gateway (incoming and outgoing) for free from your browser: "Test SMS Gateway".
TM4B offer an easy-to-use web-based API, but there are some limitations to what kind of content it can be used for (nothing to do with music, gambling, drinking), BulkSMS is also quite highly regarded and, once again, offer a very simple web-based API.
I've used both before (we have an SMS provider abstraction library create in-house) and both are as reliable as the underlying transport (SMS is not a guaranteed communication method, so messages can go astray).
We use AQL. They arent the cheapest but never had a single issue. We only use for outgoing however so I cant speak for inbound. Simple to use in .NET. Great web interface too.