Subject: Remote participation

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Nov 2015 07:01:21 -0000

If we are serious about this, we need some kind of test tool so that speakers
can know that they can connect and have reasonable service before their agenda
slot.

Adrian

---

From: Lou Berger <[email-masked]>
Date: Mon, 02 Nov 2015 16:13:51 +0900

I asked the meetecho folks about the presentation that we both saw fail and 
they said they saw the same issues during a test with the presentor.

Perhaps we also need a high loss tollerant codec available for such cases.  
Of course the added latency is likely to make interaction cumbersome,  but 
better than the complete failure we both witnessed -- where apparently the 
presentor was told it wasn't join to work, but only had the option of 
hoping his access link would (magically) improve. ..

Lou

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 2 Nov 2015 07:17:46 -0000

Oh OK.
So there is a test for quality in advance, and if you fail the test you go right
ahead and present anyway?

Is that possibly broken?

---

From: joel jaeggli <[email-masked]>
Date: Mon, 2 Nov 2015 16:22:52 +0900

> ahead and present anyway?

positive action would be required on the part of the remote participant
if the connectivity is an issue on that end.

there is certianly potent for problems with the IETF network last mile
but we're doing ok right now.

---

From: Lou Berger <[email-masked]>
Date: Mon, 02 Nov 2015 16:30:49 +0900

> ahead and present anyway?

Yes, at least that is my understanding of what happened in this case.

> Is that possibly broken?

Not broken strictly speaking,  but it is a limitation or new requirement 
depending on how you look at it.

Lou

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 2 Nov 2015 08:58:49 +0100

Hi,

let me chime in on this. I’m copy-pasting below the “standard” message we send to each potential remote presenter:

> Dear $PRESENTER,
> you're getting this mail as the chairs indicated you will be presenting
> remotely via Meetecho in $WG on $DAY. Please read the guidelines
> provided here, as they provide instructions on how to proceed in order
> to present remotely:
> 
> http://$SERVER.conf.meetecho.com/index.php/Remote_Participation <http://$SERVER.conf.meetecho.com/index.php/Remote_Participation>
> 
> That said, the first thing to do is check whether or not WebRTC will
> work for you, as it is mandatory for presenting remotely. We developed
> a simple web page you can use to test this:
> 
> 	http://$SERVER.conf.meetecho.com/self-test/ <http://$SERVER.conf.meetecho.com/self-test/>
> 
> so please use it and let us know about the results. 
> 
> You'll need a WebRTC compliant browser like Chrome or Firefox. It will
> start an echo test that will try and capture your audio and video and
> bounce them back to you: if you can see yourself in both boxes and hear
> you back, it means that everything's fine. If not, please let us know
> in advance, as fixing things during the session could disrupt the
> natural flow of the meeting.
> 
> Please try this from where you'll do your presentation, and not from
> somewhere else: e.g., if you're going to present from the office, don't
> test at home, as network constraints may be different.
> 
> Please also remember to wear a headset, both during this test and when
> presenting, to make sure there won't be any noise or echo when you
> present remotely. Besides, it will make the test much easier as you'll
> be immediately aware of the remote audio.
> 
> Let us know if you encounter any issue with this. See you online!

As you can see, we provide prospective presenters with a self-test facility which should allow them to properly check
whether or not they are in the right condition to make a remote presentation. This almost always works, as witnessed by the
5 presentations (plus 4 “injections” from the virtual queue) we had so far and which worked like a charm.
If you are referring, as I can figure out, to today’s CCAMP session, this was an unlucky case.
The remote presenter had made the test and he had indeed reported that he could not make any video (from his work location),
whereas he could do “good enough” audio, due to a slow (and firewalled) network connection.
My personal feeling is that we should avoid this kind of situations and perhaps ask the presenters to either find a better connection or
delegate some of the local participants, or simply throw in the towel. Though, I don’t think we (i.e., the Meetecho team) can take on the responsibility 
for this choice. That’s why we always keep WG chairs in the loop for all our e-mail exchanges with prospective remotees. 
If you believe we should adopt a different policy, just let us know. We’re obviously open to discussion and ready to take your savvy advice.

