- sg16-avd - lists.packetizer.com

Re: Use of two Calling Party Number IEs
by Callaghan, Robert 13 Jun '00

13 Jun '00

Rich, Yes, this is allowed under the clause that allows any information arriving from an ISDN gateway to be transported over the Q.931 portion of H.225.0. It is not to be generated by any H.323 terminal. On the other hand, how many stacks would think of this. The essence of France Telecom's proposal is to allow transport of a user provided number and a secure network provided number with ISUP and ISDN as examples. It should not be limited to ISUP or ISDN provided numbers. It should be allowed when secure network is H.323. This requires that the numbers be generated by H.323 terminals. This is contray to the clause referenced in the first paragraph. Also this only works for E.164 type numbers in that H.225.0 can only transport this type of number in the Calling Party Number Ie. Other forms of numbers (e.g. Private Number, URL) must be transported in ASN.1 coding. It is possible to tranport more that one number in the Calling Party Number field; but how do you mark one as user provided and the other network provided? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Monday, June 12, 2000 4:37 PM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: Re: Use of two Calling Party Number IEs Bob, Annex A/Q.951, for some good editorial reason I'm sure, is between Clauses 3 and 4 in Q.951.3. My understanding from the discussion was that this option is already allowed in H.225.0, and that we just needed to clarify that it is allowed. For the ISUP case, Note 1 at the bottom of Table 56 of H.246 Annex C states that two Calling Party Number IEs are sent in H.225.0 if the option is supported, or that only the generic number is forwarded if the option is not supported. For the Q.931 case, I assumed the same approach would apply. I'm not sure I understand the issues about multiple private numbers or URLs. I don't think the scope of this contribution included URLs, etc. It was only addressing the case of receiving two calling party number IEs from the SCN. - Rich "Callaghan, Robert" wrote: > > Rich, > > We did not agree to a delivery method in Osaka. I certainly would like to > review any proposed method before agreeing. > > I could not fine Annex A/Q.951; could you help. > > In all probability, it proposes the duplication of the Calling Party Number > IE; each with individual presentation and screening controls. How does this > map to H.225.0? How do you have private number each with individual > presentation and screening controls? Does this include multiple URLs, > E-mail address, etc.? > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Rich Bowen [mailto:rkbowen@CISCO.COM] > Sent: Sunday, June 11, 2000 10:24 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Use of two Calling Party Number IEs > > Mr. Blin, > > In Osaka, it was agreed as you proposed in TD-09 to add clarifying text > to H.225.0 regarding the use of two calling party number IEs. Would the > following clarification address this concern? > > A note would be added to the Setup message IE table concerning use of > the Calling Party Number IE that would state: > > Multiple Calling Party Number IEs may be present in order to > support, for example, the "Two Calling party number information > elements delivery option" defined in Annex A/Q.951 or the > interworking of H.323 and ISUP supplementary services as described > in Annex C/H.246. > > Regards, > Rich > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > rkbowen(a)cisco.com Research Triangle Park, NC > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Use of two Calling Party Number IEs
by Callaghan, Robert 12 Jun '00

12 Jun '00

Rich, We did not agree to a delivery method in Osaka. I certainly would like to review any proposed method before agreeing. I could not fine Annex A/Q.951; could you help. In all probability, it proposes the duplication of the Calling Party Number IE; each with individual presentation and screening controls. How does this map to H.225.0? How do you have private number each with individual presentation and screening controls? Does this include multiple URLs, E-mail address, etc.? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Sunday, June 11, 2000 10:24 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Use of two Calling Party Number IEs Mr. Blin, In Osaka, it was agreed as you proposed in TD-09 to add clarifying text to H.225.0 regarding the use of two calling party number IEs. Would the following clarification address this concern? A note would be added to the Setup message IE table concerning use of the Calling Party Number IE that would state: Multiple Calling Party Number IEs may be present in order to support, for example, the "Two Calling party number information elements delivery option" defined in Annex A/Q.951 or the interworking of H.323 and ISUP supplementary services as described in Annex C/H.246. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Issue with APC-1804
by Callaghan, Robert 12 Jun '00

12 Jun '00

Paul, The definition of the global call reference is a value that represent all call references on a link. Q.931 limites this to STATUS, RESTART, and RESTART ACK in that these are the only messages that can have global context. It would be valid for H.225.0 to extend this to any message that can reasonable have a global context (Remember this is not Q.931). The proposal is the use the FACILITY Message to indicate the ability of the link; that is all call references on the link. This seems reasonable. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, June 12, 2000 2:53 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Issue with APC-1804 Folks, APC-1804 describes how an entity may signal its current ability to handle multiple connections over a call signaling channel. The intent is for this to be a dynamic capability. Two issues: 1) This has been proposed for the H.323v3 IG. Will there be any backward compatibility issues? 2) The text of the proposal (as agreed and further truncated my me) reads: ``An entity may dynamically set the value of the multipleCalls field in order to indicate its present ability to support multiple connections along the Call Signalling Channel. If an endpoint wishes to change the value of multipleCalls at a time when no other H.225.0 messages are being exchanged across the call signalling channel, it shall transmit the multipleCalls field via a Facility message and the CRV shall be the Global Call Reference as shown in Figure 4-5/Q.931.'' The desire was to use the Global Call Reference value to indicate a change in this capability when no messages are being exchange. It was also proposed that the Facility message shall be used. However, I believe that Q.931 limits the Global Call Reference value to being used with Status, Restart, and Restart Acknowledge. Is this a point that may become an issue for us in the future or is it acceptable that we are using the Facility message with the Global Call Reference when Q.931 forbids such use? (Perhaps I am wrong on this point.. I invite the correction!) Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Another H323/H225 defect
by Callaghan, Robert 12 Jun '00

12 Jun '00

