CCSMB-5: PCM Audio Transmissions over modem

[EmmaKnijn]

Here is CCSMB-5, suggestions are welcome!

[tomodachi94]

First draft looks good, just a few minor things.

[MasonGulu]

There should be a field that uniquely identifies a packet as following this spec. With the addition of that, the field names could be simplified into station, and title.

[EmmaKnijn]

There should be a field that uniquely identifies a packet as following this spec. What should be the field name? Something like spec?

[MasonGulu]

protocol

[EmmaKnijn]

Like that?

[tomodachi94]

Should we make clients reject packets from servers with an invalid protocol field in order to be compliant?

[EmmaKnijn]

Should we make clients reject packets from servers with an invalid protocol field in order to be compliant?

It would create more stability, I'm expecting to expand this someday in another standard so that should be good

[EmmaKnijn]

I think we're ready right?

[Erb3]

I think we're ready right?

Slow down, speedy. RFCs take time...

[MasonGulu]

Wait for more feedback.

[walksanatora]

it does not appear to have a standard port assignment are we expected to listen on all modem channels for radio messages or a specifc standard port

[EmmaKnijn]

I mean on SC3 I use the range 2048-3072 for radio, but idk if thats a standard thats supposed to be there yk

[EmmaKnijn]

That should do, ports 2048-4096 should allow for plenty radio stations

[totallynotmarcus]

My biggest concern with this is that there is no validation whatsoever. Anyone could easily pretend to be the radio station and send whatever they want. ECC and private/public key cryptography could be used to solve this, however that brings up the problem: how do we get the public key to the client? HTTP could work, but then it's not quite as seamless.

[bananasov]

My biggest concern with this is that there is no validation whatsoever. Anyone could easily pretend to be the radio station and send whatever they want. ECC and private/public key cryptography could be used to solve this, however that brings up the problem: how do we get the public key to the client? HTTP could work, but then it's not quite as seamless.

Possibly by sending the public key to the client in the packet with the buffer stuff? This seems the most reasonable in my opinion.

[totallynotmarcus]

Possibly by sending the public key to the client in the packet with the buffer stuff? This seems the most reasonable in my opinion.

This is still easily spoofable, anyone could send their own message with their own public key. You'd have to distribute it via HTTP, disk, or some other medium. It can't be sent over modem.

This comment was modified by @tomodachi94 to fix the block-quote formatting.

[bananasov]

Possibly by sending the public key to the client in the packet with the buffer stuff? This seems the most reasonable in my opinion. This is still easily spoofable, anyone could send their own message with their own public key. You'd have to distribute it via HTTP, disk, or some other medium. It can't be sent over modem.

Nice reply fail first of, but yeah I did not think of that.

[walksanatora]

by standard port i mean a default port that all servers would use ex: ssh is default to port 20 http is 80 telnet is 19 gopher is port 70 etc... i thought that mutiple radios could use the same port, and just use a diffrent id for each station therefore there is only one port needed for radio (current standard is like if SSH had every server within portrange 2000-4000)

[walksanatora]

and personally the thing i dont like is it does not contains what happens if a server were to transmit early and what if a client joins mid-song, is the client expected to wait or ... i propose a packet ID system packets count UP, thatway clients can keep watch for the "next packet" and if it recieves packet 0 then we know that the next song has startd and we can reset the counter to 0 and also a server-bound packet to request re-send latest audio packet (in the case a client connects mid-song)

[MCJack123]

it does not appear to have a standard port assignment are we expected to listen on all modem channels for radio messages or a specifc standard port

Having unique channel numbers is a good thing in this case, as channels are broadcast to all listening computers, so having them all on one channel will cause a lot of noise and potentially lag/CPU use. The channel number should be given to the users, or scanned for in some cases. If we add discovery, then we will definitely need one channel for that.

[MCJack123]

Some code examples would be nice too, especially basic clients.

I'll also note that this currently violates CCSMB-1 by not including examples. It also needs some language improvement to have a professional tone.

[EmmaKnijn]

If we add discovery, then we will definitely need one channel for that.

Discovery is definitely a good idea imo

[EmmaKnijn]

Some code examples would be nice too, especially basic clients.

I'll work on that once it's pretty much set in stone

It also needs some language improvement to have a professional tone.

I agree

[EmmaKnijn]

My biggest concern with this is that there is no validation whatsoever. Anyone could easily pretend to be the radio station and send whatever they want.

I honestly don't know if this is fixable over CC, if you compare it to real life, anyone with a Pi can transmit over FM

[EmmaKnijn]

and personally the thing i dont like is it does not contains what happens if a server were to transmit early and what if a client joins mid-song, is the client expected to wait or ... i propose a packet ID system packets count UP, thatway clients can keep watch for the "next packet" and if it recieves packet 0 then we know that the next song has startd and we can reset the counter to 0 and also a server-bound packet to request re-send latest audio packet (in the case a client connects mid-song)

Packets are up to 2.7s long, It would take like 6 seconds at max to get a solid connection

[tomodachi94]

@EmmaKnijn @MCJack123 what if stations broadcasted some information like station name, channel number etc over a specified channel every, say, 15 seconds, and had a specific range of channel IDs that are specified for radio but aren't hard coded?

[MCJack123]

what if stations broadcasted some information like station name, channel number etc over a specified channel every, say, 15 seconds, and had a specific range of channel IDs that are specified for radio but aren't hard coded?

I'd rather make it be a request-response system - the client sends a request for servers on a standardized channel, and all servers respond with their names/channel number. Broadcasting to nobody is just wasted CPU time.

[Erb3]

You have a lot of feedback to work with here, and a fair bit of work to do. I would also request that do not make tons of GitHub comments for responding, when you can quote multiple messages in one message.

cc @EmmaKnijn

---

I am all for the idea for server discovery. A client sends a message on a specific channel, and all stations reply on that channel with names / channel.

---

I am not sure how I feel about encryption or signing of the radio. Afaik it would take valuable time to verify this before playing the audio?

[EmmaKnijn]

Added a bunch of things, feel free to have another look

[Erb3]

Still a lot of unresolved conversations here. Not ready for merge.

[EmmaKnijn]

Alright, I iterated again. Feel free to have another look.