Re: [Standards] Fwd: Radical Solution for remote participants

[Dave Cridland]

On 19 Aug 2013 23:15, "Peter Saint-Andre"  wrote:
>
> I'm waiting for the IETF discussion to yield clear and stable
> requirements before I start to design any XMPP extensions. :-)
>

Sure, I'm just curious about how much we do already.

By the way, you sound amazingly optimistic that the discussion will yield
requirements at all, let alone stable and clear ones...

> On 8/13/13 1:31 AM, Dave Cridland wrote:
> > How much of this stuff can we do already? I know that much of (6) has
> > been implemented in military clients, and I suspect (2) is an
> > application of Jingle. (7) smells like a BOSH app, or some kind of a bot
> > with a web UI.
> >
> > -- Forwarded message --
> > From: *Douglas Otis* >
> > Date: Tue, Aug 13, 2013 at 2:00 AM
> > Subject: Radical Solution for remote participants
> > To: John Leslie mailto:j...@jlc.net>>
> > Cc: IETF Discussion Mailing List mailto:i...@ietf.org>>
> >
> >
> >
> > On Aug 12, 2013, at 1:06 PM, John Leslie  > > wrote:
> >
> >> Janet P Gunn mailto:jgu...@csc.com>> wrote:
> >>>
>  Again, it strengthens the case to get it done right. This part has
been
>  working well though.
> >>>
> >>> Not necessarily.  There was one WG where I had to send an email to
the WG
> >>> mailing list asking for someone to provide slide numbers on jabber.
> >>
> >>   ... and Janet was merely the one who _did_ so. Others did their best
> >> to guess at the slide numbers.
> >>
> >>   At least one-third of the sessions I listened to failed to provide
> >> all we are told to expect in the way of jabber support. :^(
> >>
> >>   OTOH, we _do_ get what we pay for; so I don't mean to complain.
> >
> > Dear John,
> >
> > You are right about getting your money's worth.  In the case of remote
> > participants, they are charged nothing and receive no credit for having
> > done so.  Often their input is ignored as well.
> >
> > A radical solution for meaningful remote participation is to change how
> > A/V in meeting rooms operate.  This change will require a small amount
> > of additional equipment and slightly different room configurations.
> >
> > 1) Ensure exact digital interfaces driving projectors are fully
> > available remotely.
> >
> > 2) Ensure Audio access requires an identified request via XMPP prior to
> > enabling either a remote or local audio feed.
> >
> > 3) RFI tags could facilitate enabling local audio feed instead of an
> > identified request via XMPP.
> >
> > 4) In the event of the local venue loosing Internet access, the device
> > regulating A/V presentations must be able to operate in a virtual mode
> > where only remote participants are permitted to continue the meeting
> > proceedings.
> >
> > 5) Important participants should plan for alternative modes of Internet
> > access to remain part of the proceedings.
> >
> > 6) Develop a simple syntax used on XMPP sessions to:
> >  1) signify a request to speak on X
> >  2) withdraw a request to speak on X
> >  3) signify support of Y
> >  4) signify non-support of Y
> >  5) signal when a request has been granted or revoked.  For local
> > participants this could be in the form of a red or green light at their
> > microphone.
> >
> > 7) Develop a control panel managed by chairs or their proxies that
> > consolidate and sequence requests and log support and nonsupport
> > indications and the granting of requests.
> >
> > 8) Chairs should be able to act as proxies for local participants
> > lacking access to XMPP.
> >
> > 9) Chairs should have alternative Internet access independent of that of
> > the venue's.
> >
> > 10) Establish a reasonable fee to facilitate remote participants who
> > receive credit for their participation equal to that of being local.
> >
> > 11) The device regulating A/V presentations must drive both the video
> > and audio portions of the presentations.  A web camera in a room is a
> > very poor replacement.
> >
> > 12) All video information in the form of slides and text must be
> > available from the Internet prior to the beginning of the meeting.
> >
> > Regards,
> > Douglas Otis
> >