Paul, I brought a contribution to Belin for the correction of this problem. It was rejected as breaking many current implementations. We will have to live with this errror. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 10, 2000 7:02 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Another H323/H225 defect Folks, Since we're raising issues with coding Q.931 IEs, I thought that it would be appropriate to post this message I received some time back. (I removed the person's name and such, in case they preferred not to share this with the world.) Is this a change that we should consider? Paul ----- Original Message (modified) ----- During recent H323 interoperability testing in Portland the problem detailed below was identified. I could not find an existing Implementors Guide or draft recommendation that covers this issue. Could you take a look at this and let me know if there is an existing decision (or update) on this item. Affected recommendation: H225 Summary: Q931 and H225 descriptions of Bearer Capability IE octet 4 are not consistent Description: In Q931 Section 4.5.5 Bearer Capability IE octet 4 always has the extension bit set. The existence of octet 4.1 is determined based on the contents of octet 4. This is shown in Figure 4-11/Q.931 and elaborated on by Note 1 below the table. In H225 Section 7.2.2.1 Bearer Capability IE octet 4 extension bit "Shall be set to '0' if the information transfer rate is set to multirate". However the same section says that the information element is encoded according to Figure 4-11/Q.931. Suggested resolution: Document (in H225) this bit as working as documented in Q931. Add a note that implementations should not rely upon this bit and should not use it as an indication that octet 4.1 exists (instead should check for multirate setting). This solution will have a low level of impact on existing systems and retains interoperability with Q931 ISDN equipment.

1 0

Issue with APC-1804
by Paul E. Jones 12 Jun '00

12 Jun '00

Folks, APC-1804 describes how an entity may signal its current ability to handle multiple connections over a call signaling channel. The intent is for this to be a dynamic capability. Two issues: 1) This has been proposed for the H.323v3 IG. Will there be any backward compatibility issues? 2) The text of the proposal (as agreed and further truncated my me) reads: ``An entity may dynamically set the value of the multipleCalls field in order to indicate its present ability to support multiple connections along the Call Signalling Channel. If an endpoint wishes to change the value of multipleCalls at a time when no other H.225.0 messages are being exchanged across the call signalling channel, it shall transmit the multipleCalls field via a Facility message and the CRV shall be the Global Call Reference as shown in Figure 4-5/Q.931.'' The desire was to use the Global Call Reference value to indicate a change in this capability when no messages are being exchange. It was also proposed that the Facility message shall be used. However, I believe that Q.931 limits the Global Call Reference value to being used with Status, Restart, and Restart Acknowledge. Is this a point that may become an issue for us in the future or is it acceptable that we are using the Facility message with the Global Call Reference when Q.931 forbids such use? (Perhaps I am wrong on this point.. I invite the correction!) Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Use of two Calling Party Number IEs
by Rich Bowen 11 Jun '00

11 Jun '00

Mr. Blin, In Osaka, it was agreed as you proposed in TD-09 to add clarifying text to H.225.0 regarding the use of two calling party number IEs. Would the following clarification address this concern? A note would be added to the Setup message IE table concerning use of the Calling Party Number IE that would state: Multiple Calling Party Number IEs may be present in order to support, for example, the "Two Calling party number information elements delivery option" defined in Annex A/Q.951 or the interworking of H.323 and ISUP supplementary services as described in Annex C/H.246. Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. rkbowen(a)cisco.com Research Triangle Park, NC -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Another H323/H225 defect
by Paul E. Jones 10 Jun '00

10 Jun '00

Folks, Since we're raising issues with coding Q.931 IEs, I thought that it would be appropriate to post this message I received some time back. (I removed the person's name and such, in case they preferred not to share this with the world.) Is this a change that we should consider? Paul ----- Original Message (modified) ----- During recent H323 interoperability testing in Portland the problem detailed below was identified. I could not find an existing Implementors Guide or draft recommendation that covers this issue. Could you take a look at this and let me know if there is an existing decision (or update) on this item. Affected recommendation: H225 Summary: Q931 and H225 descriptions of Bearer Capability IE octet 4 are not consistent Description: In Q931 Section 4.5.5 Bearer Capability IE octet 4 always has the extension bit set. The existence of octet 4.1 is determined based on the contents of octet 4. This is shown in Figure 4-11/Q.931 and elaborated on by Note 1 below the table. In H225 Section 7.2.2.1 Bearer Capability IE octet 4 extension bit "Shall be set to '0' if the information transfer rate is set to multirate". However the same section says that the information element is encoded according to Figure 4-11/Q.931. Suggested resolution: Document (in H225) this bit as working as documented in Q931. Add a note that implementations should not rely upon this bit and should not use it as an indication that octet 4.1 exists (instead should check for multirate setting). This solution will have a low level of impact on existing systems and retains interoperability with Q931 ISDN equipment.

1 0

One step at a time...
by Paul E. Jones 10 Jun '00

10 Jun '00

Folks, It appears we have a more positive article on H.323: http://www.csdmag.com/main/2000/06/0006top.htm I've seen plenty attacking H.323 (often from the same small group of people), but I have seen few saying good things about the protocol. Have you seen other positive articles? If so, please send me pointers. If I get a few, I may put something on Packetizer :-) Paul

1 0

3rd CFP (EXTENDED DEADLINE): IP Telecom Services Workshop 2000
by Gregory W. Bond 09 Jun '00

09 Jun '00

[Please accept our apologies for multiple copies of this call.] ------------- THIRD CALL FOR PAPERS --------------- ------------- EXTENDED DEADLINE --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 submission deadline: June 23, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. The IPTS 2000 Program Committee invites submission of papers on substantial, original and previously unpublished research in IP telecom services, including, but not limited to: - service architectures (e.g. AIN, SoftSwitch, JAIN, Parlay, DFC) - service creation environments - protocols, standards and interoperability (e.g. H.323, SIP, MGCP, Megaco/H.248, etc.) - service programming languages - service management - billing, fault tolerance, monitoring - novel services We welcome papers describing original research; position papers describing research interests in the field, work in progress, or future directions of research; project or system descriptions. IMPORTANT DATES June 23, 2000 Submission deadline July 21, 2000 Notification of acceptance August 25, 2000 Final version of papers September 11, 2000 IPTS 2000 PAPER SUBMISSIONS Papers must describe original, previously unpublished work that has not been simultaneously submitted for publication elsewhere. They must be written in English, not exceeding 6 pages including figures, tables and references in 10-12 point font on 8.5x11-inch (US letter) paper. The first page must include an abstract of up to 200 words, keywords, and email address of the corresponding author. All papers must be submitted electronically unless specifically approved by the Workshop Co-Chairs. Submissions in PostScript or PDF format should be sent to mailto:ipts2000@research.att.com. Authors of accepted papers are expected to present their contribution at the workshop. The proceedings will be published in hardcopy and on the web. REVIEW PROCEDURE All submissions will be subject to academic peer review by the IPTS 2000 Program Committee under the chairmanship of the Workshop Co-Chairs. Each paper will receive three written reviews, and reviews will be returned to the authors. The Workshop Co-Chairs have final authority over the review process and all decisions relating to acceptance of papers. Review criteria include originality of ideas, technical soundness, significance of results, and quality of presentation. CONFERENCE VENUE AND RELATED EVENTS IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Details about Fall 2000 VON can be found at http://pulver.com. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com) WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: H.225.0 v4 inconsistencies/errors found
by Horvath Ernst 09 Jun '00

