Revised H.310 version2

Thu Dec 18 01:50:00 EST 1997

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

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.


Scott Petrack

More information about the sg16-avd mailing list