<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=utf-8">
<META content="MSHTML 6.00.6001.18542" name=GENERATOR></HEAD>
<BODY
style="WORD-WRAP: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space">
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2>Maybe we can work out the details along the way; I think I
started the thread, and my purpose was to secure that congestion control of
streams would be part of the solution, and to discuss if it should be in the
charter.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2>Many mails discussing _how_ to rate control, and no
mails against, means to me that people feel that congestion control
should be supported. </FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2>Cullen, Harald: something to add to the
charter?</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=285452515-23012011><FONT face=Arial
color=#0000ff size=2>//Stefan</FONT></SPAN></DIV><BR>
<BLOCKQUOTE dir=ltr
style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px solid; MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> rtc-web-bounces@alvestrand.no
[mailto:rtc-web-bounces@alvestrand.no] <B>On Behalf Of </B>Peter
Musgrave<BR><B>Sent:</B> den 23 januari 2011 13:14<BR><B>To:</B> Justin
Uberti<BR><B>Cc:</B> tom_harper@logitech.com; rtc-web@alvestrand.no; Saverio
Mascolo<BR><B>Subject:</B> Re: [RTW] Rate control and codec adaption (Re:
[dispatch] The charter formerly know as RTC-WEB take 3)<BR></FONT><BR></DIV>
<DIV></DIV>Magor also uses a TFRC-based approach. The TFRC algorithm is very
effective.
<DIV><BR></DIV>
<DIV>Peter Musgrave</DIV>
<DIV><BR>
<DIV>
<DIV>On 2011-01-23, at 12:41 AM, Justin Uberti wrote:</DIV><BR
class=Apple-interchange-newline>
<BLOCKQUOTE type="cite">Google Video Chat uses a TFRC-based algorithm for
rate control.<BR><BR>
<DIV class=gmail_quote>On Sat, Jan 22, 2011 at 6:18 AM, Saverio Mascolo
<SPAN dir=ltr><<A
href="mailto:saverio.mascolo@gmail.com">saverio.mascolo@gmail.com</A>></SPAN>
wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid"><BR><BR>
<DIV class=gmail_quote>
<DIV class=im>On Fri, Jan 21, 2011 at 8:43 PM, Justin Uberti <SPAN
dir=ltr><<A href="mailto:juberti@google.com"
target=_blank>juberti@google.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">TFRC
isn't perfect, but it seems to work pretty well in practice.</BLOCKQUOTE>
<DIV><BR></DIV></DIV>
<DIV>in practice where???? </DIV>
<DIV><BR></DIV>
<DIV>-sm</DIV>
<DIV>
<DIV></DIV>
<DIV class=h5>
<DIV><BR></DIV>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">The
RTP extension header overhead of 12 bytes per packet is fairly nominal
(1%) at today's video bitrates, as is the cost of the RTCP feedback
message.
<DIV><BR></DIV>
<DIV>I'm not aware of any other standards-track bandwidth estimation
algorithms designed to work with RTP/UDP.</DIV>
<DIV>
<DIV></DIV>
<DIV>
<DIV>
<DIV>
<DIV><BR>
<DIV class=gmail_quote>On Fri, Jan 21, 2011 at 9:46 AM, <SPAN
dir=ltr><<A href="mailto:tom_harper@logitech.com"
target=_blank>tom_harper@logitech.com</A>></SPAN> wrote:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0px 0px 0px 0.8ex; BORDER-LEFT: #ccc 1px solid">
<DIV>
<P>It seems to me neither avpf or tfrc is fully perfect- on the whole
tfrc seems to be better than avpf in terms of constant measurement of
the connection- <BR><BR>tfrc seems scary/impractical at low latencies
due to the following:<BR><TT><FONT size=4>"The TFRC requirements of
receiving feedback once per RTT can at times<BR> conflict with
the AVP RTCP bandwidth constraints, particularly at<BR> small
RTTs of 20 ms or less</FONT></TT>"<BR>and the fact that it has to be
attached as an extension header to every data packet seems like more
overhead than is needed, but others opinions may differ on
this.<BR><BR>We support avpf as defined 5104/4585, but prefer not to
use it as in some scenarios we have run into the rtcp bandwidth cap-
and then you get no feedback at all in a timely manner.<BR><BR>Are
there any other inband schemes that are up in rfc at this
point?<BR><BR>Tom<BR><BR><BR><BR><SPAN><graycol.gif></SPAN><FONT
color=#424282>Stefan H嶡ansson LK ---01/21/2011 12:38:33 AM---Isn't it
so that with the AVPF profile you can actually sent RTCP when there is
a need (even if a tr</FONT><BR><BR><FONT color=#5f5f5f size=2>From:
</FONT><FONT size=2>Stefan H嶡ansson LK <<A
href="mailto:stefan.lk.hakansson@ericsson.com"
target=_blank>stefan.lk.hakansson@ericsson.com</A>></FONT><BR><FONT
color=#5f5f5f size=2>To: </FONT><FONT size=2>Justin Uberti <<A
href="mailto:juberti@google.com"
target=_blank>juberti@google.com</A>></FONT><BR><FONT color=#5f5f5f
size=2>Cc: </FONT><FONT size=2>Cullen Jennings <<A
href="mailto:fluffy@cisco.com" target=_blank>fluffy@cisco.com</A>>,
DISPATCH list <<A href="mailto:dispatch@ietf.org"
target=_blank>dispatch@ietf.org</A>>, Henry Sinnreich <<A
href="mailto:henry.sinnreich@gmail.com"
target=_blank>henry.sinnreich@gmail.com</A>>, Harald Alvestrand
<<A href="mailto:harald@alvestrand.no"
target=_blank>harald@alvestrand.no</A>>, "<A
href="mailto:rtc-web@alvestrand.no"
target=_blank>rtc-web@alvestrand.no</A>" <<A
href="mailto:rtc-web@alvestrand.no"
target=_blank>rtc-web@alvestrand.no</A>>, Stephen Botzko <<A
href="mailto:stephen.botzko@gmail.com"
target=_blank>stephen.botzko@gmail.com</A>></FONT><BR><FONT
color=#5f5f5f size=2>Date: </FONT><FONT size=2>01/21/2011 12:38
AM</FONT></P>
<DIV><BR><FONT color=#5f5f5f size=2>Subject: </FONT><FONT size=2>Re:
[RTW] Rate control and codec adaption (Re: [dispatch] The charter
formerly know as RTC-WEB take 3)</FONT><BR></DIV><FONT color=#5f5f5f
size=2>Sent by: </FONT><FONT size=2><A
href="mailto:rtc-web-bounces@alvestrand.no"
target=_blank>rtc-web-bounces@alvestrand.no</A></FONT><BR>
<HR style="COLOR: #8091a5" align=left width="100%" noShade SIZE=2>
<DIV>
<DIV></DIV>
<DIV><BR><BR><BR><FONT face=Arial color=#0000ff>Isn't it so that with
the AVPF profile you can actually sent RTCP when there is a need (even
if a transmission is not due)? This way you can actually react fast.
</FONT><BR><BR>
<HR align=left width="100%" SIZE=2>
<B><FONT face=Tahoma>From:</FONT></B><FONT face=Tahoma> Justin Uberti
[</FONT><FONT face=Tahoma><A href="mailto:juberti@google.com"
target=_blank>mailto:juberti@google.com</A></FONT><FONT face=Tahoma>]
</FONT><B><FONT face=Tahoma><BR>Sent:</FONT></B><FONT face=Tahoma> den
21 januari 2011 09:13</FONT><B><FONT
face=Tahoma><BR>To:</FONT></B><FONT face=Tahoma> Stefan Håkansson
LK</FONT><B><FONT face=Tahoma><BR>Cc:</FONT></B><FONT face=Tahoma>
Harald Alvestrand; Henry Sinnreich; Cullen Jennings; <A
href="mailto:rtc-web@alvestrand.no"
target=_blank>rtc-web@alvestrand.no</A>; DISPATCH list; Stephen
Botzko</FONT><B><FONT face=Tahoma><BR>Subject:</FONT></B><FONT
face=Tahoma> Re: [RTW] Rate control and codec adaption (Re: [dispatch]
The charter formerly know as RTC-WEB take 3)</FONT><FONT
size=4><BR></FONT><BR><FONT size=4>RTCP typically isn't sent
frequently enough to allow for real-time adjustments in bitrate. TFRC
provides a nice mechanism for controlling bitrate in real-time, but
the work to apply TFRC to RTP has not yet been codified into a
standard. </FONT><BR><BR><FONT size=4>There was a draft but it has
been abandonded (</FONT><A
href="http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10"
target=_blank><U><FONT color=#0000ff
size=4>http://tools.ietf.org/html/draft-ietf-avt-tfrc-profile-10</FONT></U></A><FONT
size=4>)<BR></FONT><BR><FONT size=4>On Thu, Jan 20, 2011 at 11:50 PM,
Stefan Håkansson LK <</FONT><A
href="mailto:stefan.lk.hakansson@ericsson.com" target=_blank><U><FONT
color=#0000ff
size=4>stefan.lk.hakansson@ericsson.com</FONT></U></A><FONT
size=4>> wrote:</FONT>
<UL><FONT face=Arial color=#0000ff>My view: we are discussing a
problem already solved! The common procedure would be to use info in
the RTCP reports from the receiving end to change the transmitted
bit rate (if change is required). </FONT><BR><BR>
<HR align=left width="100%" SIZE=2>
<B><FONT face=Tahoma>From:</FONT></B><FONT face=Tahoma> Harald
Alvestrand [mailto:</FONT><A href="mailto:harald@alvestrand.no"
target=_blank><U><FONT face=Tahoma
color=#0000ff>harald@alvestrand.no</FONT></U></A><FONT face=Tahoma>]
</FONT><B><FONT face=Tahoma><BR>Sent:</FONT></B><FONT face=Tahoma>
den 21 januari 2011 08:46</FONT><B><FONT
face=Tahoma><BR>To:</FONT></B><FONT face=Tahoma> Henry
Sinnreich</FONT><B><FONT face=Tahoma><BR>Cc:</FONT></B><FONT
face=Tahoma> Stefan Håkansson LK; Stephen Botzko; Cullen Jennings;
</FONT><A href="mailto:rtc-web@alvestrand.no" target=_blank><U><FONT
face=Tahoma color=#0000ff>rtc-web@alvestrand.no</FONT></U></A><FONT
face=Tahoma>; DISPATCH list</FONT><B><FONT
face=Tahoma><BR>Subject:</FONT></B><FONT face=Tahoma> Rate control
and codec adaption (Re: [RTW] [dispatch] The charter formerly know
as RTC-WEB take 3)</FONT><FONT size=4><BR></FONT><BR><FONT size=4>On
01/21/2011 12:06 AM, Henry Sinnreich wrote: </FONT>
<UL>
<UL><FONT face=Calibri size=4>></FONT><FONT face=Arial
color=#0000fe size=4>Minor comment: I think all codecs that have
been discussed (except for G.711) are adaptive in the sense that
their bitrate can be adapted.</FONT><FONT face=Calibri
size=4><BR><BR>It is not clear to me how to avoid the codec
adaptation mechanism fighting the rate control mechanism,
without some guidance in the standard for developers.<BR>Can you
explain?</FONT></UL></UL><FONT size=4>Changing the subject to
content of thread....<BR><BR>are we reducing to a previously solved
problem, or to a previously unsolved problem?<BR>I don't see how
this problem actually differs from the one that people will have
when operating RTP under TFRC
(draft-ietf-avt-tfrc-profile-10).<BR></FONT>
<UL>
<UL><FONT face=Calibri size=4><BR>Thanks, Henry<BR><BR><BR>On
1/20/11 2:02 PM, "Stefan Håkansson LK" <</FONT><A
href="http://stefan.lk.hakansson@ericsson.com/"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>stefan.lk.hakansson@ericsson.com</FONT></U></A><FONT
face=Calibri size=4>> wrote:<BR></FONT>
<UL>
<UL><FONT face=Arial color=#0000ff size=4>Minor comment: I
think all codecs that have been discussed (except for G.711)
are adaptive in the sense that their bitrate can be
adapted.</FONT><FONT face=Calibri size=4><BR></FONT><FONT
face=Arial color=#0000ff
size=4><BR>Br,<BR>Stefan</FONT><FONT face=Calibri
size=4><BR></FONT>
<UL>
<UL><FONT face=Calibri size=4><BR><BR></FONT>
<HR align=left width="100%" SIZE=2>
<B><FONT face=Tahoma size=4>From:</FONT></B><FONT
face=Tahoma size=4> Stephen Botzko [</FONT><A
href="mailto:stephen.botzko@gmail.com"
target=_blank><U><FONT face=Tahoma color=#0000ff
size=4>mailto:stephen.botzko@gmail.com</FONT></U></A><FONT
face=Tahoma size=4>] </FONT><B><FONT face=Tahoma
size=4><BR>Sent:</FONT></B><FONT face=Tahoma size=4> den
20 januari 2011 16:45</FONT><B><FONT face=Tahoma
size=4><BR>To:</FONT></B><FONT face=Tahoma size=4> Henry
Sinnreich</FONT><B><FONT face=Tahoma
size=4><BR>Cc:</FONT></B><FONT face=Tahoma size=4>
Stefan Håkansson LK; Cullen Jennings; DISPATCH list;
</FONT><A href="http://rtc-web@alvestrand.no/"
target=_blank><U><FONT face=Tahoma color=#0000ff
size=4>rtc-web@alvestrand.no</FONT></U></A><B><FONT
face=Tahoma size=4><BR>Subject:</FONT></B><FONT
face=Tahoma size=4> Re: [dispatch] The charter formerly
know as RTC-WEB take 3</FONT><FONT face=Calibri
size=4><BR><BR><BR>>>><BR>How does this fit
with adaptive codecs?<BR>>>><BR>Just because
some codecs can adapt doesn't mean rate
adaptation/congestion control should be left out of the
scope. I think it needs to be
considered.<BR><BR>>>><BR>Hint: codec selection
matters, is actually critical to this
effort.<BR>>>><BR>Codec selection does matter,
but I am not convinced that mandatory codecs need to be
in the RFCs. I believe market forces are sufficient -
SIP itself is one proof point.<BR><BR>Stephen
Botzko<BR><BR><BR><BR>On Thu, Jan 20, 2011 at 10:37 AM,
Henry Sinnreich <</FONT><A
href="http://henry.sinnreich@gmail.com/"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>henry.sinnreich@gmail.com</FONT></U></A><FONT
face=Calibri size=4>> wrote:<BR></FONT>
<UL>
<UL><FONT face=Calibri size=4>Hi
Stefan,<BR><BR><BR>> 2. The second one is about
rate adaptation/congestion control. It is
not<BR>> mentioned at all. I don't know if it is
needed, perhaps it is enough that<BR>> RFC3550
(that is already pointed at) has a section about it,
but I wanted to<BR>> highlight it.<BR><BR>How
does this fit with adaptive codecs?<BR>Hint: codec
selection matters, is actually critical to this
effort.<BR><BR>Thanks, Henry<BR><BR><BR>On 1/20/11
3:52 AM, "Stefan Håkansson LK" <</FONT><A
href="http://stefan.lk.hakansson@ericsson.com/"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>stefan.lk.hakansson@ericsson.com</FONT></U></A><FONT
face=Calibri
size=4>><BR>wrote:<BR><BR><BR><BR><BR>> Hi
Cullen,<BR>><BR>> two
comments:<BR>><BR>> 1. As requirements on the
API are explicitly described, I thinke that
there<BR>> should be a comment that the API must
support media format negotiation.<BR>> Proposal:
"The API must enable media format negotiation and
application<BR>> influence over media format
selection".<BR>><BR>> 2. The second one is
about rate adaptation/congestion control. It is
not<BR>> mentioned at all. I don't know if it is
needed, perhaps it is enough that<BR>> RFC3550
(that is already pointed at) has a section about it,
but I wanted to<BR>> highlight
it.<BR>><BR>> Br,<BR>>
Stefan<BR>><BR>>> -----Original
Message-----<BR>>> From: </FONT><A
href="http://dispatch-bounces@ietf.org/"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>dispatch-bounces@ietf.org</FONT></U></A><FONT
face=Calibri size=4><BR>>> [</FONT><A
href="mailto:dispatch-bounces@ietf.org"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>mailto:dispatch-bounces@ietf.org</FONT></U></A><FONT
face=Calibri size=4>] On Behalf Of Cullen
Jennings<BR>>> Sent: den 18 januari 2011
05:59<BR>>> To: DISPATCH list<BR>>> Cc:
</FONT><A href="http://rtc-web@alvestrand.no/"
target=_blank><U><FONT face=Calibri color=#0000ff
size=4>rtc-web@alvestrand.no</FONT></U></A><FONT
face=Calibri size=4><BR>>> Subject: [dispatch]
The charter formerly know as RTC-WEB take
3<BR>>><BR>>><BR>>> In my dispatch
co-chair role, I tried to take all the<BR>>>
comments I had seen on the list about this charter
and see if<BR>>> I could address them in a new
version of the charter. I<BR>>> probably
messed up in some places. There were
some<BR>>> conversation that did not seem to
be converging so I did not<BR>>> make any
changes for theses. Have a read and if you
think<BR>>> something needs to be changed,
propose text changes along<BR>>> with the
reasons why and we will keep the evolving this
charter.<BR>>><BR>>> Thanks<BR>>>
Cullen<BR>>><BR>>>
--------------------------------------------------------------<BR>>>
--------------------<BR>>><BR>>>
Version: 3<BR>>><BR>>> Possible
Names:<BR>>><BR>>> RTCWEB<BR>>>
WEBRTC<BR>>> STORM: Standardized Transport
Oriented for Realtime Media<BR>>> BURN:
Browsers Using Realtime Media<BR>>> WAVE: Web
And Voice/Video Enablement<BR>>> WAVVE: Web
And Voice Video Enablement<BR>>>
REALTIME<BR>>> WEBCOMM<BR>>>
WREALTIME<BR>>> WEBTIME<BR>>>
WEBFLOWS<BR>>> BRAVO Browser Realtime Audio
and VideO<BR>>> COBWEB COmmuication Between
WEBclients<BR>>>
WHEELTIME<BR>>><BR>>><BR>>><BR>>>
Body:<BR>>><BR>>> Many implementations
have been made that use a Web browser to<BR>>>
support direct, interactive communications,
including voice,<BR>>> video, collaboration,
and gaming. In these implementations,<BR>>>
the web server acts as the signaling path between
these<BR>>> applications, using locally
significant identifiers to set up<BR>>> the
association. Up till now, such applications
have<BR>>> typically required the installation
of plugins or<BR>>> non-standard browser
extensions. There is a desire to<BR>>>
standardize this functionality, so that this type
of<BR>>> application can be run in any
compatible browser and allow<BR>>> for
high-quality real-time communications experiences
within<BR>>> the
browser.<BR>>><BR>>> Traditionally, the
W3C has defined API and markup languages<BR>>>
such as HTML that work in conjunction with with the
IETF over<BR>>> the wire protocols such as
HTTP to allow web browsers to<BR>>> display
media that does not have real time
interactive<BR>>> constraints with another
human.<BR>>><BR>>> The W3C and IETF plan
to collaborate together in their<BR>>>
traditional way to meet the evolving needs of
browsers.<BR>>> Specifically the IETF will
provide a set of on the wire<BR>>> protocols,
including RTP, to meet the needs on
interactive<BR>>> communications, and the W3C
will define the API and markup to<BR>>> allow
web application developers to control the on the
wire<BR>>> protocols. This will allow
application developers to write<BR>>>
applications that run in a browser and facilitate
interactive<BR>>> communications between users
for voice and video<BR>>> communications,
collaboration, and gaming.<BR>>><BR>>>
This working group will select and define a minimal
set of<BR>>> protocols that will enable
browsers to:<BR>>><BR>>> * have
interactive real time voice and video pairwise
be</FONT></UL></UL></UL></UL></UL></UL><TT><FONT
size=4><BR>_______________________________________________<BR>RTC-Web
mailing list<BR></FONT></TT><A
href="mailto:RTC-Web@alvestrand.no" target=_blank><TT><U><FONT
color=#0000ff
size=4>RTC-Web@alvestrand.no</FONT></U></TT></A><TT><FONT
size=4><BR></FONT></TT><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank><TT><U><FONT color=#0000ff
size=4>http://www.alvestrand.no/mailman/listinfo/rtc-web</FONT></U></TT></A><TT><FONT
size=4><BR></FONT></TT></UL></UL><BR><FONT
size=4><BR>_______________________________________________<BR>RTC-Web
mailing list</FONT><U><FONT color=#0000ff size=4><BR></FONT></U><A
href="mailto:RTC-Web@alvestrand.no" target=_blank><U><FONT
color=#0000ff size=4>RTC-Web@alvestrand.no</FONT></U></A><U><FONT
color=#0000ff size=4><BR></FONT></U><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank><U><FONT color=#0000ff
size=4>http://www.alvestrand.no/mailman/listinfo/rtc-web</FONT></U></A><FONT
size=4><BR></FONT></UL><TT>_______________________________________________<BR>RTC-Web
mailing list<BR><A href="mailto:RTC-Web@alvestrand.no"
target=_blank>RTC-Web@alvestrand.no</A><BR></TT><TT><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A></TT><TT><BR></TT><BR></DIV></DIV>
<DIV><BR
class=webkit-block-placeholder></DIV></DIV><BR>_______________________________________________<BR>RTC-Web
mailing list<BR><A href="mailto:RTC-Web@alvestrand.no"
target=_blank>RTC-Web@alvestrand.no</A><BR><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A><BR><BR></BLOCKQUOTE></DIV><BR></DIV></DIV></DIV></DIV></DIV><BR>_______________________________________________<BR>RTC-Web
mailing list<BR><A href="mailto:RTC-Web@alvestrand.no"
target=_blank>RTC-Web@alvestrand.no</A><BR><A
href="http://www.alvestrand.no/mailman/listinfo/rtc-web"
target=_blank>http://www.alvestrand.no/mailman/listinfo/rtc-web</A><BR><BR></BLOCKQUOTE></DIV></DIV></DIV><BR><BR
clear=all><BR>-- <BR>Prof. Saverio Mascolo<BR>Dipartimento di
Elettrotecnica ed Elettronica<BR>Politecnico di Bari<BR>Via Orabona 4,
70125 Bari Italy<BR>Tel. <A href="tel:+390805963621" target=_blank>+39 080
5963621</A><BR>Fax. <A href="tel:+390805963410" target=_blank>+39 080
5963410</A><BR><A href="mailto:email%3Amascolo@poliba.it"
target=_blank>email:mascolo@poliba.it</A><BR> <BR><A
href="http://c3lab.poliba.it/"
target=_blank>http://c3lab.poliba.it</A><BR><BR><BR>=================================<BR> This
message may contain confidential and/or legally privileged
information.<BR> If you are not the intended recipient of the
message, please destroy it.<BR> Any unauthorized dissemination,
distribution, or copying of the material in<BR> this message, and any
attachments to the message, is strictly
forbidden.<BR></BLOCKQUOTE></DIV><BR>_______________________________________________<BR>RTC-Web
mailing list<BR><A
href="mailto:RTC-Web@alvestrand.no">RTC-Web@alvestrand.no</A><BR>http://www.alvestrand.no/mailman/listinfo/rtc-web<BR></BLOCKQUOTE></DIV><BR></DIV></BLOCKQUOTE></BODY></HTML>