Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Chris, It is valid for a discussion of the problems and desires on this list. However, no decision may be made on the list. Decisions are made at meetings. The actual rules for the operation of the documents under the scope of a Study Group question is at the descression of the Rapateur. At the worst, it is possible for the Rapateur to submit documents without input from anyone. As I understand it, Q.13/16 has agreed to use meetings as the location where decisions are made. It also guided us that conference calls and the mailing list may be used to enhance the discussion. Based on the direction given in Osaka, the correction to the agreed content for the white paper being done in conference calls and the mailing list would not include any substative change. In my mind, dropping fast TCS and M/S is a substative change. The choices should limited to including TD-26 as is based on the understanding of the participants or to find limited "editorial" changes that will not change the substance of the contribution. Also deprecating FastStart is a substative change beyond any discussion at this time. All things can be proposed in Portland, subject to the limitation to changes in the White Paper. All things can be proposed in Geneva, subject to a potential delay in v4. Bob -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, June 06, 2000 12:42 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Bob, Is it really beyond the editor's discretion to react to problems which come to light in between the formal meetings? I thought that was one of the purposes of this list! Alternative solutions are being sought, but the one discussed in Osaka is clearly too flawed to be permitted to proceed. Regards, Chris "Callaghan, Robert" wrote:
Paul,
I was afraid that this might happen.
The changes under discussion were agreed to in Osaka, with the
participants
understanding the risks. To not include it in v4 would be a substantive change from the agreed content which I challenge as being beyond the discression of the editor to make editorial changes.
There is a real problem in that keypad information must be sent before the connect message. This is needed to support network services in the U.S. Because the H.245 rules require the exchange of TSC and master-slave before any other messages may be sent, there is a significate delay after fast connect before keypad digits may be sent. In Osaka, several proposal were submitted to solve this and other needed negotiation problems. The agreed solution was the proposal for which you have reservations. This is needed in the real world.
PLEASE! find a solutions that will not remove these changes!
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, May 31, 2000 11:14 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
We agreed at the Osaka meeting to allow a SETUP to contain both the fastStart and h245Control, but it has not been officially approved by the ITU.
As it stands right now, I don't think I can agree to include it in H.323v4 on the grounds that it breaks backward compatibility with V2-- I just don't see a clean solution here.
I'm opening to hearing more suggestions, but as you pointed out, there are two issues: 1) H.323v2 states explicitly that it is illegal 2) There is no way to know what version to destination EP is before sending this illegal message
Paul
----- Original Message ----- From: "Paul Long" <Plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, May 31, 2000 10:34 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pete,
Table 13/H.225.0v3 shows that the User-to-User IE is mandatory. What IEs do you believe are not mandatory?
H.323 states that the fastStart and h245Control components cannot both be present in the Setup message (do I need to quote it again?). A Setup User-to-User IE containing either or neither component is valid; one containing both is clearly invalid. Why do you think otherwise?
H.323, by way of Q.931, requires that the called EP respond with ReleaseComplete with cause 100. There is no other appropriate cause.
The feature that should be deprecated is the inclusion of both fastStart and h245Control in Setup. I was under the impression that either through IGv3 or H.323v4 this had already made it into the standard. If its not too late, we should simply remove this feature from any proposed text; if it is too late, we should deprecate it because it causes insurmountable backward compatibility problems.
Paul
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, May 31, 2000 4:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
I don't really believe that the release cause you cite is valid. The IEs are not mandatory, and (taken by themselves) they don't have invalid content. I don't believe it is the intent of this cause code to signal the sort of thing that we are talking about here either.
Are there any other causes and clauses that you think might be more appropriate?
Also, when you say "the feature" should be deprecated, what are you referring to as "the feature"? I'm not quite clear.
Pete.
============================================= Pete Cordell pete@tech-know-ware.com =============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
Chris,
It is valid for a discussion of the problems and desires on this list. However, no decision may be made on the list. Decisions are made at meetings.
The actual rules for the operation of the documents under the scope of a Study Group question is at the descression of the Rapateur. At the worst, it is possible for the Rapateur to submit documents without input from anyone. As I understand it, Q.13/16 has agreed to use meetings as the location where decisions are made. It also guided us that conference calls and the mailing list may be used to enhance the discussion. Based on the direction given in Osaka, the correction to the agreed content for the white paper being done in conference calls and the mailing list would not include any substative change. In my mind, dropping fast TCS and M/S is a substative change. The choices should limited to including TD-26 as is based on the understanding of the participants or to find limited "editorial" changes that will not change the substance of the contribution. Also deprecating FastStart is a substative change beyond any discussion at this time. All things can be proposed in Portland, subject to the limitation to changes in the White Paper. All things can be proposed in Geneva, subject to a potential delay in v4.
Bob
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, June 06, 2000 12:42 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Bob,
Is it really beyond the editor's discretion to react to problems which come to light in between the formal meetings? I thought that was one of the purposes of this list! Alternative solutions are being sought, but the one discussed in Osaka is clearly too flawed to be permitted to proceed.
Regards, Chris
"Callaghan, Robert" wrote:
Paul,
I was afraid that this might happen.
The changes under discussion were agreed to in Osaka, with the
participants
understanding the risks. To not include it in v4 would be a substantive change from the agreed content which I challenge as being beyond the discression of the editor to make editorial changes.
There is a real problem in that keypad information must be sent before
connect message. This is needed to support network services in the U.S. Because the H.245 rules require the exchange of TSC and master-slave before any other messages may be sent, there is a significate delay after fast connect before keypad digits may be sent. In Osaka, several proposal were submitted to solve this and other needed negotiation problems. The agreed solution was the proposal for which you have reservations. This is needed in the real world.
PLEASE! find a solutions that will not remove these changes!
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, May 31, 2000 11:14 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
We agreed at the Osaka meeting to allow a SETUP to contain both the fastStart and h245Control, but it has not been officially approved by
Bob, and others, Just in case any clarification is required,... As you say, we certainly can NOT document that fast start is deprecated in V4. We may never be able to document such a thing. However, we can certainly discuss it on the list at this time, and such discussions may have a bearing on what we decide to do. 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.INTEL.COM> Sent: 08 June 2000 13:14 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 the the
ITU.
As it stands right now, I don't think I can agree to include it in H.323v4 on the grounds that it breaks backward compatibility with V2-- I just don't see a clean solution here.
I'm opening to hearing more suggestions, but as you pointed out, there are two issues: 1) H.323v2 states explicitly that it is illegal 2) There is no way to know what version to destination EP is before sending this illegal message
Paul
----- Original Message ----- From: "Paul Long" <Plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, May 31, 2000 10:34 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pete,
Table 13/H.225.0v3 shows that the User-to-User IE is mandatory. What IEs do you believe are not mandatory?
H.323 states that the fastStart and h245Control components cannot both be present in the Setup message (do I need to quote it again?). A Setup User-to-User IE containing either or neither component is valid; one containing both is clearly invalid. Why do you think otherwise?
H.323, by way of Q.931, requires that the called EP respond with ReleaseComplete with cause 100. There is no other appropriate cause.
The feature that should be deprecated is the inclusion of both fastStart and h245Control in Setup. I was under the impression that either through IGv3 or H.323v4 this had already made it into the standard. If its not too late, we should simply remove this feature from any proposed text; if it is too late, we should deprecate it because it causes insurmountable backward compatibility problems.
Paul
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, May 31, 2000 4:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
I don't really believe that the release cause you cite is valid. The IEs are not mandatory, and (taken by themselves) they don't have invalid content. I don't believe it is the intent of this cause code to signal the sort of thing that we are talking about here either.
Are there any other causes and clauses that you think might be more appropriate?
Also, when you say "the feature" should be deprecated, what are you referring to as "the feature"? I'm not quite clear.
Pete.
============================================= Pete Cordell pete@tech-know-ware.com =============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Chris,
It is valid for a discussion of the problems and desires on this list. However, no decision may be made on the list. Decisions are made at meetings.
The actual rules for the operation of the documents under the scope of a Study Group question is at the descression of the Rapateur. At the worst, it is possible for the Rapateur to submit documents without input from anyone. As I understand it, Q.13/16 has agreed to use meetings as the location where decisions are made. It also guided us that conference calls and the mailing list may be used to enhance the discussion. Based on the direction given in Osaka, the correction to the agreed content for the white paper being done in conference calls and the mailing list would not include any substative change. In my mind, dropping fast TCS and M/S is a substative change. The choices should limited to including TD-26 as is based on the understanding of the participants or to find limited "editorial" changes that will not change the substance of the contribution. Also deprecating FastStart is a substative change beyond any discussion at this time. All things can be proposed in Portland, subject to the limitation to changes in the White Paper. All things can be proposed in Geneva, subject to a potential delay in v4.
Bob
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, June 06, 2000 12:42 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Bob,
Is it really beyond the editor's discretion to react to problems which come to light in between the formal meetings? I thought that was one of the purposes of this list! Alternative solutions are being sought, but the one discussed in Osaka is clearly too flawed to be permitted to proceed.
Regards, Chris
"Callaghan, Robert" wrote:
Paul,
I was afraid that this might happen.
The changes under discussion were agreed to in Osaka, with the
participants
understanding the risks. To not include it in v4 would be a substantive change from the agreed content which I challenge as being beyond the discression of the editor to make editorial changes.
There is a real problem in that keypad information must be sent before
connect message. This is needed to support network services in the U.S. Because the H.245 rules require the exchange of TSC and master-slave before any other messages may be sent, there is a significate delay after fast connect before keypad digits may be sent. In Osaka, several proposal were submitted to solve this and other needed negotiation problems. The agreed solution was the proposal for which you have reservations. This is needed in the real world.
PLEASE! find a solutions that will not remove these changes!
Bob
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Wednesday, May 31, 2000 11:14 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
We agreed at the Osaka meeting to allow a SETUP to contain both the fastStart and h245Control, but it has not been officially approved by
Bob, The rapporteur is charged with producing quality text that is delivered on time. Part of that responsibility is necessarily delegated to the editors. Now, you know me and you know that I would never conscienously leave out material or alter material in any technical way. I will work to resolve issues such as this one, and I believe we have worked out a preliminary solution. However, there has been no "decision" on the H.323v4 document. The H.323v4 document has not been reviewed-- at least this material has not been reviewed in the context of the H.323v4 text. It is completely appropriate for Experts to object to the inclusion of TD-26 during the formal H.323v4 document review, which will be conducted via a phone conference within the next couple of weeks. I suppose it is perfectly within the right of the Rapporteur to object to my objection, but I am quite sure that Mr. Skran would not want to knowingly include text that would break backward compatibility with previous versions of H.323. On the contrary, I am quite sure that he would want me to review contributions as I prepare the document and raise these very issues. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan@ICN.SIEMENS.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Thursday, June 08, 2000 8:14 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 the the
ITU.
As it stands right now, I don't think I can agree to include it in H.323v4 on the grounds that it breaks backward compatibility with V2-- I just don't see a clean solution here.
I'm opening to hearing more suggestions, but as you pointed out, there are two issues: 1) H.323v2 states explicitly that it is illegal 2) There is no way to know what version to destination EP is before sending this illegal message
Paul
----- Original Message ----- From: "Paul Long" <Plong@SMITHMICRO.COM> To: <ITU-SG16@mailbag.cps.intel.com> Sent: Wednesday, May 31, 2000 10:34 AM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Pete,
Table 13/H.225.0v3 shows that the User-to-User IE is mandatory. What IEs do you believe are not mandatory?
H.323 states that the fastStart and h245Control components cannot both be present in the Setup message (do I need to quote it again?). A Setup User-to-User IE containing either or neither component is valid; one containing both is clearly invalid. Why do you think otherwise?
H.323, by way of Q.931, requires that the called EP respond with ReleaseComplete with cause 100. There is no other appropriate cause.
The feature that should be deprecated is the inclusion of both fastStart and h245Control in Setup. I was under the impression that either through IGv3 or H.323v4 this had already made it into the standard. If its not too late, we should simply remove this feature from any proposed text; if it is too late, we should deprecate it because it causes insurmountable backward compatibility problems.
Paul
-----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, May 31, 2000 4:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
Paul,
I don't really believe that the release cause you cite is valid. The IEs are not mandatory, and (taken by themselves) they don't have invalid content. I don't believe it is the intent of this cause code to signal the sort of thing that we are talking about here either.
Are there any other causes and clauses that you think might be more appropriate?
Also, when you say "the feature" should be deprecated, what are you referring to as "the feature"? I'm not quite clear.
Pete.
============================================= Pete Cordell pete@tech-know-ware.com =============================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
-- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (3)
-
Callaghan, Robert -
Paul E. Jones -
Pete Cordell