Jim,
You've definitely captured the core technical functionality required. I
was hoping to get you to appreciate the big picture behind the technical
details so that you can understand why they are so important. It's at
this level we are perhaps not agreeing. But still, maybe that doesn't
matter so let's get on with looking for a technical solution.
I note your comments below. Although I don't entirely agree with them
on all counts, one of the wonders of the English language is that
different people can get different meanings from the same piece of text.
So if we can agree that we understood different things from the text,
we can move on...
Firstly I'm worried about sending multiple call proceedings/alertings to
an endpoint. Conceivably we could get the case that we receive a call
proceeding after alerting for example. This is definitely not valid
Q.931. We could say that any endpoint that accepts fastStart should be
able to cope with this case, but this involves multiple modifications to
the Q.931/H.225 state machine which I feel is undesirable. User
invitation and media establishment are in many respects orthogonal and
so making media negotiation conform to the invitation sequence is tying
one arm behind your back. What would be your comments if I suggested
moving the fastCaps stuff to the H323-UU-PDU field? This would allow us
to send the messages at any time (via FACILITY if necessary) without
affecting the Q.931 sequence and state. This should be OK as this is
what is being used for supplementary services. If this approach doesn't
work then we have a major problem, so any issues with it need to be
raised!!!
I'm also thinking about how the gatekeeper will transfer the
capabilities through itself. It will have to decode the messages (e.g.
setup) so that it can find the relevant information. It may then have
to change some of the fields before passing the message on. This will
mean re-encoding the message. If there is a mis-match in the version of
Capability supported by the endpoint and the gatekeeper then capability
information will get lost in this process. This means that endpoints
will not be able to achieve end-to-end negotiation of caps, and any new
codecs added by vendors will not be usable in this configuration. As I
envision faster evolution in the endpoint arena this seems a very real
proposition. To get around this problem it may be best to include the
capability information as an OCTET STRING. This allows the gatekeeper
to look at it, but also allows it to insert the information into an
outgoing message without having to have decoded it and re-encoded it
(i.e. it is just a copy operation) and so no information is lost.
I hope this moves us forward and not backwards!!! I look forward to
your comments,
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell(a)bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
>----------
>From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com]
>Sent: 09 December 1997 01:48
>To: pete.cordell(a)bt-sys.bt.co.uk; itu-sg16(a)mailbag.jf.intel.com
>Subject: Re: Pete Cordell's FastStart issues
>
>Pete,
>
>Thanks for you response. It looks like you have articulated some
>useful
>functionality
>in the ability to quickly switch media channels, but this is orthogonal
>to
>the FastStart sequence.
>
>I would be very interested in pursuing a light weight media switching
>in
>_all_ cases, independant
>of FastStart or any other control establishment that exists in H.323.
>
>I have tried to clarify and corrected some of your statements by
>referencing APC documents and presume
>that we are getting to the same 'wavelength'.
>
>
>Best Regards,
>jimt.
>
>
>
>> -----Original Message-----
>> From: Pete Cordell [SMTP:pete.cordell@bt-sys.bt.co.uk]
>> Sent: Monday, December 08, 1997 9:16 AM
>> Subject: RE: Pete Cordell's FastStart issues
>>
>> Jim et al.,
>>
>> I'm glad we've got a discussion going on this. This seems to be a
>> really big issue that can have a major impact on the future of H.323. I
>> know we're all really busy, but come January we will be stuck with what
>> ever we decide, so I'm hoping that other people can jump in here to
>> thrash out the issues as much as possible. The more input, the better
>> the solution is likely to be.
>
>To be honest, it looks like H.323 is having a serious impact even
>without
>V2..... :-)
>
>>
>> I've put comments in below. From the comments presented though I don't
>> think we are on the same wavelength yet, so most of the comments are
>> related to the problem space rather than any solutions.
>
>I thought we had agreement. The functionality that you would like is
>the
>ability to
>break and re-make 'connections' in a lightweight manner.
>(which I still assume are media channels, unless you tell me
>otherwise...)
>
>>
>> Pete
>> ================================> Pete Cordell
>> BT Labs
>> E-Mail: pete.cordell(a)bt-sys.bt.co.uk
>> Tel: +44 1473 646436
>> Fax: +44 1473 645499
>> ================================>
>>
>> >----------
>> >From: Jim Toga[SMTP:jtoga@ideal.jf.intel.com]
>> >Sent: 07 December 1997 19:18
>> >Subject: Re:Pete Cordell's FastStart issues
>> >
>> >Pete, (and others)
>> >
>> >Let me try and respond to your issues and hopefully we can resolve this
>> >in a relatively concise manner. Before we get started though I would like
>> >to make a couple of points clear:
>> >
>> >Recall that the "fast start" problem as stated previous to the Israel
>> >meeting and formalized in the contribution to that meeting, was the
>> >following. To provide a minimal round trip time connection sequence,
>> >for simple constrained calling scenarios. The requirement was to have
>> >minmal engineering impact to current shipping products and complete
>backward
>> >compatability.
>
>> I've looked through my notes and I can see any authoritative, exclusive
>> list of what the fast start should be expected to solve. I don't see
>> anything that said it should be restricted to "simple constrained
>> calling scenarios".
>
>There were verbal discussions before Israel, these were formalized in
>APC-1187 with the text:
>
>"Specifically with audio-only being the base system requirement, many
>current implementations
>are operating in this manner on the Internet. These environments
>provide
>many challenges to the
>implementers of these systems with regard to transmission delay,
>transport
>jitter, and overall reliability.
>Most if not all of these issues have been designed around by the
>developers, however there is
>one element that is inherent in the protocol and cannot be avoided;
>startup
>time.
>
>The number of RTT (round-trip-times) that occur in the normal startup
>of an
>H.323 call is typically
>4 by the time the first media channel is open, assuming that both ends
>are
>truly asynchronous.
>(Setup-Connect, Cap Sets, M/S, OLC). On the Internet, this number of
>RTTs
>can lead to very long
>connect times, independent of the quality of the implementation. Users
>expectations
>(such as those using H.323 for Internet-telephony) may never be met in
>some
>situations.
>The solution to this, is to simply cut down on the number of RTTs - an
>optimal number would be 1.
>
>The idea is to provide a mechanism by which an H.323 terminal could
>call
>another terminal and operate
>in a fast mode (i.e. audio only) using only the Setup-Connect
>sequence.
>The called terminal
>would always have the option of refusing this fast mode and
>continuing
>in the standard manner."
>
>This same text was in APC-1306 at Sun River and was approved without
>changes.
>
>
>> >
>> >I have always been a proponent of Gatekeepers and the functionality,
>> >features, and services that they can provide.
>> >
>> >Everyone (including you), supported the final version of FastStart
>> >which came out SunRiver with the additions of bi-directional capabilities.
>> >With the presentation of your alternative approach there was never any
>clear
>> >motivation for developing the more complicated version other than you
>> >'didn't like' the current form. I'm happy to see you've presented a
>> >real issue to which you would like a solution.
>> >
>> >I would like codify my understanding of your issues and see if we can
>> >find a solution to them. I _think _you imply the need for a low overhead
>> >'mode switch' which really has nothing to do with FastStart, but let me
>see
>> >if I understand your points.
>
>> To me connection setup (i.e. user-to-user connection) is pretty much all
>> that H.323 is about. Once a connection is setup there is little more
>> for H.323 to do, other than tear-down.
>
>
>I'm still confused by what you mean by connection. By 'call startup'
>what
>is meant in the above
>APC's is the point at which the caller and callee can begin exchanging
>media.
>
>> >
>> >
>> >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote:
>> >[SNIP]
>> >> Each user has an account on the system. They can use
>> >>it as a single number by which to contact them by. As you move from
>> >office to home to mobile, you configure it using a web browser with
>> >>the number to contact you on. People trying to contact you dial a
>> >>single number and the platform forwards the call to the correct location.
>> >> It also allows people to leave voice messages on the system.
>> >>Additionally you can configure it to do things like try the office phone
>> >>first, then the mobile and if that doesn't work leave a message. This
>> >>sort of flexibility is not easily addressed by a directory. It
>> >>can also receive e-mails and faxes etc.
>> >>
>> >[SNIP]
>> >
>> >>This is admittedly not rocket science, and you've probably come across
>> >>services like this already. Our job is to move this to the IP world.
>> >
>> >Why can't you can accomplish this today (in R2) with the multiple alias
>> >registrations (that fact that you may use WEB front end is irrelevent)?
>> >The Gatekeeper then has his 'rotary switch' of locations to look
>>through to
>> >find the current active location. This is much like (if not exactly)
>> >VocalTec's CMA architecture.
>
>> Your right, the configuration side of things is not the issue.
>
>> >
>> >>Product Impact
>> >>=============> >>To understand the impact of this on the protocol,
>>let's look at the case
>> >>of using a search algorithm to look for a user and also returning a call
>> >>after interrogating the voice bank.
>> >>
>> >
>> >Tying user-network signalling to network-network signalling in the
>> >protocol is bad practice, limiting and cumbersome.
>
>> I agree, network-network signalling is for another day. However this
>> issue is very much in the user-network signalling area. The issues
>> remain even if only one gatekeeper is involved (which hopefully implies
>> that there is no network-network signalling).
>
>I still don't think we want to burden the endpoints with a 'search
>algorithm to look for a user'.
>The user-network signaling is contained in the ACF (or perhaps a GK
>routed
>Setup) anything
>more complicated seems a lot like network-network signalling. (Or at
>least
>for further study :-) )
>
>> >
>> >>Let's assume the system is configured to contact my work number first
>> >>and them my mobile number. In this case the final connected endpoint is
>> >> not known until the CONNECT message is received. Hence the
>> >>capabilities of the endpoint you will be talking to are not known for
>> >>sure until you get CONNECT.
>> >
>> >I see this, and agree it is entirely true. It has no effect however on
>> >the the capabilities of the _calling_ party. They _are_ known, and there
>> >is no reason why the possibile capabilities should change.
>
>> Correct
>
>> >
>> >>This is not a problem with the basic call setup sequence as the H.245 is
>> >>not established until after CONNECT.
>> >
>> >This is not quite true. There has been the ability (since 3/96) to
>> >start H.245 at any point after the SETUP message is received. This
>required
>> >two things, which by the way would be required in all of these scenarios.
>> >
>> >The caller and callee has to be able to deal with H.245 and possibly
>> >media, 'early'. The caller has to place the H.245 port in the Setup
>message.
>> >(Alternatively the callee can place the H.245 port in the Call
>> >Proceeding/Alerting message)
>
>> True, but hopefully you'll agree with me that in this case the
>> gatekeeper could delete any H.245 addresses from messages other than
>> CONNECT and it would get the desired behaviour.
>
>As you point out, the Gatekeeper has full control. In fact it can
>enable
>or disable the FastConnect
>sequence as well.
>
>>This seems to be a pretty NULL operation as nobody seems to be sending
>H.245 addresses in
>> messages other than connect anyway.
>
>Exactly point the point I made below concerning the Facility message.
>Endpoint manufactures
>would like to have the option of a low impact, one roundtrip connect
>sequence.
>
>> >
>> >>However, with fast connect we want to start capability negotiation as
>> >>soon as possible, and are not able to wait until CONNECT.
>> >
>> >The Determined version of FastStart DOES do a full capability exchange
>> >before the CONNECT. (althought it does not provide for an iterative
>> >_negototiation_, as this defeats the Fast portion of FastStart).
>
>> I have problems with saying the FastStart shall be 1 round trip or bust.
>> The intent seems to have been that a minimum of round trips should be
>> used compatible with negotiation, security etc. If a particular case
>> requires an extra round trip, then that is the minimum number of round
>> trips that case can be set up in. That doesn't break fastStart. I
>> would say it's good because it has meant that we don't fall back to the
>> 6 1/2 round trips that we typically need.
>
>No, actually the original intent (see above) was to establish a one
>round
>trip method.
>The negotiation is poorly termed it really should be called
>'capabilities
>exchange'.
>Both this, and security require no extra messages or round trips.
>
>> >
>> >>This also has the benefits that we can listen to announcements prior to
>> >>the CONNECT message (such as "The number you have dialled has
>> >>changed, but we are re-routing you anyway").
>> >
>> >This is EXACTLY what FastStart provides as soon as the Setup is
>> >recieved, the recipient may start playing media back to the caller. The
>caller
>> >may be constrained from sending media to the callee until the Connect is
>> >received - just as it works in the circuit world.
>
>> I was trying to capture the issues here, not saying that the current
>> fast start doesn't meet any of them. Basically we have conflicting
>> requirements here 1) we want to establish media prior to CONNECT to
>> allow announcements, 2) we want to delay establishing media until after
>> CONNECT so that the gatekeeper can do some intelligent stuff. This is
>> what makes this topic so interesting!!!!
>
>Seems like you _have_ established the media stream back to the caller;
>it is
>just that you are switching the ultimate source of that media. In the
>case
>you
>describe, it seems like you want the protocol signalling to be aware of
>this -
>I'm not sure why.
>
>> >
>> >>However, if the system gives up ringing my work number and then tries
>> >>the mobile number, it has to present a new set of capabilities to the
>> >calling endpoint.
>> >
>> >That is true, and this can occur by simply sending another Call
>> >Proceeding message (or Alerting) with the new caps. There is no need
>however for
>> >the _caller_ change or otherwise resend its caps..... In other words the
>> >Gatekeeper will still be presenting the same set to the subsequent
>> >callees as it polls them.
>
>> You're right that the caller does not have to generate new caps.
>> However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint
>> breaks H.225, and so would not be backwards compatible.
>
>Why does it break H.225.0? FastStart will not be supported by Rev1
>endpoints in any case
>which is why there is backward compatible signalling.
>> >
>> >>Now I'm in the mode of interrogating the voice messages that have been
>> >>left for me. My endpoint is connected to the sub-system that plays out
>> >>the recorded messages and it asks me if I want to return the
>> >>call. To do this the system needs to create an outgoing call, and
>> >>locally generate a ringing tone. When the remote party answers the two
>> >>endpoints need to be connected together.
>> >
>> >This is either some form of a transfer (from a protocol point of view)
>> >or shouldn't it be hidden from the endpoint in terms of signalling?
>
>> In a distributed world there is only so much that you can hide from an
>> endpoint. That's why this topic is so important. To roll out customer
>> friendly services the endpoints need to support some basic capabilities.
>> Hopefully this is worth endpoint vendors doing as useful services mean
>> that people can use there endpoints for more things. Thus the
>> technology is more likely to catch on, than if you are only likely to
>> get reasonable service from a call centre via good old POTS.
>
>It would seem to me that endpoint vendors would make a trade-off on
>what
>customers request for functionality vs the general industry support and
>ease of implementation
>of that functionality.
>
>I do know of one vendor :-) that is interested in making sure that
>rolling
>out of "customer friendly services"
>is possible, and for customers to utilize endpoints for more "things".
>
>> >
>> >>You may say that the FACILITY message could be used to do this. However,
>> >>the caller has state stored
>> >>in the platform/gatekeeper (such as where they are in the menus etc.) so
>> >>that when they finish this new call they can go back to interrogating
>their messages.
>> >>This would not be possible with the FACILITY approach.
>> >
>> >It would seem that exposing this bookkeeping/signalling would require a
>> >_large_ commitment on the part of all the endpoint manufacturers -
>> >wouldn't it be better to provide this in an 'invisible' way? Aside from
>the
>> >complexity/compatibiliy issues it provides for product differentiation.
>
>> I think you're agreeing with me that the FACILITY way is a bad way to go.
>
>> >
>> >>
>> >>WOW that's complicated!!!
>> >>========================> >>At first sight this appears horrendous,
>>but in actual fact it is quite
>> >>simple. All it requires is for the platform/gatekeeper to be able to
>> >break connections and re-establish
>> >>new connections when it wants to.
>> >
>> >AAHHH.... so this is what you wanted! This _does_ seem like a
>> >'transfer' type of thing, in any case it would appear to be
>>independant of
>> >FastStart.
>
>> A setup is almost invariably part of transfer, so I don't see that you
>> can call them independent. Anyway, the report from Hertzliya says
>> support for supplementary services should be included in fast setup.
>
>Actually the meeting report said just the opposite. In APC-1249 (the
>meeting report) on page 8 it says
>
>"A. Supplementary services must consider fast cut-thru, and...."
>
>
>A Setup is invariably part of transfer, but only if that transfer
>envolves
>the _control channel_.
>It is not clear that you wanted this, I thought we were talking about
>media. During your sequence does
>the Gatekeeper 'get out of the way' when the final endpoint is found?
>Or
>for the duration of the call
>does the Gatekeeper act as a 'proxy' for the other endpoint ? (i.e.
>stay in
>the Gatekeeper routed model)
>
>> >
>> >I have to admit, I'm not sure what you mean by 'connection' though. Is
>> >this simply logical media channels, or is it a larger concept?
>
>> I'm really mean establishing some sort of media exchange between users
>> such as audio or video.
>
>OK, so OpenLogicalChannels, not establishing H.225.0 or H.245?
>
>> >
>> >[SNIP]
>> >
>> >>
>> >>So where's the problem
>> >>=====================> >>The problem is that I can not make use of
>>the fast setup scheme with
>> >>these services, because it does not support the break and make
>> capability.
>> >
>> >This is _new_ functionality that was never listed as a requirement of
>> >FastStart, and I would argue that 'breaking and making connections'
>> >goes against the scope of the FastStart usefulness.
>> This is where I totally disagree. The list of fast start requirements
>> was never exclusive. We announced our requirements for fast start and
>> no body objected to them, and some even backed them up. If you had
>> objections you should have raised them at the time.
>> >
>> >>To do these services I need tofall back to H.245. If the
>> >>standard setup is not good enough for a basic point-to-point call then
>> >>it is not good enough for entities that introduce intelligence which in
>> >>fact have more stringent timing
>> >>requirements because the breaks and makes are more difficult to conceal
>> >under things like ringing.
>> >
>> >The 'standard setup' is no way "not good enough" for basic
>> >point-to-point operation. It simply as case that in certain well
>defined (resources
>> >and entities known) that optimizations can and should be made to
>>operate in
>> >simple low delay environments.
>> >
>> >>Assuming that the reason for implementing the gatekeeper routed model is
>> >>to add these sorts of features, then really the gatekeeper routed model
>becomes a second class citizen. This
>> >>is a problem for us.
>> >
>> >The Gatekeeper should most definitely NOT be constrained from adding
>> >features and providing expanded services. The Gatekeeper routed model
>> >was specifically developed to hide this complexities from the
>>endpoints, in
>> >fact the endpoint cannot even tell which mode it is running in other
>> >than a bit in the ACF.
>> >
>> >The Gatekeeper is no more or less a "second class citizen" with
>> >FastStart as with the 'standard' signaling. In fact I believe that it
>has even
>> >more control, because it may provide an asymmetrical connection on either
>> >side of itself forcing either the caller or callee into a particular
>mode of
>> >operation.
>
>> If the standard startup is good enough then we seem to be taking
>> elaborate measures to tune the efficiency of the "standard setup".
>
>In general, you can either have it 'fast' or you can have 'powerful and
>flexible'.
>I'm not implying at all that it should be an either/or situation. Why
>do
>we allow different
>media codecs? Some modes are better for one situation, some are better
>for
>others.
>
>> Either the standard setup is good enough or it isn't. If it is good
>> enough then we don't need fast start. I happen to think that it is not
>> good enough. Hence we need a solution that is good enough for the basic
>> call model and is also good enough for those of us that want to add
>> value. If we don't achieve this, then as far as I can see the
>> gatekeeper routed model can only become a second class citizen.
>
>I just don't understand this statement. The basis for being a 'second
>class citizen' seems
>to be that Gatekeepers don't have a special mode to swap media channels
>which no other entity
>has either. Again, this just seems to be completely orthonganl to
>FastStart.
>
>> >
>> >>
>> >>Where to go next
>> >>===============> >>To do what I need to do, I need a fast method for
>>making and breaking
>> >>connections without first establishing the TCP connection, negotiating
>> >>caps, MSD, OLC, OLC ACK,
>> >>and then sending media. We could achieve this by adding a break command
>> >>to the FACILITY message and then having the ability to send new
>> >>fastCaps at any time to make a new connection. This seems a minimal
>> >>change from where we are at the moment and such a change would be fine
>> >>by me.
>> >
>> >Again I'm not clear on what you mean by 'connections', but assuming
>> >that you mean something like an audio channel (say 711-->723.1) than I
>think
>> >there are a number of fine options we can pursue. (for example H.245
>> >has established a 're-open' command.)
>> >
>> >>
>> >>However, I know that Glen is interested in always running an MC, so he
>> >>would want to add extra features. Others will probably also want
>>features
>> >>that have been carefully crafted
>> >>into H.245. As a result we are likely to get feature creep so that more
>> >and more H.245 functionality is put into H.225.
>> >
>> >I completely agree that it would be a very bad thing to re-invent H.245
>within H.225.0.
>> >
>> >> I also have concerns about having two ways and two APIs (fast and slow)
>> >> for doing things. This explains my attempt to re-use as much of H.245
>as possible.
>> >
>> >To pick a nit, we're not talking about API's; there is one way within
>> >the protocol to establish an H.245 connection. If you need these
>>features,
>> >flexibility and control; this is what you should do. That being said
>> >there are two forms of Setup/Connect messages for those
>> >Endpoints/Gatekeepers/MCUs that would like to utilize them.
>
>> To pick more nits ( :-) ), we at some point have to build what we
>> propose. Therefore, we can not conceive of protocols in isolation of
>> how we will build them. If one protocol idea is easier to develop than
>> another then we should go with that one. So although the ITU is not
>> bothered with APIs, we as contributors, should be.
>>
>> Most stacks that I am aware of separate out the Q.931 part and the H.245
>> part. At the moment the H.245 part knows about caps and the Q.931 part
>> does not. To put caps in Q.931 we need to put an API on the Q.931 part
>> that accepts caps. Therefore we really do have two APIs, which is an
>> issue.
>
>I can't comment on your development environment or platform, I only
>know it is
>not an issue in many of the currently shipping products.
>
>> >
>> >>
>> >>But let me reassure you I have no requirement to use H.245! I have a
>> >>requirement to solve the problem presented above.
>> >
>> >The problem is to 'break and make' connections with minimal
>> >overhead?.....
>
>> Yep
>
>> >
>> >>
>> >>A little history
>> >>===============> >
>> >[SNIP].
>> The issues raised here are hopefully covered off elsewhere.
>> >
>> >>
>> >>To sum up
>> >>========> >>To differentiate I want to add intelligence to my
>>platform (effectively
>> >>a gatekeeper). If I can't use fast setup as part of this people will
>> >>either use the direct call model,
>> >>or use dumb gatekeepers. Basically the gatekeeper routed model will
>>loose
>> >out.
>> >
>> >Nothing you have described so far is either helped or hindered by
>> >FastStart, this point is completely irrelevent. As I said above,
>> >Intel has always believed in the value of Gatekeepers to H.323 systems.
>I'm
>> >surprised that you didn't present a contribution to provide
>> >lightweight 'connection switching' in a general manner.
>
>> The point really is that it has not helped......
>
>> >
>> >>
>> >>Hence I need fast setup to be useful for a gatekeeper adding
>> >>intelligence, which basically means being
>> >>able to quickly break and make connections.
>> >
>> >This is great! If this is what you require, lets come to quick
>> >agreement on this and move on.
>> >
>> >>
>> >>I have presented a solution that I believe meets these requirements.
>> >>But if there is another way of meeting my requirements then I would be
>> >only too happy to adopt it.
>> >>
>> >
>> >Here are my suggestions that I _think_ provide the functionality you
>> >desire:
>> I think it's important that we try to sort out the problem we are
>> solving first. If you feel we are on the same wavelength then we can
>> move on to the technical implementation, but I don't think we are quite
>> there yet. I hope this has helped. Besides, I would also like more
>> time to think about what you have proposed.
>> >
>> >
>> [SNIPPED, but not forgotten]
>> >
>> >Does this solve your issues?
>>
>> This is a good start and I'm confident that in a few rounds we can get
>> there. Thanks for the time you've put into this Jim. You may not thank
>> me now, but I'm sure that in a few years you (or your company) will
>> thank me for bringing this all up!!!! (well say 10 years. Or not more
>> than 20 years. Well not much more than 20 years....)
>
>Let's keep slogging away, You know I'll always thank you Pete... :-)
>I'm hoping that I have picked the issue that you would like to solve
>and that
>one of the previous solutions works for you.
>
>> >
>> >Best Regards,
>> >jimt.
>> >
>>
>> Pete
>> >
>
>
>************************************************************************
>*
>*** +1-503-264-8816(voice) +1-503-264-3485(fax)
>***
>*** jtoga(a)ibeam.intel.com Intel - Hillsboro, OR.
>***
>*** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41***
>************************************************************************
>*
>
