Rich,
A new tunneling specific H.225.0 ReleaseCompleteReason would be valuable to be received at an ingress GWY from the egress GWY.
However, regarding SCN mapping rules of such a new ReleaseCompleteReason to Cause IE, I do not like any of the proposed values:
* Cause 88 "incompatible destination" is not suitable. * Cause 111 "Interworking, unspecified" would sound good. However, in case of Annex M1, a QSIG PINX would interpret Cause 111 as "Protocol error, unspecified" (this is what Cause 111 is defined in QSIG). * Cause 63 is not really suitable since tunneling is not a service or option requested by the SCN (e.g. QSIG side).
Regards, Karl
-----Ursprüngliche Nachricht----- Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] Gesendet am: Monday, June 19, 2000 00:22 An: ITU-SG16@mailbag.cps.intel.com Betreff: TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
Mr. Holm and others,
In Osaka it was suggested during the discussion of TD-54a (Draft Annex M.2, ISUP tunneling) that a new ReleaseCompleteReason is needed to support tunnelling. The reason would indicate that the called endpoint is dropping the call because it rejects tunnelling and the tunnellingRequired flag was set in the Setup message.
My notes indicate that I was to look into whether this was needed in H.225.0 v4. The existing reasons are:
ReleaseCompleteReason ::= CHOICE { noBandwidth NULL, -- bandwidth taken away or ARQ denied gatekeeperResources NULL, -- exhausted unreachableDestination NULL, -- no transport path to the destination destinationRejection NULL, -- rejected at destination invalidRevision NULL, noPermission NULL, -- called party's gatekeeper rejects unreachableGatekeeper NULL, -- terminal cannot reach gatekeeper for ARQ gatewayResources NULL, badFormatAddress NULL, adaptiveBusy NULL, -- call is dropping due to LAN crowding inConf NULL, -- no address in AlternativeAddress undefinedReason NULL, ..., facilityCallDeflection NULL, -- call was deflected using a Facility message securityDenied NULL, -- incompatible security settings calledPartyNotRegistered NULL, -- used by gatekeeper when endpoint has -- preGrantedARQ to bypass ARQ/ACF callerNotRegistered NULL, -- used by gatekeeper when endpoint has -- preGrantedARQ to bypass ARQ/ACF newConnectionNeeded NULL, -- indicates that the Setup was not accepted on this -- connection, but that the Setup may be accepted on -- a new connection nonStandardReason NonStandardParameter, replaceWithConferenceInvite ConferenceIdentifier -- call dropped due to subsequent -- invitation to a conference -- (see H.323 8.4.3.8) }
So I'll ask ... is a new reason needed?
If so, Mr. Holm's draft contains an editor's note that suggests a reason code of "tunnelRejected". Should I incorporate that value as a ReleaseCompleteReason?
If so, what Q.931/Q.850 mapping should I add to Table 5/H.225.0 for this reason? Some suggestions:
63 - Service or option not available, unspecified 88 - Incompatible destination 111 - Interworking, unspecified
Thanks, Rich
Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com