Karl and Editors!
I agree with your point #2 (H.450.2 Clause 10.6.1.1). My only request is to expand the OPTIONAL possibilities of the FACILITY message NOW. H.450.x are new evolving, and therefore flexible, series. On the other hand, who knows when H.323v3 will be available!
Orit Levin RADVision Inc. E Mail: orit@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516
---------- From: Karl Klaghofer [SMTP:karl.klaghofer@MCH.PN.SIEMENS.DE] Sent: Wednesday, December 03, 1997 4:41 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Limitation of nonStandardData and other issues related toH.450
Some comments related to H.450.x have been placed to the reflector the last days. 1) H.450.2 Clause 10.5 (item 1 of Levin Orit´s comments, dated Dec.1) I agree, 2nd paragraph, third line: ...and conferenceGoal="invite"... should be deleted.
2) H.450.2 Clause 10.6.1.1 (item 4 of Levin Orit´s comments, dated Dec.1) The procedures defined for this gatekeeper active transfer case right now are very much based on the gatekeeper having H.225 as well as H.245 control (i.e. H.225 as well as H.245 routed via gk). The model you are referring to (H.225 via gk; H.245 direct routed) was not investigated in conjunction with active gk transfer, since this model is (as Pete sayd) still marked as "for further study" in H.323V2 ! Using the direct H.245 model in conjunction with active transfer by gatekeeper would introduce a further, alternative method of handling the logical channel closing and reopening issue at the transferred endpoint B. Remark: In Sunriver September meeting, the goal was to have just one method (we picked the "empty terminalCapabilitySet" method and dropped the "requestChannelClose with reopen" method in order to reach this goal. Proposal for further proceeding: First the H.245 direct model has to be investigated for H.323 (maybe H.323V3). Then, H.450.2 (maybe V2) might be updated to get this model also to work for active gk transfer.
3) Limitation of nonStandardData (Comment from Pete Cordell, dated Dec.2) Currently we have in H.450.x constructs like the following: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData NonStandardParameter } OPTIONAL
ExtensionSeq ::= SEQUENCE OF Extension{{ExtensionSet}}
ExtensionSet EXTENSION ::= {...} -- Actual values defined by individual manufacturers This means: either one value nonStandardParameter or a SEQ of an arbitrary number of values of type Extension may be inserted.
1st possible change: allow more than one nonStandardParameter: argumentExtension CHOICE {extensionSeq ExtensionSeq, nonStandardData SEQUENCE OF NonStandardParameter } OPTIONAL
which means either a SEQ of Extensions or a SEQ of NonStandardParameter may be inserted. This 1st possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245. 2nd possible change: argumentExtension SEQUENCE OF MixedExtension OPTIONAL MixedExtension ::= CHOICE {extension Extension{{ExtensionSet}}, nonStandardData NonStandardParameter }
This 2nd possibility would be a H.450 change corresponding to Pete´s proposal for H.225/H.245, which adds a further dimension of allowing mixing of any number of NonStandardParameter and ISO like Extensions within one pdu. This may have advantages e.g. in the case that an ISO like Extension is contained within a received pdu in a gk and the gk wants to add further extensions of the NonStandardParamter type (or vice versa) to the same pdu. Proposal for further proceeding. The 2nd possibility mentioned above should be added to a H.450V2.
================================================== Karl Klaghofer Siemens AG Munich, Hofmannstr. 51, D-81359 Munich, Germany Dptmnt: PN VS LP3, Building/Room: 1760/455 Tel.: +49 89 722 31488 Fax.: +49 89 722 23977 email: karl.klaghofer@mch.pn.siemens.de ==================================================