Ultravox - Broadcaster, DistributionPoint, Listener are what I'm thinking they are?
 

I'm a bit confused, I went reading http://wiki.shoutcast.com/wiki/SHOUT...otocol_Details
and it speaks about three entities: the Broadcaster, the DistributionPoint, the Listener.
I'm consulting you to be sure that these three entities mentioned above are respectively:
the DSP, the Server, the Client.
And therefore:
the Shoutcast DSP, the Shoutcast server sc_serv2, the winamp player.

Also, reading more elsewhere, I got the doubt that Shoutcast and Ultravox are two separate things. How they are related? Can they be identified in the iso/osi scheme?

yes they are what you think they are.

the Ultravox protocol is just a different form of protocol that AOL developed and which a version off (2.1) was adopted (and developed) to make the SC2 protocol. it's obviously different from the SC1 protocol (which is effectively custom HTTP headers (as the ICY protocol) and raw audio data dumped in the stream (with some in-stream metadata packets).

between data inspection from the source (e.g. looking for a valid ultravox 2.1 frame or the lack of a HTTP header) and the user agent of the listener (looking for "Ultravox/2.1"), the 2.x DNAS will process things as applicable for the connection from the source and the listener, thus being able to accept SC1 and SC2 connections as well as providing a SC1 or SC2 formatted stream to the clients as needed.

thanks!

How to see shoutcast streaming code protocol?
 

"Is it" and "how" is it possible to see the code of the messages being sent from the DSP, the Server and the Client?
I'm saying
the Shoutcast DSP (and winamp that plays what I wanna send I guess),
the Shoutcast-sc_serv2,
the Client winamp player
when they are performing or whatsoever.

I guess maybe I'm using SHOUTcast2, I installed sc_serv2_win32_10_16_2013.exe, shoutcast-dsp-2-3-5-windows.exe and the latest version of winamp player.

I mean the code like I saw in the famous link https://forums.radiotoolbox.com/viewtopic.php?t=74

code:
icy-name:Unnamed Server\r\n

icy-genre:Unknown Genre\r\n

icy-pub:1\r\n

icy-br:56\r\n

icy-url:http://www.shoutcast.com\r\n

icy-irc:%23shoutcast\r\n

icy-icq:0\r\n

icy-aim:N%2FA\r\n

\r\n

code:
content-type: mime/type\r\n

icy-reset: 1\r\n

icy-prebuffer: ??\r\n

code:
ICY 200 OK\r\n (signifying that the server was successful)



icy-notice1:<BR>This stream requires <a href="http://www.winamp.com/">Winamp</a><BR> (redundant notice)



icy-notice2:SHOUTcast Distributed Network Audio Server/posix v1.x.x<BR> (tells the client what server it is and version)SHOUTcast Specific



icy-name:Unnamed Server\r\n (Name of the server)



icy-genre:Unknown Genre\r\n (what genre the server falls under)



icy-url:http://www.shoutcast.com\r\n (homepage for the server)



Content-Type:audio/mpeg\r\n (Content type of the stream to follow)



icy-pub:1\r\n (whether the server is public or not)



icy-br:56\r\n (bitrate of the server)



icy-metaint:8192\r\n (if icy-metadata:1 was signified this was shown I will discuss this further later)



\r\n (end of header)

so, you want something like wireshark or tcpflow to inspect the packets of data going back and forth

but it wont be so nice and clean, you're going to have to do a lot of work

Also, with ultravox, there's lot's of non "text" stuff to the data part of the packets, so, that'll be fun for you.

are you trying to write a v2 source client?

Why do you need to "crack" the stream, when the protocol is fully documented on the wiki? http://wiki.shoutcast.com/wiki/SHOUT...otocol_Details

Thanks for the good reply, I appreciate it.
I'm doing a little research project for a school course and the teacher would value my work better if I do some actual practice.
Luckylly I already saw the documentation you mentioned and it tourned out to be quite enought as information to work on I guess (I hope also for my teacher).
Now I'm finishing writing this research with the collected materials.