Re: Remarks on H.450.x and H.225.0

1 Dec 1997

      Dear All,
Please see comments below:
Pete
=================================
Pete Cordell
BT Labs
E-Mail: pete.cordell@bt-sys.bt.co.uk
Tel: +44 1473 646436
Fax: +44 1473 645499
=================================
...

From:  Orit Levin[SMTP:orit@RADVISION.COM]
Sent:  01 December 1997 15:59
To:    ITU-SG16@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:

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.

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

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?
...

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@radvision.com
575 Corporate Dr., Suite 420            Tel:    201-529-4300 ext. 230
Mahwah, NJ 07430                        Fax:    201-529-3516