Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Francois,
Woohoo!!!! :-)
Actually, I suppose earlyH245Control could contain multiple H.245 messages, since it will presumably be defined the same as h245Control:
Yes, I had meant to make a comment about this yesterday, but I had already disconnect from dial-up.
Given: H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL
therefore: h245Control H245Control, and: earlyh245Control H245Control,
Looks good to me.
Well if you want to kick the final bit of life out of H.323 then add another field to H.323 that does much the same as something that's already in there. Heck, we'll probably have to do something similar with a few other features as well, so this change would hardly be noticed.
The issue is a bit like the ozone layer and CFCs. A squirt of deodorant in the morning surely didn't make much difference to the ozone layer. But the fact was that it all added up. Fortuneately policy has come in to attempt to address the ozone layer problem, and hopefully we can avoid having to go around covered from head to toe in future. We face much the same issue with H.225, but we already have to wear factor 50 sun cream all the time!!!
On the other hand, defining this addition using the packages field would stop this beating a dead horse approach. I've attached a doc that shows what is involved. Note that most of the procedure elements would have to be included with what ever approach is taken and they do not represent a burden of implementing this using packages.
Pete.
============================================= Pete Cordell pete@tech-know-ware.com =============================================
----- Original Message ----- From: Francois Audet To: ITU-SG16@MAILBAG.INTEL.COM Sent: 05 June 2000 16:39 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Francois,
Woohoo!!!! :-)
Actually, I suppose earlyH245Control could contain multiple H.245 messages, since it will presumably be defined the same as h245Control:
Yes, I had meant to make a comment about this yesterday, but I had already disconnect from dial-up.
Given: H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL
therefore: h245Control H245Control, and: earlyh245Control H245Control,
Looks good to me.
Pete- Thanks for the writeup on earlyH245Control. I would like to suggest that make acceptance of fastStart independent of the acceptance of earlyH245Control. It might be useful for the called endpoint (or gatekeeper) to accept early H.245 and proceed with TCS and M/S negotiations before it establishes any media channel via the FastStart procedures. This could be done by permitting the earlyH245Control element in all messages (like fastStart), or in the basic H323-UU-PDU (like h245Control). That way, FastStart is accepted by the return of a fastStart element, and acceptance of early H.245 is clearly accepted by the return of an earlyH245Control element. The use of the earlyH245Control tunnel would then be enabled. (Is there any reason to move to the h245Control tunnel?) Should we prohibit both an earlyH245Control and an h245Control element in the same message? What do you think? -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Bob,
Thanks for your comments...
At the moment I can't see any benefit in doing a bit of H.245 before doing fast start. Fast start is really only saving you a round trip, and if you don't do any fast start for that period, then surely you might as well have done it using H.245 anyway. I might be missing something, so please explain what you have in mind.
As starting H.245 kills off fast start in current systems, I was assuming that once the fast start data in the new arrangement had been handled it would also be killed off. Put another way, from my point of view I was seeing the fast start as a one shot deal which are effectively fast virtual OLCs. My gut feeling is that allowing them later introduces complications. I would be interested in other peoples comments on the implications of this.
I think I prefer your suggestion about sticking with the early H.245 tunnel rather than switching to the existing tunnel. I was merely trying to align the text with what Paul J proposed.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Bob Gilman rrg@LUCENT.COM To: ITU-SG16@MAILBAG.INTEL.COM Sent: 06 June 2000 17:01 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pete- Thanks for the writeup on earlyH245Control. I would like to suggest that make acceptance of fastStart independent of the acceptance of earlyH245Control. It might be useful for the called endpoint (or gatekeeper) to accept early H.245 and proceed with TCS and M/S negotiations before it establishes any media channel via the FastStart procedures. This could be done by permitting the earlyH245Control element in all messages (like fastStart), or in the basic H323-UU-PDU (like h245Control). That way, FastStart is accepted by the return of a fastStart element, and acceptance of early H.245 is clearly accepted by the return of an earlyH245Control element. The use of the earlyH245Control tunnel would then be enabled. (Is there any reason to move to the h245Control tunnel?) Should we prohibit both an earlyH245Control and an h245Control element in the same message? What do you think?
-Bob
Bob Gilman rrg@lucent.com +1 303 538 3868
For 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
Pete- Thanks for your reply. What I had in mind for the early H.245 reply that might come before acceptance of fastStart were things like completion of TCS exchange and M/S negotiation (and, perhaps, user-dialed digits if I understood Mr. Callahan's mail correctly.) With regard to ending fastStart, I believe everyone expects it to be a one-shot deal (with a possible exception for Annex F sets). -Bob ---------------------------------------------------- Bob Gilman rrg@lucent.com +1 303 538 3868
Pete Cordell wrote:
Bob,
Thanks for your comments...
At the moment I can't see any benefit in doing a bit of H.245 before doing fast start. Fast start is really only saving you a round trip, and if you don't do any fast start for that period, then surely you might as well have done it using H.245 anyway. I might be missing something, so please explain what you have in mind.
As starting H.245 kills off fast start in current systems, I was assuming that once the fast start data in the new arrangement had been handled it would also be killed off. Put another way, from my point of view I was seeing the fast start as a one shot deal which are effectively fast virtual OLCs. My gut feeling is that allowing them later introduces complications. I would be interested in other peoples comments on the implications of this.
I think I prefer your suggestion about sticking with the early H.245 tunnel rather than switching to the existing tunnel. I was merely trying to align the text with what Paul J proposed.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com
+44 1473 635863
----- Original Message ----- From: Bob Gilman rrg@LUCENT.COM To: ITU-SG16@MAILBAG.INTEL.COM Sent: 06 June 2000 17:01 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pete- Thanks for the writeup on earlyH245Control. I would like to suggest that make acceptance of fastStart independent of the acceptance of earlyH245Control. It might be useful for the called endpoint (or gatekeeper) to accept early H.245 and proceed with TCS and M/S negotiations before it establishes any media channel via the FastStart procedures. This could be done by permitting the earlyH245Control element in all messages (like fastStart), or in the basic H323-UU-PDU (like h245Control). That way, FastStart is accepted by the return of a fastStart element, and acceptance of early H.245 is clearly accepted by the return of an earlyH245Control element. The use of the earlyH245Control tunnel would then be enabled. (Is there any reason to move to the h245Control tunnel?) Should we prohibit both an earlyH245Control and an h245Control element in the same message? What do you think?
-Bob
Bob Gilman rrg@lucent.com +1 303 538 3868
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
participants (3)
-
Bob Gilman -
Francois Audet -
Pete Cordell