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.
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 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.
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
A->S: @intent=WEBRTC PRIVMSG Bob CALL-OFFER
B->S: @intent=WEBRTC NOTICE Bob CALL-DECLINE
A->S: @intent=WEBRTC PRIVMSG Bob CALL-OFFER
B->S: @intent=ERROR NOTICE Alice WEBRTC
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
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
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
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
Netflow diagram of some of the interactions above: