Subject: Re: [dispatch] New draft on RTCWeb Requirements and API draft-jennings-rtcweb-api

From: Henry Sinnreich <[email-masked]>
Date: Wed, 23 Mar 2011 11:25:07 -0500

Hi Lorenzo, Cullen,

> We implemented something like that for our system, also documented in a paper
> lately: basically a controller protocol that tunnels every other protocol on
> top of HTTP to bypass restrictive firewalls.

Having explained HTTP tunneling flavors in the paper and also shown
measurement results, besides a working product, should really make IMO your
approach or something similar to it an option for the RTC-Web media
solution. Such an option should also be reflected in the API part, on which
the draft-jennings-rtcweb-api is focused.

RT media over HTTP may be quite effective in some usage scenarios, such as
CDN with >100k HTPP proxies around the globe, collocated in 1,000s of
networks with plenty of bandwidth, smaller delay and arguably without all
the other SIP, etc. intermediaries found inside and between most service
provider networks.

I know profiles in standards are not desirable, but hindering innovations
such as yours and ignoring CDN and other Web application scenarios is even
less desirable. 
This is a challenge both the IETF and the W3C will hopefully manage.

Thanks for sharing,

Henry

On 3/16/11 3:12 PM, "Lorenzo Miniero" <[email-masked]> wrote:

> On Wed, 16 Mar 2011 13:54:39 -0500
> Henry Sinnreich <[email-masked]> wrote:
> 
>> Hi Cullen,
>> 
>> Section 3. Requirements says:
>> ... In addition, there is a strong interest to define a TURN-like protocol
>>    that looks like HTTP to intermediaries, so that media can be tunneled
>>    over HTTP. 
>> ...
>> 
>> This is very interesting and innovative.
>> Can you explain here a little bit?
>> 
>> Thanks, Henry
>> 
> 
> 
> We implemented something like that for our system, also documented in a paper
> lately: basically a controller protocol that tunnels every other protocol on
> top of HTTP to bypass restrictive firewalls. Since it works, we were also
> thinking about a "lightweight" version of such protocol to only convey RTP
> specifically for our web interface, considering RTP is the only protocol we
> couldn't wrap via JavaScript so far. So I agree that such a TURN-like protocol
> would be a good idea for the WG.
> 
> Of course, there would be limitations and issues because of this transport,
> but since firewalls are there to stay, and few of them like RTP appearing "out
> of the blue", that's something we probably need to live with.
> 
> L.
> 
> 
>> 
>> On 3/10/11 2:20 PM, "Cullen Jennings" <[email-masked]> wrote:
>> 
>>> 
>>> I wrote up the start of a draft on requirements.
>>> 
>>> http://tools.ietf.org/html/draft-jennings-rtcweb-api-00
>>> 
>>> I think the key thing for the key thing for IETF working is starting to
>>> think
>>> about the requirements and what on the on the wire protocols are that we
>>> want
>>> to select. I included some API definition because I found it helpful to be
>>> thinking about that in this draft but that would not be part of the IETF
>>> work.
>>> That would be work I think W3C should do. The draft also touches on the of
>>> the
>>> security issues for media and signaling originating from browsers.
>>> 
>>> Cullen 
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> dispatch mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/dispatch
>> 
>> 
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 24 Mar 2011 17:52:17 +0100

Hi Henry,

On Wed, 23 Mar 2011 11:25:07 -0500

> the draft-jennings-rtcweb-api is focused.

I'd be glad to contribute to the definition of a related solution, should such a work be started within the IETF.

I'll also try and make available, hopefully before the meeting, a publicly reachable prototype version of our current approach for you all to play with, just to have some live experience to foster discussion.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Lorenzo Miniero <[email-masked]>
Date: Sat, 26 Mar 2011 17:45:04 +0100

Dear all,

as anticipated, I've just made available a prototype version of our RTP-over-HTTP tunneling approach:

	http://143.225.229.136/WebLite/echotest.jsp

It is a very simple Echo Test: the page uses JavaScript to setup a server-originated SIP call to a URI associated with an RTP echo application. Then, a Java applet is started to take care of the the RTP tunneling and encoding/decoding process.

To play with it, just enable the "Enable RTP tunneling" checkbox and then click the button to launch the test. If everything goes fine, a new box should appear on the left with the remote audio and video streams: a voice prompt with a video logo will precede the actual echo feature. All the RTP packets will be tunneled over HTTP.

Before you start, nevertheless, please have a quick look at a few prerequisites and instructions here:

	http://ietf.conf.meetecho.com/index.php/Web_Client

for what concerns the applet-based Audio/Video functionality (last section in the page: our Web Client uses the same applet). In fact, applets can give a few problems at times (especially for multimedia-driven applications) in some configurations, and so checking a few things before delving in the demo may spare you from headache! :)

Let us know if and how it works. Of course please beware that this is just a very dumb prototype, so rough that it can give you the creeps if you just skim over it! :)
Nevertheless, the basic concepts are there, so it may be useful to foster some discussion on the matter. If you're interested in some more details, I'm already in Prague.

Lorenzo

On Thu, 24 Mar 2011 17:52:17 +0100

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Heinrich Sinnreich <[email-masked]>
Date: Mon, 28 Mar 2011 06:59:22 +0200

Thanks for the demo yesterday, Sunday outside the welcome reception!
For those who may have missed it, the RTP-over-HTTP tunneling demo really
works, though some of us will try again, after flying home.

Thanks again,
Henry

On 3/26/11 6:45 PM, "Lorenzo Miniero" <[email-masked]> wrote:

> It is a very simple Echo Test: the page uses JavaScript to setup a
> server-originated SIP call to a URI associated with an RTP echo application.
> Then, a Java applet is started to take care of the the RTP tunneling and
> encoding/decoding process.
> 
> To play with it, just enable the "Enable RTP tunneling" checkbox and then
> click the button to launch the test. If everything goes fine, a new box should
> appear on the left with the remote audio and video streams: a voice prompt
> with a video logo will precede the actual echo feature. All the RTP packets
> will be tunneled over HTTP.
> 
> for what concerns the applet-based Audio/Video functionality (last section in
> the page: our Web Client uses the same applet). In fact, applets can give a
> few problems at times (especially for multimedia-driven applications) in some
> configurations, and so checking a few things before delving in the demo may
> spare you from headache! :)
> 
> Let us know if and how it works. Of course please beware that this is just a
> very dumb prototype, so rough that it can give you the creeps if you just skim
> over it! :)
> Nevertheless, the basic concepts are there, so it may be useful to foster some
> discussion on the matter. If you're interested in some more details, I'm
> already in Prague.
> 
> Lorenzo
> 
> 
> 
>> I'll also try and make available, hopefully before the meeting, a publicly
>> reachable prototype version of our current approach for you all to play with,
>> just to have some live experience to foster discussion.
>> 
>> L.
>> 
>>

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Mar 2011 02:33:25 -0500

I suggest trying it from a pc tethered to an EDGE mobile modem.
> To play with it, just enable the "Enable RTP tunneling" checkbox and then
click the button to launch the test. If everything goes fine, a new box
should appear on the left with the remote audio and video streams: a voice
prompt with a video logo will precede the actual echo feature. All the RTP
packets will be tunneled over HTTP.
> for what concerns the applet-based Audio/Video functionality (last section
in the page: our Web Client uses the same applet). In fact, applets can give
a few problems at times (especially for multimedia-driven applications) in
some configurations, and so checking a few things before delving in the demo
may spare you from headache! :)
>
> Let us know if and how it works. Of course please beware that this is just
a very dumb prototype, so rough that it can give you the creeps if you just
skim over it! :)
> Nevertheless, the basic concepts are there, so it may be useful to foster
some discussion on the matter. If you're interested in some more details,
I'm already in Prague.
>> I'll also try and make available, hopefully before the meeting, a
publicly reachable prototype version of our current approach for you all to
play with, just to have some live experience to foster discussion.

---

From: Lorenzo Miniero <[email-masked]>
Date: Mon, 28 Mar 2011 14:03:35 +0200

Hi Dean,

On Mon, 28 Mar 2011 02:33:25 -0500

> I suggest trying it from a pc tethered to an EDGE mobile modem.

Or with no network at all :)

Jokes apart, it's clear that the QoE can't benefit from such limited bandwidth/conditions, and that would be true for pure RTP as well. I can only say that we've used this and older versions of the tunnel on limited networks (home adsls, umts, etc.) for our purposes and it seemed fine, though I agree that every attempt at addressing this feature should take care of tackling such issues.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Mar 2011 07:14:28 -0500

It is not the bandwidth that worries me. It is packet loss and resulting tcp
retransmit jitter.
On Mar 28, 2011 2:08 PM, "Lorenzo Miniero" <[email-masked]> wrote:
> Jokes apart, it's clear that the QoE can't benefit from such limited
bandwidth/conditions, and that would be true for pure RTP as well. I can
only say that we've used this and older versions of the tunnel on limited
networks (home adsls, umts, etc.) for our purposes and it seemed fine,
though I agree that every attempt at addressing this feature should take
care of tackling such issues.
>> >> > > We implemented something like that for our system, also documented
in
>> a paper
>> >> > measurement results, besides a working product, should really make
IMO
>> your
>> >> > solution. Such an option should also be reflected in the API part,
on
>> which
>> >> I'd be glad to contribute to the definition of a related solution,
should
>> such a work be started within the IETF.
>> >>
>> >> > RT media over HTTP may be quite effective in some usage scenarios,
such
>> as
>> >> > networks with plenty of bandwidth, smaller delay and arguably
without
>> all
>> >> > such as yours and ignoring CDN and other Web application scenarios
is
>> even
>> >> > > We implemented something like that for our system, also documented
in
>> a paper
>> >> > > top of HTTP to bypass restrictive firewalls. Since it works, we
were
>> also
>> >> > > couldn't wrap via JavaScript so far. So I agree that such a
TURN-like
>> protocol
>> >> > >>> thinking about that in this draft but that would not be part of
the
>> IETF
>> >> > >>> work.
>> >> > >>> That would be work I think W3C should do. The draft also touches
on
>> the of

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 28 Mar 2011 14:28:35 +0200