Re: [Standards] Fwd: Radical Solution for remote participants

[Bernard Aboba]

Part of why the requirements discussions don't seem to converge is that
remote participation in physical meetings encounters a number of issues,
each of could require a substantial effort to resolve.

However, while this is a "target rich environment", at the most basic
level, the goals were stated by Randy Bush a while ago:
http://comments.gmane.org/gmane.ietf.vmeet/127

Approaches to conferencing and bridge control based on XMPP (as well as
SIP) are described here:
http://www.kamailio.org/events/2013-KamailioWorld/14-Emil.Ivov-Jitsi.pdf

For example, for bridge setup and control,
https://jitsi.org/Projects/JitsiVideobridge  suggests:

"the video organizer, or in other words, the party that sets up a call
through a video bridge, controls and uses the video bridge with the COLIBRI
protocol (COnferences with LIghtweight BRIdging). COLIBRI is an open XMPP
extension protocol designed by the Jitsi development team. It allows the
conference organiser to allocate channels for everyone add or remove
participants, and generally remain informed of the call state. All this
happens transparently for the user. "








On Mon, Aug 19, 2013 at 3:15 PM, Peter Saint-Andre wrote:

> I'm waiting for the IETF discussion to yield clear and stable
> requirements before I start to design any XMPP extensions. :-)
>
>

Re: [Standards] Fwd: Radical Solution for remote participants

[Peter Saint-Andre]

I'm waiting for the IETF discussion to yield clear and stable
requirements before I start to design any XMPP extensions. :-)

On 8/13/13 1:31 AM, Dave Cridland wrote:
> How much of this stuff can we do already? I know that much of (6) has
> been implemented in military clients, and I suspect (2) is an
> application of Jingle. (7) smells like a BOSH app, or some kind of a bot
> with a web UI.
> 
> -- Forwarded message --
> From: *Douglas Otis* mailto:doug.mtv...@gmail.com>>
> Date: Tue, Aug 13, 2013 at 2:00 AM
> Subject: Radical Solution for remote participants
> To: John Leslie mailto:j...@jlc.net>>
> Cc: IETF Discussion Mailing List mailto:i...@ietf.org>>
> 
> 
> 
> On Aug 12, 2013, at 1:06 PM, John Leslie  > wrote:
> 
>> Janet P Gunn mailto:jgu...@csc.com>> wrote:
>>>
 Again, it strengthens the case to get it done right. This part has been
 working well though.
>>>
>>> Not necessarily.  There was one WG where I had to send an email to the WG
>>> mailing list asking for someone to provide slide numbers on jabber.
>>
>>   ... and Janet was merely the one who _did_ so. Others did their best
>> to guess at the slide numbers.
>>
>>   At least one-third of the sessions I listened to failed to provide
>> all we are told to expect in the way of jabber support. :^(
>>
>>   OTOH, we _do_ get what we pay for; so I don't mean to complain.
> 
> Dear John,
> 
> You are right about getting your money's worth.  In the case of remote
> participants, they are charged nothing and receive no credit for having
> done so.  Often their input is ignored as well.
> 
> A radical solution for meaningful remote participation is to change how
> A/V in meeting rooms operate.  This change will require a small amount
> of additional equipment and slightly different room configurations.
> 
> 1) Ensure exact digital interfaces driving projectors are fully
> available remotely.
> 
> 2) Ensure Audio access requires an identified request via XMPP prior to
> enabling either a remote or local audio feed.
> 
> 3) RFI tags could facilitate enabling local audio feed instead of an
> identified request via XMPP.
> 
> 4) In the event of the local venue loosing Internet access, the device
> regulating A/V presentations must be able to operate in a virtual mode
> where only remote participants are permitted to continue the meeting
> proceedings.
> 
> 5) Important participants should plan for alternative modes of Internet
> access to remain part of the proceedings.
> 
> 6) Develop a simple syntax used on XMPP sessions to:
>  1) signify a request to speak on X
>  2) withdraw a request to speak on X
>  3) signify support of Y
>  4) signify non-support of Y
>  5) signal when a request has been granted or revoked.  For local
> participants this could be in the form of a red or green light at their
> microphone.
> 
> 7) Develop a control panel managed by chairs or their proxies that
> consolidate and sequence requests and log support and nonsupport
> indications and the granting of requests.
> 
> 8) Chairs should be able to act as proxies for local participants
> lacking access to XMPP.
> 
> 9) Chairs should have alternative Internet access independent of that of
> the venue's.
> 
> 10) Establish a reasonable fee to facilitate remote participants who
> receive credit for their participation equal to that of being local.
> 
> 11) The device regulating A/V presentations must drive both the video
> and audio portions of the presentations.  A web camera in a room is a
> very poor replacement.
> 
> 12) All video information in the form of slides and text must be
> available from the Internet prior to the beginning of the meeting.
> 
> Regards,
> Douglas Otis
> 

