Pete Cordell's FastStart issues

[Toby Nixon]

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 bt-sys.bt.co.uk]
> Sent: Monday, December 08, 1997 9:16 AM
> To:   'pete.cordell at bt-sys.bt.co.uk'; 'Narjala_Bhasker at ccm.jf.intel.com';
> 'Vineet_Kumar at ccm.jf.intel.com'; 'amir at radvision.rad.co.il';
> 'gthom at DELTA-INFO.COM'; 'lindbergh at pictel.com'; 'reid at pictel.com';
> 'Scott_Petrack at VOCALTEC.COM'; 'okubo at gctech.co.jp'; Toby Nixon; Steve
> Liffick; 'karl.klaghofer at MCH.PN.SIEMENS.DE'; 'amotz at radvision.rad.co.il';
> 'sebes at PNSTA1.ZFE.SIEMENS.DE'; 'dskran at ascend.com';
> 'nstarkey at databeam.com'; 'Robert.Callaghan at SIEMENSCOM.COM';
> 'gkajos at videoserver.com'; 'ggf at lucent.com'; 'jeff at pictel.com';
> 'john.boucher at bt-sys.bt.co.uk'; 'gkisor at ideal.jf.intel.com';
> 'reinhard.scholl at oen.siemens.de'; 'ofer at radvision.rad.co.il';
> 'nilsson_m_e at bt-web.bt.co.uk'; 'helmut.schink at oen.siemens.de';
> 'roni_e at accord.co.il'; 'gfargo at intecom.com'; 'adfranklin at lucent.com'; '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 bt-sys.bt.co.uk
> Tel: +44 1473 646436
> Fax: +44 1473 645499
> =================================
>
>
> >----------
> >From:        Jim Toga[SMTP:jtoga at ideal.jf.intel.com]
> >Sent:        07 December 1997 19:18
> >To:  pete.cordell at bt-sys.bt.co.uk; Narjala_Bhasker at ccm.jf.intel.com;
> >Vineet_Kumar at ccm.jf.intel.com; amir at radvision.rad.co.il;
> >gthom at DELTA-INFO.COM; lindbergh at pictel.com; reid at pictel.com;
> >Scott_Petrack at VOCALTEC.COM; okubo at gctech.co.jp; tnixon at MICROSOFT.COM;
> >stevel at MICROSOFT.COM; karl.klaghofer at MCH.PN.SIEMENS.DE;
> >amotz at radvision.rad.co.il; sebes at PNSTA1.ZFE.SIEMENS.DE;
> >dskran at ascend.com; nstarkey at databeam.com;
> >Robert.Callaghan at SIEMENSCOM.COM; gkajos at videoserver.com;
> >ggf at lucent.com; jeff at pictel.com; john.boucher at bt-sys.bt.co.uk;
> >gkisor at ideal.jf.intel.com; reinhard.scholl at oen.siemens.de;
> >ofer at radvision.rad.co.il; nilsson_m_e at bt-web.bt.co.uk;
> >helmut.schink at oen.siemens.de; roni_e at accord.co.il; gfargo at intecom.com;
> >adfranklin at lucent.com
> >Cc:  jtoga at ideal.jf.intel.com
> >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 ibeam.intel.com              Intel - Hillsboro, OR.
> >***
> >***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41***
> >************************************************************************
> >*
> >