[Cerowrt-devel] webrtc on cerowrt

Daniel Pocock daniel at pocock.com.au
Thu Feb 6 16:05:16 EST 2014



On 25/01/14 21:17, Dave Taht wrote:
> On Sat, Jan 25, 2014 at 2:20 PM, Daniel Pocock <daniel at pocock.com.au> wrote:
>>
>>
>> On 25/01/14 16:28, Dave Taht wrote:
>>> On Sat, Jan 25, 2014 at 9:52 AM, Dave Taht <dave.taht at gmail.com> wrote:
>>>> This conversation here died, and I don't know if all the requisite packages
>>>> made it up to openwrt.
>>>>
>>>> http://comments.gmane.org/gmane.comp.embedded.cerowrt.devel/1268
>>>>
>>>> I was willing at the time (and still am) to have the relevant packages
>>>> in the ceropackages repo...
>>>
>>> I just pushed the 2012 package into ceropackages...
>>
>> I was really hoping to get everything through openwrt but I'm happy to
>> work directly with cerowrt on this as well
>>
>> The only progress with openwrt was the bdb c++ header package (one of
>> the build dependencies).  Everything else I contributed has been ignored
>> by the openwrt community, I find that quite disappointing and have
>> simply been contributing to other projects like Debian instead.
> 
> openwrt tries to do things that are small and fast. c++ and other
> large packages that need things like boost libs are not welcomed with great joy,
> and last year there was a re-org into "core" and packages repos
> so that they could focus more on improving the core.
> 
> There already is a tiny stun server for example.
> 
> Also telephony,
> routing, etc, got split out. So in your case you are trying to get into
> the current telephony repo and I don't know who maintains that.
> 
> Also webrtc has only been recently appearing on the radar.
> I think it's widely perceived that all the nat nonsense has to happen
> on some big honking server outside the lan run by some service
> provider, for it to work right. I disagree with that but need to prove it.

The argument for having it on the server is that some people have bad
routers and having the server on some independent network, ready to act
as a relay as the last resort

Having TURN on the router as well though it becomes a bit like UPnP,
effectively letting local clients access the router's public IP in a
predictable manner

The downside is latency: if the user is not at home and wants to make
some call from their mobile browser to some service, they may not want
it relayed via a home router

> Webrtc has been creeping high on my radar too, as one huge benefit
> of all the smart queue management we've been doing is much better
> videoconferencing. But I thought we'd won *big* with fq_codel, when
> the current designs for stun/turn servers are trying to multiplex
> *everything* on a single port, which reduces things to codel only
> (still a big win, but not as big).


Jitsi videobridge made a very compelling demo of this at FOSDEM on the
weekend

> In my last exchange with randel jesup on the rmcat mailing list I
> realized that I couldn't do the analysis I wanted without having
> control over the stun/turn server behavior too, and that's what
> made me pop up today wondering what had happened to the
> code for openwrt.
> 
> It's been a fascinating thread on congestion control, Randel
> popped up here...
> 
> http://www.ietf.org/mail-archive/web/rmcat/current/msg00729.html
> 
> And blew up a core tenet of my philosophy on port use here:
> 
> http://www.ietf.org/mail-archive/web/rmcat/current/msg00733.html
> 
>> cerowrt has accepted the asio package directly so cerowrt is one step
>> closer to having WebRTC
> 
> cerowrt-packages exists to get stuff tested that can't quite make
> openwrt mainline yet. If you have more packages and patches
> please send 'em along....
> 
>>>
>>>> http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/
>>>>
>>>> There is a new resiprocate release with websocket support:
>>>>
>>>> http://www.resiprocate.org/ReSIProcate_1.9_Release
>>>>
>>
>> There is one new dependency for v1.9.0 - the cajun-jsonapi package:
>>
>> https://github.com/cajun-jsonapi/cajun-jsonapi
>>
>> It is a fairly trivial header package needed during compilation of
>> reSIProcate
>>
>> One issue for me, to run cerowrt myself and test this stuff properly.
>> My own router is Buffalo WZR-HP-AG300H (128MB RAM, 32MB flash)
>>
>> I found my old TP-Link (32MB RAM) was not sufficient to run reSIProcate
>> with TLS support because of the amount of flash and RAM needed when
>> OpenSSL libraries are involved.
>>
>> Will my Buffalo device be suitable for cerowrt or do I need to look at
>> other devices?
> 
> Although this is the same chipset as cero, cero only runs on the wndr3800.
> 
> For your own builds of openwrt...
> 
> all you have to do is add to your feeds.conf file the ceropackages-3.3
> repository, and pull a few packages from there. Notably the sqm system
> is coming along nicely... :)
> 
> If you want to create a specific git repo for package feeds
> for your stuff, that would be fine, I can pull from that,
> otherwise I can take your patches into ceropackages.
> 
> don't give up! you were just a little ahead of your time. I know what
> that feels like....
> 
> 



More information about the Cerowrt-devel mailing list