Issues related to H.225.0 and H.450

[Orit Levin]

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 at 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 at MCH.PN.SIEMENS.DE]
Sent:  Wednesday, December 03, 1997 4:41 AM
To:  ITU-SG16 at 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 at mch.pn.siemens.de
==================================================