- 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