Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
Greetings all,
Please see below related to Annex G.
Best Regards,
Adrian P STEPHENS
Tel: +44 1954 204 609 (office)
Tel: +44 7920 084 900 (mobile)
Skype: adrian_stephens
----------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47
-----Original Message-----
From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Mark Rison
Sent: Saturday, September 01, 2012 8:46 AM
To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
[Adrian Stephens] [snip]
Actually, an AP is always a STA, in IEEE 802.11, except when it "contains" a STA, of course (one for TGmc). The Figure shows an AP, not a STA (that's the change you made in r1).
[Adrian Stephens]
This relates to a difference of opinion between myself and Dave Bagby, which Dave won.
Dave maintains that an AP contains a STA, plus a lot besides, such as an interface to the DS, possibly a portal ...
I maintain that an AP is a refinement of the class STA, and an AP is therefore a STA.
Both are really equivalent statements, because any rule specified for (unqualified) STA is followed by an AP
regardless of linguistic niceties.
I doubt whether REVmc will want to change the language, because TGac adds nothing new to the debate.
[Adrian Stephens] [snip]
> > - Why is txop-part-requiring-ack being modified rather than
> > ht-txop-sequence or one of its children (or even adding a
> > vht-txop-sequence)?
> It is very difficult to figure out just exactly what the allowable
> frame exchange sequences are from reading annex G, even though it is
> written with a "rigid" logical syntax - during the conference call,
> Simone Merlin suggested that rather than create a new exchange which
> again, seems too limited in its choices of what can really be done
> within a TXOP, what should really be allowed in the case of MU PPDU is
> that anywhere in Annex G that a "data-bearing or management bearing
> frame" exists in the entire set of allowable frame exchanges, the
> option for inserting +mu-ppdu should be added and I think that he is
> correct.
> And it seems that if annex G has been correctly created, then
> somewhere in annex G, there should be ONE place that describes that
> fundamental thing embedded in a fundamental sequence that is a TXOP,
> with phrasing that logically says that anything that is a "blah-unit"
> can appear here, where "here" is that fundamental TXOP exchange to
> which can be added other things optional in front, such as preceding
> RTS/CTS or CTS2SELF, etc. and optional things behind, such as
> BAR+BA, ACK, more MPDUs, etc. and I think that
> txop-part-requiring-ack is pretty close to being the "blah-unit" and
> the cited exchange looks pretty close to being that fundamental txop
> exchange but maybe I've not read it correctly.
> There should be a similar "blah-unit" for the no-ack case but I cannot
> find it. Once both of those are found, then they can be modified to
> allow +mu+ppdu, and then any fancy combination of frames that makes a
> single TXOP will allow the insertion of an MU PPDU and I hope that no
> other places would need the addition of +mu-ppdu.
[Adrian Stephens]
I agree. I think that there needs to be an mu-exchange described,
the essence of which is that it contains multiple a-mpdus, each addressed
to a different STA, and only one of which can generate an immediate
response.
> But the more I look at annex G, the more I think it is a heaping plate
> of indigestible spaghetti and as anyone else tries to join the search
> and repair mission, I think that they will agree with my opinion and
> the more that annex G is examined in an open forum, the more likely
> someone is to stand up and move to make the entire annex informative
> again.
> I believe that everyone just allowed someone to write that text
> because they volunteered to do it and no one really looked at it too
> hard when it was done and I believe that it is probably missing a lot
> of things and duplicating a lot of things and I believe that no one
> really cares and I know that I do not really care, but I spent my
> personally created and imposed and policed two hour limit of honest
> effort looking into it and so I will not spend any more time on annex
> G, other than to present the couple of choices that I have created in
> the F2F in September, even though I believe that none of my choices is
> convincingly correc!
[Adrian Stephens]
At this point I have to stand up and admit reluctant authorship of Annex G.
I submitted changes for REVma to replace what was in the earlier
revision, because we could find no reasonable way of expressing the TGn exchanges
using the terminology of STD-2003 (TGn was progressing at the same time
as REVma, so I was writing submissions to both at the time).
We tried to find a slightly more formal syntax for Annex G in the hope
it could remain normative. We failed, inasmuch as Annex G doesn't
even start to describe all the possible A-MPDU sequences involving
the 5 types of Beamforming training x the various possible responses.
At that point we admitted defeat and made the Annex informative,
and removed all references to it from normative text in REVma.
However, REVmb came along and decided that we really did need
some of those references, and made it normative again, without really
addressing the issues of partial coverage of sequences in Annex G. I probably
spoke against this at the time, but you can see I lost out.
Having spent many many hours on Annex G. I am not minded to
repeat the exercise. The characterization " no one really looked at it too hard when it was done"
is not fair. TGma and TGmb both paid it a lot of attention. Bill Marshall and Tomo Adachi
were the main reviewers, and they put a lot of hours into it.
If anybody wants to make this their cause celebre, be my guest.
I will pay sufficient attention to any changes to ensure that we don't
make it any worse than it already it.
> t in my mind and if anyone else wants to try to figure it out, they
> are welcomed to do so - I gave it a shot.
> As for allowable frame exchanges, I just figure that as long as a STA
> keeps using SIFS and the same AC, then it can continue to send DATA
> and control frames and management frames up to the limit of TXOPLimit
> and everything should be fine - and it can use PIFS too in the case of
> recovery - i.e.
> in my heart, I know which frame exchanges are right, because they feel
> right, morally.
> Annex G is to me, an apocryphal addendum to the otherwise
> 802.11 holy writings and somewhere in a desert there must be a small
> radical gathering of adherents to a sect of the
> 802.11 religion of which I am not a member who believe that annex G is
> a part of the true writings of 802.11. At this point, I would prefer
> to let them reconcile their ancient document with the latest 802.11
> advances.
I share your pain, but, if we're not going to make sure Annex G is fixed for 11ac, we need to add something like:
This annex is obsolete as regards VHT. Consequently this annex may be removed in a future revision of this standard. This
clause is no longer maintained and may not be compatible with or describe all features of this standard.
[Adrian Stephens]
Well, I suppose this is following the path we took with the SDL. It became useless because the
specific knowledge to maintain it disappeared, and folks didn't see the benefit from it. REVmc will
delete it.
> > - The addition of the [1{}] in "[1{RTS CTS}]" appears to be
> something
> > new and not something required for resolution of this
> comment per se.
> > What is the justification for this change?
> On the call, Liwen mentioned that somehow, somewhere, there had been
> discussion and agreement and maybe even that draft text was written
> and exists somewhere that allows the sending of multiple RTS-CTS
> exchanges preceding an MU PPDU transmission and this should also
> appear in annex G. I think that he is right but I cannot cite any
> text.
Well, if he is right, I think this important change should be addressed explicitly via a relevant comment resolution, not buried in a comment resolution about a different topic (MU PPDU acknowledgement).
> > - "An ACK frame can be sent in response to an MPDU within an MU PPDU
> > if the ack policy requires it." I realise I supported this
> > previously, but when can this happen, in fact? I can see nothing in
> > Table 8-284 "A-MPDU contents in the data enabled immediate response
> > context"
> > which could result in such an outcome (all the possible MPDUs in
> > such an A-MPDU either need no immediate acknowledgement or need a
> > BlockAck as immediate acknowledgement)
> See 8.6.3, the new 11ac Table 8-288-A-MPDU contents in the VHT single
> MPDU context and then go look up the rules on acknowledgement for VHT
> single MPDU.
Duh, of course! I retract my retraction, and instead suggest the wording be modified to:
An ACK frame can be sent in response to an MU PPDU
in the case where it contains a VHT single MPDU.
[Adrian Stephens]
I believe this is already implicit, but don't object to this. As this is informative language "can",
a NOTE works just as well.
Mark
--
Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
CSR, Cambridge Business Park Tel: +44 1223 692000
Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
ROYAUME UNI WWW: http://www.csr.com
> -----Original Message-----
> From: *** 802.11 TGac - VHT below 6GHz***
> [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Matthew Fischer
> Sent: 31 August 2012 18:50
> To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
>
> > -----Original Message-----
> > From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-
> > TGAC@xxxxxxxx] On Behalf Of Mark Rison
> > Sent: Friday, August 31, 2012 4:02 AM
> > To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> > Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> >
> > Some comments on 1021r5:
> >
> > - I basically like it
> >
> > - I still don't see the point of "there is no more than one
> immediate
> > response required for an A-MPDU, and further indicate" and think it
> > should be deleted
> [MFischer]
>
> It is the sort of note for which the commenter is asking:
> i.e. it clarifies just exactly how the MU PPDU exchange is supposed to
> work. The first question that most reader have when seeing the MU PPDU
> is - how do you keep the responders from colliding with each other?
> And the text above provides an explicit answer to that, rather than
> the inferred one that is the result of a dozen sleepless nights
> reading and re-reading all parts of the spec and then assembling the
> different parts in different orders in your head to finally connect
> the dots and come to the conclusion that is presented in the sentences
> above.
>
>
> > - I still think "STA transmitting the MU PPDU" should be "AP"
> [MFischer]
>
> I do not know of any place in the spec that restricts MU PPDU
> transmission to an AP (even though I believe that most people
> believe that such a restriction exists)
> And for the typical case, an AP is a STA, so there is nothing
> technically incorrect here
>
> Maybe the group wants such a restriction and maybe it is
> there and I just cannot find it.
>
>
> > - I still think the "No BlockAckRequest frame should be
> sent to a STA
> > in the case where the A-MPDU to that STA contained no MPDUs
> requiring
> > acknowledgement." needs a NOTE to explain why it's a
> "should" and not
> > a "shall"
> [MFischer]
>
> Basically, nearly any sequence of frames is allowed and a STA
> could transmit an MU PPDU followed by BAR or followed by some
> non-MU PPDUs. A STA could transmit an MU PPDU and immediately
> follow it with BAR frames to unrelated STAs or for unrelated
> BA agreements, even if the MU PPDU contained no frames for acking.
>
> A very large number of sequences is allowed and possible.
> Thinking of it this way, maybe that sentence should simply be removed.
>
>
> > - What's the "+mu-ppdu" attribute?
> [MFischer]
> It is a new attribute that is modeled on the +a-mpdu attribute
> See annex G, compare to +a-mpdu
>
>
> > - Why is txop-part-requiring-ack being modified rather than
> > ht-txop-sequence or one of its children (or even adding a
> > vht-txop-sequence)?
>
> [MFischer]
> It is very difficult to figure out just exactly what the
> allowable frame exchange sequences are from reading annex G,
> even though it is written with a "rigid" logical syntax -
> during the conference call, Simone Merlin suggested that
> rather than create a new exchange which again, seems too
> limited in its choices of what can really be done within a
> TXOP, what should really be allowed in the case of MU PPDU is
> that anywhere in Annex G that a "data-bearing or management
> bearing frame" exists in the entire set of allowable frame
> exchanges, the option for inserting +mu-ppdu should be added
> and I think that he is correct.
>
> And it seems that if annex G has been correctly created, then
> somewhere in annex G, there should be ONE place that
> describes that fundamental thing embedded in a fundamental
> sequence that is a TXOP, with phrasing that logically says
> that anything that is a "blah-unit" can appear here, where
> "here" is that fundamental TXOP exchange to which can be
> added other things optional in front, such as preceding
> RTS/CTS or CTS2SELF, etc. and optional things behind, such as
> BAR+BA, ACK, more MPDUs, etc. and I think that
> txop-part-requiring-ack is pretty close to being the
> "blah-unit" and the cited exchange looks pretty close to
> being that fundamental txop exchange but maybe I've not read
> it correctly.
>
> There should be a similar "blah-unit" for the no-ack case but
> I cannot find it. Once both of those are found, then they can
> be modified to allow +mu+ppdu, and then any fancy combination
> of frames that makes a single TXOP will allow the insertion
> of an MU PPDU and I hope that no other places would need the
> addition of +mu-ppdu.
>
> But the more I look at annex G, the more I think it is a
> heaping plate of indigestible spaghetti and as anyone else
> tries to join the search and repair mission, I think that
> they will agree with my opinion and the more that annex G is
> examined in an open forum, the more likely someone is to
> stand up and move to make the entire annex informative again.
> I believe that everyone just allowed someone to write that
> text because they volunteered to do it and no one really
> looked at it too hard when it was done and I believe that it
> is probably missing a lot of things and duplicating a lot of
> things and I believe that no one really cares and I know that
> I do not really care, but I spent my personally created and
> imposed and policed two hour limit of honest effort looking
> into it and so I will not spend any more time on annex G,
> other than to present the couple of choices that I have
> created in the F2F in September, even though I believe that
> none of my choices is convincingly correc!
> t in my mind and if anyone else wants to try to figure it
> out, they are welcomed to do so - I gave it a shot.
>
> As for allowable frame exchanges, I just figure that as long
> as a STA keeps using SIFS and the same AC, then it can
> continue to send DATA and control frames and management
> frames up to the limit of TXOPLimit and everything should be
> fine - and it can use PIFS too in the case of recovery - i.e.
> in my heart, I know which frame exchanges are right, because
> they feel right, morally.
>
> Annex G is to me, an apocryphal addendum to the otherwise
> 802.11 holy writings and somewhere in a desert there must be
> a small radical gathering of adherents to a sect of the
> 802.11 religion of which I am not a member who believe that
> annex G is a part of the true writings of 802.11. At this
> point, I would prefer to let them reconcile their ancient
> document with the latest 802.11 advances.
>
>
> > - The addition of the [1{}] in "[1{RTS CTS}]" appears to be
> something
> > new and not something required for resolution of this
> comment per se.
> > What is the justification for this change?
> [MFischer]
> On the call, Liwen mentioned that somehow, somewhere, there
> had been discussion and agreement and maybe even that draft
> text was written and exists somewhere that allows the sending
> of multiple RTS-CTS exchanges preceding an MU PPDU
> transmission and this should also appear in annex G. I think
> that he is right but I cannot cite any text.
>
>
> > - "An ACK frame can be sent in response to an MPDU within an MU PPDU
> > if the ack policy requires it." I realise I supported this
> previously,
> > but when can this happen, in fact? I can see nothing in Table 8-284
> > "A-MPDU contents in the data enabled immediate response context"
> > which could result in such an outcome (all the possible MPDUs in
> > such an A-MPDU either need no immediate acknowledgement or need a
> > BlockAck as immediate acknowledgement)
> [MFischer]
>
> See 8.6.3, the new 11ac Table 8-288-A-MPDU contents in the
> VHT single MPDU context and then go look up the rules on
> acknowledgement for VHT single MPDU.
>
>
>
> >
> > Mark
> >
> > --
> > Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
> > CSR, Cambridge Business Park Tel: +44 1223 692000
> > Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
> > ROYAUME UNI WWW: http://www.csr.com
> >
> > > -----Original Message-----
> > > From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-
> > TGAC@xxxxxxxx] On Behalf Of Merlin,
> > > Simone
> > > Sent: 31 August 2012 00:19
> > > To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> > > Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> > >
> > > Hi Matt,
> > >
> > > My opinion is that there is no need to add so much new
> text/figure to describe
> > the MU BA procedure. In
> > > fact the text you propose is essentially reiterating on
> mechanisms described
> > somewhere else, so it is
> > > not adding much new information.
> > >
> > > The figure referred by the comment was there to
> illustrate the TXOP sharing
> > concept, not the BA
> > > procedure; why not remove the BAs from that figure instead?
> > >
> > > Regarding the text you propose:
> > >
> > > These two paragraphs could be OK as a clarification note
> placed somewhere
> > >
> > > "The acknowledgement procedure performed by a STA that receives
> > MPDUs that were transmitted
> > > within an MU PPDU is the same as the acknowledgement procedure for
> > MPDUs that were not
> > > transmitted within an MU PPDU.
> > > NOTE - All MPDUs transmitted within an MU PPDU are
> contained within
> > A-MPDUs and the rules
> > > specified in 8.6.3 (A-MPDU contents) ensure that there is
> no more than one
> > immediate response
> > > required for an A-MPDU, and further indicate that there
> can only be one
> > immediate response to an MU
> > > PPDU."
> > >
> > >
> > > But this one does not tell much, and may generate further
> comments (e.g. the
> > ones from Mark, below...)
> > >
> > > "Responses to A-MPDUs within an MU PPDU that are not immediate
> > responses to the MU PPDU are
> > > transmitted in response to explicit BlockAckRequest
> frames by the STA
> > transmitting the MU PPDU.
> > > --> no new info. how else could it happen?
> Also, does response
> > indicate immediate response?
> > > What about delayed BA?
> > >
> > > "An MU PPDU frame exchange sequence is shown in Figure 9-9a (The
> > MU PPDU acknowledgement
> > > procedure)"
> > > --> I foresee additional comments regarding
> this figure in later
> > drafts
> > >
> > > Recovery within the TXOP can be performed
> according to the rules of
> > 9.19.2.4 (Multiple
> > > frame transmission in an EDCA TXOP). BlockAckRequest frames can be
> > transmitted in a TXOP separate from
> > > the one that contained the MU PPDU.
> > > --> no new info
> > >
> > > Simone
> > >
> > > -----Original Message-----
> > > From: *** 802.11 TGac - VHT below 6GHz*** [mailto:STDS-802-11-
> > TGAC@xxxxxxxx] On Behalf Of Mark Rison
> > > Sent: Wednesday, August 29, 2012 10:27 AM
> > > To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> > > Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> > >
> > > I will not be able to attend, but assuming 1021r3 will be
> presented, I have the
> > following comments
> > > thereon:
> > >
> > > - I think "ensure that there is no more than one
> immediate response
> > > required for an A-MPDU" in the first NOTE is a statement of the
> > > blindingly obvious, and should be deleted. I also
> think "indicate"
> > > should be changed to "ensure". The NOTE should read
> simply "NOTE---
> > > All MPDUs transmitted within an MU PPDU are contained
> within A-MPDUs
> > > and the rules specified in 8.6.3 (A-MPDU contents)
> ensure that there
> > > can only be one immediate response to an MU PPDU."
> > >
> > > - The figure should show BA/ACK rather than just BA in
> the green boxes
> > > (for the reasons given in NOTE 1). The last of the
> three figures
> > > shown (page 5) is correct.
> > >
> > > - The NOTE 1 should just be a NOTE (since there's only
> one of them).
> > >
> > > - "BAR frames" should be "BlockAckReq frames" (twice).
> > >
> > > - "STA transmitting the MU PPDU" should be changed to
> "AP" (to match
> > > the figure).
> > >
> > > - "HT-delayed BlockAck" should be "HT-delayed Block Ack"
> (it's not the
> > > frame, it's the behaviour).
> > >
> > > - I think the baseline mostly calls for a "frame" after
> "A BlockAck or
> > > an ACK" and "No BlockAckRequest".
> > >
> > > - The case where none of the A-MPDUs in the MU PPDU
> requires immediate
> > > acknowledgement is not covered. What happens in this
> case? Does a
> > > BAR follow the MU PPDU after SIFS?
> > >
> > > - I'm guessing the "should" in the "No BlockAckRequest
> should be sent
> > > to a STA in the case where the A-MPDU to that STA
> contained no MPDUs
> > > requiring acknowledgement." is to cover the case where
> although the
> > > A-MPDU did not have any MPDUs requiring ack, the AP
> wants to get a
> > > BA for some MPDUs sent earlier which do require ack.
> But this is
> > > not clear and should be spelt out (perhaps another NOTE?).
> > >
> > > Mark, who hadn't realised MU ack was such a can of worms!
> > >
> > > --
> > > Mark RISON, Systems Architect, Wi-Fi English/Esperanto/Francais
> > > CSR, Cambridge Business Park Tel: +44 1223 692000
> > > Cowley Road, Cambridge CB4 0WZ Fax: +44 1223 692001
> > > ROYAUME UNI WWW: http://www.csr.com
> > >
> > > > -----Original Message-----
> > > > From: *** 802.11 TGac - VHT below 6GHz***
> > > > [mailto:STDS-802-11-TGAC@xxxxxxxx] On Behalf Of Osama AboulMagd
> > > > Sent: 28 August 2012 13:04
> > > > To: STDS-802-11-TGAC@xxxxxxxxxxxxxxxxx
> > > > Subject: Re: [STDS-802-11-TGAC] IEEE 802.11ac telecon
> > > >
> > > > Hello All,
> > > >
> > > > There is a TGac conference call scheduled for Thursday,
> August 30 at
> > > > 20:00 ET. Please let me know if you plan a presentation.
> > > >
> > > > Dial in information is available below.
> > > >
> > > > The latest revision of LB188 Comment spread sheet is
> available at:
> > > >
> https://mentor.ieee.org/802.11/dcn/12/11-12-0752-08-00ac-lb188-comment
> > > > s-tgac-d3-0.xls
> > > >
> <https://mentor.ieee.org/802.11/dcn/12/11-12-0752-08-00ac-lb188-commen
> > > > ts-tgac-d3-0.xls>
> > > >
> > > > Teleconferences are bound by the conditions stipulated by the
> > > > documentation below. Please review them and bring up any
> > questions/concerns you may have before
> > > proceeding with the teleconference.
> > > >
> > > >
> > > > *
> > > >
> http://standards.ieee.org/resources/anthttp://www.ieee.org/web/members
> > > > hip/ethics/code_ethics.html
> > > >
> >
> <http://standards.ieee.org/resources/anthttp://www.ieee.org/we
> b/membership/ethic
> > s/code_ethics.html>
> > > > *
> http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guide
> lines.pdf
> > > >
> <http://standards.ieee.org/faqs/affiliationFAQ.htmlitrust-guid
> elines.pdf>
> > > > * http://standards.ieee.org/board/pat/loa.pdf
> > <http://standards.ieee.org/board/pat/loa.pdf>
> > > > * http://standards.ieee.org/board/pat/index.html
> > > <http://standards.ieee.org/board/pat/index.html>
> > > > * http://standards.ieee.org/board/pat/pat-slideset.ppt
> > > <http://standards.ieee.org/board/pat/pat-
> > > > slideset.ppt>
> > > > * http://standards.ieee.org/board/pat/faq.pdf
> > <http://standards.ieee.org/board/pat/faq.pdf>
> > > > * http://www.ieee802.org/policies-and-procedures.pdf
> > <http://www.ieee802.org/policies-and-
> > > > procedures.pdf>
> > > > *
> http://www.ieee802.org/PNP/2008-11/LMSC_OM_approved_081114.pdf
> > > > <http://www.ieee802.org/PNP/2008-11/LMSC_OM_approved_081114.pdf>
> > > >
> > > >
> > > > Regards;
> > > > Osama.
> > > >
> > > >
> > > >
> > > > -----Original Appointment-----
> > > > From: Brian Hart (brianh) [mailto:brianh@xxxxxxxxx]
> > > > Sent: Monday, July 23, 2012 12:15 PM
> > > > To: Brian Hart (brianh); Reza Hedayat (rehedaya);
> Perahia, Eldad;
> > > > Osama AboulMagd; Stephens, Adrian P
> > > > Cc: Luoyi (Roy); auyehara@xxxxxxxxxxx; Daniel Camps Mur;
> > > > mesem@xxxxxxxxxxxx
> > > > Subject: IEEE 802.11ac telecon
> > > > When: Thursday, August 30, 2012 8:00 PM-10:00 PM
> (UTC-05:00) Eastern
> > Time (US & Canada).
> > > > Where: Webex
> > > >
> > > >
> > > >
> > > > Approved times
> > > > 10:00 - 12:00 ET: July 26, August 9, August 23,
> Sept 6, Sept 27, Oct 11
> > > > 20:00 - 22:00 ET: August 2, August 16, August 30,
> Sept 13, Oct. 4
> > > >
> > > > Cautions
> > > >
> > > > * Help: http://www.webex.com/lp/keyfeatures/index.php
> > > > <http://www.webex.com/lp/keyfeatures/index.php>
> > > > * [Recommended] To join the teleconference and
> see shared documents,
> > click on the first link below
> > > > ("To start this meeting"), go through the various
> screens until your
> > > > inside Webex, then Webex will prompt you so it can call
> your phone
> > > > * [If in the car, etc] Otherwise, to join the
> teleconference only
> > > > * You must dial (408) 525-6800 when calling from
> a US 408 number (the
> > 866 number is blocked)
> > > > * You must dial (919) 392-3330 when calling from
> a US 919 number (the
> > 866 number is blocked)
> > > > * Otherwise dial (866) 432-9903 from the USA or
> see the second link below
> > for dial-in numbers for
> > > > other locations
> > > > * The meeting number is 204 708 684 #
> > > > * To mute, use *6 (and also to unmute) or right
> click on your name in the
> > Participants window and
> > > > hit Mute
> > > > * Please use these methods preferentially since
> your local mute
> > mechanism may introduce echo
> > > > * If you have an incoming call, don't answer it!
> (Everyone else hears on-
> > hold music)
> > > > * To share a document, I'll hand you the ball in
> the "Participants" window,
> > you'll see "You are
> > > > now the Presenter" on your screen, then in the menu hit "Share |
> > > > Application | select your open document window". You
> can share multiple
> > windows at once.
> > > >
> > > >
> > > >
> > > >
> > > > Brian Hart invites you to an online meeting using WebEx.
> > > >
> > > > Meeting Number: 204 708 684
> > > > Meeting Password: 11ac
> > > >
> > > > -------------------------------------------------------
> > > > To join this meeting (Now from mobile devices!)
> > > > -------------------------------------------------------
> > > > 1. Go to
> > > > https://cisco.webex.com/cisco/j.php?J=204708684&PW=NNDI3MmY2Nzg4
> > > >
> <https://cisco.webex.com/cisco/j.php?J=204708684&PW=NNDI3MmY2Nzg4>
> > > > 2. Enter the meeting password: 11ac
> > > > 3. Click "Join Now".
> > > > 4. Follow the instructions that appear on your screen.
> > > >
> > > >
> > > > ----------------------------------------------------------------
> > > > ALERT:Toll-Free Dial Restrictions for (408) and (919) Area Codes
> > > > ----------------------------------------------------------------
> > > >
> > > > The affected toll free numbers are: (866) 432-9903 for the San
> > > > Jose/Milpitas area and (866) 349-3520 for the RTP area.
> > > >
> > > > Please dial the local access number for your area from
> the list below:
> > > > - San Jose/Milpitas (408) area: 525-6800
> > > > - RTP (919) area: 392-3330
> > > >
> > > > -------------------------------------------------------
> > > > To join the teleconference only
> > > > -------------------------------------------------------
> > > > 1. Dial into Cisco WebEx (view all Global Access Numbers at
> > > >
> http://cisco.com/en/US/about/doing_business/conferencing/index.html
> > > >
> <http://cisco.com/en/US/about/doing_business/conferencing/index.html>
> > > > 2. Follow the prompts to enter the Meeting Number
> (listed above) or Access
> > Code followed by the #
> > > sign.
> > > >
> > > > San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330
> > > >
> > > > US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117
> > > >
> > > > India: +91.80.4350.1111 Germany: +49.619.6773.9002
> > > >
> > > > Japan: +81.3.5763.9394 China: +86.10.8515.5666
> > > >
> > > > http://www.webex.com <http://www.webex.com>
> > > >
> > > > CCP:+14085256800x204708684#
> > > >
> > > > IMPORTANT NOTICE: This WebEx service includes a feature
> that allows
> > > > audio and any documents and other materials exchanged
> or viewed during
> > > > the session to be recorded. By joining this session,
> you automatically
> > > > consent to such recordings. If you do not consent to
> the recording,
> > > > discuss your concerns with the meeting host prior to
> the start of the recording
> > or do not join the
> > > session. Please note that any such recordings may be
> subject to discovery in
> > the event of litigation.
> > > >
> > > >
> > > >
> > > >
> > > > To report this email as spam click here
> > > > <https://www.mailcontrol.com/sr/wQw0zmjPoHdJTZGyOCrrhg==
> > > > 7EAwh6aunJTqVygQ==> .
> > >
> > >
> > >
> > > Member of the CSR plc group of companies. CSR plc
> registered in England and
> > Wales, registered number
> > > 4187346, registered office Churchill House, Cambridge
> Business Park, Cowley
> > Road, Cambridge, CB4 0WZ,
> > > United Kingdom More information can be found at
> www.csr.com. Follow CSR
> > on Twitter at
> > > http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog
>