TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
Rich Bowen
rkbowen at CISCO.COM
Tue Jun 20 03:43:26 EDT 2000
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 at tech-know-ware.com
> +44 1473 635863
> =============================================
>
> ----- Original Message -----
> From: Klaghofer Karl ICN SIB NL D1 <Karl.Klaghofer at ICN.SIEMENS.DE>
> To: <ITU-SG16 at 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 at CISCO.COM]
> > Gesendet am: Monday, June 19, 2000 00:22
> > An: ITU-SG16 at 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 at mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at 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 at mailbag.intel.com
More information about the sg16-avd
mailing list