uuencoded file

[Robert Webber]

Karl,

Your 2nd option looks good to me too...

Regards,

Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell at bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================


>----------
>From:  Karl Klaghofer[SMTP:karl.klaghofer at MCH.PN.SIEMENS.DE]
>Sent:  03 December 1997 09:40
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Re: Limitation of nonStandardData and other issues related to
>H.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
>==================================================
>