[Cerowrt-devel] webrtc on cerowrt

[Cerowrt-devel] webrtc on cerowrt

[Dave Taht]

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...

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


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] webrtc on cerowrt

[Dave Taht]

On Sat, Jan 25, 2014 at 9:52 AM, Dave Taht <dave.taht@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...

> 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
>
>
> --
> Dave Täht
>
> Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] webrtc on cerowrt

[Daniel Pocock]

On 25/01/14 16:28, Dave Taht wrote:
> On Sat, Jan 25, 2014 at 9:52 AM, Dave Taht <dave.taht@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.

cerowrt has accepted the asio package directly so cerowrt is one step
closer to having WebRTC

> 
>> 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?

Re: [Cerowrt-devel] webrtc on cerowrt

[Dave Taht]

On Sat, Jan 25, 2014 at 2:20 PM, Daniel Pocock <daniel@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@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.

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).

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....


-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] webrtc on cerowrt

[Daniel Pocock]

On 25/01/14 21:17, Dave Taht wrote:
> On Sat, Jan 25, 2014 at 2:20 PM, Daniel Pocock <daniel@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@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....
> 
> 

Re: [Cerowrt-devel] webrtc on cerowrt

[Dave Taht]

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

Which? resiprocate? webrtc? fq_codel?  :)





-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html

Re: [Cerowrt-devel] webrtc on cerowrt

[Daniel Pocock]

On 06/02/14 22:08, Dave Taht wrote:
>> Jitsi videobridge made a very compelling demo of this at FOSDEM on the
>> weekend
> 
> Which? resiprocate? webrtc? fq_codel?  :)
> 
> 

WebRTC video conferencing in browsers

Look at the little server, it is not much bigger than a business card:

https://drive.google.com/folderview?id=0BwiF7kZbHitaLTdKMWFqb3ZHUmM&usp=sharing

Re: [Cerowrt-devel] webrtc on cerowrt

[Dave Taht]

On Thu, Feb 6, 2014 at 4:09 PM, Daniel Pocock <daniel@pocock.com.au> wrote:
>
>
> On 06/02/14 22:08, Dave Taht wrote:
>>> Jitsi videobridge made a very compelling demo of this at FOSDEM on the
>>> weekend
>>
>> Which? resiprocate? webrtc? fq_codel?  :)
>>
>>
>
> WebRTC video conferencing in browsers
>
> Look at the little server, it is not much bigger than a business card:
>
> https://drive.google.com/folderview?id=0BwiF7kZbHitaLTdKMWFqb3ZHUmM&usp=sharing

I had this stuff working in little servers 12 years ago. :)

In terms of dealing with the SIP/RTP proxy situation, what I used to
do was use split dns,
aliasing pbx.taht.net to an internal server on the internal network,
and to a cloud service
on external.



-- 
Dave Täht

Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html