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.
Neil
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 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***
>> >************************************************************************
>> >*
>> >
>
>
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Neil Starkey, EVP/CTO nstarkey at databeam.com
DataBeam Corporation http://www.databeam.com
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