Error in H.323v3 ASN.1

Paul Long Plong at SMITHMICRO.COM
Thu Oct 5 14:08:39 EDT 2000


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
}

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.

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



More information about the sg16-avd mailing list