Subject: skype remote audio

From: Marc Blanchet <[email-masked]>
Date: Thu, 11 Nov 2010 12:33:03 +0800

FYI,
  for iri wg meeting, the co-editor of the main document was remote 
using skype with audio out from my computer to the sound system using a 
cable provided by Joel. It worked perfectly, much better than I was 
expecting. We had bidi discussions with the remote presenter without any 
issue.

Regards, Marc.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 10 Nov 2010 20:52:32 -0800

I have participated remotely with Skype in a number of meetings at previous IETFs as well as
two meetings so far at IETF 79.  Configurations tested include:

* Skype audio + video, for remote participation in a meeting (not a WG).  Did this today, worked very well, both for sending and receiving. 
* Skype audio + webex, for remote chairing of a WG session.  In this case there were some issues with my mic, so I had to mute to get good incoming audio quality.  

In a WG meeting on Friday (RADEXT) we have got several remote presenters.  The plan is to have them speak via Skype audio.  I am
also wondering whether it might make sense for them to share their screens via Skype, or whether we should instead use WebEx with
the chair acting as page-turner.  

One thing I've noticed is that on platforms with older Skype versions (Linux, MacOS X) can send Skype video but can't necessarily receive it from other versions of Skype (e.g. on Windows).  

Coupling to the sound system seems to be one issue encountered.  I'm also curious about

> Date: Thu, 11 Nov 2010 12:33:03 +0800
> From: [email-masked]
> To: [email-masked]
> Subject: skype remote audio
> 
> FYI,

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 11 Nov 2010 19:31:51 +0800

For outgoing audio, it seems that skype keeps delay well below the level
achieved by the IETF media servers. Several remote participants have
complained about this (i.e., about the media servers).

Cheers,

Gonzalo

On 11/11/2010 12:52 PM, Bernard Aboba wrote:
> * Skype audio + video, for remote participation in a meeting (not a
> WG).  Did this today, worked very well, both for sending and receiving.
> * Skype audio + webex, for remote chairing of a WG session.  In this
> case there were some issues with my mic, so I had to mute to get good
> incoming audio quality. 
> 
> In a WG meeting on Friday (RADEXT) we have got several remote
> presenters.  The plan is to have them speak via Skype audio.  I am
> also wondering whether it might make sense for them to share their
> screens via Skype, or whether we should instead use WebEx with
> One thing I've noticed is that on platforms with older Skype versions
> (Linux, MacOS X) can send Skype video but can't necessarily receive it
> from other versions of Skype (e.g. on Windows). 
> 
>

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 11 Nov 2010 19:18:45 +0100

I should not say that, but I do wonder when will we be able to use an 
IETF-compliant, integrated (audio, video, wb, chat, desktop sharing, 
polling, etc...) collaboration framework, perhaps capable to also 
provide BFCP-based moderation and session recordings ;-)? We, people 
from the RAI area, should be definitely looking after this...

Simon

