Re: Fast Start issues
Tom,
The answer to you question is ablsolutely yes.
jimt.
At 12:34 PM 12/18/97 -0500, you wrote:
I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing?
-----Original Message----- From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] Sent: Thursday, December 18, 1997 8:45 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Fast Start issues
Scott,
Thanks for your lengthy reply...
What I was hoping to indicate was that for certain call scenarios you want media established before CONNECT, but for other scenarios this is not possible.
A situation where you have to send CONNECT before the media is negotiated is when multiple phones are rang and the first one is answered. There are probably others.
The point is that some flexibility is required on this point.
I agree with your comments about mandating that fast start should allow for H.245 to be started at any time. I didn't contest the wording as it seemed to me that whatever wording was in the standard, if it suited a vendor they could quite easily ignore any request to do fast start. This would total destroy any attempt to deliver some services and is hence a problem for us.
I'm also interested that you state that you are looking for light-weight systems that do not use H.245. Firstly this is in conflict with the wording at the moment. Secondly, it is only an illusion of a simpler implementation, as much of H.245 is being copied into H.225 (work out how much of H.245 is included into H.225 just by referencing Capability).
As to how CONNECT works in the switched network, it seems that the called endpoint sends CONNECT before the bearer path is in place. The final switch will connect the bearer when it receives CONNECT. The CONNECT is then forwarded. The point is that the CONNECT is sent before the bearer is connected through, but the bearer is connect through by the time CONNECT is received. This is difficult to emulate in our environment. You can't just delay the CONNECT in the gatekeeper until the media is established because the user is concerned with the time from 'picking up the handset' to when they can speak and are not concerned with how this relates to the timing of the CONNECT message. Some one said the switched network delay in this instance is less than 100ms.
Regards,
Pete
Pete Cordell BT Labs E-Mail: pete.cordell@bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================
From: Scott Petrack[SMTP:Scott_Petrack@VOCALTEC.COM] Sent: 18 December 1997 01:52 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Fast Start issues
Friends, and especially Pete,
It really does seem to me that it is possible to get everyone happy. I would like to try and convince you (Pete) that: a. you can get EXACTLY what you need, in the fastest, most correct way possible, right now, and b. Intel's FastStart is really an important and useful thing as is for H.323.
It is possible that a single sentence needs to be added to the FastStart text (see below in the paragraph starting "The thing that you require..."). But mainly I believe that there is a small misunderstanding going on, which is main the source of the problem.
Pete, to get this extra "intelligence" you want, I believe that in most cases you must use gatekeeper routed signalling. The called gatekeeper, acting as a proxy for the called user, must send the H.245 port in the CallProceeding message, H.245 negotiation must be used, and the CONNECT message must come at the end, after all location/media negotiations are over and media is available.
I say "in most cases" because there are some cases where you will probably choose to do some intelligence in the LRQ phase, before the CallSetup is sent. In these cases it might be possible to know that the CallSetup message is really being sent to the correct Terminal, and so you can then use FastStart to that Terminal. There are also other cases where you may choose to do FastStart with to the user's gatekeeper, have the gatekeeper play out a prompt saying something like "we are looking for your user now", have the gatekeeper do H.245 negotiation with the caller on behalf of the callee, and in the end establish a new media channel to the final negotiated endpoint, breaking the original media channel negotiated with the gatekeeper in the FastStart. All this can be done now by using a combination of FastStart and "classic" H.323 signalling.
The "misunderstanding" I was alluding to earlier is this: you are correct that most endpoints until now unfortunately did CONNECT before media negotiation. This is a very unfortunate breaking of Q.931 semantics which could have been avoided, and we should try hard to return to the normal situation where CONNECT is sent only at the end of the entire call establishment procedure. My problem is with the 2nd requirement you gave in an earlier posting:
we want to delay establishing media until after CONNECT so that the gatekeeper can do some intelligent stuff.
I definitely DON'T want to delay establishing media until after CONNECT. And I claim that this is NOT needed for the gatekeeper to do some intelligent stuff.
The thing that you require, that is not quite there in the current FastStart proposal, is that "even if a connection is made using FastStart, it shall be possible for either endpoint to start H.245 negotiation at any point in the conversation". I would be willing to go with this in the spirit of compromise. (although personally I feel that such "shalls" are about as strong as "An H.uman endpoint shall not eat pork." Lot's of people who claim "Bible compliance" do not follow this shall, and somehow the world continues to interoperate...)
We at VocalTec, as part of our CMA work, support many of the scenarios you talk about, and we do it quite quickly (we think as quickly as logically possible in fact). Some of them require H.245, some require gatekeeper routed signalling, some can be done with FastStart alone.
I want to go on record saying that we DEFINITELY want to encourage finishing the H.245 negotiation before CONNECT if it happens. This function is in H.323 now, and it is *the thing* that allows us to do the scenarios that Pete seems to want. We believe that this is how complex services will have to work in H.323. This allows H.245 and H.225 to go completely independently and in parallel, and the poor CONNECT message can just be the final word saying "you're on the air". Logically, if you need H.245 for your call, this is the fastest possible way to get it.
You may be thinking, quite correctly "If Scott thinks that the next generation of terminals is going to do H.245 before CONNECT then why in the world does he need FastStart?" This is a good question, but it has a very good answer (I'll bet you thought I would have one....)
We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, and that a system that cannot support such devices will be very vunerable to attack from competing systems that can. It is very important to be able to build "dumb telephone systems" as well as "intelligent ones". FastStart is a great step forward for dumbness ;-). (sorry Jim).
At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold.
The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245.
I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323.
Sincerely,
Scott Petrack
Jim,
The equally simple-minded follow-on question is how (does a terminating gateway connected to the POTS differentiate between a callee and a recorded service announcement)?
At 08:36 19/12/97 -0800, you wrote:
Tom,
The answer to you question is ablsolutely yes.
jimt.
At 12:34 PM 12/18/97 -0500, you wrote:
I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing?
[SNIP]
We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, ...
[SNIP]
At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold.
The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245.
I can see a definite requirement to make simple (cheap) endpoints and avoid building a whole lot of capability and intelligence (cost) into every endpoint.
A mechanism to connect an endpoint (PSTN Gateway) to an intermediate (IVR) system without triggering billing would be useful. This would allow call processing intelligence to be located outside the endpoint and utilised only during call-setup. The intermediate (IVR) system would then need to be able to redirect the call to either another intermediate system or the ultimate endpoint.
I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323.
I agree, we do need to be able to connect media (at least DTMF forward and voice reverse) before a final CONNECT. An "interim" non-chargeable "CONNECT" followed by a "REDIRECT" and final chargeable "CONNECT" is an alternative possibility. Chargeability and connected media are not the same thing.
Douglas
Douglas,
I would expect that that would be entirely a local implementation issue with the gateway. The calling endpoint is simply going to get a media stream back. I can think of reasons why the gateway might want to differentiate between a 'canned' and live stream. At the same time, I can think of reason why the implementation would want to be oblivious to it.
Regards, jimt.
At 01:27 PM 12/22/97 +1100, you wrote:
Jim,
The equally simple-minded follow-on question is how (does a terminating gateway connected to the POTS differentiate between a callee and a recorded service announcement)?
At 08:36 19/12/97 -0800, you wrote:
Tom,
The answer to you question is ablsolutely yes.
jimt.
At 12:34 PM 12/18/97 -0500, you wrote:
I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing?
[SNIP]
We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, ...
[SNIP]
At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold.
The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245.
I can see a definite requirement to make simple (cheap) endpoints and avoid building a whole lot of capability and intelligence (cost) into every endpoint.
A mechanism to connect an endpoint (PSTN Gateway) to an intermediate (IVR) system without triggering billing would be useful. This would allow call processing intelligence to be located outside the endpoint and utilised only during call-setup. The intermediate (IVR) system would then need to be able to redirect the call to either another intermediate system or the ultimate endpoint.
I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323.
I agree, we do need to be able to connect media (at least DTMF forward and voice reverse) before a final CONNECT. An "interim" non-chargeable "CONNECT" followed by a "REDIRECT" and final chargeable "CONNECT" is an alternative possibility. Chargeability and connected media are not the same thing.
Douglas
************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************
Jim,
I'm not sure which 'that' you are referring to as 'a local implementation issue' but suspect it still depends on your point of view, the gateway or another (gatekeeperlike) device trying to add value to a 'dumb' gateway without triggering unwanted behaviour - like billing.
If the POV is the gatekeeper and the gateway is from someone else, defined behaviour would be nice to have :). If I ask the GW to (FastStart) connect to an IVR server for pre-call processing ('enter the number you wish to call') it would be nice to know that media is connected both ways and that billing has not been triggered, irrespective of local gateway implementation issues.
If my POV is from the gateway then, my owners (and maybe their customers) would like me to know when chargeable service has commenced and terminated. It would simplify things if CONNECT meant 'chargeable end-to-end bearer is available' and end-to-end meant caller to callee rather than their respective gateways. An additional message to indicate this end-to-end state, like answer supervision, is an option.
Regards,
Douglas
At 08:56 22/12/97 -0800, you wrote:
Douglas,
I would expect that that would be entirely a local implementation issue with the gateway. The calling endpoint is simply going to get a media stream back. I can think of reasons why the gateway might want to differentiate between a 'canned' and live stream. At the same time, I can think of reason why the implementation would want to be oblivious to it.
Regards, jimt.
At 01:27 PM 12/22/97 +1100, you wrote:
Jim,
The equally simple-minded follow-on question is how (does a terminating gateway connected to the POTS differentiate between a callee and a recorded service announcement)?
At 08:36 19/12/97 -0800, you wrote:
Tom,
The answer to you question is ablsolutely yes.
jimt.
At 12:34 PM 12/18/97 -0500, you wrote:
I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing?
[SNIP]
We perceive an absolute market requirement for the shortest, simplest, fastest, lightweightest, stupidest kind of Internet Telephones, ...
[SNIP]
At the risk of repeating myself, even in the some of the scenarios Pete mentions it is useful to use FastStart. It allows a gatekeeper to answer immediately (i.e. "as fast as possible") and reassure the caller that although the system may take a few seconds to find the user and negotiate, this is being done. This is the way to port standard call center stuff to IP seamlessly. The "call center gatekeeper" answers in one round trip with FastStart, sends a CONNECT, and then the ACD-function starts up the real H.245 as part of its thing while blasting out music on hold.
The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the CONNECT message. We believe that we in the H.323 community should do everything possible to return the CONNECT message to its true Q.931 meaning of "you have end to end bearer NOW." The little fight over billing we had at SunRiver is only one of the issues. It is very confusing for people and systems to have CONNECT all of a sudden mean something else. Granted, there is nothing that we can do now about v1 systems, but we believe very deeply that every effort should be made to delay CONNECT until all media/location decisions are over, there is bearer, and talking/seeing can occur. This is what the CONNECT message is about. The fact is that it is possible to do H.245 upon CallSetup, and the system can take as long as it needs to do "intelligence" before the CONNECT message. Remember that these intelligent things take some time, at least a few round trips, and in our experience if you start doing them you have plenty of time to negotiate media via H.245.
I can see a definite requirement to make simple (cheap) endpoints and avoid building a whole lot of capability and intelligence (cost) into every endpoint.
A mechanism to connect an endpoint (PSTN Gateway) to an intermediate (IVR) system without triggering billing would be useful. This would allow call processing intelligence to be located outside the endpoint and utilised only during call-setup. The intermediate (IVR) system would then need to be able to redirect the call to either another intermediate system or the ultimate endpoint.
I hope that it is clearer now why I have a problem with any scheme to "delay establishing media until after the CONNECT message." This is a bad habit that we need to end. I hope too that it is clearer why I like the FastStart. We need good old dumb "black telephone service." If you have been listening to the IETF noise over this issue, you will know that this attack on H.323 is being taken seriously by many customers. Fast Start answers that attack and adds a real new feature to H.323.
I agree, we do need to be able to connect media (at least DTMF forward and voice reverse) before a final CONNECT. An "interim" non-chargeable "CONNECT" followed by a "REDIRECT" and final chargeable "CONNECT" is an alternative possibility. Chargeability and connected media are not the same thing.
Douglas
*** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41***
Douglas,
My comments are embedded below....
Regards, jimt.
At 02:59 PM 12/23/97 +1100, you wrote:
Jim,
I'm not sure which 'that' you are referring to as 'a local implementation issue' but suspect it still depends on your point of view, the gateway or another (gatekeeperlike) device trying to add value to a 'dumb' gateway without triggering unwanted behaviour - like billing.
The 'that' to which I was referring is the comment you made initially, the ability to "differentiate between a callee and a recorded service announcement"
If the POV is the gatekeeper and the gateway is from someone else, defined behaviour would be nice to have :). If I ask the GW to (FastStart) connect to an IVR server for pre-call processing ('enter the number you wish to call') it would be nice to know that media is connected both ways and that billing has not been triggered, irrespective of local gateway implementation issues.
It seems like you are tying a specific relationship between the onset of bidirectional media and billing triggers. In general I believe this is a valid assumption although there are probably specific exceptions (such as the 'service announcement'). This issue with the GW example is whether or not someone is triggering billing based upon the end-end connection or simply the 'leg' between the IP client and the GW. If it is the latter, I'm not sure what can be done for the 'service anouncement' that are sourced on the far side of the GW assuming you wait for the Connect to pass the media....
If my POV is from the gateway then, my owners (and maybe their customers) would like me to know when chargeable service has commenced and terminated. It would simplify things if CONNECT meant 'chargeable end-to-end bearer is available' and end-to-end meant caller to callee rather than their respective gateways. An additional message to indicate this end-to-end state, like answer supervision, is an option.
AAhh... I understand the scenario now. The current mechanism works fine for this. The GWs should never pass Connect unless the 'ultimate' endpoint has accepted the call. Prior to that, bi-directional media may be exchanged/addressed using either the CallProceeding or Alerting messages. It seems that the hard part is how a 'near' GW 'knows' that the media during this time is to be trusted as coming from a 'system announcement' type source. (i.e. the 'far' GW must be trusted.....and vice-versa)
Regards,
Douglas
At 08:56 22/12/97 -0800, you wrote:
Douglas,
I would expect that that would be entirely a local implementation issue with the gateway. The calling endpoint is simply going to get a media stream back. I can think of reasons why the gateway might want to differentiate between a 'canned' and live stream. At the same time, I can think of reason why the implementation would want to be oblivious to it.
Regards, jimt.
At 01:27 PM 12/22/97 +1100, you wrote:
Jim,
The equally simple-minded follow-on question is how (does a terminating gateway connected to the POTS differentiate between a callee and a recorded service announcement)?
At 08:36 19/12/97 -0800, you wrote:
Tom,
The answer to you question is ablsolutely yes.
jimt.
At 12:34 PM 12/18/97 -0500, you wrote:
I have what may be a simple-minded question relating to the availability of media before CONNECT. In a situation where the called party is on the GSTN, the terminating switch may return announcements or tones under some circumstances. In an all-GSTN situation the caller would hear these without getting billed. As a typical example, an announcement might inform the subscriber that "The number you have reached is not in service". Can we achieve this result with Fast Start, without triggering billing?
[SNIP]
>We perceive an absolute market requirement for the shortest, simplest, >fastest, lightweightest, stupidest kind of Internet Telephones, ...
[SNIP]
>At the risk of repeating myself, even in the some of the scenarios Pete >mentions it is useful to use FastStart. It allows a gatekeeper to >answer >immediately (i.e. "as fast as possible") and reassure the caller that >although the system may take a few seconds to find the user and >negotiate, >this is being done. This is the way to port standard call center stuff >to >IP seamlessly. The "call center gatekeeper" answers in one round trip >with >FastStart, sends a CONNECT, and then the ACD-function starts up the >real >H.245 as part of its thing while blasting out music on hold. > >The gatekeeper can do intelligent stuff by bringing up H.245 BEFORE the >CONNECT message. We believe that we in the H.323 community should do >everything possible to return the CONNECT message to its true Q.931 >meaning >of "you have end to end bearer NOW." The little fight over billing we >had >at SunRiver is only one of the issues. It is very confusing for people >and >systems to have CONNECT all of a sudden mean something else. Granted, >there >is nothing that we can do now about v1 systems, but we believe very >deeply >that every effort should be made to delay CONNECT until all >media/location >decisions are over, there is bearer, and talking/seeing can occur. This >is >what the CONNECT message is about. The fact is that it is possible to >do >H.245 upon CallSetup, and the system can take as long as it needs to do >"intelligence" before the CONNECT message. Remember that these >intelligent >things take some time, at least a few round trips, and in our >experience if >you start doing them you have plenty of time to negotiate media via >H.245.
I can see a definite requirement to make simple (cheap) endpoints and avoid building a whole lot of capability and intelligence (cost) into every endpoint.
A mechanism to connect an endpoint (PSTN Gateway) to an intermediate (IVR) system without triggering billing would be useful. This would allow call processing intelligence to be located outside the endpoint and utilised only during call-setup. The intermediate (IVR) system would then need to be able to redirect the call to either another intermediate system or the ultimate endpoint.
>I hope that it is clearer now why I have a problem with any scheme to >"delay establishing media until after the CONNECT message." This is a >bad >habit that we need to end. I hope too that it is clearer why I like the >FastStart. We need good old dumb "black telephone service." If you >have >been listening to the IETF noise over this issue, you will know that >this >attack on H.323 is being taken seriously by many customers. Fast Start >answers that attack and adds a real new feature to H.323.
I agree, we do need to be able to connect media (at least DTMF forward and voice reverse) before a final CONNECT. An "interim" non-chargeable "CONNECT" followed by a "REDIRECT" and final chargeable "CONNECT" is an alternative possibility. Chargeability and connected media are not the same thing.
Douglas
*** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41***
************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga@ibeam.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************
participants (2)
-
Douglas Clowes -
Jim Toga