Hi Dean,

we made a number of tests with an "off-the-shelf" ADSL connection (both 
in an un-congested and in a congested network). Jitter was between 80 
and 100 msec in the former case; in the latter case (congested network) 
it was much more variable, with an average of around 105 msec and peaks 
between 60 and 160 msec (which clearly show a dependence on TCP 
congestion control mechanisms).

Simon

In the former case (no congestion in the network), jitter

Il 28/03/2011 14:14, Dean Willis ha scritto:
>
> It is not the bandwidth that worries me. It is packet loss and 
> resulting tcp retransmit jitter.
>
> On Mar 28, 2011 2:08 PM, "Lorenzo Miniero" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> > Hi Dean,
> >
> >
> > Dean Willis <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >
> bandwidth/conditions, and that would be true for pure RTP as well. I 
> can only say that we've used this and older versions of the tunnel on 
> limited networks (home adsls, umts, etc.) for our purposes and it 
> seemed fine, though I agree that every attempt at addressing this 
> feature should take care of tackling such issues.
> >
> > L.
> >
> >
> >
> >> On Mar 26, 2011 4:49 PM, "Lorenzo Miniero" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> > Dear all,
> >> >
> >> > Lorenzo Miniero <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> >
> >> >> Hi Henry,
> >> >>
> >> >>
> >> >> Henry Sinnreich <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> >>
> >> >> > Hi Lorenzo, Cullen,
> >> >> >
> >> >> > > We implemented something like that for our system, also 
> documented in
> >> a paper
> >> >> > measurement results, besides a working product, should really 
> make IMO
> >> your
> >> >> > solution. Such an option should also be reflected in the API 
> part, on
> >> which
> >> >> I'd be glad to contribute to the definition of a related 
> solution, should
> >> >> > RT media over HTTP may be quite effective in some usage 
> scenarios, such
> >> as
> >> >> > such as yours and ignoring CDN and other Web application 
> scenarios is
> >> even
> >> >> > less desirable.
> >> >> > On 3/16/11 3:12 PM, "Lorenzo Miniero" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> >> >
> >> >> > > Henry Sinnreich <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> >> > >
> >> >> > >> Hi Cullen,
> >> >> > >>
> >> >> > >> ... In addition, there is a strong interest to define a 
> TURN-like
> >> protocol
> >> >> > > We implemented something like that for our system, also 
> documented in
> >> a paper
> >> >> > > top of HTTP to bypass restrictive firewalls. Since it works, 
> we were
> >> also
> >> >> > >> On 3/10/11 2:20 PM, "Cullen Jennings" <[email-masked] 
> <mailto:[email-masked]>> wrote:
> >> >> > >>
> >> >> > >>>
> >> >> > >>> about the requirements and what on the on the wire 
> protocols are
> >> that we
> >> >> > >>> want
> >> >> > >>> thinking about that in this draft but that would not be 
> part of the
> >> IETF
> >> >> > >>> work.
> >> >> > >>> That would be work I think W3C should do. The draft also 
> touches on
> >> the of
> >> >> > >>> the
> >> >> > >>> [email-masked] <mailto:[email-masked]>
> >> >> > >> [email-masked] <mailto:[email-masked]>
> >> >> [email-masked] <mailto:[email-masked]>
> >> > [email-masked] <mailto:[email-masked]>

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 Mar 2011 09:49:32 -0500

What was the packet loss rate? Were they randomly distributed single-packet
losses or contiguos burst losses? RTP/UDP with simple CODECs is surprisingly
useful at 1% losses with burst losses up to 3 sequential packets.
On Mar 28, 2011 2:28 PM, "Simon Pietro Romano" <[email-masked]> wrote:
>> >> >> > > lately: basically a controller protocol that tunnels every
other
>> >> protocol on
>> >> >> > > lately: basically a controller protocol that tunnels every
other
>> >> protocol on
>> >> >> > > Of course, there would be limitations and issues because of
this
>> >> transport,