09 Jun '00

Paul, having been through it a number of time does not solve a problem at all unless we fix it. Facts are: 1) Octet 3a is an optional octet in calling party number IE. It may or may not be present. 2) Q.931 clause 4.5.1, which is mandatory for H.225.0 (see clause 7.2.2), specifies the use of the extension bit to indicate presence or absence of optional octets. 3) My interpretation of 7.2.2.6 of H.225.0 is that Q.931 clause 4.5.10 applies for the coding of calling party number, including the use of octet 3 bit 8 as extension bit. 4) As octet 3a was not allowed in H.323v1, bit 8 in octet 3 was correctly set to '1'. 5) Octet 3a, when present, poses a problem for v1 in any case, independent of bit 8 of octet 3! 6) Clearing the call if an optional information element is flawed is not correct - it should be ignored. Clearing is only correct for erroneous mandatory or 'comprehension-required' optional IEs. Calling party number is not 'comprehension-required'. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Paul Long [mailto:Plong@SMITHMICRO.COM] > Gesendet am: Donnerstag, 08. Juni 2000 05:03 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: H.225.0 v4 inconsistencies/errors found > > Karl, > > We've been through this before. Allowing the extension bit in > octet 3 to be > set to 0 causes H.225.0v4 to be inconsistent with earlier versions and > potentially causes insurmountable backwards-compatibility > problems between > v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall > not be set to > 0 under any circumstances. Since the calling EP cannot know > the version of > the called EP before it sends Setup, it would be sending an > IE that would > contain invalid content for a pre-v4 EP. According to Q.931, > the receiving > EP would then be required to terminate the call with > ReleaseComplete. A safe > solution would be to add a new Calling Party Number field > where this bit is > allowed to be set to 0. > > Paul Long > Smith Micro Software, Inc. > "Primum non nocere" > > -----Original Message----- > From: Klaghofer Karl ICN SIB NL D1 > [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: Wednesday, June 07, 2000 10:29 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.225.0 v4 inconsistencies/errors found > > > Rich, and others > > Please find below comments I have in the area of Calling > Party Number IE > and > the ASN.1 elements ScreeningIndicator and PresentationIndicator. > Comments no. 1-4 should be corrected by the editor in v4, since these > are > inconsistencies/errors. Comment 5 could be solved later. > > > 1) Calling Party Number IE (octet 3 extension bit 8) > The H.225.0v4 definition looks as follows: > - Set to '1' > This is not compliant with the extension bit handling used in > Q.931 and > H.225.0. It should be corrected in v4 (v3 impl guide) to read: > - Set to '1' if octet 3a is not present; set to "0" if > octet 3a is > present. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

6 6

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 09 Jun '00

09 Jun '00

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(a)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(a)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(a)SMITHMICRO.COM> > To: <ITU-SG16(a)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(a)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(a)tech-know-ware.com > > ============================================= > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)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(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: H.225.0 v4 inconsistencies/errors found
by Callaghan, Robert 08 Jun '00

08 Jun '00

Rich, >IMO, we should keep it simple, one indicator applies to all aliases. >E.g., in example 2, if one verification fails, they all are considered >to have failed. Is it really valuable to be able to independently >indicate the status of multiple aliases? > >The alternative would be to have a list of presentation and screening >indicators. I think it's too late to add this to v3, and would be >complicated to add to v4 since it would be a separate field. (It's bad >enough that we have both an indicator field and an IE in some messages!) The problem comes from the situation that Mr. Blin has been trying to solve where where are two numbers - one is user provided (screen or not screened) and the other is Service Provider provided. How does one indicate which is which and the relative reliability of each. There may not be an immedite solution; but a solution is needed. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225.0 v4 inconsistencies/errors found
by Klaghofer Karl ICN SIB NL D1 08 Jun '00

08 Jun '00

Rich, and others Please find below comments I have in the area of Calling Party Number IE and the ASN.1 elements ScreeningIndicator and PresentationIndicator. Comments no. 1-4 should be corrected by the editor in v4, since these are inconsistencies/errors. Comment 5 could be solved later. 1) Calling Party Number IE (octet 3 extension bit 8) The H.225.0v4 definition looks as follows: - Set to '1' This is not compliant with the extension bit handling used in Q.931 and H.225.0. It should be corrected in v4 (v3 impl guide) to read: - Set to '1' if octet 3a is not present; set to "0" if octet 3a is present. 2) Calling Party Number IE in draft H.225.0v4 (editorial only) There are two descriptions for "Type of number" in the H.225.0v4 draft - one too much. The first one should be deleted. "..... Type of number (octet No. 3, bits 5-7) - Encoded following the values and rules of Table 4-11/Q.931. Type of number (octet No. 3, bits 5-7) - Encoded following the values and rules of Table 4-11/Q.931. A number with the Numbering plan identification coded as '0000' (Unknown) shall be coded as '000' (Unknown). A number with the Numbering plan identification coded as '0001' (ISDN/Telephony Numbering Plan, Recommendation E.164) with the Type of number coded as '000' (Unknown) may be used for backward compatibility. ......." 3) Inconsistency of Screening Indicator usage With use of Calling Party Number IE, the octet 3a allows for setting of all four Q.931 defined Screening indicator values. When using the Setup-UUIE.screeningIndicator (for controlling the Setup-UUIE.sourceAddress), then the value "userProvidedVerifiedAndFailed" is not allowed (according to the current ASN.1 comment of type ScreeningIndicator definition). This is inconsistent. Since the text in H.323v3, v4 clause 7.8 Caller Identification Service allows the usage of all four values, the current ASN.1 comment for ScreeningIndicator value (2) which reads "-- not used, value reserved" should be deleted in v4. 4) Arguments presentationIndicator and screeningIndicator in Setup-UUIE should be OPTIONAL Why are they mandatory in H.225.0v4 ? What if I do not include the sourceAddress ? Same comment applies to Alerting-UUIE, ReleaseComplete-UUIE, Connect-UUIE Please also check v3. 5) Multiple alias addresses in Setup-UUIE.sourceAddress - how to apply different screening indicators/presentation indicators The Setup-UUIE.sourceAddress allows to put multiple aliases (sourceAddress SEQUENCE OF AliasAddress) within the SETUP message. With the current definition of types ScreeningIndicator and PresentationIndicator it is not possible to have different settings for the various aliases contained in sourceAddress. The same comment applies to busyAddress, alertingAddress and connectedAddress. Example 1: How to set e.g. the Setup-UUIE.screeningIndicator if the terminal has provided an alias 1 in Setup-UUIE.sourceAddress (i.e. screeningIndicator should be set to userProvidedNotScreened (0) for this alias) but the GK adds an alias 2 (i.e. screeningIndicator should be set to networkProvided (3) for this alias). Example 2: Both aliases provided by terminal. GK screens both aliases - one verification is successful (i.e. use value 1), the other is verified and failed (i.e. value 2 should be used), ..... Regards, Karl Klaghofer, Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 08 Jun '00

