Limitation of nonStandardData and other issues related to H.450

Karl Klaghofer karl.klaghofer at MCH.PN.SIEMENS.DE
Wed Dec 3 04:40:34 EST 1997


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
==================================================



More information about the sg16-avd mailing list