Skip to content

Instantly share code, notes, and snippets.

@clokep
Last active April 24, 2023 21:10
Show Gist options
  • Save clokep/f7a07fa9e0bdcfe8cf6a to your computer and use it in GitHub Desktop.
Save clokep/f7a07fa9e0bdcfe8cf6a to your computer and use it in GitHub Desktop.

WebRTC negotiation over IRC

Copyright (c) 2015 Patrick Cloke clokep@instantbird.org

Unlimited redistribution and modification of this document is allowed provided that the above copyright notice and this permission notice remains intact.

WebRTC

Web real-time communications is a standardized set of APIs used in web browsers to support voice calling, video calling, file sharing and other data streams. This document specifies how IRC is to be used as the signaling channel to negotiate a connection between two client endpoints.

The negotiation

The negotiation revolves around the Session Description Protocol (SDP): RFC 4566 and how to transfer that between clients. WebRTC does not define a signaling channel to send this data across, thus we can send this data over IRC.

Two users will be used to show an example negotiation: Alice (A) and Bob (B) through a Server (S). The server is not shown as it is assumed messages would pass through the server unchanged. Note that ensuring there is no man-in-the-middle (MITM) attack from the server due to this negotiation is outside the scope of this document.

Successful negotiation

The overview of the negotiation is:

  • Alice offers a call to Bob
  • Bob can reject (or error if his client doesn't understand WebRTC) or accept
  • Alice notifies she will send her SDP
  • Alice sends her SDP
  • Alice notifies that her SDP is over
  • Bob notifies he will send his SDP
  • Bob sends his SDP
  • Bob notifies that his SDP is over
  • Alice sends ICE candidates
  • Bob sends ICE candidates
  • Alice and Bob establish a P2P peer connection
A->S: @intent=WEBRTC PRIVMSG Bob CALL-OFFER
B->S: @intent=WEBRTC PRIVMSG Alice CALL-ACCEPT
A->S: @intent=WEBRTC PRIVMSG Bob SDP-START
A->S: Send the Offer SDP (TBD how)
A->S: @intent=WEBRTC PRIVMSG Bob SDP-END
A->S: @intent=WEBRTC PRIVMSG Alice SDP-START
B->S: Send the Asnwer SDP (TBD how)
A->S: @intent=WEBRTC PRIVMSG Alice SDP-END
A->B: ICE candidate
B->A: ICE candidate
A->B: <peer connection established over P2P using WebRTC protocols>x

Declined negotiation

A->S: @intent=WEBRTC PRIVMSG Bob CALL-OFFER
B->S: @intent=WEBRTC NOTICE Bob CALL-DECLINE

Errored negotiation

A->S: @intent=WEBRTC PRIVMSG Bob CALL-OFFER
B->S: @intent=ERROR NOTICE Alice WEBRTC

WebRTC capability query

It is also possible to query a client for what aspects of WebRTC are supported before performing a call. This should allow for user interface customizations if, e.g. only voice is supported.

The supported capabilities list is currently defined as:

  • VOICE
  • VIDEO
  • FILE

Successful query

The following is an example query where Bob supports voice and video over WebRTC.

A->S: @intent=WEBRTC PRIVMSG Bob CAPABILITIES
B->S: @intent=WEBRTC NOTICE Alice CAPABILITIES VOICE VIDEO

Bob might also understand the WebRTC command, but not support any of it:

A->S: @intent=WEBRTC PRIVMSG Bob CAPABILITIES
B->S: @intent=WEBRTC NOTICE Alice CAPABILITIES

Unsuccessful query

Clients that do not support WebRTC should return an error command.

# Does Bob support WebRTC?
A->S: @intent=WEBRTC PRIVMSG Bob CAPABILITIES
B->S: @intent=ERROR NOTICE Alice WEBRTC

A note about CTCP support

It is expected that these commands are sent with either messages intents or as a CTCP query using the similarly translated commands.

The intent specification is vague about what happens if an intent is not supported, this specification follows prior CTCP specifications of responding with an ERROR message with a single parameter of the intent that is not supported.

An example of the above two paragraphs:

A->S: @intent=FOO PRIVMSG Bob
S->B: :Alice PRIVMSG :\0x01FOO\0x01
B->S: NOTICE Alice :\0x01ERROR FOO\0x01
S->A: @intent=ERROR :Bob NOTICE Alice FOO

Additionally, as with CTCP, PRIVMSG is used for commands that an automated response is expected, while NOTICE is used in situation where clients are not expected to respond automatically.

For example:

A->S: PRIVMSG Bob :\0x01WEBRTC CAPABILITIES\0x01
B->S: NOTICE Alice :\0x01WEBRTC CAPABILITIES VOICE VIDEO\0x01
@clokep
Copy link
Author

clokep commented Jun 15, 2017

Netflow diagram of some of the interactions above:

y4mhloi4owdg5ughqjprgd23ultmr2kmhuu-8qaxdkqa5rafrjtmz-6whi6zb5uuccs-u8z8u85pvcixfssaforeo470yvtvusm7fn5yll849pmzbi7y5hycpzqdoic4mrpmom4qckfdz8gjag260mqbfenoaxl8zvy08shi0ch0zl5rete6kp6lnkfifbabj4cckxiyzdqltd01o2qomo3uw

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment