Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 11:31 PM, Martin J. Dürst wrote: > On 2012/03/30 22:15, Marshall Eubanks wrote: >> On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland wrote: >>> On Fri Mar 30 14:01:52 2012, Yoav Nir wrote: > >> 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. > > 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. Requires a room with more than one working mic. Sometimes that's all we get. Stupid related question: 98% of the people in the room have two or more devices with a mic in their possession during the meeting. Why do we queue at mics and needs special mics for scribes when we've got all this idle hardware laying about the room? A simple SIP conference bridge with UAs sporting "push to talk" and time-delay features (echo avoidance) might make life much easier. -- Dean ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 7:41 AM, Russ Housley wrote: >> >> 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. > > 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 is absolutely correct. I'd like to clarify that I was referring to remote participation in IETF meetings and face-to-face interim meetings; these are scenarios where a mixed model makes temporal requirements very difficult to meet. Also, the more participants one has, the more that cancellation of hybrid echo tends to become a problem. Recall that this sort of echo comes from the electronics of two-wire telephone connections (they send and receive on the same wires) interconnecting with the "four-wire" connections (or virtualizations thereof, like DS0). No PSTN, no hybrid echo. Note that even using a conventional PSTN phone with a VoIP adaptor can induce the problem, hence my suggestion for not using phone numbers. Having been the one "remote" participant at company executive team meetings held locally in New Jersey for several years, I'd have to say that being stuck on the other end of a conference phone was not an optimum strategy for effectively influencing company decisions. Remote participation in all-virtual meetings might well allow for PSTN dial-in, but to my mind only if every participant is reduced to that least-common-denominator. The same probably applies to IESG telechats, although this is a rarefied scenario in which one can arguably expect higher level of tool training and cultural adaptation because we have a small group of the the same people using the same tools again and again. They can more readily adapt to tool weirdness than can occasional users in a large and open user group. Then again, the same could be said of my disappointing executive team, and we know it didn't work there. OTOH, they didn't try very hard. -- Dean ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
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. On 2012/03/30 20:11, Dean Willis wrote: 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On 2012/03/30 22:15, Marshall Eubanks wrote: On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland wrote: On Fri Mar 30 14:01:52 2012, Yoav Nir wrote: 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On Fri, Mar 30, 2012 at 8:48 AM, Dave Cridland wrote: > 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. > 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 > Dave. > -- > Dave Cridland - mailto:d...@cridland.net - xmpp:d...@dave.cridland.net > - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ > - http://dave.cridland.net/ > Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade > > ___ > NOTE WELL: This list operates according to > http://mipassoc.org/dkim/ietf-list-rules.html. > https://www.ietf.org/mailman/listinfo/vmeet ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
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:d...@cridland.net - xmpp:d...@dave.cridland.net - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/ - http://dave.cridland.net/ Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
Dean: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
[sorry for the resend] ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote: > 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. 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 ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
Re: [vmeet] Issue: is PSTN access really required?
On Mar 30, 2012, at 1:11 PM, Dean Willis wrote: > 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. 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. ___ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html. https://www.ietf.org/mailman/listinfo/vmeet
