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