anyone knows what cc is used by skype?<div><br></div><div>we did this investigation for skype audio</div><div><a href="http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf">http://c3lab.poliba.it/images/9/9b/Skype-tac10.pdf</a></div>
<div><br></div><div>and this one for video</div><div><a href="http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf">http://c3lab.poliba.it/images/b/b7/Skype_comnet.pdf</a></div><div><br></div><div>-sm<br><br><div class="gmail_quote">
On Sun, Jan 23, 2011 at 4:30 PM, Stefan Håkansson LK <span dir="ltr"><<a href="mailto:stefan.lk.hakansson@ericsson.com">stefan.lk.hakansson@ericsson.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div style="word-wrap:break-word">
<div dir="ltr" align="left"><span><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><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><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><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2">Cullen, Harald: something to add to the
charter?</font></span></div>
<div dir="ltr" align="left"><span><font face="Arial" color="#0000ff" size="2"></font></span> </div>
<div dir="ltr" align="left"><span><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 lang="en-us" dir="ltr" align="left">
<hr>
<font face="Tahoma" size="2"><b>From:</b> <a href="mailto:rtc-web-bounces@alvestrand.no" target="_blank">rtc-web-bounces@alvestrand.no</a>
[mailto:<a href="mailto:rtc-web-bounces@alvestrand.no" target="_blank">rtc-web-bounces@alvestrand.no</a>] <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> <a href="mailto:tom_harper@logitech.com" target="_blank">tom_harper@logitech.com</a>; <a href="mailto:rtc-web@alvestrand.no" target="_blank">rtc-web@alvestrand.no</a>; Saverio
Mascolo<div><div></div><div class="h5"><br><b>Subject:</b> Re: [RTW] Rate control and codec adaption (Re:
[dispatch] The charter formerly know as RTC-WEB take 3)<br></div></div></font><br></div><div><div></div><div class="h5">
<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>
<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" target="_blank">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>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>
<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></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" 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>
</blockquote></div><br></div></div></div></blockquote></div>
</blockquote></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. +39 080 5963621<br>Fax. +39 080 5963410<br>
<a href="mailto:email%3Amascolo@poliba.it">email:mascolo@poliba.it</a><br> <br><a href="http://c3lab.poliba.it">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>
</div>