Fast Start issues

Douglas Clowes dclowes at OZEMAIL.COM.AU
Mon Dec 22 22:59:01 EST 1997


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



More information about the sg16-avd mailing list