On TD26 - Fast TCS and M/S negotiation in H.323v4

[Pete Cordell]

Bob,

In APC-1524 the media is up and running at EXACTLY the same time as it is
with fast start.

I'm not surprised it was rejected if this point was not understood.  Perhaps
it should be re-considered.

Additionally, it also works after pause, with MCs, multi-unicast, allows
other aspects of capability negotiation, no issue about when to start H.245
in relation to fast start and so on.

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
pete at tech-know-ware.com
+44 1473 635863
=============================================

----- Original Message -----
From: Callaghan, Robert <Robert.Callaghan at icn.siemens.com>
To: 'Pete Cordell' <pete at TECH-KNOW-WARE.COM>
Cc: 'Mailing list for parties associated with ITU-T Study Group 16'
<ITU-SG16 at mailbag.cps.intel.com>
Sent: 07 June 2000 21:37
Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4


> Pete,
>
> This solution was proposed in Santiago de Chile, and was rejected.
>
> Your proposal, as I understand it, requires 2 round trip.  Faststart only
> requires 1.  I need the faster connect.
>
> As to Dave Walkers proposal, Keypad digits do not solve the problems
needed
> to solve DTMF transmission; such as long  "#" used to indicate a new
credit
> card call.
>
> Bob
>
> -----Original Message-----
> From: Pete Cordell [mailto:pete at TECH-KNOW-WARE.COM]
> Sent: Wednesday, June 07, 2000 5:32 AM
> To: ITU-SG16 at mailbag.cps.intel.com
> Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
>
>
> Dave, Paul etc.,
>
> In terms of cleanliness, it seems to me that now H.323 has matured, the
> original design goal of fastConnect is no longer sufficient for our needs.
> Perhaps we should be looking to deprecate fastConnect in a orderly fashion
> rather than trying to enhance it.
>
> This would need to be managed in an orderly way so that we still allow
> interworking with as many entities as possible.
>
> One strategy to do this would be:
>
> 1) Introduce an early H.245 tunnel as a package (it's important to be a
> package as you will see later)
>
> 2) Formally bless Dave and mine's H.245 pre-opened channels proposal
> (APC-1524).  This achieves the same setup time as fast connect, and is
ready
> to be used today.  (The only real requirement needed is to give it an
> officially sanctioned identifier rather than a GUID.)
>
> 3) Declare that it is intended for fast connect to be deprecated.
>
> 4) Obviously fast connect will still be around for a long time to come,
but,
> if they desire,  people will have the chance to use pre-opened channels in
> preference to fast connect when they are both used in parallel, thus
> allowing a smooth migration.
>
> 5) When its deemed suitable, don't use fast connect, and just use
tunnelled
> H.245 with pre-opened channels in the existing tunnel.  This decision
point
> could be made by vendors on an individual basis.
>
> 6) Deprecate the early H.245 package, thus leaving the base syntax blemish
> free(-ish).
>
> I think this slightly longer term view is required to enhance the future
> viability of 323.  It was a short term fix that got us into this mess;
let's
> not rely on a short term fix to try and get us out.  If I've learnt
anything
> from this, it is that <short term fix> = <long term pain>!
>
> Pete.
>
> =============================================
> Pete Cordell
> Tech-Know-Ware
> pete at tech-know-ware.com
> +44 1473 635863
> =============================================
>
... cut ...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com