08 Jun '00

Jane, The only race condition lies in the OLC procedure. It should be possible to restrict OLC procedure elements until FastStart has either completed or is rejected. bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Jane Hua [mailto:huajane@YAHOO.COM] Sent: Wednesday, June 07, 2000 2:18 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Pre Script: Sorry for the previous mail Hi All, As far as my understanding goes, the purpose of prohibiting both fastStart and H.245 tunnel in SETUP was to avoid race conditions in two tunnels (fastStart can also be considered as a H.245 tunnel with different procedures). Here we are adding a new tunnel which will lead to more such race scenarios until proper care is taken in defining the procedures. The decision on this should not be like a voice vote in Congress. The procedures should be clearly documented and circulated over the reflector and let people argue on those concrete documented steps. Let us see, can we fix the problem introduced by introduction of fastStart? Regards, Jane Hua Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg(a)lucent.com +1 303 538 3868 Paul Long wrote: > > Bob, > > H.323 only says that fastStart and h245Control cannot both be included in > _Setup_, so it could indeed be included in the Setup-UUIE type. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Tuesday, June 06, 2000 10:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > Paul, > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and > CONNECT message in that all of these messages can be sent before Fast > Start > is completed or may not be present with Fast Start elements based on v2. > > Bob > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 08 Jun '00

08 Jun '00

Looks good to me. > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: Wednesday, June 07, 2000 8:50 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Paul, > > While you're at it, I would like to propose these (hopefully) > uncontroversial corrections and a clarification to TD-26a. Here are my > recommendations. > > 1. However rare, an EP may have a valid reason to reject TCS or MSD. > Therefore, we cannot require that the called EP always > respond with TCSAck > and MSDAck. Replace this passage: > > "... it shall include the fastStart element and the > h245Control element > including both the TerminalCapabilitySetAck for the calling > endpoint, the > TerminalCapabilitySet for the called endpoint and the > MasterSlaveDeterminationAck in the same H.225.0 message." > > with this: > > "... it shall encode the fastStart element and the > h245Control element in > the same call-signalling message. This h245Control element > shall contain the > TerminalCapabilitySet for the called endpoint and the called > endpoint's > responses to the calling endpoint's TerminalCapabilitySet and > MasterSlaveDetermination." > > 2. Likewise, replace this: > > "If the h245Control element with the TerminalCapabilitySetAck for the > calling endpoint, the TerminalCapabilitySet for the called > endpoint and > MasterSlaveDeterminationAck are not received in the same message as > fastStart (e.g., because the called endpoint is pre-H.323v4), > the fast start > procedures shall be completed, but not the Terminal Capability Set > negotiation and the Master/Slave Determination procedures." > > with this: > > "If the h245Control element with the called endpoint's > TerminalCapabilitySet > and the called endpoint's responses to the calling endpoint's > TerminalCapabilitySet and MasterSlaveDetermination are not > received in the > same message as fastStart (e.g., because the called endpoint is > pre-H.323v4), the fast start procedures shall be completed, > but not the > Terminal Capability Set negotiation and the Master/Slave Determination > procedures." > > 3. It's not a big deal, but I'd like to make the disposition > of the MSD and > TCS procedures clearer by adding this to the end of the above > sentence: > > ", as if they had never been initiated by the calling endpoint" > > Paul Long > Smith Micro Software, Inc. > "Primum non nocere" > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Wednesday, June 07, 2000 2:59 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Jane, > > I suspect that TD-26 has the procedural issues addressed-- it > will just > be a > matter of specifying the usage of a different field. > > I'll have to review what is written there, but the most obvious way to > prevent race conditions is to specify that channels may not be opened > via > H.245 until Fast Connect is accepted, explicitly refused, or > implicitly > refused by not receiving a fastStart element up to and including > CONNECT. > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

AW: H.225.0 v4 inconsistencies/errors found
by Klaghofer Karl ICN SIB NL D1 08 Jun '00

08 Jun '00

