SG16 meeting on 15 June

[Sakae OKUBO]

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