Subject: [vmeet] Issue: is PSTN access really required?

From: Dean Willis <[email-masked]>
Date: Fri, 30 Mar 2012 13:11:12 +0200

From today's meeting, taking to list.

Remote participation for users connecting via the PSTN though gateways into a VoIP conference platform raises some issues.

One of these is "registration" . There are hacks like PINs that can be made to work.

But to me, the biggest problem is that it is just really hard to make it work, especially for participants on the fringe of the PSTN. Echo cancellation may be impossible to provide without exceeding the 150ms latency interaction/interrupt threshold determined in Brian Rosen's research.

One doesn't necessarily need "broadband" to use IP. I've talked quite successfully between participants with EDGE mobile connections. But going over a long path of telephone network to a PSTN gateway, thence over IP to a conference platform is a recipe for disaster.

I therefore propose that our remote participation system neither require nor support dial-in telephone numbers. This assumption can greatly simplify the system, reduce operating expense, and reduce the probability of systemic marginal failure where the system "works" but not well enough to actually use.

Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, and it's far more unfair to make an IETF meeting fail for these who are actually using the Internet to participate in it.

--
dean

---

From: Yoav Nir <[email-masked]>
Date: Fri, 30 Mar 2012 15:01:52 +0200

> Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, a…

I disagree that providing service to people connecting from PSTN or through a gateway from the "wrong" software (like Skype) needs have any effect on the service provided for the other remote participants. People might be excluded because they are behind a corporate firewall or because the particular solution we chose does not run on their favorite distribution of Linux or z/OS.

I also disagree with Brian's claim that 150ms is a limit for the kind of discussion that takes place in IETF working groups. It does apply to phone calls, but WG discussion tends not to be interrupt-driven. People politely wait their turn at the mike, with the chairs signaling the use of the "floor". Not having the ability to connect from work (when the IETF is in  a suitable time zone) means having to take the day off or relying on cellular internet that seems to have higher latency anyways.

So I think some ability to connect via PSTN (and Skype) should be a requirement.

---

From: Yoav Nir <[email-masked]>
Date: Fri, 30 Mar 2012 15:09:05 +0200

> Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, a…

I disagree that providing service to people connecting from PSTN or through a gateway from the "wrong" software (like Skype) needs have any effect on the service provided for the other remote. Whatever solution we choose may be blocked by flaky network or corporate firewall. It might require remote participants to take the day off to attend a single meeting.

I also disagree with the claim that the 150ms limit applies to IETF WG discussions. These are not equivalent to phone conversations. They are structured and controlled by the chairs. Even the people who are physically present politely wait their turn at the mike.  I think the ability to patch in from a PSTN or Skype should be part of the requirements.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Fri, 30 Mar 2012 15:11:24 +0200

[sorry for the resend]

---

From: Russ Housley <[email-masked]>
Date: Fri, 30 Mar 2012 08:41:21 -0400

> Some argue that this would unfairly exclude people who can't get Internet connections, but I counter that it's certainly less of an exclusion than requiring them to physically attend the meeting, a…

I'd like to expand the scope of this portion of the discussion.  Remote participation in IETF meetings, remote participation in face-to-face interim meeting, remote participation in virtual interim meetings, and remote participation in IESG telechats may have differing requirements regarding PSTN connectivity.

Russ

---

From: Dave Cridland <[email-masked]>
Date: Fri, 30 Mar 2012 13:48:32 +0100

On Fri Mar 30 14:01:52 2012, Yoav Nir wrote:
> I disagree that providing service to people connecting from PSTN or  
> through a gateway from the "wrong" software (like Skype) needs have  
> any effect on the service provided for the other remote  
> participants. People might be excluded because they are behind a  
> corporate firewall or because the particular solution we chose does  
> not run on their favorite distribution of Linux or z/OS.
> 
> 
People can be excluded for a multitude of reasons.  Arranging to have  
working connectivity for the period of a meeting is far from an  
onerous problem, in my opinion (as a remote participant), so I'd be  
fine with not requiring PSTN connectivity. I'd also note that "pure"  
PSTN conferences I've had have always been a disaster, anyway, with  
buzzing handsets and poor audio quality.