Paul, With not correcting the extension bit, a v1,v2 receiver of a current v3 or v4 Calling party number IE (that includes octet 3a) would interpret the octet 3a being the first number digit. I do not consider this backwards compatible ! With correcting the extension bit as proposed below, the backwards compatibility problem would be solved. A v1,v2 receiver always expects octet 3 bit 8 set to 1. So far we agree. See two cases below: a) If a v3,v4 sender does not include octet 3a the extension bit would be set to 1 and the v1,v2 receiver is happy and can interpret the IE. b) If the v3, v4 sender does include the octet 3a, the extension bit shall be set to 0. The v1, v2 receiver is required to act according to the so called "non-mandatory information element contents error procedures of Q.931", which is to ignore the IE but process the rest of the message - which is exactly what we want since the v1, v2 receiver would e.g. not honor a presentation restriction flag anyway. Paul, to release the call due to a non mandatory information element content error - as you mention - is wrong behavier. Please no further field or element - we have already enough of them ! Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Gesendet am: Thursday, June 08, 2000 05:03 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: H.225.0 v4 inconsistencies/errors found > > Karl, > > We've been through this before. Allowing the extension bit in octet 3 to > be > set to 0 causes H.225.0v4 to be inconsistent with earlier versions and > potentially causes insurmountable backwards-compatibility problems between > v4 EPs and v1, v2, and v3 EPs. For pre-v4 EPs, this bit shall not be set > to > 0 under any circumstances. Since the calling EP cannot know the version of > the called EP before it sends Setup, it would be sending an IE that would > contain invalid content for a pre-v4 EP. According to Q.931, the receiving > EP would then be required to terminate the call with ReleaseComplete. A > safe > solution would be to add a new Calling Party Number field where this bit > is > allowed to be set to 0. > > Paul Long > Smith Micro Software, Inc. > "Primum non nocere" > > -----Original Message----- > From: Klaghofer Karl ICN SIB NL D1 > [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: Wednesday, June 07, 2000 10:29 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.225.0 v4 inconsistencies/errors found > > > Rich, and others > > Please find below comments I have in the area of Calling Party Number IE > and > the ASN.1 elements ScreeningIndicator and PresentationIndicator. > Comments no. 1-4 should be corrected by the editor in v4, since these > are > inconsistencies/errors. Comment 5 could be solved later. > > > 1) Calling Party Number IE (octet 3 extension bit 8) > The H.225.0v4 definition looks as follows: > - Set to '1' > This is not compliant with the extension bit handling used in Q.931 and > H.225.0. It should be corrected in v4 (v3 impl guide) to read: > - Set to '1' if octet 3a is not present; set to "0" if octet 3a is > present. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 08 Jun '00

