Fast Start issues

[Tom Taylor]

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?

>-----Original Message-----
>From:  Pete Cordell [SMTP:pete.cordell at BT-SYS.BT.CO.UK]
>Sent:  Thursday, December 18, 1997 8:45 AM
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Fast Start issues
>
>Scott,
>
>Thanks for your lengthy reply...
>
>What I was hoping to indicate was that for certain call scenarios you
>want media established before CONNECT, but for other scenarios this is
>not possible.
>
>A situation where you have to send CONNECT before the media is
>negotiated is when multiple phones are rang and the first one is
>answered.  There are probably others.
>
>The point is that some flexibility is required on this point.
>
>I agree with your comments about mandating that fast start should allow
>for H.245 to be started at any time.  I didn't contest the wording as it
>seemed to me that whatever wording was in the standard, if it suited a
>vendor they could quite easily ignore any request to do fast start.
>This would total destroy any attempt to deliver some services and is
>hence a problem for us.
>
>I'm also interested that you state that you are looking for light-weight
>systems that do not use H.245.  Firstly this is in conflict with the
>wording at the moment.  Secondly, it is only an illusion of a simpler
>implementation, as much of H.245 is being copied into H.225 (work out
>how much of H.245 is included into H.225 just by referencing
>Capability).
>
>As to how CONNECT works in the switched network, it seems that the
>called endpoint sends CONNECT before the bearer path is in place.  The
>final switch will connect the bearer when it receives CONNECT.  The
>CONNECT is then forwarded.  The point is that the CONNECT is sent before
>the bearer is connected through, but the bearer is connect through by
>the time CONNECT is received.  This is difficult to emulate in our
>environment.  You can't just delay the CONNECT in the gatekeeper until
>the media is established because the user is concerned with the time
>from 'picking up the handset' to when they can speak and are not
>concerned with how this relates to the timing of the CONNECT message.
>Some one said the switched network delay in this instance is less than
>100ms.
>
>Regards,
>
>Pete
>=================================
>Pete Cordell
>BT Labs
>E-Mail: pete.cordell at bt-sys.bt.co.uk
>Tel: +44 1473 646436
>Fax: +44 1473 645499
>=================================
>
>
>>----------
>>From:  Scott Petrack[SMTP:Scott_Petrack at VOCALTEC.COM]
>>Sent:  18 December 1997 01:52
>>To:    ITU-SG16 at MAILBAG.INTEL.COM
>>Subject:       Fast Start issues
>>
>>Friends, and especially Pete,
>>
>>It really does seem to me that it is possible to get everyone happy. I
>>would like to try and convince you (Pete) that:
>>     a. you can get EXACTLY what you need, in the fastest, most correct
>>way
>>possible, right now, and
>>     b. Intel's FastStart is really an important and useful thing as is
>>for
>>H.323.
>>
>>It is possible that a single sentence needs to be added to the
>>FastStart
>>text (see below in the paragraph starting "The thing that you
>>require...").
>>But mainly I believe that there is a small misunderstanding going on,
>>which
>>is main the source of the problem.
>>
>>Pete, to get this extra "intelligence" you want, I believe that in most
>>cases you must use gatekeeper routed signalling. The called gatekeeper,
>>acting as a proxy for the called user, must send the H.245 port in the
>>CallProceeding message, H.245 negotiation must be used, and the CONNECT
>>message must come at the end, after all location/media negotiations are
>>over and media is available.
>>
>>I say "in most cases" because there are some cases where you will
>>probably
>>choose to do some intelligence in the LRQ phase, before the CallSetup
>>is
>>sent. In these cases it might be possible to know that the CallSetup
>>message is really being sent to the correct Terminal, and so you can
>>then
>>use FastStart to that Terminal. There are also other cases where you
>>may
>>choose to do FastStart with to the user's gatekeeper, have the
>>gatekeeper
>>play out a prompt saying something like "we are looking for your user
>>now",
>>have the gatekeeper do H.245 negotiation with the caller on behalf of
>>the
>>callee, and in the end establish a new media channel to the final
>>negotiated endpoint, breaking the original media channel negotiated
>>with
>>the gatekeeper in the FastStart. All this can be done now by using a
>>combination of FastStart and "classic" H.323 signalling.
>>
>>The "misunderstanding" I was alluding to earlier is this: you are
>>correct
>>that most endpoints until now unfortunately did CONNECT before media
>>negotiation. This is a very unfortunate breaking of Q.931 semantics
>>which
>>could have been avoided, and we should try hard to return to the normal
>>situation where CONNECT is sent only at the end of the entire call
>>establishment procedure. My problem is with the 2nd requirement you
>>gave in
>>an earlier posting:
>>
>>>we want to delay establishing media until after
>>>CONNECT so that the gatekeeper can do some intelligent stuff.
>>
>>I definitely DON'T want to delay establishing media until after
>>CONNECT.
>>And I claim that this is NOT needed for the gatekeeper to do some
>>intelligent stuff.
>>
>>The thing that you require, that is not quite there in the current
>>FastStart proposal, is that "even if a connection is made using
>>FastStart,
>>it shall be possible for either endpoint to start H.245 negotiation at
>>any
>>point in the conversation". I would be willing to go with this in the
>>spirit of compromise. (although personally I feel that such "shalls"
>>are
>>about as strong as "An H.uman endpoint shall not eat pork." Lot's of
>>people
>>who claim "Bible compliance" do not follow this shall, and somehow the
>>world continues to interoperate...)
>>
>>We at VocalTec, as part of our CMA work, support many of the scenarios
>>you
>>talk about, and we do it quite quickly (we think as quickly as
>>logically
>>possible in fact). Some of them require H.245, some require gatekeeper
>>routed signalling, some can be done with FastStart alone.
>>
>>I want to go on record saying that we DEFINITELY want to encourage
>>finishing the H.245 negotiation before CONNECT if it happens. This
>>function
>>is in H.323 now, and it is *the thing* that allows us to do the
>>scenarios
>>that Pete seems to want. We believe that this is how complex services
>>will
>>have to work in H.323. This allows H.245 and H.225 to go completely
>>independently and in parallel, and the poor CONNECT message can just be
>>the
>>final word saying "you're on the air". Logically, if you need H.245 for
>>your call, this is the fastest possible way to get it.
>>
>>You may be thinking, quite correctly "If Scott thinks that the next
>>generation of terminals is going to do H.245 before CONNECT then why in
>>the
>>world does he need FastStart?" This is a good question, but it has a
>>very
>>good answer (I'll bet you thought I would have one....)
>>
>>We perceive an absolute market requirement for the shortest, simplest,
>>fastest, lightweightest, stupidest kind of Internet Telephones, and
>>that a
>>system that cannot support such devices will be very vunerable to
>>attack
>>from competing systems that can. It is very important to be able to
>>build
>>"dumb telephone systems" as well as "intelligent ones". FastStart is a
>>great step forward for dumbness ;-). (sorry Jim).
>>
>>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 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.
>>
>>Sincerely,
>>
>>Scott Petrack
>>