June 2000 - sg16-avd - lists.packetizer.com

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