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

RE: H.245 Terminates Fast Connect
by Callaghan, Robert 13 Jun '00

13 Jun '00

Paul, If the agreement was clearly to remove the text, how can you not remove it? This is true even if you have difficulties agreeing with the decision. Yes there is a race condition, but only regarding the pending OLCs. A simple statement is that OLC activity cannot be done until the FastStart terminates or is explicity rejected. Other H.245 activity should be fine. 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: Tuesday, June 13, 2000 6:17 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.245 Terminates Fast Connect Folks, As you know, we added some text to the H.323 Implementers Guide (section 6.1.7) removing the text from 8.2.1/H.323 that used to state: ``The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures.'' There was also some further supporting text added to the IG, but removed before the final agreed document that read (this is somewhat out of date now that H.323v4 devices that use Fast Connect *shall* tunnel, but text is necessary for V2 and V3 entities): ``It is possible to switch to H.245 procedures before the Fast Connect procedure completes. If h245Tunneling is enabled, the terminating party may start using tunneling as described in 8.2.1. If H.245 transport address is included in the Setup message, then the terminating party may start the switch to H.245 as described in 8.2.3. In either case the Fast Connect procedure is terminated.'' Unfortunately, removing this text (particular the text that was already existing the H.323) has caused all kinds of grief, as there are implementations that do, in fact, behave according to this text found in H.323v2 and H.323v3. I know a few people have discussed reversing this decision, but no formal proposal has been submitted. We need to have a discussion on this topic. I want to propose that the H.323v4 white paper *not* have this text removed. If people agree with that, I will bring a contribution that will propose reinstating this text. Part of the reason for its removal is that there is a race condition that can occur. For example, if the caller sends a Setup with fastStart and then later initiates H.245 while at the same time, the called endpoint returns a message with fastStart, what state is H.245 in? I believe that we can resolve the issues by documenting the fact that a race condition exists and introducing a few new rules. For example, we could say that if, as in this example above, the calling endpoint initiates H.245 and then gets a fastStart element in a message, the caller shall recognize the fact that Fast Connect was accepted. Hopefully, no logical channel signaling will have taken place. If it has, the called party should reject any conflicting channels, so the calling endpoint can recognize that a rejected channel is the result of Fast Connect being accepted and the channel is actually open (as per the FC received). I would like to see if we can come to any kind of agreement on this issue and a recommendation for a direction forward. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Use of two Calling Party Number IEs
by Klaghofer Karl ICN SIB NL D1 13 Jun '00

13 Jun '00

The requirement of TD-9 from Mr. Blin in Osaka was the support of two calling party numbers in H.323 (and NOT two Calling Party Number Information Elements) ! There was no agreement to intruduce a second Calling Party Number IE in H.225.0 (of course it is allowed due to the general H.323 statement that a GWY may pass on any Q.931 Information elements towards the LAN). The agreement was that such a requirement of TD-9 from Osaka is already covered by H.323 anyway, since there are at least two fields already available (Calling Party Number IE and SourceAddress) to which e.g. two Calling Party Number IEs from the SCN could be mapped to or which may be used by an originating H.323 endpoint if there is the need to signal different calling party numbers. The agreement was that the editor would add add some clarifying text (e.g. a sentence basically telling that Calling Party Number IE and SourceAddress may be used in the same SETUP message to carry different calling party numbers, if required). Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Gesendet am: Sunday, June 11, 2000 16:24 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: 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

1 0

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

13 Jun '00

Rich, As you pointed out, the information can be passed in H.225.0 v1 when it is presented at an ISDN gateway. By extension this can be true for ISUP. Therefor, there is no need for any changes. As I understand it, FT need was to have a secure Calling Party address presented to a gateway when routing from H.323 to SCN. If this is true, the case of information provided by an incoming ISDN gateway is trivial. It appears to be more important that the H.323 network providers also be able to add a secure address. On the other hand, there are better security methods available in the H.323 world (tokens) such that a secure address may not be needed for gateway security. Seperate, some IVR functions need a secure address in order to work even when a User blows a configuration. 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: Tuesday, June 13, 2000 12:53 AM 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, I think I understand your concern now, and I agree that there apparently has not been much consideration given to how these features would extend to H.323 terminals. My understanding of the result of the Osaka discussion is that H.225.0 should basically state, "There can be 2 Calling Party Number IEs", which is already stated in H.246 and is allowed by the statement about Q.931 transport. Do you think FT was asking for more than this? It sounds like you would prefer to see this change incorporated only as part of a broader solution that includes terminals. Would this broader solution change the fact that 2 Calling Party Number IEs could be present? I'm wondering if the terminal issue could be addressed separately. - Rich "Callaghan, Robert" wrote: > > 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

1 0

Final Corrections to H.225.0v3
by Paul E. Jones 13 Jun '00

13 Jun '00

Folks, As many of you know, there were a number of errors found in the H.225.0v3 ASN.1. Attached to this e-mail, please find a Microsoft Word file that contains revision marks for the ASN.1 portion of the Decided H.225.0v3 document. I have prepared an ASN.1 file that *should* contain the complete and up-to-date H.225.0v3 ASN.1. You can find it here: http://www.packetizer.com/iptel/h323/ *Please* if you find any errors in these ASN.1 files, let me know *now*. There are a number of Implementers who are planning to bring their V3 products to the SuperOp next month. More importantly, H.323v3 has been in a decided state for quite some time now and folks need to be aware of these errors, because products are shipping! These errors represent every known error that needs to be applied to the H.225.0v3 ASN.1. If any errors are found in the future, we will likely not fix them unless backward compatibility is completely broken. As you all know, making changes to the ASN.1 once a product is in the customer's hands is not the best way to go about pleasing a customer :-) Best Regards, Paul E. Jones Editor, H.323 and the H.323-series Implementers Guide

1 0

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