Bob,
My ears pricked up when you mentioned "migration path".
Do you see more additions to fast start/ quicker start/ flexible start? It would be nice to know what your thoughts are.
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: ITU-SG16@mailbag.cps.intel.com Sent: 27 July 2000 18:48 Subject: Re: Expediting H.245
Paul,
Actually I like the procedure for early H.245 tunneling that is in H.323
v4.
It allows for an incremental addition to the Fast Connect procedure of v4 with a reasonable migration path. The additional field in SETUP that eliminates the conflict with the requirements of V2 is minimal. I see no need to create a new procedure that then requires administration or negotiation.
Bob
Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan@ICN.Siemens.com
-----Original Message----- From: Bob Gilman [mailto:rrg@LUCENT.COM] Sent: Thursday, July 27, 2000 12:52 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Expediting H.245
Paul- I didn't say anything about the possiblity of offering both Fast Connect and Fast Open. It seems to me that doing so would present the same problems that TD-26 encountered: we'd need a new tunnel to hide H.245 in the SETUP message and we'd need to abandon the statement that starting H.245 terminated Fast Connect (or use the same tunnel to continue to hide H.245). The only reason to offer Fast Connect from an endpoint that supports Fast Open is to work with earlier-version endpoints - and they're the ones that can't tolerate starting H.245 before Fast Connect is completed. I'd rather specify that an endpoint could offer either Fast Connect or Fast Open (or accept the one offered) at its option. The question is: how does a calling endpoint know which to do? It could be done by out-of- band means (administration), but it could also be done by looking at the RAS protocolIdentifier which requires a relationship between H.225.0 and H.245 versions. Isn't that usually the case anyway? Again, the advantages of Fast Open over Fast Connect and early H.245 include:
- More compact messaging;
- multiple caps, one OLC;
- can be used anytime, not just call establishment;
- no need to switch from one protocol to another, or from one tunnel to another, especially going forward;
- uses current cap set;
- just as fast as Fast Connect;
- backward compatible with Fast Connect;
- Fast Open "callee" can accept Fast Start from an earlier version, knows not to use Fast Open;
- but Fast Open caller should not offer Both Fast Open and Fast Connect - needs to know which to do;
- processing is very similar to Fast Connect;
- no need to modify historical H.225.0 restrictions.
- Fast Open offered to older version endpoint results in H.245 operation.
The problem of backward compatibility is a sticky one, given the existing restrictions on simultaneous operation and early switching to H.245. The sooner we remove these restrictions from H.225.0, the better off we will be, but I think we've actually backed ourselves into a corner, unless we effectively change v2. I would note that the cases for which TD-26 would work would also work for simultaneous Fast Connect and Fast Open - but there's no way around the fact that some v2 endpoints will object in either case.
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
"Paul E. Jones" wrote:
Bob,
This looks quite reasonable to me.
I may have missed it in here, but do you say anything about including
both
fastStart and these new fields. Proponents of TD-26 wanted to ensure
that
the devices could still take advantage of Fast Connect for those devices that support the procedure.
However, I'm not sure that I understand exactly what the advantage is
over
the combined usage of the existing Fast Connect procedure + Early H.245. Can you clarify that for me?
Paul
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com