search

because-why-not / awrtc_signaling

BSD 3-Clause "New" or "Revised" License
25 stars 25 forks source link

Protocol documentation? #6

Open piranna opened 3 years ago

piranna commented 3 years ago

I'm connecting to your signaling server from a Node.js application, so I'm not able to use your browser library and instead I did my own client of the signaling server (my plan is to release it as open source).

So far I've been able to connect to the signalint server listening to an address (with StartServer(), a little bit hacky but Connect() doesn't listen on addresses, and in fact seems to prevent it, although tecnically seems it should be possible) and listen for NewConnection events, but when I send back an offer SDP with sendReliableMessage() (after serializing it with JSON as UTF-16, as I've found the protocol does by reverse engineering it), I get no answer from the other clients, nor success or failure.

I'm not sure if I'm missing something, because other C# clients connected to the same signaling server can be able to exchange both SDPs and ICE Candidates (I added traces to the signaling server to inspect them), so my main suspect is an initial JSON message that's send after connection is stablished with some pseudo-random number. I've already checked it and it's not the protocol version message (I'm not sending it, but seems the server is not using it at all, does I need to send it?) nor looks like a timestamp because it's too low and give me some date around March 1970, some months after epoch. Since I can't not be able to access to the C# client source code since it's only provided as a binary DLL file, can you explain me what this number is, how is it generated, how is it used, and if is it needed at all?

devluz commented 3 years ago

It is mostly documented in place in the INetwork.ts and related files. There is no formal documentation because this was always considered something internal / implementation specific.

I suspect you mean the following? https://github.com/because-why-not/awrtc_browser/blob/master/src/awrtc/network/WebRtcPeer.ts#L116 and https://github.com/because-why-not/awrtc_browser/blob/master/src/awrtc/network/WebRtcPeer.ts#L268

This is from a hack used for the conference app examples. In normal mode for 1 to 1 connections the number will be sent but ignored. The user that creates the outgoing connection (calls Connect or Call method) will start signaling & send out an offer. The one that used StartServer / Listen will respond to it.

In Conference mode there is no clear "outgoing" connection because every user will call StartServer / Listen on the address without ever calling Connect / Call. In this case both sides send this random number. The higher number will then start the signaling process & send out an offer.

Note that this isn't json but just a clear text positive 32 bit integer.

piranna commented 3 years ago

It is mostly documented in place in the INetwork.ts and related files. There is no formal documentation because this was always considered something internal / implementation specific.

I suspect you mean the following? https://github.com/because-why-not/awrtc_browser/blob/master/src/awrtc/network/WebRtcPeer.ts#L116 and https://github.com/because-why-not/awrtc_browser/blob/master/src/awrtc/network/WebRtcPeer.ts#L268

Yes, that ones, just only I was doing my implementation based on the server code and it didn't make any sense, now I understand it, thanks.

In Conference mode there is no clear "outgoing" connection because every user will call StartServer / Listen on the address without ever calling Connect / Call. In this case both sides send this random number. The higher number will then start the signaling process & send out an offer.

Ok, now it makes more sense, it's to decide who will initiate the negotiation, got it, thanks.

Is there any way for a client to listen for an address for new connections, without emitting, only receiving? I suspect is possible, but according to signaling code, seems it's only registered in the connectionsPool to listen for connections when using StartServer(), and Connect() is in fact preventing actively it by returning an error...

Note that this isn't json but just a clear text positive 32 bit integer.

Well, strings are already a valid JSON value, so it's possible to parse it with JSON.parse() too :-)

devluz commented 3 years ago

Not sure what you mean by emitting. Do you mean sending / receiving media? This is usually done via the MediaConfig on the client side only. The signaling connections itself are always 1 to 1 peer connections that are just relayed via the server. For them there is no clear sender / receiver.