WebRTC over IRC

[Patrick Cloke]

I've started thinking about how we can do any WebRTC signaling over IRC and it seems like we'll fairly easily have the characters, assuming that we split the SDP message and send each part individually. I calculate ~72 characters of overhead to send a CTCP private message. This was not extremely conservative, however, so I'd prefer assuming 112. That leaves 400 characters of actual message content [2]. From the sample SDP requests I've seen, this should be more than adequate [3].

I've linked to [1] an example netflow (and my math for the number of characters) and would appreciate feedback. Sorry for the handwriting. The top half shows the netflow on the right with descriptions between two users over CTCP. The left shows possible CTCP command names. The bottom has two sets of math.

I'd be curious if other people have thoughts on this. In particular:
1. Does the request / response make sense?
2. Would this actually work for a WebRTC negotiation?
3. What do we think of the command names? Should we bookend the SDP with both a begin and end command or just an end command?
4. Is my math totally off? In particular, how long are host names usually?
5. What should be a PRIVMSG vs. a NOTICE CTCP message?

Thanks,
Patrick

[1] http://1drv.ms/X1M3om
[2] http://tools.ietf.org/html/rfc2812#section-3
[3] http://en.wikipedia.org/wiki/Session_Description_Protocol
[4] http://www.alien.net.au/irc/ctcp.txt

[Florian Quèze]

On Wed, Aug 6, 2014 at 5:51 PM, Patrick Cloke <clo...@gmail.com> wrote:

> I've started thinking about how we can do any WebRTC signaling over IRC
> and it seems like we'll fairly easily have the characters, assuming that we
> split the SDP message and send each part individually.

What do you mean by "we'll fairly easily have the characters" and "send
each part individually".

An example SDP from WebRTC for audio+video (no datachannel) looks like
this: http://pastebin.instantbird.com/805010
If we had a datachannel it will have a few more lines.

Thanks for thinking through this! :)
Florian

--
Florian Quèze
Instantbird lead developer

[al...@instantbird.org]

Thanks for looking into this! I think something along these lines should
certainly work. None of the SDP lines I have seen so far are of a length
that could cause problems.

> 3. What do we think of the command names? Should we bookend the SDP with
> both a begin and end command or just an end command?

> 5. What should be a PRIVMSG vs. a NOTICE CTCP message?

Naively, I think we should use CTCP WEBRTC for all the signalling, along
the lines of what AVATAR does. The command names look fine. I don't
think it needs an explicit BEGIN if you initiate a SDP with something
like WEBRTC ACCEPT which is effectively a BEGIN.

Are CTCP CLIENTINFO WEBRTC parameters enough to provide capability
information (canvideo/canaudio), or would we also need a CTCP WEBRTC
CAPABILITIES mechanism that on request provides/obtains enough info to
set the availabilitydetails for IRC accountbuddies? Initially we can
probably do without this (in fact it's not possible to make work
properly until certain webrtc bugs are fixed).

--
http://www.fastmail.fm - mmm... Fastmail...

[Patrick Cloke]

Florian,

This is discussing the number of characters that can be in each IRC message, 512 total - some generic stuff that would have to be sent for these messages. So each SDP line would be sent separately and would individually need to be less than a certain length.

Thanks for the example SDP!

Hope that clears it up,
Patrick

[Patrick Cloke]

aleth,

I agree that a BEGIN seems excessive, but wanted to capture my thoughts.

What would be gained by a WebRTC Capabilities request? Are you thinking so that we can enable/disable buttons in conversations?

I initially wrote that we definitely wouldn't want this and to let the SDP negotiation handle it, but we should discuss this more.

Thanks!
Patrick

-----Original Message-----
From: "al...@instantbird.org" <al...@instantbird.org>
Sent: ‎8/‎6/‎2014 10:57 AM
To: "Patrick Cloke" <clo...@gmail.com>; "dev-...@lists.mozilla.org" <dev-...@lists.mozilla.org>
Subject: Re: WebRTC over IRC

[al...@instantbird.org]

Actually I wonder if pairs like BEGIN ACCEPT ... END ACCEPT
might not be safer and easier to implement.

> What would be gained by a WebRTC Capabilities request? Are
you thinking so that we can enable/disable buttons in

> conversations?

Yes, exactly. But I think it should be enough to just enable
the button if CLIENTINFO WEBRTC is received.

I initially wrote that we definitely wouldn't want this and to
let the SDP negotiation handle it, but we should discuss this
more.

Thanks!
Patrick

__________________________________________________________

From: [1]al...@instantbird.org
Sent: 8/6/2014 10:57 AM

To: [2]Patrick Cloke; [3]dev-...@lists.mozilla.org

References

1. mailto:al...@instantbird.org
2. mailto:clo...@gmail.com
3. mailto:dev-...@lists.mozilla.org

--
http://www.fastmail.fm - Access your email from home and the web

[clo...@gmail.com]

On Friday, August 8, 2014 9:38:08 AM UTC-4, al...@instantbird.org wrote:
> Actually I wonder if pairs like BEGIN ACCEPT ... END ACCEPT
> might not be safer and easier to implement.

I think I like this better, it's clearer.

> > What would be gained by a WebRTC Capabilities request? Are
> > you thinking so that we can enable/disable buttons in
> > conversations?
>
> Yes, exactly. But I think it should be enough to just enable
> the button if CLIENTINFO WEBRTC is received.

That seems reasonable for now. We can add some querying later, if need be. (WEBRTC CAPABILITIES probably sounds reasonable.)

Florian also asked me about throttling since this could be a good amount of lines of network traffic all at once. I had thought that ISUPPORT had a flag about message flooding we should implement...but I can't seem to find it. So, yes. This is a concern, I think we just should throttle our message rate (we should probably be doing this anyway). Bug 954167 [1] was about implementing that. Does anyone have other suggestions of how to handle this?

Florian also brought up this concept of "trickle ICE": when instead of giving us one SDP with all the network candidates, createOffer (or createAnswer) returns immediately what it already knows and gives us later additional candidates once it has them. We should at least ensure the protocol can handle this.

--Patrick

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=954167