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***