Schedule for 14-25 Sep 1998 meeting of Study Group 16

Toby Nixon tnixon at MICROSOFT.COM
Mon Dec 15 17:58:05 EST 1997

Please do put this on the list.  This is an issue we (DataBeam) are
interested in but have lost out on part of the discussion.


At 12:23 PM 12/8/97 -0800, Toby Nixon wrote:
>Might I suggest that this discussion be broadened to include the ITU-SG16
>reflector instead of sending a long list of recipients each time?
>> -----Original Message-----
>> From: Pete Cordell [SMTP:pete.cordell at]
>> Sent: Monday, December 08, 1997 9:16 AM
>> To:   'pete.cordell at'; 'Narjala_Bhasker at';
>> 'Vineet_Kumar at'; 'amir at';
>> 'gthom at DELTA-INFO.COM'; 'lindbergh at'; 'reid at';
>> 'Scott_Petrack at VOCALTEC.COM'; 'okubo at'; Toby Nixon; Steve
>> Liffick; 'karl.klaghofer at MCH.PN.SIEMENS.DE'; 'amotz at';
>> 'sebes at PNSTA1.ZFE.SIEMENS.DE'; 'dskran at';
>> 'nstarkey at'; 'Robert.Callaghan at SIEMENSCOM.COM';
>> 'gkajos at'; 'ggf at'; 'jeff at';
>> 'john.boucher at'; 'gkisor at';
>> 'reinhard.scholl at'; 'ofer at';
>> 'nilsson_m_e at'; 'helmut.schink at';
>> 'roni_e at'; 'gfargo at'; 'adfranklin at'; 'Jim
>> Toga'
>> Subject:      RE: Pete Cordell's FastStart issues
>> Jim et al.,
>> I'm glad we've got a discussion going on this.  This seems to be a
>> really big issue that can have a major impact on the future of H.323.  I
>> know we're all really busy, but come January we will be stuck with what
>> ever we decide, so I'm hoping that other people can jump in here to
>> thrash out the issues as much as possible.  The more input, the better
>> the solution is likely to be.
>> I've put comments in below.  From the comments presented though I don't
>> think we are on the same wavelength yet, so most of the comments are
>> related to the problem space rather than any solutions.
>> Pete
>> =================================
>> Pete Cordell
>> BT Labs
>> E-Mail: pete.cordell at
>> Tel: +44 1473 646436
>> Fax: +44 1473 645499
>> =================================
>> >----------
>> >From:        Jim Toga[SMTP:jtoga at]
>> >Sent:        07 December 1997 19:18
>> >To:  pete.cordell at; Narjala_Bhasker at;
>> >Vineet_Kumar at; amir at;
>> >gthom at DELTA-INFO.COM; lindbergh at; reid at;
>> >Scott_Petrack at VOCALTEC.COM; okubo at; tnixon at MICROSOFT.COM;
>> >stevel at MICROSOFT.COM; karl.klaghofer at MCH.PN.SIEMENS.DE;
>> >amotz at; sebes at PNSTA1.ZFE.SIEMENS.DE;
>> >dskran at; nstarkey at;
>> >Robert.Callaghan at SIEMENSCOM.COM; gkajos at;
>> >ggf at; jeff at; john.boucher at;
>> >gkisor at; reinhard.scholl at;
>> >ofer at; nilsson_m_e at;
>> >helmut.schink at; roni_e at; gfargo at;
>> >adfranklin at
>> >Cc:  jtoga at
>> >Subject:     Re:Pete Cordell's FastStart issues
>> >
>> >Pete, (and others)
>> >
>> >Let me try and respond to your issues and hopefully we can resolve this
>> >in
>> >a relatively concise manner.  Before we get started though I would like
>> >to
>> >make a couple of points clear:
>> >
>> >Recall that the "fast start" problem as stated previous to the Israel
>> >meeting and formalized in the contribution to that meeting, was the
>> >following. To provide a minimal round trip time connection sequence,
>> >for
>> >simple constrained calling scenarios.  The requirement was to have
>> >minmal
>> >engineering impact to current shipping products and complete backward
>> >compatability.
>> I've looked through my notes and I can see any authoritative, exclusive
>> list of what the fast start should be expected to solve.  I don't see
>> anything that said it should be restricted to "simple constrained
>> calling scenarios".
>> >
>> >I have always been a proponent of Gatekeepers and the functionality,
>> >features, and services that they can provide.
>> >
>> >Everyone  (including you), supported the final version of FastStart
>> >which
>> >came out SunRiver with the additions of bi-directional capabilities.
>> >With
>> >the presentation of your alternative approach there was never any clear
>> >motivation for developing the more complicated version other than you
>> >'didn't like' the current form. I'm happy to see you've presented a
>> >real
>> >issue to which you would like a solution.
>> >
>> >I would like codify my understanding of your issues and see if we can
>> >find
>> >a solution to them. I _think _you imply the need for a low overhead
>> >'mode
>> >switch'  which really has nothing to do with FastStart, but let me see
>> >if I
>> >understand your points.
>> To me connection setup (i.e. user-to-user connection) is pretty much all
>> that H.323 is about.  Once a connection is setup there is little more
>> for H.323 to do, other than tear-down.
>> >
>> >
>> >At 03:58 PM 12/5/97 -0000, Pete Cordell wrote:
>> >[SNIP]
>> >> Each user has an account on the system.  They can use
>> >>it as a single number by which to contact them by.  As you move from
>> >office to home to mobile,
>> >>you configure it using a web browser with
>> >>the number to contact you on.  People trying to contact you dial a
>> >>single number and the platform forwards the call to the correct
>> location.
>> >> It also allows people to leave voice messages on the system.
>> >>Additionally you can configure it to do things like try the office phone
>> >>first, then the mobile and if  that doesn't work leave a message.  This
>> >>sort
>> >> of flexibility is not easily addressed by a directory.  It
>> >>can also receive e-mails and faxes etc.
>> >>
>> >[SNIP]
>> >
>> >>This is admittedly not rocket science, and you've probably come across
>> >>services like this already.  Our job is to move this to the IP world.
>> >
>> >Why can't you can accomplish this today (in R2) with the multiple alias
>> >registrations (that fact that you may use WEB front end is irrelevent)?
>> >The
>> >Gatekeeper then has his 'rotary switch' of locations to look through to
>> >find the current active location.  This is much like (if not exactly)
>> >VocalTec's CMA architecture.
>> Your right, the configuration side of things is not the issue.
>> >
>> >>Product Impact
>> >>==============
>> >>To understand the impact of this on the protocol, let's look at the case
>> >>of using a search algorithm to look for a user and also returning a call
>> >>after interrogating the voice bank.
>> >>
>> >
>> >Tying user-network signalling to network-network signalling in the
>> >protocol
>> >is bad practice, limiting and cumbersome.
>> I agree, network-network signalling is for another day.  However this
>> issue is very much in the user-network signalling area.  The issues
>> remain even if only one gatekeeper is involved (which hopefully implies
>> that there is no network-network signalling).
>> >
>> >>Let's assume the system is configured to contact my work number first
>> >>and them my mobile number.  In this case the final connected endpoint is
>> >> not known until the CONNECT message is received.  Hence the
>> >>capabilities of the endpoint you will be talking to are not known for
>> >>sure until you get CONNECT.
>> >
>> >I see this, and agree it is entirely true.  It has no effect however on
>> >the
>> >the capabilities of the _calling_ party.  They _are_ known, and there
>> >is no
>> >reason why the possibile capabilities should change.
>> Correct
>> >
>> >>This is not a problem with the basic call setup sequence as the H.245 is
>> >>not established until after CONNECT.
>> >
>> >This is not quite true.  There has been the ability (since 3/96) to
>> >start
>> >H.245 at any point after the SETUP message is received.  This required
>> >two
>> >things, which by the way would be required in all of these scenarios.
>> >
>> >The caller and callee has to be able to deal with H.245 and possibly
>> >media,
>> >'early'.
>> >The caller has to place the H.245 port in the Setup message.
>> >(Alternatively the callee can place the H.245 port in the Call
>> >Proceeding/Alerting message)
>> True, but hopefully you'll agree with me that in this case the
>> gatekeeper could delete any H.245 addresses from messages other than
>> CONNECT and it would get the desired behaviour.  This seems to be a
>> pretty NULL operation as nobody seems to be sending H.245 addresses in
>> messages other than connect anyway.
>> >
>> >>However, with fast connect we want to start capability negotiation as
>> >>soon as possible, and are not able to wait until CONNECT.
>> >
>> >The Determined version of FastStart  DOES do a full capability exchange
>> >before the CONNECT. (althought it does not provide for an iterative
>> >_negototiation_, as this defeats the Fast portion of FastStart).
>> I have problems with saying the FastStart shall be 1 round trip or bust.
>>  The intent seems to have been that a minimum of round trips should be
>> used compatible with negotiation, security etc.  If a particular case
>> requires an extra round trip, then that is the minimum number of round
>> trips that case can be set up in.  That doesn't break fastStart.  I
>> would say it's good because it has meant that we don't fall back to the
>> 6 1/2 round trips that we typically need.
>> >
>> >>This also has the benefits that we can listen to announcements prior to
>> >the CONNECT >message (such as "The
>> > >number you have dialled has > changed, but we are re-routing you
>> >anyway").
>> >
>> >This is EXACTLY what FastStart provides as soon as the Setup is
>> >recieved,
>> >the recipient may start playing media back to the caller.  The caller
>> >may
>> >be constrained from sending media to the callee until the Connect is
>> >received - just as it works in the circuit world.
>> I was trying to capture the issues here, not saying that the current
>> fast start doesn't meet any of them.  Basically we have conflicting
>> requirements here 1) we want to establish media prior to CONNECT to
>> allow announcements, 2) we want to delay establishing media until after
>> CONNECT so that the gatekeeper can do some intelligent stuff.  This is
>> what makes this topic so interesting!!!!
>> >
>> >>However, if the system gives up ringing my work number and then tries
>> >>the mobile number, it has to present a new set of capabilities to the
>> >calling endpoint.
>> >
>> >That is true, and this can occur by simply sending another Call
>> >Proceeding
>> >message (or Alerting) with the new caps.  There is no need however for
>> >the
>> >_caller_ change or otherwise resend its caps..... In other words the
>> >Gatekeeper will still be presenting the same set to the subsequent
>> >callees
>> >as it polls them.
>> You're right that the caller does not have to generate new caps.
>> However, sending multiple CALL PROCEEDINGs or ALERTINGs to an endpoint
>> breaks H.225, and so would not be backwards compatible.
>> >
>> >
>> >>Now I'm in the mode of interrogating the voice messages that have been
>> >>left for me.  My endpoint is connected to the sub-system that plays out
>> >the recorded
>> >>messages and it asks me if I want to return the
>> >>call.  To do this the system needs to create an outgoing call, and
>> >>locally generate a ringing tone.  When the remote party answers the two
>> >endpoints need
>> >>to be connected together.
>> >
>> >This is either some form of a transfer (from a protocol point of view)
>> >or
>> >shouldn't it be hidden from the endpoint in terms of signalling?
>> In a distributed world there is only so much that you can hide from an
>> endpoint.  That's why this topic is so important.  To roll out customer
>> friendly services the endpoints need to support some basic capabilities.
>>  Hopefully this is worth endpoint vendors doing as useful services mean
>> that people can use there endpoints for more things.  Thus the
>> technology is more likely to catch on, than if you are only likely to
>> get reasonable service from a call centre via good old POTS.
>> >
>> >>You may say that the FACILITY message could be used to do this.
>> However,
>> >the caller has state stored
>> >>in the platform/gatekeeper (such as where they are in the menus etc.) so
>> >that when they finish this new
>> >>call they can go back to interrogating their messages.  This would not
>> be
>> >possible with the
>> >>FACILITY approach.
>> >
>> >It would seem that exposing this bookkeeping/signalling would require a
>> >_large_ commitment on the part of all the endpoint manufacturers -
>> >wouldn't
>> >it be better to provide this in an 'invisible' way?  Aside from the
>> >complexity/compatibiliy issues it provides for product differentiation.
>> I think you're agreeing with me that the FACILITY way is a bad way to
>> go.
>> >
>> >>
>> >>WOW that's complicated!!!
>> >>=========================
>> >>At first sight this appears horrendous, but in actual fact it is quite
>> >>simple.  All it requires is for the platform/gatekeeper to be able to
>> >break connections and re-establish
>> >>new connections when it wants to.
>> >
>> >AAHHH.... so this is what you wanted! This _does_ seem like a
>> >'transfer'
>> >type of thing, in any case it would appear to be  independant of
>> >FastStart.
>> A setup is almost invariably part of transfer, so I don't see that you
>> can call them independent.  Anyway, the report from Hertzliya says
>> support for supplementary services should be included in fast setup.
>> >
>> >I have to admit, I'm not sure what you mean by 'connection' though.  Is
>> >this simply logical media channels, or is it a larger concept?
>> I'm really mean establishing some sort of media exchange between users
>> such as audio or video.
>> >
>> >[SNIP]
>> >
>> >>
>> >>So where's the problem
>> >>======================
>> >>The problem is that I can not make use of the fast setup scheme with
>> >>these services, because it does not support the break and make
>> capability.
>> >
>> >This is _new_ functionality that was never listed as a requirement  of
>> >FastStart, and I would argue that 'breaking and making connections'
>> >goes
>> >against the scope of the FastStart usefulness.
>> This is where I totally disagree.  The list of fast start requirements
>> was never exclusive.  We announced our requirements for fast start and
>> no body objected to them, and some even backed them up.  If you had
>> objections you should have raised them at the time.
>> >
>> >>To do these services I need tofall back to H.245.  If the
>> >>standard setup is not good enough for a basic point-to-point call then
>> >>it is not good enough for entities that introduce intelligence which in
>> >fact have more stringent timing
>> >>requirements because the breaks and makes are more difficult to conceal
>> >under things like ringing.
>> >
>> >The 'standard setup' is no way "not good enough" for basic
>> >point-to-point
>> >operation.  It simply as case that in certain well defined (resources
>> >and
>> >entities known) that optimizations can and should be made to operate in
>> >simple low delay environments.
>> >
>> >>Assuming that the reason for implementing the gatekeeper routed model is
>> >to add these sorts of features, then
>> >>really the gatekeeper routed model becomes a second class citizen.  This
>> >is a problem for us.
>> >
>> >The Gatekeeper should most definitely NOT be constrained from adding
>> >features and providing expanded services.  The Gatekeeper routed model
>> >was
>> >specifically developed to hide this complexities from the endpoints, in
>> >fact the endpoint cannot even tell which mode it is running in other
>> >than a
>> >bit in the ACF.
>> >
>> >The Gatekeeper is no more or less a "second class citizen" with
>> >FastStart
>> >as with the 'standard' signaling.  In fact I believe that it has even
>> >more
>> >control, because it may provide an asymmetrical connection on either
>> >side
>> >of itself
>> >forcing either the caller or callee into a particular mode of
>> >operation.
>> If the standard startup is good enough then we seem to be taking
>> elaborate measures to tune the efficiency of the "standard setup".
>> Either the standard setup is good enough or it isn't.  If it is good
>> enough then we don't need fast start.  I happen to think that it is not
>> good enough.  Hence we need a solution that is good enough for the basic
>> call model and is also good enough for those of us that want to add
>> value.  If we don't achieve this, then as far as I can see the
>> gatekeeper routed model can only become a second class citizen.
>> >
>> >>
>> >>Where to go next
>> >>================
>> >>To do what I need to do, I need a fast method for making and breaking
>> >>connections without first establishing the TCP connection, negotiating
>> >caps, MSD, OLC, OLC ACK,
>> >>and then sending media.  We could achieve this by adding a break command
>> >to the FACILITY message and >then having the ability to send new
>> >fastCaps
>> >at any time to make a new connection.  This seems a minimal
>> >>change from where we are at the moment and such a change would be fine
>> by
>> >me.
>> >
>> >Again I'm not clear on what you mean by 'connections', but assuming
>> >that
>> >you mean something like an audio channel (say 711-->723.1) than I think
>> >there are a number of fine options we can pursue.  (for example H.245
>> >has
>> >established a 're-open' command.)
>> >
>> >>
>> >>However, I know that Glen is interested in always running an MC, so he
>> >>would want to add extra features.  Others will probably also want
>> features
>> >that have been carefully crafted
>> >>into H.245.  As a result we are likely to get feature creep so that more
>> >and more H.245 functionality is
>> >>put into H.225.
>> >
>> >I completely agree that it would be a very bad thing to re-invent H.245
>> >within H.225.0.
>> >
>> >> I also have concerns about having two ways and two APIs (fast and slow)
>> >for doing
>> >>things.  This explains my attempt to re-use as much of H.245 as
>> possible.
>> >
>> >To pick a nit, we're not talking about API's;  there is one way within
>> >the
>> >protocol to establish an H.245 connection.  If you need these features,
>> >flexibility and control; this is what you should do.  That being said
>> >there
>> >are two forms of Setup/Connect messages for those
>> >Endpoints/Gatekeepers/MCUs that would like to utilize them.
>> To pick more nits ( :-) ), we at some point have to build what we
>> propose.  Therefore, we can not conceive of protocols in isolation of
>> how we will build them.  If one protocol idea is easier to develop than
>> another then we should go with that one.  So although the ITU is not
>> bothered with APIs, we as contributors, should be.
>> Most stacks that I am aware of separate out the Q.931 part and the H.245
>> part.  At the moment the H.245 part knows about caps and the Q.931 part
>> does not.  To put caps in Q.931 we need to put an API on the Q.931 part
>> that accepts caps.  Therefore we really do have two APIs, which is an
>> issue.
>> >
>> >>
>> >>But let me reassure you I have no requirement to use H.245!  I have a
>> >>requirement to solve the problem presented above.
>> >
>> >The problem is to 'break and make' connections with minimal
>> >overhead?.....
>> Yep
>> >
>> >>
>> >>A little history
>> >>================
>> >
>> >[SNIP].
>> The issues raised here are hopefully covered off elsewhere.
>> >
>> >>
>> >>To sum up
>> >>=========
>> >>To differentiate I want to add intelligence to my platform (effectively
>> >>a gatekeeper).  If I can't use fast setup as part of this people will
>> >either use the direct call model,
>> >>or use dumb gatekeepers.  Basically the gatekeeper routed model will
>> loose
>> >out.
>> >
>> >Nothing you have described so far is either helped or hindered by
>> >FastStart,  this point is completely irrelevent.  As I said above,
>> >Intel
>> >has always believed in the value of Gatekeepers to H.323 systems.  I'm
>> >surprised that you didn't  present a contribution to provide
>> >lightweight
>> >'connection switching' in a general manner.
>> The point really is that it has not helped......
>> >
>> >>
>> >>Hence I need fast setup to be useful for a gatekeeper adding
>> intelligence,
>> >which basically means being
>> >>able to quickly break and make connections.
>> >
>> >This is great! If this is what you require, lets come to quick
>> >agreement on
>> >this and move on.
>> >
>> >>
>> >>I have presented a solution that I believe meets these requirements.
>> >>But if there is another way of meeting my requirements then I would be
>> >only too happy to adopt it.
>> >>
>> >
>> >Here are my suggestions that I _think_ provide the functionality you
>> >desire:
>> I think it's important that we try to sort out the problem we are
>> solving first.  If you feel we are on the same wavelength then we can
>> move on to the technical implementation, but I don't think we are quite
>> there yet.  I hope this has helped.  Besides, I would also like more
>> time to think about what you have proposed.
>> >
>> >
>> [SNIPPED, but not forgotten]
>> >
>> >Does this solve your issues?
>> This is a good start and I'm confident that in a few rounds we can get
>> there.  Thanks for the time you've put into this Jim.  You may not thank
>> me now, but I'm sure that in a few years you (or your company) will
>> thank me for bringing this all up!!!!  (well say 10 years.  Or not more
>> than 20 years.  Well not much more than 20 years....)
>> >
>> >Best Regards,
>> >jimt.
>> >
>> Pete
>> >
>> >************************************************************************
>> >*
>> >***  +1-503-264-8816(voice)             +1-503-264-3485(fax)
>> >***
>> >***  jtoga at              Intel - Hillsboro, OR.
>> >***
>> >***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
>> >************************************************************************
>> >*
>> >
Neil Starkey, EVP/CTO      nstarkey at
DataBeam Corporation
230 Lexington Green Circle +1 606 425 3500 voice  <<NEW ADDR/PHONE
Lexington, KY 40503        +1 606 425 3528 fax    <<NEW FAX

... no we didn't move - it's a conspiracy between the phone
company and the post office!

More information about the sg16-avd mailing list