Thanks for your feedback!

Simon

> On 02/nov/2015, at 08:30, Lou Berger <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> 
> On November 2, 2015 4:18:15 PM "Adrian Farrel" <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> Oh OK.
> Not broken strictly speaking,  but it is a limitation or new requirement depending on how you look at it.
> 
> Lou
> 

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked] <mailto:[email-masked]>

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 02 Nov 2015 18:44:42 +0900

Simon Pietro Romano <[email-masked]> wrote:
    > this was an unlucky case.  The remote presenter had made the test and
    > he had indeed reported that he could not make any video (from his work
    > location), whereas he could do “good enough” audio, due to a slow (and
    > firewalled) network connection.  My personal feeling is that we should
    > avoid this kind of situations and perhaps ask the presenters to either
    > find a better connection or delegate some of the local participants, or
    > simply throw in the towel. Though, I don’t think we (i.e., the Meetecho

I agree: especially when the issue is a firewall outside of the presenter's
control, the presenter should be told to move somewhere else.

Further: could the echo test produce a log of ports
         attempted/succeeded/failed, and errors (ICMPs/etc) received?
It would be nice if we could make it easier to report the issue to "IT",
as presumably people are doing this kind of thing with the blessing of their
employer, and so they should get supported.

It also seems that the decision to present remotely, and not to travel is
usually made 2-3 months in advance, and so really there is no excuse to not
having things working in that amount of time.

(Of course, there are exceptions where people are unable to travel due to
last minute issues) 

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Yoav Nir <[email-masked]>
Date: Mon, 2 Nov 2015 18:48:05 +0900

> On 2 Nov 2015, at 6:44 PM, Michael Richardson <[email-masked]> wrote:
> 

There are also last-minute decisions to present where somebody who *was* supposed to be at the meeting was supposed to present, but in the end didn’t make it to the meeting.

---

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 2 Nov 2015 11:11:22 +0100

+1 to all of Michael’s considerations.

Simon

> On 02/nov/2015, at 10:44, Michael Richardson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> Simon Pietro Romano <[email-masked] <mailto:[email-masked]>> wrote:
> Michael Richardson <[email-masked] <mailto:[email-masked]>>, Sandelman Software Works

                     					       _\\|//_
                           				      ( O-O )

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 07:07:40 -0500

Hi.  Without knowing what happened today, but having done remote
presentations a few comments:

--On Monday, November 02, 2015 08:58 +0100 Simon Pietro Romano
<[email-masked]> wrote:

>...
> let me chime in on this. I'm copy-pasting below the
> "standard" message we send to each potential remote
> presenter:

That setup, and the test tools, have gotten much better since I
started using Meetecho.  While there is always room for
improvement, I think they are more than adequate by now.

>...
> As you can see, we provide prospective presenters with a
> self-test facility which should allow them to properly check
> whether or not they are in the right condition to make a
> remote presentation. This almost always works, as witnessed by
> the 5 presentations (plus 4 "injections" from the virtual
> queue) we had so far and which worked like a charm. If you are
> referring, as I can figure out, to today's CCAMP session,
> this was an unlucky case. The remote presenter had made the
> test and he had indeed reported that he could not make any
> video (from his work location), whereas he could do "good
> enough" audio, due to a slow (and firewalled) network
> connection. My personal feeling is that we should avoid this
> kind of situations and perhaps ask the presenters to either
> find a better connection or delegate some of the local
> participants, or simply throw in the towel.

With two exceptions, I think that is just right.  If the
presenter does not get good test results, he or she should
either find a location from which good test results are
possible, get their "normal" location fixed (it is sometimes
possible to open corporate firewalls for a single desktop or
address if the company feels cooperative), or make a plan that
doesn't involve remote presentations.   However, two suggestions
(neither specific to Meetecho)

(i) No WG should ever allow a presentation that depends on
remote access unless there is a clear fallback plan, presumably
in the form of either prerecorded video or audio that is
available on-site (and a setup for running it) or someone in the
room who is prepared to talk through the slides or presentation
materials.  Stuff happens and, although it has been a long time
since an IETF network suffered an extended LAN or WAN outage, we
can't say "impossible".

(ii) Pre-meeting testing for intended remote presenters should
be mandatory, not discretionary with the would-be presenter, and
results reported to WG chairs, not just that presenter.  The
decision to put a presentation on the agenda belongs to the
chair(s) (subject to appeal, etc.) and they are at least
partially accountable if such a presentation doesn't come off,
so they are entitled to full information.  And, if a presenter's
setup doesn't test well, the chair(s) should be at least as
responsible for being sure other arrangements are in place (if
necessary taking the presentation off the agenda) as the
presenter.

In case it isn't clear, if I've correctly understood this
particular situation from the collection of messages, blaming
the Meetecho folks is neither appropriate nor useful: if there
is blame to be cast, this was fairly clearly a presenter and/or
chair problem.   Almost exactly the same comment would apply to
Meetecho responsibility for a network outage or degraded
performance at the IETF end.   I hope that, rather than casting
blame, we can learn to remember that infallible technology is
rare, that ours is no exception, and that having fallback plans
in place is a necessity.

     john

p.s. It seems that one of the presumably unanticipated
side-effects of the new ART (ex-Apps) schedule is that Simon and
his colleagues don't get to hear my complaining in the first
Monday session :-)

 Though, I don't
