Typo in Gatekeeper discovery annex to H.225.0, etc.

Toby Nixon tnixon at MICROSOFT.COM
Tue Dec 30 20:37:45 EST 1997


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

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