[Standards] Fwd: Radical Solution for remote participants

[Dave Cridland]

How much of this stuff can we do already? I know that much of (6) has been
implemented in military clients, and I suspect (2) is an application of
Jingle. (7) smells like a BOSH app, or some kind of a bot with a web UI.

-- Forwarded message --
From: Douglas Otis 
Date: Tue, Aug 13, 2013 at 2:00 AM
Subject: Radical Solution for remote participants
To: John Leslie 
Cc: IETF Discussion Mailing List 



On Aug 12, 2013, at 1:06 PM, John Leslie  wrote:

> Janet P Gunn  wrote:
>>
>>> Again, it strengthens the case to get it done right. This part has been
>>> working well though.
>>
>> Not necessarily.  There was one WG where I had to send an email to the WG
>> mailing list asking for someone to provide slide numbers on jabber.
>
>   ... and Janet was merely the one who _did_ so. Others did their best
> to guess at the slide numbers.
>
>   At least one-third of the sessions I listened to failed to provide
> all we are told to expect in the way of jabber support. :^(
>
>   OTOH, we _do_ get what we pay for; so I don't mean to complain.

Dear John,

You are right about getting your money's worth.  In the case of remote
participants, they are charged nothing and receive no credit for having
done so.  Often their input is ignored as well.

A radical solution for meaningful remote participation is to change how A/V
in meeting rooms operate.  This change will require a small amount of
additional equipment and slightly different room configurations.

1) Ensure exact digital interfaces driving projectors are fully available
remotely.

2) Ensure Audio access requires an identified request via XMPP prior to
enabling either a remote or local audio feed.

3) RFI tags could facilitate enabling local audio feed instead of an
identified request via XMPP.

4) In the event of the local venue loosing Internet access, the device
regulating A/V presentations must be able to operate in a virtual mode
where only remote participants are permitted to continue the meeting
proceedings.

5) Important participants should plan for alternative modes of Internet
access to remain part of the proceedings.

6) Develop a simple syntax used on XMPP sessions to:
 1) signify a request to speak on X
 2) withdraw a request to speak on X
 3) signify support of Y
 4) signify non-support of Y
 5) signal when a request has been granted or revoked.  For local
participants this could be in the form of a red or green light at their
microphone.

7) Develop a control panel managed by chairs or their proxies that
consolidate and sequence requests and log support and nonsupport
indications and the granting of requests.

8) Chairs should be able to act as proxies for local participants lacking
access to XMPP.

9) Chairs should have alternative Internet access independent of that of
the venue's.

10) Establish a reasonable fee to facilitate remote participants who
receive credit for their participation equal to that of being local.

11) The device regulating A/V presentations must drive both the video and
audio portions of the presentations.  A web camera in a room is a very poor
replacement.

12) All video information in the form of slides and text must be available
from the Internet prior to the beginning of the meeting.

Regards,
Douglas Otis