H.bmultipoint drift

[Li Yan]

Bob,

I don't know how I can say this differently, but I am definitely not
saying that we should always wait for CONNECT for connecting through
media.  As you (and Tom) have said there are very good reasons for
connecting it through early.

HOWEVER, there are situations where the gatekeeper needs the CONNECT
from an endpoint before the media is connected through, and we need some
flexibility here.

This is a very complicated area (which in my eyes at least has quite a
simple solution) and the band-aid fix that we have is going to come back
a bite us in the future.

As this will be my last message this year, my feeling is that we are
shooting H.323 in the foot with this fix.  It makes clients heavier, it
is not flexible enough, and hasn't been thought through properly.

To expand on the latter, there is no procedures for handling both the
called and calling endpoints trying to start H.245 at the same time.
Gatekeepers will have a hard time passing through the cap sets if the
versions of the Capability structure they are not the same.

Seasons Greetings,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Callaghan, Robert[SMTP:Robert.Callaghan at SIEMENSCOM.COM]
>Sent:  18 December 1997 18:01
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Fast Start issues
>
>Pete,
>
>Please do no minimize the requirement for a bearer path cut-through
>before CONNECT.  In the PBX world, the path is fully cut-through before
>the ALERT message.  That allows for the transmission of progress tones
>(Alerting, Busy, etc.) and announcements.  The Public network, because
>of fraud control, fully cuts-through all nodes except for the last node
>in the Public Network.  Here a half path is cut-through.  This also
>allows for progress tones and announcements.  The side benefit is that
>the "Hello" can transverse the network while the path is being
>completed.  The specified "100 ms" is from the answer signal (off-hook)
>of the terminal to the complete path cut-through. (This covers more
>delays that the time between the network CONNECT signal and the
>cut-through.)  In the switched network this is very difficult, when
>even
>a portion of the path is left open.
>
>As I stated in Sun River, many users will allow for 5 seconds between
>answering the telephone and abandoning the call when there is no
>response.  This is substantially below the 15 to 20 seconds time for an
>H.323v1 terminal.  This is based on informal human factors surveys.
>
>Solutions include the setup, negotiation, and path establishment based
>on the SETUP message; or using the Fast Start setup.  In either case,
>the receiving end should fully establish the path before alerting the
>terminal or, for gateways, sending the call to the switched circuit
>network (PSTN).
>
>I don't understand the concern over obtaining enhanced operation with
>terminals that do not implement the "enhancing" procedures.  This is a
>fact.  A H.323v1 terminal cannot support this operation.  If enhanced
>procedures are required, it makes no difference whether it is "Fast
>Start" or your proposal.  To repeat, in order to get enhanced services,
>enhanced procedures are required; however, they are optional for the
>terminal providers.  There is no solution to this dilemma.
>
>Bob
>
>--------------------------------------
>Robert Callaghan
>Siemens Business Communication Systems
>Email:  Robert.Callaghan at Siemenscom.com
>Tel:    +1.561.997.3756
>FAX:    +1.561.997.3403
>
>>-----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
>>>
>