08 Jun '00

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(a)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(a)tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Paul E. Jones <paulej(a)PACKETIZER.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: 07 June 2000 07:18 Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Dave, > > Arguably (and yes, I've heard plenty), this little feature has a few > benefits-- notably, prevention of media clipping and call handling with the > involvement of an ACD system. > > Advocates of "other solutions" will have similar problems when their > solutions reach a similar level of maturity. I believe that any system has > pros and cons and we cannot necessarily say we "screwed it up" in this case. > It's a matter of wanting to extend current functionality, while preserving > backward compatibility. Should we have allowed FC and tunneling? Perhaps, > but I am sure that time constraints were an unavoidable factor in that > decision. > > With previous releases of H.323, such strict policies on backward > compatibility was not such a big deal, as there were not nearly so many > implementations. Today, this is a serious issue-- we have to preserve > backward compatibility with V2 with no exceptions, as it is widely deployed > in production networks. > > Paul > > ----- Original Message ----- > From: "Dave Walker" <drwalker(a)ss8networks.com> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Tuesday, June 06, 2000 4:44 PM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > Paul, why are we even doing this? I'd just tell Bob to use the Keypad > > Facility IE if he really needs DTMF signalling. You must realize how > > ridiculous this'll look to advocates of other solutions: the ITU > > screwed up H.245 tunneling, and now they're adding a new tunnel to fix > > it - yech. > > > > Dave. > > > > > > "Paul E. Jones" wrote: > > > > > > Bob, > > > > > > For messages other than SETUP, I was assuming we could use the existing > > > h245Control field for H.245 message exchange-- only the SETUP message is > a > > > special case, since it was explicitly disallowed in H.323v2 when > fastStart > > > was also present. > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > > > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> > > > Cc: "'Mailing list for parties associated with ITU-T Study Group 16'" > > > <ITU-SG16(a)mailbag.cps.intel.com> > > > Sent: Tuesday, June 06, 2000 11:27 AM > > > Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > Paul, > > > > > > > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, > and > > > > CONNECT message in that all of these messages can be sent before Fast > > > Start > > > > is completed or may not be present with Fast Start elements based on > v2. > > > > > > > > Bob > > > > > > > > -----Original Message----- > > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > > Sent: Saturday, June 03, 2000 6:41 AM > > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > > > > Paul, Francois, and others, > > > > > > > > If we were able to get consensus here, I believe we could add a field > to > > > the > > > > SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is > > > intended > > > > for SETUP only as a means of allowing H.245 to used with fastConnect > in a > > > > backward compatible manner. > > > > > > > > We have an entire proposal on verbiage to be added to H.323. I'll > have to > > > > review that to see what needs changing-- but there's actually a lot of > > > > description. > > > > > > > > Can we agree to introduce a new "earlyH245" field to go along with > > > > "fastStart" in the SETUP? > > > > > > > > Paul > > > > > > > > ----- Original Message ----- > > > > From: "Paul Long" <Plong(a)SMITHMICRO.COM> > > > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > > > Sent: Friday, June 02, 2000 10:11 PM > > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > > > > > Paul, > > > > > > > > > > While not ideal (nothing is), that's a safe, workable solution. I > like > > > it. > > > > > Are you proposing adding the new component to the H323-UU-PDU or the > > > > > Setup-UUIE type? Both locations have their merits. This then should > be > > > the > > > > > new text for section 8.2.1/H.323: "The calling endpoint shall not > > > include > > > > > both a fastStart element and encapsulated H.245 messages in > h245Control > > > in > > > > > the same Setup message. However, the calling endpoint may include > both a > > > > > fastStart element and encapsulated H.245 messages in > earlyH245Control in > > > > the > > > > > same Setup message." And then explain what the called endpoint is > > > supposed > > > > > to do when fastStart and earlyH245Control are present. While we're > at > > > it, > > > > > maybe we should define a separate type, i.e., > > > > > > > > > > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > > > > > -- each octet string > may > > > > contain exactly > > > > > -- one H.245 PDU > > > > > > > > > > But now how do the two components, h245Control and earlyH245Control > > > > > otherwise relate to each other, i.e., when fastStart is not > included? > > > > Should > > > > > we say that if one is present the other shall not be present? That > would > > > > be > > > > > the clearest, IMO. Not much is gained by allowing both. > > > > > > > > > > > > > > > Remember, the first rule of standards revision is (everybody repeat > > > after > > > > > me)... > > > > > "Primum non nocere" ("First do no harm.") > > > > > - the Roman physician, Galen > > > > > > > > > > Paul Long > > > > > Smith Micro Software, Inc. > > > > > > > > > > -----Original Message----- > > > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > > > Sent: Friday, June 02, 2000 8:14 PM > > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > > > > > > > Francois, > > > > > > > > > > I agree that the behavior is desirable, but I still argue that it > will > > > > > break backward compatibility. If we can agree with a new field > > > > > "earlyH245" as a special field for SETUP to do essentially the same > > > > > thing, but only for V4, I would be quite happy-- we get the same end > > > > > result without V3 and V2 compatibility issues. > > > > > > > > > > I do not want to wait until Portland. The Whitepaper drafts are due > > > > > before then and I hope that that meeting will be focused on only > > > > > critical issues in H.323 and that most of our time will be spent on > > > > > further development of Annexes and perhaps forward thinking on V5 > :-) > > > > > > > > > > Paul > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > > > listserv(a)mailbag.intel.com > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > > listserv(a)mailbag.intel.com > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Jane Hua 08 Jun '00

08 Jun '00

Pre Script: Sorry for the previous mail Hi All, As far as my understanding goes, the purpose of prohibiting both fastStart and H.245 tunnel in SETUP was to avoid race conditions in two tunnels (fastStart can also be considered as a H.245 tunnel with different procedures). Here we are adding a new tunnel which will lead to more such race scenarios until proper care is taken in defining the procedures. The decision on this should not be like a voice vote in Congress. The procedures should be clearly documented and circulated over the reflector and let people argue on those concrete documented steps. Let us see, can we fix the problem introduced by introduction of fastStart? Regards, Jane Hua Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg(a)lucent.com +1 303 538 3868 Paul Long wrote: > > Bob, > > H.323 only says that fastStart and h245Control cannot both be included in > _Setup_, so it could indeed be included in the Setup-UUIE type. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Tuesday, June 06, 2000 10:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > Paul, > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and > CONNECT message in that all of these messages can be sent before Fast > Start > is completed or may not be present with Fast Start elements based on v2. > > Bob > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 3

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Jane Hua 07 Jun '00

07 Jun '00

Paul- The problem is that inclusion of an H.245 message in the tunnel terminates FastStart according to section 8.2.1 of H.323. This could be "satisfied" by using the early H.245 element for the replys so that FastStart could proceed. At least this mechanism would make it easy to know that the responder (the called endpoint) was able to overlap FastStart and H.245. -Bob ---------------------------------------------------- Bob Gilman rrg(a)lucent.com +1 303 538 3868 Paul Long wrote: > > Bob, > > H.323 only says that fastStart and h245Control cannot both be included in > _Setup_, so it could indeed be included in the Setup-UUIE type. > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Tuesday, June 06, 2000 10:27 AM Hi All, As far as my understanding goes, the purpose of prohibiting both fastStart and H.245 tunnel in SETUP was to avoid race conditions in two tunnels (fastStart can also be considered as a H.245 tunnel with different procedures). Here we are adding a new tunnel which will lead to more such race scenarios until proper care is taken in defining the procedures. The decision on this should not be like a voice vote in Congress. The procedures should be clearly documented and circulated over the reflector and let people argue on those concrete documented steps. Let us see, can we fix the problem introduced by introduction of fastStart? Regards, Jane Hua > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > Paul, > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and > CONNECT message in that all of these messages can be sent before Fast > Start > is completed or may not be present with Fast Start elements based on v2. > > Bob > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

5 6

Re: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Francois Audet 07 Jun '00

07 Jun '00

Dave, I am sure you know that Keypad doesn't allow you to send long tones. For voice GATEWAYS (like a PBX), it is necessary to perform a full TCS after call setup to know each other's capabilities. A simple example is FAX: for sure a big gateway can not set-up two channels (one for voice and one for fax) just in case, fax tone is detected on one of the ends. There are other H.245 commands that are necessary in H.245 for PBX functionality: e.g., Third Party pause and re-routing, to offer call features (AVR, hunting, etc.). All these issues were discussed at length in Osaka. It's déjà-vu all over again... > -----Original Message----- > From: Dave Walker [mailto:drwalker@SS8NETWORKS.COM] > Sent: Tuesday, June 06, 2000 1:45 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Paul, why are we even doing this? I'd just tell Bob to use the Keypad > Facility IE if he really needs DTMF signalling. You must realize how > ridiculous this'll look to advocates of other solutions: the ITU > screwed up H.245 tunneling, and now they're adding a new tunnel to fix > it - yech. > > Dave. > > > "Paul E. Jones" wrote: > > > > Bob, > > > > For messages other than SETUP, I was assuming we could use > the existing > > h245Control field for H.245 message exchange-- only the > SETUP message is a > > special case, since it was explicitly disallowed in H.323v2 > when fastStart > > was also present. > > > > Paul > > > > ----- Original Message ----- > > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > > To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> > > Cc: "'Mailing list for parties associated with ITU-T Study > Group 16'" > > <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Tuesday, June 06, 2000 11:27 AM > > Subject: RE: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > Paul, > > > > > > It would be required in the SETUP, CALL PROCeeding, > ALERT, FACILITY, and > > > CONNECT message in that all of these messages can be sent > before Fast > > Start > > > is completed or may not be present with Fast Start > elements based on v2. > > > > > > Bob > > > > > > -----Original Message----- > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > Sent: Saturday, June 03, 2000 6:41 AM > > > To: ITU-SG16(a)mailbag.cps.intel.com > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > Paul, Francois, and others, > > > > > > If we were able to get consensus here, I believe we could > add a field to > > the > > > SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is > > intended > > > for SETUP only as a means of allowing H.245 to used with > fastConnect in a > > > backward compatible manner. > > > > > > We have an entire proposal on verbiage to be added to > H.323. I'll have to > > > review that to see what needs changing-- but there's > actually a lot of > > > description. > > > > > > Can we agree to introduce a new "earlyH245" field to go along with > > > "fastStart" in the SETUP? > > > > > > Paul > > > > > > ----- Original Message ----- > > > From: "Paul Long" <Plong(a)SMITHMICRO.COM> > > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > > Sent: Friday, June 02, 2000 10:11 PM > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > > Paul, > > > > > > > > While not ideal (nothing is), that's a safe, workable > solution. I like > > it. > > > > Are you proposing adding the new component to the > H323-UU-PDU or the > > > > Setup-UUIE type? Both locations have their merits. This > then should be > > the > > > > new text for section 8.2.1/H.323: "The calling endpoint > shall not > > include > > > > both a fastStart element and encapsulated H.245 > messages in h245Control > > in > > > > the same Setup message. However, the calling endpoint > may include both a > > > > fastStart element and encapsulated H.245 messages in > earlyH245Control in > > > the > > > > same Setup message." And then explain what the called > endpoint is > > supposed > > > > to do when fastStart and earlyH245Control are present. > While we're at > > it, > > > > maybe we should define a separate type, i.e., > > > > > > > > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > > > > -- each > octet string may > > > contain exactly > > > > -- one H.245 PDU > > > > > > > > But now how do the two components, h245Control and > earlyH245Control > > > > otherwise relate to each other, i.e., when fastStart is > not included? > > > Should > > > > we say that if one is present the other shall not be > present? That would > > > be > > > > the clearest, IMO. Not much is gained by allowing both. > > > > > > > > > > > > Remember, the first rule of standards revision is > (everybody repeat > > after > > > > me)... > > > > "Primum non nocere" ("First do no harm.") > > > > - the Roman physician, Galen > > > > > > > > Paul Long > > > > Smith Micro Software, Inc. > > > > > > > > -----Original Message----- > > > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > > > Sent: Friday, June 02, 2000 8:14 PM > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > > > > > > > Francois, > > > > > > > > I agree that the behavior is desirable, but I still > argue that it will > > > > break backward compatibility. If we can agree with a new field > > > > "earlyH245" as a special field for SETUP to do > essentially the same > > > > thing, but only for V4, I would be quite happy-- we get > the same end > > > > result without V3 and V2 compatibility issues. > > > > > > > > I do not want to wait until Portland. The Whitepaper > drafts are due > > > > before then and I hope that that meeting will be focused on only > > > > critical issues in H.323 and that most of our time will > be spent on > > > > further development of Annexes and perhaps forward > thinking on V5 :-) > > > > > > > > Paul > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > > listserv(a)mailbag.intel.com > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

