Fast Start issues

[Jim Toga]

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