> think we (i.e., the Meetecho team) can take on the
> responsibility  for this choice. That's why we always keep
> WG chairs in the loop for all our e-mail exchanges with
> prospective remotees.  If you believe we should adopt a
> different policy, just let us know. We're obviously open to
> discussion and ready to take your savvy advice.

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 2 Nov 2015 13:21:22 +0100

One thought:

In several countries, 4G mobile phones (including in "tethered hotspot"
mode) give adequate bandwidth for a WebRTC call.

If the corporate firewall can't be bothered to behave decently, the
answer may be to .... pick up the phone.

-- 
Surveillance is pervasive. Go Dark.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 2 Nov 2015 13:51:48 +0000

FWIW - we had an excellent experience today in the LMAP session with Juergen Schoenwaelder presenting remotely and interacting in real time with the attendees in the meeting room in Yokohama. Meetecho worked perfectly. 

Regards,

Dan

> -----Original Message-----
> From: ietf [mailto:[email-masked]] On Behalf Of Harald Alvestrand
> Sent: Monday, November 02, 2015 2:21 PM
> To: [email-masked]
> Subject: Re: Remote participation
> 
>  One thought:
> 
> If the corporate firewall can't be bothered to behave decently, the answer
> may be to .... pick up the phone.
> 
> > I agree: especially when the issue is a firewall outside of the
> > presenter's control, the presenter should be told to move somewhere
> else.
> >
> > It would be nice if we could make it easier to report the issue to
> > "IT", as presumably people are doing this kind of thing with the
> > blessing of their employer, and so they should get supported.
> >
> > It also seems that the decision to present remotely, and not to travel
> > is usually made 2-3 months in advance, and so really there is no
> > excuse to not having things working in that amount of time.
> >
> > (Of course, there are exceptions where people are unable to travel due
> > to last minute issues)
> >
> >
> 
> 
> --

---

From: Kathleen Moriarty <[email-masked]>
Date: Mon, 2 Nov 2015 10:08:45 -0500

MILE had a good experience with a remote presentation as well.  I have also been remote for several sessions and the quality has been very good.  It seems I can hear the speakers in the room when the folks in the room are having trouble.

Best regards,
Kathleen 

Sent from my iPhone

> On Nov 2, 2015, at 8:51 AM, Romascanu, Dan (Dan) <[email-masked]> wrote:
>

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 3 Nov 2015 08:35:29 +1300

> answer may be to .... pick up the phone.

Harald is onto something. But the real point is to test in advance and if
it doesn't work, find a work-around.

I hate to suggest more work for our Meetecho friends, but maybe the testing
needs to be a bit more organised and 24 hours in advance (or maybe 12 hours
in advance for Monday sessions). And if it fails, no compromise: don't try.

BTW, it seemed to work nicely yesterday between Auckland and Yokohama.

   Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 02 Nov 2015 17:20:12 -0500

--On Tuesday, November 03, 2015 08:35 +1300 Brian E Carpenter
<[email-masked]> wrote:

>> If the corporate firewall can't be bothered to behave
>> decently, the answer may be to .... pick up the phone.
> 
> Harald is onto something. But the real point is to test in
> advance and if it doesn't work, find a work-around.

And then test the workaround and, if that doesn't work, try
something else or give up.

> I hate to suggest more work for our Meetecho friends, but
> maybe the testing needs to be a bit more organised and 24
> hours in advance (or maybe 12 hours in advance for Monday
> sessions). And if it fails, no compromise: don't try.

Given my limited understanding of TCP/IP, there are three
possible areas of problems that would affect some remote users
and not others:

(i) Close to the user site, i.e., between the user's location
and the Internet.

(ii) Close to the IETF site, i.e., in the connectivity between
the IETF LAN(s) and the WAN connection(s)

(iii) Routing or source-related filtering problems across the
Internet (and past any user-site-associated firewalls or other
filters) and the IETF site.

If Meetecho isn't working (at all or on the IETF LAN), that is a
different problem and would affect everyone, as would the IETF
network being down or completely disconnected.

Now, at least in my experience, the first of these is by far the
most likely.  To the extent that it is application-specific, it
should be possible to test to Italy, California, or any other
convenient location and to do so weeks in advance -- early
enough to affect WG agendas without a meeting week fire drill.
The second should require fairly easy tests as soon as the IETF
network come up and should be easy to perform because they are
not participant-specific.   For the third, some of the possible
issues will not exist as long as we are consistent about
requiring a non-filtered environment as the price of selecting a
site.  For the rest --an actual network or routing outage
somewhere "in the middle", -- advanced testing won't help.   

So, while I'd be happier with confirmation between participant
location and the actual meeting Meetecho setup 12 or 24 hours in
advance, I think the vast majority of cases --especially those
for which "restrictive corporate firewall" is a special case--
can be checked out a week, or even a month, in advance and
should be.

    john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Tue, 3 Nov 2015 09:46:12 +0900

On Tue, Nov 3, 2015 at 12:08 AM, Kathleen Moriarty <
[email-masked]> wrote:
>
> t seems I can hear the speakers in the room when the folks in the room
are having trouble.

It's only Tuesday, but I'm onsite, and this is what I'm seeing. I was
sitting in a meeting yesterday (probably RMCAT) and there were several
soft-spoken folk in a row at the mike. I wasn't hearing well, so wondered
if the speakers were too far from the mike, and checked in Jabber. The
answer I got back was that the remote participants weren't having any
trouble at all.

I may try earbuds for Meetecho in the room today, and see how badly that
works!

Spencer

---

From: Kathleen Moriarty <[email-masked]>
Date: Tue, 3 Nov 2015 04:45:41 -0500

After all of the good sessions, we just had a problem with meetecho in
SACM.  The jabber room stopped working.  The streaming video
continued, but remote participants couldn't enter something to be said
at the Mic:

-Kathleen

On Mon, Nov 2, 2015 at 7:46 PM, Spencer Dawkins at IETF
<[email-masked]> wrote:
>
> On Tue, Nov 3, 2015 at 12:08 AM, Kathleen Moriarty
> <[email-masked]> wrote:
>>
>> t seems I can hear the speakers in the room when the folks in the room are
>> having trouble.
>
> soft-spoken folk in a row at the mike. I wasn't hearing well, so wondered if
> the speakers were too far from the mike, and checked in Jabber. The answer I
> got back was that the remote participants weren't having any trouble at all.
>

