Subject: [91attendees] New draft offers suggestions/guidance for Jabber scribes...

From: Dan York <[email-masked]>
Date: Fri, 7 Nov 2014 16:13:56 +0000

IETF 91 attendees,

If you are going to serve as a "Jabber scribe" in meetings next week at IETF 91 (or wind up being asked to do that), Peter St. Andre and I tried to capture some of the experiences we and others have had as Jabber scribes and advice we've received from others in a new draft:

https://tools.ietf.org/html/draft-saintandre-chatroom-relay-02

Our hope is that this can be helpful to people who might get tasked with performing this role that is so VERY critical for remote attendees.

I'd also encourage folks who haven't considered it to volunteer as jabber scribes.  I do it often because I've been a remote attendee and know how much I came to rely on the scribe relay... and also because it's a great way to learn the names of people involved with a working group and to get involved with helping out with the IETF processes.  (And also quite frankly because it forces me to pay attention to what's happening in the room instead of wandering off into email or something...)

Anyway... the draft is out there and we would welcome any feedback that people have.  If you are doing jabber scribing (or what we called "chatroom relay" to be product-neutral) next week at IETF 91 and come up with any additional tips or tricks, please do let us know.  The goal is to help provide suggestions that can make this role work smoother and easier and through that to help improve the experience for remote attendees.

Dan

---

From: Alexandre Petrescu <[email-masked]>
Date: Fri, 07 Nov 2014 18:36:02 +0100

In the additional tasks section... "measure the delay between when 
something is said in the physical room and when heard on audio stream - 
tell the delay to the remote partipants".

Alex

Le 07/11/2014 17:13, Dan York a écrit :
> IETF 91 attendees,
>
> If you are going to serve as a "Jabber scribe" in meetings next week at
> IETF 91 (or wind up being asked to do that), Peter St. Andre and I tried
> to capture some of the experiences we and others have had as Jabber
> scribes and advice we've received from others in a new draft:
>
> Our hope is that this can be helpful to people who might get tasked with
> performing this role that is so VERY critical for remote attendees.
>
> I'd also encourage folks who haven't considered it to volunteer as
> jabber scribes.  I do it often because I've been a remote attendee and
> know how much I came to rely on the scribe relay... and also because
> it's a great way to learn the names of people involved with a working
> group and to get involved with helping out with the IETF processes.
>   (And also quite frankly because it forces me to pay attention to
> what's happening in the room instead of wandering off into email or
> something...)
>
> Anyway... the draft is out there and we would welcome any feedback that
> people have.  If you are doing jabber scribing (or what we called
> "chatroom relay" to be product-neutral) next week at IETF 91 and come up
> with any additional tips or tricks, please do let us know.  The goal is
> to help provide suggestions that can make this role work smoother and
> easier and through that to help improve the experience for remote attendees.
>
> Dan
>
>
> _______________________________________________
> 91attendees mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/91attendees
>

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 7 Nov 2014 15:04:39 -0500

> On Nov 7, 2014, at 12:36 PM, Alexandre Petrescu <[email-masked]> wrote:
> 
> In the additional tasks section... "measure the delay between when something is said in the physical room and when heard on audio stream - tell the delay to the remote partipants".
> 
> Alex

Since the audio stream is first relayed to some servers on the west coast of the US and then exploded to participants around the world, I'm not sure what you're measuring and what it would mean to the various participants.

Care to explain more?

Thanks,
Tom

---

From: Tom Pusateri <[email-masked]>
Date: Fri, 7 Nov 2014 15:27:10 -0500

> On Nov 7, 2014, at 11:13 AM, Dan York <[email-masked]> wrote:
> 
> IETF 91 attendees,
> 
> https://tools.ietf.org/html/draft-saintandre-chatroom-relay-02 <https://tools.ietf.org/html/draft-saintandre-chatroom-relay-02>
> 
> ...

I have been searching for a way to synchronize the slides with the audio for a better playback experience after the session. A few releases ago, I started parsing the jabber logs and displaying them time synchronized with the audio playback. This is a good start but you still have to page through the slides manually. At least now, you get some hints as to when to advance if someone or Meetecho puts the slide number or title in the jabber chatroom.

But the format of the slide info varies from jabber session to session and the slide filename isn’t always apparent so it is difficult to automate this.

Adobe suggested a URL format to reference a file and page number here: http://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html <http://helpx.adobe.com/acrobat/kb/link-html-pdf-page-acrobat.html>
Example: <A HREF="http://www.example.com/myfile.pdf#page=4”>

This would make the jabber logs machine parseable if the format was consistently followed. But the Meetecho guys said they tried URLs in the jabber sessions and got complaints about the links from remote participants and so they stopped.

Maybe we need a machine parseable chatroom and one for human consumption.

And defining a format isn’t enough to track the actual slide changes. That still has to be done manually. But if we could get events from Powerpoint, Keynote, or Adobe Reader, maybe we could automate that too and have the presenter’s machine send the jabber messages as the slides change.

I’m willing to work on this but I need some help from people knowledgable about the hooks in these tools. Anyone from Adobe, Apple, & Microsoft want to help? Anyone else have some good ideas to make this better?

Thanks,
Tom

---

From: joel jaeggli <[email-masked]>
Date: Fri, 07 Nov 2014 16:20:30 -0800

On 11/7/14 9:36 AM, Alexandre Petrescu wrote:
> something is said in the physical room and when heard on audio
> stream - tell the delay to the remote partipants".

The largest source of delay in the mp3 audio stream is  accumulated in
the buffer in the recieving application, even if they begin playing
immediately they play around with the gap between samples to
accumulate enough buffer to support retransmission and gapless
playback. you can put two clients right next to each other and they
will have differing playout delays.

That said I believe the goal this meeting is to substantially
emphasize meetecho with it's new codecs (and which has fully meeting
coverage this time) and which by design is intended minimize playout
delay.