On the other hand, if the solution won't run on Linux purely because  
it's some non-standard gloop, I *will* be very annoyed. We've  
currently at least two standards-track protocols capable of  
negotiating an RTP stream, we should be using them.

> I also disagree with Brian's claim that 150ms is a limit for the  
> kind of discussion that takes place in IETF working groups. It does  
> apply to phone calls, but WG discussion tends not to be  
> interrupt-driven. People politely wait their turn at the mike, with  
> the chairs signaling the use of the "floor". Not having the ability  
> to connect from work (when the IETF is in  a suitable time zone)  
> means having to take the day off or relying on cellular internet  
> that seems to have higher latency anyways.

I think we can go higher than 150ms - my unsubstantiated guess would  
be as high as 500ms - for the reasons you give, but there are  
frequent conversations between the person at the mike and the person  
leading the session (the draft presenter, chairman, whatever).  
Sometimes even conversations between two people at the mike.

The high bandwidth, low latency conversations are the only real  
reason to have IETF meetings at all, so I think it's worth preserving.

As I say, the somewhat formalized nature of these does allow for a  
higher latency than would be need for natural conversation, but not  
*much* higher - and I can tell you how frustrating it is to be a  
remote participant, and be unable to engage in even slightly  
real-time conversations.

As an example, in the xmppwg meeting on Wednesday, I was still  
listening to Peter Saint-Andre voicing my words when I was reading on  
the chatroom Joe Hildebrand's summarized response. After thirty more  
seconds, I could hear the response. Peter had, by the time, left the  
mike, so my chance for a counter-response was entirely lost, and in  
any case, the discussion had moved on in the room already - I had  
actually lost my chance for a reasonable counter-response by the time  
I heard Joe's voice.

The number of times one hears "I think this is in relation to..."  
when referring the the channelled comments from remote participants  
is quite astonishing. It's even worse when the comments are assumed  
to be in response to something the commenter hadn't even heard when  
they wrote the comment.

If there's a single practical goal from vmeet, reducing the outbound  
audio latency to a reasonable level should be it.

Everything else, I can deal with, albeit through rough mechanical  
labour-intensive ways - but these are ways that fundamentally work to  
achieve the higher level goal.

I don't (really)  care (too much) that my comments are read out in an  
American monotone (Peter didn't do a monotone, though he pointedly  
refused to do a British accent). I don't care that I need to download  
slides and be told what page we're on via XMPP. I'm entirely cool  
that the slides, the chatroom, and the audio feed all run through  
wildly different systems.

But I do care - hugely - that my comments can get there in a timely  
manner, and help shape the conversation. That latter - shaping the  
conversation - is the ultimate goal.

Dave.
-- 
Dave Cridland - mailto:[email-masked] - xmpp:[email-masked]
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 30 Mar 2012 09:15:49 -0400

On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland <[email-masked]> wrote:
>> through a gateway from the "wrong" software (like Skype) needs have any
>> effect on the service provided for the other remote participants. People
>> might be excluded because they are behind a corporate firewall or because
>> the particular solution we chose does not run on their favorite distribution
>> of Linux or z/OS.
>>
>>
> working connectivity for the period of a meeting is far from an onerous
> problem, in my opinion (as a remote participant), so I'd be fine with not
> requiring PSTN connectivity. I'd also note that "pure" PSTN conferences I've
> had have always been a disaster, anyway, with buzzing handsets and poor
> audio quality.
>
> On the other hand, if the solution won't run on Linux purely because it's
> some non-standard gloop, I *will* be very annoyed. We've currently at least
> two standards-track protocols capable of negotiating an RTP stream, we
> should be using them.
>
>
>
>> I also disagree with Brian's claim that 150ms is a limit for the kind of
>> discussion that takes place in IETF working groups. It does apply to phone
>> calls, but WG discussion tends not to be interrupt-driven. People politely
>> wait their turn at the mike, with the chairs signaling the use of the
>> "floor". Not having the ability to connect from work (when the IETF is in  a
>> suitable time zone) means having to take the day off or relying on cellular
>> internet that seems to have higher latency anyways.
>
>
> I think we can go higher than 150ms - my unsubstantiated guess would be as
> high as 500ms - for the reasons you give, but there are frequent
> conversations between the person at the mike and the person leading the
> session (the draft presenter, chairman, whatever). Sometimes even
> conversations between two people at the mike.
>
> The high bandwidth, low latency conversations are the only real reason to
> have IETF meetings at all, so I think it's worth preserving.
>
> As I say, the somewhat formalized nature of these does allow for a higher
> latency than would be need for natural conversation, but not *much* higher -
> and I can tell you how frustrating it is to be a remote participant, and be
> unable to engage in even slightly real-time conversations.
>
> As an example, in the xmppwg meeting on Wednesday, I was still listening to
> Peter Saint-Andre voicing my words when I was reading on the chatroom Joe
> Hildebrand's summarized response. After thirty more seconds, I could hear
> the response. Peter had, by the time, left the mike, so my chance for a
> counter-response was entirely lost, and in any case, the discussion had
> moved on in the room already - I had actually lost my chance for a
> reasonable counter-response by the time I heard Joe's voice.
>
> The number of times one hears "I think this is in relation to..." when
> referring the the channelled comments from remote participants is quite
> astonishing. It's even worse when the comments are assumed to be in response
> to something the commenter hadn't even heard when they wrote the comment.
>
> If there's a single practical goal from vmeet, reducing the outbound audio
> latency to a reasonable level should be it.
>
> American monotone (Peter didn't do a monotone, though he pointedly refused
> to do a British accent). I don't care that I need to download slides and be
> told what page we're on via XMPP. I'm entirely cool that the slides, the
> chatroom, and the audio feed all run through wildly different systems.
>
> But I do care - hugely - that my comments can get there in a timely manner,
> and help shape the conversation. That latter - shaping the conversation - is
> the ultimate goal.
>

I have carried my laptop up to the mike when channeling people
precisely so that there could be some
amount of interaction when their question was asked. This is pretty
cumbersome and could certainly be improved by technology.

Regards
Marshall

> _______________________________________________
> NOTE WELL: This list operates according to
> http://mipassoc.org/dkim/ietf-list-rules.html.
> https://www.ietf.org/mailman/listinfo/vmeet

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 31 Mar 2012 13:31:31 +0900

On 2012/03/30 22:15, Marshall Eubanks wrote:
> On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland<[email-masked]>  wrote:

> cumbersome and could certainly be improved by technology.

 From a usually remote participant: Thanks, great idea.

As a general suggestion: Let the "channeler" sit just besides the mike, 
so this involves minimal effort.

Regards,    Martin.

---

From: "Martin J. Dürst" <[email-masked]>
Date: Sat, 31 Mar 2012 13:42:46 +0900

Personal experience from yesterday, being a remote presenter for about 
half of the session in the IRI WG meeting:

- Meetecho gave a lot of options for audio. When testing, the Java stuff 
didn't work, but Skypeout from Japan into the Italian Meetecho PSTN 
number worked.

- The echo was tough, mostly for me. I only had to filter out my own 
voice, so I knew what was coming. There was some heavy echo for other 
remote participants also, but apparently not all the time.

- The interrupt thing is *really* tough. Once there was a question, 
people in the room started arguing, and I was cut off because I didn't 
want to interrupt (given that I "had a mike", it would have been 
possible to interrupt, though, strictly physically speaking).

- I think there is also some cultural dependency re. interrupt timing. A 
pause of so many (milli)seconds may mean "you can interrupt me now if 
you need" is some culture, but it means "I'm still talking" in another 
culture.

- For long distances (half around the globe), the interrupt thing starts 
to be a problem independent of the technology.

So I'd say: Please keep PSTN as an option; it's maybe not the best in 
terms of quality, but it's very good in terms of reliability.

Regards,   Martin.