-- 

Best regards,
Kathleen

---

From: Vinayak Hegde <[email-masked]>
Date: Tue, 3 Nov 2015 16:14:06 +0530

I (and another draft author) just did a remote presentation at IPPM
WG. It worked fairly well.

- We did have a little bit of problem working with Firefox (meetecho
slides stopped in between) when listening to other presenters.

- Experience on Chrome was great. We were able to interact with each
other and even hum

- We could interact with the room (see and talk to them) and answer
questions. We could interact with the chair and ask him to advance the
slides (something meetecho can possibly improve - give control of
slides to the remote speaker)

- There were a few glitches with the audio/video intermittently but
the overall experience was much better than we thought it would be.

Thanks
Vinayak

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 3 Nov 2015 09:07:17 -0500

> On Nov 2, 2015, at 2:17 AM, Adrian Farrel <[email-masked]> wrote:
> 
> Oh OK.

Im planning to do a remote presentation. The test tool give a me a positive results. 
There is a backup plan in place that if the connection fails or I’m not available someone else will 
present. 

I think this is the minimum standard remote presenters should have. 
Similarly presenters should run the test tool just before the WG meeting to see the current network 
situation. 

I think this should be the minimum standard for remote presenters, "plan ahead”

Olafur

---

From: Dave Crocker <[email-masked]>
Date: Tue, 3 Nov 2015 09:10:08 -0800

On 11/3/2015 6:07 AM, Olafur Gudmundsson wrote:
> Similarly presenters should run the test tool just before the WG mee

Folks have been citing a constellation of details to arrange, along
these lines.  All sounds quite reasonable.  And quite necessary.

At this point, it's probably worth producing a semi-standardized
operational checklist document for presenters and session chairs to use,
to set all this up in a routinized way.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Ross Callon <[email-masked]>
Date: Tue, 3 Nov 2015 18:41:10 +0000

I had a similar event yesterday but from the other side. I was listening in (from North America) using Meetecho and could hear very well without any problem. One of the things that I heard clearly was someone in the room in Yokohama complaining that the speaker wasn’t close enough to the mic.

Ross

From: ietf [mailto:[email-masked]] On Behalf Of Spencer Dawkins at IETF
Sent: Monday, November 02, 2015 7:46 PM
To: Kathleen Moriarty
Cc: Romascanu, Dan (Dan); [email-masked]; Harald Tveit Alvestrand
Subject: Re: Remote participation

On Tue, Nov 3, 2015 at 12:08 AM, Kathleen Moriarty <[email-masked]<mailto:[email-masked]>> wrote:
>
> t seems I can hear the speakers in the room when the folks in the room are having trouble.

It's only Tuesday, but I'm onsite, and this is what I'm seeing. I was sitting in a meeting yesterday (probably RMCAT) and there were several soft-spoken folk in a row at the mike. I wasn't hearing well, so wondered if the speakers were too far from the mike, and checked in Jabber. The answer I got back was that the remote participants weren't having any trouble at all.

I may try earbuds for Meetecho in the room today, and see how badly that works!

Spencer

---

From: Mark Andrews <[email-masked]>
Date: Wed, 04 Nov 2015 07:23:14 +1100

In message <[email-masked]
look.com>, Ross Callon writes:
> I had a similar event yesterday but from the other side. I was listening
> in (from North America) using Meetecho and could hear very well without
> any problem. One of the things that I heard clearly was someone in the
> room in Yokohama complaining that the speaker wasnt close enough to the
> mic.

Or too close to the mic.  This thing however gets better with practice.

The meetecho folks have been good at responding to issues.  A simple
meetecho + issue / advice in the chat window works.

The remote queue worked fine as does the old "mic: comment" with a good
jabber scribe.

Mark

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]