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@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Callaghan, Robert Robert.Callaghan@icn.siemens.com To: 'Pete Cordell' pete@TECH-KNOW-WARE.COM Cc: 'Mailing list for parties associated with ITU-T Study Group 16' ITU-SG16@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@TECH-KNOW-WARE.COM] Sent: Wednesday, June 07, 2000 5:32 AM To: ITU-SG16@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:
- Introduce an early H.245 tunnel as a package (it's important to be a
package as you will see later)
- 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.)
Declare that it is intended for fast connect to be deprecated.
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.
- 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.
- 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@tech-know-ware.com
+44 1473 635863
... cut ...
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com