Limitation of nonStandardData

Pete Cordell pete.cordell at BT-SYS.BT.CO.UK
Mon Dec 1 14:02:32 EST 1997


Dear All,

Please see comments below:

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


>----------
>From:  Orit Levin[SMTP:orit at RADVISION.COM]
>Sent:  01 December 1997 15:59
>To:    ITU-SG16 at MAILBAG.INTEL.COM
>Subject:       Remarks on H.450.x and H.225.0
>
>Hello, Editors!
>
>We are working know on the Supplementary Services stuff and came across
>some pitfalls in the last (Geneva) versions of the above protocols. It
>would be helpful to fix them before Geneva. I am listing them below:
>
>1. H.450.2 Clause 10.5
><<FACILITY message containing a callTransferInitiate invoke APDU and
>conferenceGoal = "invite">> is mentioned here. There is no
>conferenceGoal in FACILITY message. Possibly this mistake derives from
>the SETUP message, mentioned later in the same clause, which indeed has
>conferenceGoal field.
>
>2. H.225.0 Annex H - ASN.1
>InfoRequestResponse ::= SEQUENCE --(IRR)
>{
>        nonStandardData NonStandardParameter OPTIONAL,
>        .
>        .
>        perCallInfo             SEQUENCE OF SEQUENCE
>        {
>                .
>                .
>                originator              BOOLEAN,
>                .
>                .
>        } OPTIONAL,
>        ...,
>        .
>        .
>}
>
>The field "originator" is no longer OPTIONAL (the way it was defined in
>V.1), which makes the situation NOT backward compatible. Was there any
>reason for that change, or it just a mistake? In any case, because of
>the ASN.1 encoding rules, this situation highly undesirable.
This looks correct.  I'm partly responsible for this as I asked Glen to
take out OPTIONAL from a number of BOOLEANS.  However, we can only do
this for BOOLEANS that we have added for V2.  I've looked through and
this is the only instance where I can see this has been done.
>
>3. H.225.0 Annex H - ASN.1
>All ,but UI-UUIE, XXX-UUIE messages have callIdentifier field. We
>propose to add this field for UI-UUIE message as well ("for future
>sake"):
>UI-UUIE ::=SEQUENCE
>{
>        protocolIdentifier      ProtocolIdentifier,
>        ...
>        callIdentifier          CallIdentifier
>
>}
Since CallIdentifier is becoming such an important parameter then we
really need to put it in a place where we can get it in a message
independent way, i.e. H323-UserInformation, or H323-UU-PDU.  This will
also mean that it is in all messages and we don't have to reference it
in any new messages we create (i.e. as above).  e.g.:

H323-UserInformation ::= SEQUENCE               -- root for all Q.931 related ASN.1
{
        h323-uu-pdu     H323-UU-PDU,
        user-data       SEQUENCE
        {
                protocol-discriminator          INTEGER (0..255),
                user-information                OCTET STRING (SIZE(1..131)),
                ...
        } OPTIONAL,
        ...,
        callIdentifier  CallIdentifier
}


P.S. Can I confirm that even when CallIdentifier is present, the CRV
will still have the use and mean that it does in V1?
>
>4. H.450.2 Clause 10.6.1.1
>This clause is talking about Call Transferring in case of GK Call
>Routed model and both Q.931 Signaling and H.245 protocol are "routed"
>by the GK. According to H.323V.2 GK's Call Routed model where Q.931
>Signaling is routed by the GK, but H.245 messages flow directly is
>legal and more efficient. It seems that the clause above doesn't cover
>this case. In order to provide a working solution for this case, an
>additional OPTIOANAL field "h245Address" should be added to
>Facility-UUIE message as follows:
>
>H.225.0: Add "h245Address" field to the Facility message:
>
>Facility-UUIE ::= SEQUENCE
>{
>        protocolIdentifier              ProtocolIdentifier,
>        alternativeAddress              TransportAddress OPTIONAL,
>        alternativeAliasAddress SEQUENCE OF AliasAddress OPTIONAL,
>        conferenceID                    ConferenceIdentifier OPTIONAL,
>        reason                          FacilityReason,
>        ...,
>        callIdentifier                  CallIdentifier,
>        destExtraCallInfo               SEQUENCE OF AliasAddress
>OPTIONAL,
>        remoteExtensionAddress          AliasAddress OPTIONAL,
>        tokens                          SEQUENCE OF ClearToken
>OPTIONAL,
>        cryptoTokens                    SEQUENCE OF CryptoH323Token
>OPTIONAL,
>        conferences                     SEQUENCE OF ConferenceList
>OPTIONAL,
>        h245Address                     TransportAddress OPTIONAL
>
>}
Three things on this:  Firstly the call model you described is marked as
for further study in  7.3.2/H.323.  This was presumably done for a good
reason and we shouldn't change it without understanding why we did it.
(I think Mark was the one who said why the model wouldn't work, but I'm
not sure.)  Secondly, the facility message described in H.450.2 section
is not the same as the Facility-UUIE that you mention above.  Thirdly,
the H.245 address would not be needed in the Facility-UUIE because it is
determined using the usual means of getting it, e.g. in SETUP, ALERTING,
CONNECT etc.
>
>Thanks,
>
>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
>



More information about the sg16-avd mailing list