Fast Start issues

Douglas Clowes dclowes at OZEMAIL.COM.AU
Sun Dec 21 21:27:31 EST 1997


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:
>The answer to you question is ablsolutely yes.
>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?
>>>>We perceive an absolute market requirement for the shortest, simplest,
>>>>fastest, lightweightest, stupidest kind of Internet Telephones, ...
>>>>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
>>>>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
>>>>this is being done. This is the way to port standard call center stuff
>>>>IP seamlessly. The "call center gatekeeper" answers in one round trip
>>>>FastStart, sends a CONNECT, and then the ACD-function starts up the
>>>>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
>>>>of "you have end to end bearer NOW." The little fight over billing we
>>>>at SunRiver is only one of the issues. It is very confusing for people
>>>>systems to have CONNECT all of a sudden mean something else. Granted,
>>>>is nothing that we can do now about v1 systems, but we believe very
>>>>that every effort should be made to delay CONNECT until all
>>>>decisions are over, there is bearer, and talking/seeing can occur. This
>>>>what the CONNECT message is about. The fact is that it is possible to
>>>>H.245 upon CallSetup, and the system can take as long as it needs to do
>>>>"intelligence" before the CONNECT message. Remember that these
>>>>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

I can see a definite requirement to make simple (cheap) endpoints and avoid
building a whole lot of capability and intelligence (cost) into every

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
>>>>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
>>>>been listening to the IETF noise over this issue, you will know that
>>>>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


More information about the sg16-avd mailing list