-- 
                             _\\|//_
                             ( 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: Bernard Aboba <[email-masked]>
Date: Thu, 11 Nov 2010 18:50:22 -0800

Just did a WG session (RADEXT) with three people (two presenters and me, the co-chair) being remote.  It was "interesting".    Some thoughts:

1.
 Overall there were too many choices for the remote presenter.  Skype audio vs. streaming audio, 
 Jabber chat room vs. Skype chat room,  Remote conferencing software 
with its options, muting in software vs. hardware.   During the session we adjusted choices (started off with the room MIC muted, so we started streaming audio, then we were unmuted and dropped streaming audio, moving over to listening to Skype audio).   If I had to do it over again, I'd probably move as much of the presenter functionality as possible to one system. 

2.  Skype audio was way better 
than streaming audio, both in terms of quality and delay.  I was 
surprised by how much better it was.  Streaming audio had a 6 second delay!

4.  I found the Skype conferencing 
functionality (first time I've used it) cumbersome; was hard to manage 
the two Skype windows plus the conferencing software window (showing 
slides) and the XMPP client windows (showing the jabber.ietf.org chat room).  Basic 
Windows functionality such as alt-Tab to switch windows didn't work.  

5. 
 Being able to sync up the audio with the slides was quite helpful, 
which made it best to listen via Skype rather than streaming audio given the delay. 

> Date: Thu, 11 Nov 2010 19:18:45 +0100
> From: [email-masked]
> To: [email-masked]
> Subject: Re: skype remote audio
> CC: [email-masked]; [email-masked]; [email-masked]
>

---

From: Robert Sparks <[email-masked]>
Date: Fri, 12 Nov 2010 14:36:35 +0800

> 
> 
> 2.  Skype audio was way better than streaming audio, both in terms of quality and delay.  I was surprised by how much better it was.  Streaming audio had a 6 second delay!
Interesting - the delay was _much_ higher for some participants (we observed 3 minutes at some points) in meetings earlier in the week.

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 12 Nov 2010 14:50:53 +0800

On 11/12/10 2:36 PM, Robert Sparks wrote:
>>
>>
>> 2.  Skype audio was way better than streaming audio, both in terms of
>> quality and delay.  I was surprised by how much better it was. 
>> Streaming audio had a 6 second delay!
> Interesting - the delay was _much_ higher for some participants (we
> observed 3 minutes at some points) in meetings earlier in the week.

the deepest buffer in icecast style http streaming audio is in the clients.

I can assure you that I didn't buffer 175KB in the network

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Nov 2010 02:01:02 -0500

I believe it.  However, we have available clients (Skype clients) that have much smaller buffers.
We need to advertise this issue and find http streaming audio clients that keep the buffers low to recommend

iTunes clearly can get tens of seconds, don't know if it will get up to minutes.

Skype consistently keeps it to hundreds of milliseconds. 

Brian

---

From: Dean Willis <[email-masked]>
Date: Fri, 12 Nov 2010 13:45:15 -0600

On Nov 12, 2010, at 1:01 AM, Brian Rosen wrote:

> We need to advertise this issue and find http streaming audio  
> clients that keep the buffers low to recommend
>

I don't think it is just the buffer size.  On a noisy channel there's  
no silence to discard for resynch.  So delay increases cumulatively  
with each buffer starvation that occurs.

You can either have drops (where delayed traffic is discarded, silence  
is discarded to catch up, etc.  or periods of silence and increased  
delay but receive ever sound sent. Take your pick.

--
Dean

---

From: Brian Rosen <[email-masked]>
Date: Fri, 12 Nov 2010 15:16:44 -0500

The experience with Skype suggests that drops is the best policy.

Brian

On Nov 12, 2010, at 2:45 PM, Dean Willis wrote:

> I don't think it is just the buffer size.  On a noisy channel there's no silence to discard for resynch.  So delay increases cumulatively with each buffer starvation that occurs.
> 
> You can either have drops (where delayed traffic is discarded, silence is discarded to catch up, etc.  or periods of silence and increased delay but receive ever sound sent. Take your pick.
> 
> --
> Dean

---

From: Alan DeKok <[email-masked]>
Date: Fri, 12 Nov 2010 21:34:49 +0100

Dean Willis wrote:
> I don't think it is just the buffer size.  On a noisy channel there's no
> silence to discard for resynch.  So delay increases cumulatively with
> each buffer starvation that occurs.

  RADEXT had long periods (2-3s) of silence.  The audio stream was
consistently 6s behind skype, which was in sync (sub second) for
multiple users scattered across the planet.

> delay but receive ever sound sent. Take your pick.

  I'll pick the technology that shows consistent small delays in the
best circumstance, versus one that shows consistent large delays in the
best circumstance.

  Alan DeKok.

---

From: Roni Even <[email-masked]>
Date: Sat, 13 Nov 2010 00:52:00 +0200

This depends on your use. In a conversation this is OK to drop packet since
end to end delay is important to the user experience and if you lose
something you can ask the other side, "what did you say". This does not work
for streaming to multiple user where delivery is important.
My experience with Skype is that the voice quality may be good and can be
bad. I cannot predict what quality I will get when making a call. 

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Alan DeKok
> Sent: Friday, November 12, 2010 10:35 PM
> To: Dean Willis
> Cc: [email-masked]; [email-masked]
> no

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 16 Nov 2010 19:13:58 +0800

> complained about this (i.e., about the media servers).

I sort of fail to understand why a unidrectional stream  needs to be low
latency. neither does you client apparently because in my experience
it's got between 10 seconds an one minute of buffer...

back in the day I choose icecast becasue it seemed about as platform
agnostic as anything got and the mpeg-1 layer-3 encoder provided much
higher tonal and dynamic range than any of these voice optimized codecs
it still does, which is important when you've got a room full of live
microphones and speakers at various distances from the/

Skype ultimately is delivering similar functionality that the webex
conference bridges were delivering when we were experimenting with that.
I do think invidual initiative is the important way that new
technologies come into use.

---

From: Joel Jaeggli <[email-masked]>
Date: Tue, 16 Nov 2010 19:21:41 +0800

> from the RAI area, should be definitely looking after this...

we had one, it was vic/vat/wb rtp-recording and playback etc.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 16 Nov 2010 10:32:46 -0800

> it's got between 10 seconds an one minute of buffer...

Unfortunately, we're not using these as unidirectional streams.

Rather, people are trying to listen in real time with Jabber as the
remote->IETF
channel.

-Ekr

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 16 Nov 2010 19:48:30 +0100

Hi Joel,
> we had one, it was vic/vat/wb rtp-recording and playback etc.

I remember those great tools for the MBone!
Though, I was actually bringing grist to my mill, since I am since long 
proposing in RAI meetings at the IETF the adoption of an open source 
tool we developed while contributing to the Centralized Conferencing 
(XCON) and MEDIACTRL working groups ;-). I will perhaps invite 
interested people to play a bit with it at the next meeting in Prague...

Simon

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Nov 2010 15:15:04 -0500

When you are trying to be interactive, you notice the delay.  A few seconds isn't bad, but several seconds is very noticeable, and minutes is intolerable.

The jabber room is roughly instantaneous.  A decent jabber scribe can deal with issues in the room, but when there is delay, especially minutes of delay, it doesn't work.

You also notice when the jabber chatter for in room people doesn't align with jabber chatter for remote people.

Brian

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 16 Nov 2010 14:49:21 -0600

Hi,

> proposing in RAI meetings at the IETF the adoption of an open source tool 
> we developed while contributing to the Centralized Conferencing (XCON) and 
> MEDIACTRL working groups ;-). I will perhaps invite interested people to 
> play a bit with it at the next meeting in Prague...
>
> Simon

I'm not a genius of conferencing, but if this is the tool that MEDIACTRL 
used in Hiroshima, it was good enough for us to have a remote presenter 
working effectively... I'd encourage people to look at it in Prague, if 
that's an option ...

Spencer

---

From: Ted Lemon <[email-masked]>
Date: Tue, 16 Nov 2010 16:07:36 -0500

> working effectively... I'd encourage people to look at it in Prague, if 

If it's open source, maybe a URL now rather than a presentation later would be the best move.

---

From: Simon Pietro Romano <[email-masked]>
Date: Fri, 26 Nov 2010 17:30:21 +0100

Hi all,

> If it's open source, maybe a URL now rather than a presentation later would be the best move.

here is the requested URL (always Work In Progress...):

http://www.meetecho.com (Click on the English flag for the English 
version of the site...http://www.meetecho.com/index.php?lang=en)

As to the use of the client, you have many options available:

- you can install our java integrated client (Windows, Linux, MAC), 
which supports the whole set of functions (audio, video, slide shows, 
polling, whiteboard, desktop sharing, xmpp chat, file sharing, BFCP 
moderation);

- you can use any standard SIP client as if you were entering a 
traditional conference room (DTMF tones to interact with the BFCP 
server). In this case, you just have audio and video (if the phone is a 
video-enabled one); if you want to have access to the other functions, 
you can use a web client we developed recently (chat, whiteboard, slide 
shows, etc.)

- you can use the mentioned web client to access advanced functions, and 
attach to the IETF mp3 stream, if you are ok with passive audio;

- you can use a mobile phone (android is the most complete by now, but 
we also support Symbian, I-Phone and Blackberry).

- you can access conferences from the PSTN network. In such case, the 
same considerations that I did for SIP phones apply.

Keep in mind that the multimedia flows are all managed through BFCP, so 
a chair can actually play the chair role ;-).

Just drop us an e-mail if you want to give it a try (you'll need an 
account on our servers...). We might even organize an open demo session 
if you see it worth.

Cheers,

Simon