Fw: Update of H.323 implementors guide

[Sakae OKUBO]

On Thu, 5 Oct 2000, Paul Long wrote:

> Paul,
>
> I just checked, and we are shipping v3 EPs. I agree that there are probably
> many more v2 entities than v3 entities, and therefore if we have to break
> one, we should break the one which will have the least impact on the market.
>
> To minimize the impact this will have on interoperability, however, let's
> don't simply move the reasons around. Instead, lets deprecate the current
> routeCallToSCN and aliasesInconsistent reasons using the following syntaxes
> in IGv3 and H.225.0v4.
>
> Proposed IGv3 syntax
>
> AdmissionRejectReason ::= CHOICE
> {
>       calledPartyNotRegistered        NULL,   -- cannot translate address
>       invalidPermission                       NULL,   -- permission has expired
>       requestDenied                   NULL,   -- no bandwidth available
>       undefinedReason                 NULL,
>       callerNotRegistered             NULL,
>       routeCallToGatekeeper           NULL,
>       invalidEndpointIdentifier       NULL,
>       resourceUnavailable             NULL,
>       ...,
>       securityDenial                  NULL,
>       qosControlNotSupported          NULL,
>       incompleteAddress                       NULL,
>
> -- changes start here:
>       deprecatedAliasesInconsistent   NULL,                                   -- do not use
>       deprecatedRouteCallToSCN        SEQUENCE OF PartyNumber,        -- do not use
>       callCapacityExceeded            NULL,   -- destination has exceeded call capacity
>       aliasesInconsistent             NULL,   -- multiple aliases in request identify distinct
> people
>       routeCallToSCN                  SEQUENCE OF PartyNumber
> }
>
>
> Proposed H.225.0v4 syntax
>
> AdmissionRejectReason ::= CHOICE
> {
>       calledPartyNotRegistered        NULL,   -- cannot translate address
>       invalidPermission                       NULL,   -- permission has expired
>       requestDenied                   NULL,   -- no bandwidth available
>       undefinedReason                 NULL,
>       callerNotRegistered             NULL,
>       routeCallToGatekeeper           NULL,
>       invalidEndpointIdentifier       NULL,
>       resourceUnavailable             NULL,
>       ...,
>       securityDenial                  NULL,
>       qosControlNotSupported          NULL,
>       incompleteAddress                       NULL,
>
> -- changes start here:
>       deprecatedAliasesInconsistent   NULL,                   -- do not use
>       deprecatedRouteCallToSCN        SEQUENCE OF PartyNumber, -- do not use
>       exceedsCallCapacity             NULL,   -- destination does not have the capacity for
> this call
>       aliasesInconsistent             NULL,   -- multiple aliases in request identify distinct
> people
>       routeCallToSCN                  SEQUENCE OF PartyNumber,
>       collectDestination              NULL,
>       collectPIN                              NULL
> }

Unless I am misunderstanding what you are saying, the "-- do not use" will
not work if the receiver is using an earlier version in which the "-- do
not use" type is defined, for it violates X.680 clause 24.14:

   24.14 A value for a given extension addition type shall not be
   specified unless there are values specified for all extension addition
   types not marked OPTIONAL or DEFAULT that lie logically between the
   extension addition type and the extension root.

   NOTE 1 -Where the type has grown from the extension root (version 1)
   through version 2 to version 3 by the addition of extension additions,
   the presence in an encoding of any addition from version 3 requires the
   presence of an encoding of all additions in version 2 that are not
   marked OPTIONAL or DEFAULT.

Omitting OPTIONAL and DEFAULT from an extension addition definition means
that an extension addition value is mandatory in messages that are
originated by an implementation in which such extension additions are
defined, which implies that an encoding cannot have a missing mandatory
extension addition value followed by any other component.

The only way that interoperability can be achieved here is by the older
version H.225 spec being changed to add OPTIONAL to those items marked
with "-- do not use".  It will have no effect on the bits on the wire,
other than to make such encodings valid.

-------------------------------------------------------------------------
Bancroft Scott                               Toll Free    :1-888-OSS-ASN1
OSS Nokalva                                  International:1-732-302-0750
baos at oss.com                                 Tech Support :1-732-302-9669 x-1
1-732-302-9669 x-200                         Fax          :1-732-302-0023

> I assume we can change both because neither are Decided and these are true
> irreconcilable errors in the documents, correct? Here are the specifics: We
> rename the old reasons to "deprecate*", add the new ones after
> callCapacityExceeded/exceedsCallCapacity, and then in the text of IGv3 and
> H.225.0v4 say that the old ones shall not be transmitted and if received
> shall be treated like undefinedReason. Otherwise, a receiver would have to
> parse the AdmissionReject message differently depending on the version of
> the transmitter. We, Smith Micro, can actually do that with our ASN.1 parser
> but I'm guessing that most implementations cannot. Maybe we should even
> change the type of deprecatedRouteCallToSCN to NULL so that the ASN.1 PER
> parser would simply skip over the contents via the encapsulating open type.
> I know that our parser would do this. Would others?
>
> v1 implementations won't have a problem, because they would ignore this
> reason, anyway, but we could encourage v2 implementations to treat
> aliasesInconsistent like undefinedReason since they won't know if it is
> aliasesInconsistent from a v2 EP or some other extended choice from a v3+
> EP.
>
> Paul Long
> Smith Micro Software, Inc.
> ---------------------------------------------------------------------------
> ------------------------------
> Please send E-mail to contact at imtc.org <mailto:contact at imtc.org>  to
> subscribe or unsubscribe from this list
> ------------------------------
> ---------------------------------------------------------------------------
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com