Fast Start issues

[Jim Toga]

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 at ibeam.intel.com              Intel - Hillsboro, OR.        ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
*************************************************************************