Paul,
RADVision's current implementation matches H.323 v3 syntax (with "incorrect field"), also we never had the version which would match AdmissionRejectReason from H.323v2 Implementors Guide. Thus if we would move this field now, it would rather create interoperability problems so we would like to keep it the way it is currently in the H.323 v3.
Best regards, Anatoli
"Paul E. Jones" wrote:
XuPeili and other H.323 Developers,
This does appear to be in error. Unfortunately, this was published this way in the H.225.0v3 Recommendation. However, you are correct that a previous H.323v2 Implementers Guide was published which contained the aliasesInconsistent field.
So, we have an issue to contend with. I must ask the developer community-- I do not want to make this change without wide support for making such a change.
Since the Version 2 field was added via the Implementers Guide, it is entirely possible that H.323v2 vendors did not even include it in their ASN.1
So, I need to hear from all of the developers on this issue. This may have been addressed, but I don't have notes on this matter. A similar issue with the LocationRejectReason was found and I corrected that back in June when discussing with everybody that "I would never change the ASN.1 and more". Well, unfortunately, it appears that we have one last error-- honestly, I'm quite shocked this one slipped through.
So... should the "aliasesInconsistent" field be moved above the "routeCallToSCN" element in the AdmissionRejectReason sequence as shown in an earlier H.323v2 Implementers Guide?
Please post and debate this publicly. We need to resolve this matter quickly so as to minimize impact on everybody.
Best Regards, Paul
----- Original Message ----- From: "XuPeili" xupeili@huawei.com To: "Paul E. Jones" paulej@packetizer.com Cc: h323implementors@imtc.org Sent: Tuesday, October 03, 2000 9:42 PM Subject: ;X84: Multiple Call Proceedings in a H.323 call
hi Paul,
In the H225.0v3.asn downloaded form www.packetizer.com the ARJ is specified like this
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, routeCallToSCN SEQUENCE OF PartyNumber, aliasesInconsistent NULL -- multiple aliases in request identify
distinct
people }
Since the routeCallToSCN is a new choice in H.225.0v3, I think it should
be
placed after the aliasesInconsistent choice which is already exist in v2.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com