AW: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Klaghofer Karl ICN SIB NL D1 07 Jun '00

07 Jun '00

Osaka contributions like APC-1866 suggested to enhance the Fast Start structures by adding elements like userInputCapability to the fast start structure (to allow e.g. negotiation of the user input caps as early as possible together with fast start for subsequent UserInputCapability messages to be sent). This was rejected since the participants felt that start adding pieces of H.245 to Fast Connect might turn out as a never ending story. Instead, the consensus in Osaka was to allow the complete H.245 tunnel itself together with the fast start in SETUP. The backwards compatibility issue is of course important to consider. I agree with the principles what Paul said. I propose to continue the agreed approach from Osaka and further develop it using a new tunnel field in H323-UU-PDU construct (however, I believe it is saver that this new tunnel field should be used not only in SETUP but also in the other H.225.0 messages). Remark: I do not like the term "earlyH245Control" since "early H.245" in H.323 means something total different, as mentioned alrealy by a previous e-mail. Since this is in fact a new tunnel procedure available with v4, it could be named something like "245V4Control. But this are only names.... Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [SMTP:paulej@PACKETIZER.COM] > Gesendet am: Wednesday, June 07, 2000 09:59 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > Jane, > > I suspect that TD-26 has the procedural issues addressed-- it will just be > a > matter of specifying the usage of a different field. > > I'll have to review what is written there, but the most obvious way to > prevent race conditions is to specify that channels may not be opened via > H.245 until Fast Connect is accepted, explicitly refused, or implicitly > refused by not receiving a fastStart element up to and including CONNECT. > > Paul > > ----- Original Message ----- > From: "Jane Hua" <huajane(a)YAHOO.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, June 07, 2000 2:18 AM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > Pre Script: Sorry for the previous mail > > > > Hi All, > > > > As far as my understanding goes, the purpose of prohibiting both > > fastStart and H.245 tunnel in SETUP was to avoid race conditions in two > > tunnels (fastStart can also be considered as a H.245 tunnel with > > different procedures). Here we are adding a new tunnel which will lead > > to more such race scenarios until proper care is taken in defining the > > procedures. > > > > The decision on this should not be like a voice vote in Congress. The > > procedures should be clearly documented and circulated over the > > reflector and let people argue on those concrete documented steps. > > > > Let us see, can we fix the problem introduced by introduction of > > fastStart? > > > > Regards, > > Jane Hua > > > > > > Paul- > > The problem is that inclusion of an H.245 message in the tunnel > > terminates > > FastStart according to section 8.2.1 of H.323. This could be > > "satisfied" > > by using the early H.245 element for the replys so that FastStart could > > proceed. > > At least this mechanism would make it easy to know that the responder > > (the > > called endpoint) was able to overlap FastStart and H.245. > > -Bob > > ---------------------------------------------------- > > Bob Gilman rrg(a)lucent.com +1 303 538 3868 > > > > > > Paul Long wrote: > > > > > > Bob, > > > > > > H.323 only says that fastStart and h245Control cannot both be included > in > > > _Setup_, so it could indeed be included in the Setup-UUIE type. > > > > > > Paul Long > > > Smith Micro Software, Inc. > > > > > > -----Original Message----- > > > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > > > Sent: Tuesday, June 06, 2000 10:27 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > > > > Paul, > > > > > > It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, > and > > > CONNECT message in that all of these messages can be sent before Fast > > > Start > > > is completed or may not be present with Fast Start elements based on > v2. > > > > > > Bob > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > For help on this mail list, send "HELP ITU-SG16" in a message to > > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1871 Report of the Osaka meeting
by Sakae OKUBO 07 Jun '00

07 Jun '00

