I was thinking that Table 5 was an exhaustive mapping of all
ReleaseCompleteReasons to Q.931 causes, but I see now that there are a
couple of exceptions.
So unless there are other suggestions, perhaps I can leave this mapping
as an exercise for the Annex M.3 (DSS1 tunnelling) editor :-)
- Rich
Pete Cordell wrote:
Shouldn't the releaseCompleteReason be mapped to a cause in defined for the
protocol that is being tunnelled rather than Q.931. i.e. for M.1 it should
map to an ISUP cause. If that's the case, changes to Table 5 are not
needed.
Pete.
=============================================
Pete Cordell
Tech-Know-Ware
pete@tech-know-ware.com
+44 1473 635863
=============================================
----- Original Message -----
From: Klaghofer Karl ICN SIB NL D1 <Karl.Klaghofer@ICN.SIEMENS.DE>
To: <ITU-SG16@mailbag.cps.intel.com>
Sent: 19 June 2000 10:48
Subject: AW: TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
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
--
--------------------------------------------------------------------
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
Rich Bowen