Galène videoconferencing server discussion list archives
 help / color / mirror / Atom feed
* [Galene] Versioning the Galene protocol
@ 2022-07-13 17:16 Juliusz Chroboczek
       [not found] ` <j_Wwm3jCn8dC_JljNxEa71isIylRHrqby88tFFV1kOsZFwpGXDISjia2xXfzbHTqerRny3HSZhIejXxcRkbA6fhizxxs8ALpEzrkEsPQJDA=@protonmail.com>
  0 siblings, 1 reply; 4+ messages in thread
From: Juliusz Chroboczek @ 2022-07-13 17:16 UTC (permalink / raw)
  To: galene

Hi,

Following Rémi's issues, and since there are a number of third-party
clients for Galène slowly starty to emerge [1,2,3], I think the time has
come to add some versioning and extensibility to the Galene protocol.

Now Galene uses three different protocols:

1. A very simple REST interface, that is used to populate the list of
   public groups and to discover group parameters before connecting.

2. A WebSocket based protocol, used for chat and audio/video codec
   negotiation.

3. The whole WebRTC protocol stack, which is used for transmitting audio
   and video.

The protocol that needs versioning is the WebSocket-based protocol, number
(2) above.  It is described here:

  https://galene.org/README.PROTOCOL.html#message-syntax

I've given it some thought, and here are my plans.  Please let me know if
you think I'm missing something.

1. I'm going to ignore the built-in protocol negotiation of the WebSocket
   transport, since I don't feel that version negotiation should be done
   at this layer.

2. The protocol starts with an exchange of 'handshake' messages.  I'm
   going to add a field 'version' to the handshake messages, and if the
   versions don't match, the connection fails.

   Since the client sends it handshake first, this means that the client
   will need to commit to a single version, while the server will be able
   to adapt its version depending on what was announced by the client.  An
   alternative would be to allow the client to announce a list of versions
   that it supports -- is that useful?

3. If it is useful, we may add an "extensions" field to the handshake
   message, in order to allow a peer to announce that it supports
   extensions to the protocol, for example new groupactions.

Other than the versioning, I have only one change to make to the protocol
right now: I'm planning to require that the client request explicitly that
it is interested in chat messages.  (Currently, the client needs to
actively request media streams, but it has no way to state that it is not
interested in chat messages.)

Comments welcome, none of this has been implemented yet, so it's easy to
change.

[1] https://github.com/garage44/pyrite
[2] https://github.com/erdnaxe/galene-stream
[3] https://github.com/igniterealtime/openfire-galene-plugin

-- Juliusz

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-07-15  8:40 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-07-13 17:16 [Galene] Versioning the Galene protocol Juliusz Chroboczek
     [not found] ` <j_Wwm3jCn8dC_JljNxEa71isIylRHrqby88tFFV1kOsZFwpGXDISjia2xXfzbHTqerRny3HSZhIejXxcRkbA6fhizxxs8ALpEzrkEsPQJDA=@protonmail.com>
2022-07-14  5:41   ` [Galene] Fw: " Jeroen van Veen
2022-07-14  9:58     ` [Galene] " Juliusz Chroboczek
2022-07-15  8:40       ` Jeroen van Veen

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox