Subject: [vmeet] Meetecho sessions start/stop time

From: Meetecho IETF support <[email-masked]>
Date: Sun, 10 Apr 2016 19:33:16 +0200

Folks,

just to clarify that Meetecho sessions do start 5 minutes before the WG 
meeting scheduled start time, and never stops before the meeting has 
actually finished.

Only when the previous meeting runs *very* long, we have to shift the 
start time of the following Meetecho session. This is needed in order to 
avoid overlaps in the recordings. This was the case of the 6LO session 
on Thursday, which started at 17.30 sharp because the MTGVENUE session 
ended at 17.30.

Cheers,
the Meetecho team

---

From: John C Klensin <[email-masked]>
Date: Sun, 10 Apr 2016 14:04:54 -0400

--On Sunday, April 10, 2016 19:33 +0200 Meetecho IETF support
<[email-masked]> wrote:

> Folks,
> 
> just to clarify that Meetecho sessions do start 5 minutes
> before the WG meeting scheduled start time, and never stops
> before the meeting has actually finished.
> 
> Only when the previous meeting runs *very* long, we have to
> shift the start time of the following Meetecho session. This
> is needed in order to avoid overlaps in the recordings. This
> was the case of the 6LO session on Thursday, which started at
> 17.30 sharp because the MTGVENUE session ended at 17.30.

Understood, but I encountered another problem that you might
want to think about.  There were a couple of times when I was
typing something into Jabber (via Meetecho) when the session
ended.  That resulted in the screen, and Jabber session,
abruptly clearing, so I couldn't finish the message for the
Jabber log, copy the partially-finished one so I could later
send something similar in email, or otherwise salvage what had
been typed already.  I don't have suggestions other than maybe
keeping the Jabber window/link open for several minutes after
the meeting ends and/or putting up an "about to go down, save
work if you want it" warning with a bit of delay, or something
of that nature.  I'd simply run a session with a separate Jabber
client, but that introduces some extra synchronization problems.

    john

---

From: Dave Crocker <[email-masked]>
Date: Sun, 10 Apr 2016 11:43:10 -0700

On 4/10/2016 11:04 AM, John C Klensin wrote:
> There were a couple of times when I was
> been typed already.

IETF Meeting Jabber sessions, outside of Meetecho, are long-lived.  So 
the problem being described is quite basic.

Unfortunately the only reasonable solution is to permit continued use of 
jabber, but possibly better to permit a "session not active" form of 
session participation (both before and after the session) with use of 
jabber.

This could have a number of benefits, for preparation, coordination and 
-- in the current example -- finishing one's thoughts.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 10 Apr 2016 16:10:38 -0400

> on Thursday, which started at 17.30 sharp because the MTGVENUE session

I realize the audio/video feeds from the room are a resource that 
perhaps can only be attached to one meeting session at a time. But 
couldn't that be separated from everything else. So the prior session 
and the following session could still be open concurrently, with their 
own participants, with the audio/video feeds being removed from one and 
attached to the other at a time determined on the fly?

	Thanks,
	Paul

---

From: Meetecho IETF support <[email-masked]>
Date: Mon, 11 Apr 2016 10:29:06 +0200

> client, but that introduces some extra synchronization problems.

Good point. A "one minute to disconnection" warning would be trivial to 
add. We'll introduce it in the next version.

Thanks,
the Meetecho team

---

From: Dan York <[email-masked]>
Date: Mon, 11 Apr 2016 09:44:11 +0000

John,

While I think the "one minute to disconnection" warning the Meetecho team just suggested is a great addition...

On Apr 10, 2016, at 2:04 PM, John C Klensin <[email-masked]<mailto:[email-masked]>> wrote:

I'd simply run a session with a separate Jabber
client, but that introduces some extra synchronization problems.

... I've alway run a separate Jabber client connected into each working group chat when remote.

I've done this for a couple of reasons:

1. In the past, I had occasions when the Meetecho client would freeze or otherwise require me to disconnect and restart the session;

2. I've had issues where my browser crashed because of some other site... but in doing so it took down the Meetecho session; and

3. I've had a number of cases where I wanted to go back and get something out of a chat and I knew from experience that when Meetecho ended you had to get the chat from the chat logs... which was another place to go.

Typically, I've often been monitoring several sessions simultaneously through Jabber chat rooms, and so I'm already running a separate Jabber client.  My usual process has been to have one Meetecho session up with the main group I'm interested in, and then separate Jabber chat windows for the other sessions.  So it's no big deal for me to also have a Jabber chat room for the working group that I'm also in via Meetecho.

It does mean I'm in that room twice via two different clients, but that is what has worked for me.

Dan

--
Dan York
Senior Content Strategist, Internet Society
[email-masked]<mailto:[email-masked]>   +1-802-735-1624
Jabber: [email-masked]<mailto:[email-masked]>
Skype: danyork   http://twitter.com/danyork

http://www.internetsociety.org/

---

From: Dave Crocker <[email-masked]>
Date: Mon, 11 Apr 2016 08:00:24 -0700

> ... I've alway run a separate Jabber client connected into each working

That's a useful hack, but it's a hack.  Helpful now, but should not be 
necessary, IMO.

Meetecho's software needs to be much more reliable.  This marks its 
(well-deserved) transition to being an essential infrastructure 
capability for the IETF.

I think the session start/stop issue actually requires a change in the 
model for operating Meetecho.  One thought is to make a 'session' needs 
be much longer-lived -- in some cases, even persistent -- and able to 
proceed only with a jabber session.  It can then add and remove audio 
and video as needed.

d/
-- 

   Dave Crocker