Subject: [vmeet] Voice-to-room: lessons learned so far

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 02 Apr 2012 10:38:17 +0200

Dear all,

with respect to the issue of allowing remote participants to 'inject' 
their own voice in a WG session in real-time, I would like to share with 
all of you a couple of considerations.
First, I do think this represents a fundamental requirement for the 
IETF, with IM-to-mike relaying being just a backup solution. This said, 
I also recognize that bidirectional audio can be definitely tricky. With 
Meetecho, we have had some experience related to this at the last two 
meetings. I'll try to sketch a sort of taxonomy of the two main remote 
interaction flavors below.

1. Bidirectional audio through the combination of two monodirectional 
streams

In Taipei, we had a couple of sessions where remote presenters used the 
Meetecho RTSP stream to listen to the room, while exploiting a different 
tool (e.g., skype or gTalk) to send their own audio. An example of this 
approach can be found in EKR's RTCWEB presentation 
(http://77.238.22.57/Recordings/watch.jsp?recording=rtcweb_II_session_IETF82&chapter=part_1). 

Pros of the approach:
- no echo at all;
- good overall quality.

Cons of the approach:

- just one remote at a time can contribute audio to the room, unless you 
let all remotes participate (while listening to the RTSP stream) in a 
dedicated, parallel, session whose audio is injected into the IETF room.

2. Bidirectional audio through Meetecho

We had some 'experimental' sessions where Meetecho was configured in 
such a way as to provide bidirectional audio, with one or more remotes 
entering the IETF meeting room and contributing to the session with 
their own voice. With this setup we had some exciting and a number of 
discouraging results.
A good example of the first category is represented by the DRINKS 
session we had in Taipei (see, e.g., 
http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=drinks_IETF82&chapter=part_2, 
Ken Cartwright's intervention).
On the other hand, we can cite:
- the DCON BoF in Taipei 
(http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=dcon_bof&chapter=part_1), 
where we made a complete mess with the audio configuration in the room, 
hence generating a horrible echo effect (instead of relying on a single 
audio streaming computer, we had two laptops in the room, one for audio 
in and the other for audio out);
- the DRINKS session in Paris (recordings will be available today @ 
http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions), where we 
had a very law quality for audio (both in and out), due to the following 
factors: (i) a poor (and overloaded) wireless connection used for the 
streaming laptop; (ii) an off-the-cuff setup for all what concerns audio 
equipment (DRINKS met in room 212-213, which was not equipped with the 
professional stuff available in the other rooms).

In general, in Paris we had issues with hardware (i.e., mixer-enabled) 
echo cancellation, as witnessed by the first RTCWEB session 
(http://recordings.conf.meetecho.com/Recordings/watch.jsp?recording=RTCWEB_II_IETF83&chapter=part_3): 
if you seek minute 31:26 in the mentioned recording, you will notice 
that Randell Jesup's intervention (whose quality in the room was really 
good and had no echo at all)  is affected by echo (as perceived by all 
remote participants). This clearly indicates that the mixer is not 
performing the required 'n-1' composition of the incoming feeds (i.e., 
is not suppressing echo).

In summary, I think that if we want to provide bidirectional audio with 
acceptable quality, a number of requirements have to be met:

a) Need to connect a single 'audio streaming computer' to the room 
mixer: output from the mixer goes to the mic of the PC; output from the 
PC  (i.e., its speakers) goes in input to the room mixer;
b) Need to make a reliable (i.e., wired) connection available in the 
room for the audio streaming computer;
c) Need to have the room mixer implement hardware echo cancellation;
d) Need to have professional audio equipment inside the room.

If all of the above is in place, other requirements apply to the remote 
participants:

e) need to wear a headset if you are using a PC and want to send your 
audio to the room;
f) need to avoid using 'live voice' functionality if you are using a phone;
g) need to have a reliable connection if using a mobile phone while 
participating in the conference.

Hope this can help foster discussion on the RPS document.

Cheers,

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: SM <[email-masked]>
Date: Tue, 03 Apr 2012 01:41:58 -0700

Hi Simon,
At 01:38 02-04-2012, Simon Pietro Romano wrote:
>http://ietf83.conf.meetecho.com/index.php/Recorded_Sessions), where 
>we had a very law quality for audio (both in and out), due to the 
>following factors: (i) a poor (and overloaded) wireless connection 
>used for the streaming laptop; (ii) an off-the-cuff setup

Was a wired connection requested before the meeting?

Regards,
-sm

---

From: Simon Pietro Romano <[email-masked]>
Date: Tue, 03 Apr 2012 15:09:36 +0200

Hi SM,

of course it was. I have to say that the NOC did its best to provide us 
with a wired connection for the audio streaming nodes, but in some cases 
we were not able to solve this issue in due time.

Cheers,

Simon