>> If you are going to serve as a "Jabber scribe" in meetings next
>> week at IETF 91 (or wind up being asked to do that), Peter St.
>> Andre and I tried to capture some of the experiences we and
>> others have had as Jabber scribes and advice we've received from
>> others in a new draft:
>> 
>> Our hope is that this can be helpful to people who might get
>> tasked with performing this role that is so VERY critical for
>> remote attendees.
>> 
>> I'd also encourage folks who haven't considered it to volunteer
>> as jabber scribes.  I do it often because I've been a remote
>> attendee and know how much I came to rely on the scribe relay...
>> and also because it's a great way to learn the names of people
>> involved with a working group and to get involved with helping
>> out with the IETF processes. (And also quite frankly because it
>> forces me to pay attention to what's happening in the room
>> instead of wandering off into email or something...)
>> 
>> Anyway... the draft is out there and we would welcome any
>> feedback that people have.  If you are doing jabber scribing (or
>> what we called "chatroom relay" to be product-neutral) next week
>> at IETF 91 and come up with any additional tips or tricks, please
>> do let us know.  The goal is to help provide suggestions that can
>> make this role work smoother and easier and through that to help
>> improve the experience for remote attendees.
>> 
>> Dan
>> 
>> 
>> _______________________________________________ 91attendees
>> mailing list [email-masked] 
> _______________________________________________ 91attendees mailing
> list [email-masked]

---

From: Jeff Haas <[email-masked]>
Date: Sat, 8 Nov 2014 19:34:32 -0500

> will have differing playout delays.

When people are following good microphone protocol and we're not having technical issues, the incoming audio tends to be fine - if delayed.  The bigger issue is we need a better way to get comments *out*.

Watching some of the older techs for voice messaging or even some of the newer ones, e.g. the Apple IOS one, I sometimes wonder if the better answer is to allow something similar for remote participation.  The latency on such things vs. in-room respondents is the biggest challenge as you have to both accommodate and to moderate the time-delayed relays.

(Perhaps known as "how do you let residents of another in-system planet participate in the session...)

-- Jeff