Dear Q12-14/16 experts, I have belatedly edited several materials including TD49 (General report), TD-22 (Q13 report) and TD-21 (Q14 report) into a single report as in the ftp site. ftp://standard.pictel.com/avc-site/Incoming/APC-1871.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1871.zip Some obviously editorial corrections have been made to TD texts without indication. Texts with yellow marker were not in original TDs, but generated by myself. Please review it and return your comments, if any, in a week time. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: On TD26 - Fast TCS and M/S negotiation in H.323v4
by Callaghan, Robert 07 Jun '00

07 Jun '00

Paul, It would be required in the SETUP, CALL PROCeeding, ALERT, FACILITY, and CONNECT message in that all of these messages can be sent before Fast Start is completed or may not be present with Fast Start elements based on v2. Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, June 03, 2000 6:41 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 Paul, Francois, and others, If we were able to get consensus here, I believe we could add a field to the SETUP-UUIE. I'd rather not put it in the H323-UU-PDU, since it is intended for SETUP only as a means of allowing H.245 to used with fastConnect in a backward compatible manner. We have an entire proposal on verbiage to be added to H.323. I'll have to review that to see what needs changing-- but there's actually a lot of description. Can we agree to introduce a new "earlyH245" field to go along with "fastStart" in the SETUP? Paul ----- Original Message ----- From: "Paul Long" <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, June 02, 2000 10:11 PM Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > Paul, > > While not ideal (nothing is), that's a safe, workable solution. I like it. > Are you proposing adding the new component to the H323-UU-PDU or the > Setup-UUIE type? Both locations have their merits. This then should be the > new text for section 8.2.1/H.323: "The calling endpoint shall not include > both a fastStart element and encapsulated H.245 messages in h245Control in > the same Setup message. However, the calling endpoint may include both a > fastStart element and encapsulated H.245 messages in earlyH245Control in the > same Setup message." And then explain what the called endpoint is supposed > to do when fastStart and earlyH245Control are present. While we're at it, > maybe we should define a separate type, i.e., > > H245Control ::= SEQUENCE OF OCTET STRING OPTIONAL > -- each octet string may contain exactly > -- one H.245 PDU > > But now how do the two components, h245Control and earlyH245Control > otherwise relate to each other, i.e., when fastStart is not included? Should > we say that if one is present the other shall not be present? That would be > the clearest, IMO. Not much is gained by allowing both. > > > Remember, the first rule of standards revision is (everybody repeat after > me)... > "Primum non nocere" ("First do no harm.") > - the Roman physician, Galen > > Paul Long > Smith Micro Software, Inc. > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Friday, June 02, 2000 8:14 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: On TD26 - Fast TCS and M/S negotiation in H.323v4 > > > Francois, > > I agree that the behavior is desirable, but I still argue that it will > break backward compatibility. If we can agree with a new field > "earlyH245" as a special field for SETUP to do essentially the same > thing, but only for V4, I would be quite happy-- we get the same end > result without V3 and V2 compatibility issues. > > I do not want to wait until Portland. The Whitepaper drafts are due > before then and I hope that that meeting will be focused on only > critical issues in H.323 and that most of our time will be spent on > further development of Annexes and perhaps forward thinking on V5 :-) > > Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

6 9

Question on H.225- Annex G
by Archana Nehru 07 Jun '00

07 Jun '00

hi all, I have a question about prefixing TPKT header to Annex-G messages sent over UDP. Refer to section 1.8 of the Annex G specs which states: " In UDP IP implementations, messages shall also be prefixed with TPKT headers, to enable multiple messages per packet. The UDP packet length field shall hold the total length of the payload, including all the messages and their TPKT headers." My interpretation of the above paragraph is the following: 1. ALL Annex-G messages (going over UDP) MUST be prefixed with TPKT headers. 2. One UDP packet can contain multiple Annex-G messages and each one of these messages will have its OWN SEPARATE TPKT HEADER. Is this interpretation correct? I appreciate any help on this. Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

[H.323 Mobility:] Annex H and I and H.246 Annex E
by Korpi Markku ICN SIB NL D1 07 Jun '00

07 Jun '00

Dear Mobility Subgroup members & interested parties, in order to get the H.323 Mobility ready for determination in November, we need to use the available time for steady progress of the work. Since everything is driven by contributions (not alone by the editor and the chair), I would encourage the mobility subgroup participants to produce contributions, so that we can discuss them over the reflector. As soon as we have enough stuff on the agenda we can organize a telephone conference, too, if there are issues, to be discussed. But I agree with Jaakko's and other peoples' earlier suggestions, that the main work should be done over the reflector. It also helps to increase transparency of our review process. As agreed in Osaka, please write your contributions against the current drafts of Annex H, I and H.246 Annex E. This way you can help us to fill in the gaps we still have in the current drafts. In order to get an MD number for your contribution, please send an email to jaakko.sundquist(a)nokia.com with subject and author of the document. Enjoy working on H.323 Mobility! Markku Korpi, Chair of H.323 Mobility Ad Hoc group -----Original Message----- From: Roy, Radhika R, ALARC [mailto:rrroy@ATT.COM] Sent: Tuesday, June 06, 2000 5:33 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Mobility: Annex H and I and H.246 Annex E Dear Mr. Korpi: I guess that it is the time to hear publicly from you how you want to organize the conference calls and contributions related to above annexes. It is excellent that Mr. Sundquist has produced a draft for H.323 Annex H that has been set as a baseline for discussions and bringing contributions. However, we like to know more about your plan the way you want to proceed: Conference calls, Contributions, Coordination among Annexes, etc. Best regards, Radhika R. Roy H.323 Mobility Ad Hoc group +1 732 420 1580 > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Tuesday, June 06, 2000 7:01 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] New H.323 Annex H Draft > > Hi folks, > > I have uploaded a new draft of the H.323 Annex H to the following URL: > ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-101_H323AnnexH > Dr > aft.zip . > > This draft contains material from the TD-28 of the Osaka meeting in > addition > to the TD-47, which contained the H.323 Annex H Draft produced in the > Osaka > meeting. I suggest that we use this document as the baseline for the work > from now on. > > I will not be very active on this reflector this week, because of other > urgent chores at work, but I will try to produce some new ideas next week > and also encourage you to make contributions as soon as possible. > > ------------------------------------------------ > Jaakko Sundquist * > +358 50 3598281 * Audere est Facere! > jaakko.sundquist(a)nokia.com * > ------------------------------------------------ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0