Phase transition in H.310 and H.324

Sakae Okubo okubo at GCTECH.CO.JP
Fri Jan 9 11:58:41 EST 1998


Hi everyone,

Alas, someone has found a problem with the proposal that was posted on
Tuesday.  The problem is as follows:

When communicating through a "pass-through" Gateway to an H.320 endpoint, it
is possible for the H.320 endpoint to issue an unsolicited Query at any
time.  Normally this won't happen after a T.120 connection has been
established.  But it can happen during the establishment of the T.120
connection.

So, if the H.323 endpoint initiates an OLC, and is told by the Gateway to
issue a Query, it is possible that the H.320 endpoint will also issue a
Query before the T.120 connection is actually established.  In this case,
the Gateway MUST know the address of the H.323 endpoint (in order to forward
the Query), even though it has already told that endpoint to place the call.

This illustrates a case where one endpoint needs the address of the other
for unpredictable reasons.  The easiest way to ensure that endpoints will
always have the addresses they need is to mandate that BOTH endpoints shall
ALWAYS include their transport address in the OLC exchange (in both the OLC
and the OLC Ack), and that those transport addresses will remain valid for
the duration of the logical channel.

The point of these proposals is to increase the flexibility of the OLC
procedures to handle even the most complex cases.  But there has been some
concern that there is not enough guidance on how to handle the simple cases.
To this end, a new sentence has been added stating that if neither one of
the endpoints has a preference on setting up the T.120 call, then the call
will follow the direction of the H.323 call. Endpoints that need to do
something different can override this default behavior on an as-needed
basis.

The suggested changes to Tuesday's proposal are as follows:



CHANGE #1:
The following sentences:

    If the initiator is the slave, it shall include a transport address
    in the openLogicalChannel message.  If the initiator is the master,
    it may decide whether or not to include a transport address in the
    openLogicalChannel message. In either case the peer endpoint
    may choose to ignore the transport address.

will change to:

    The initiator shall include a transport address in the
    openLogicalChannel message. The peer endpoint may choose
    to ignore the transport address.


CHANGE #2:
The following sentences:

    In the openLogicalChannelAck, the responder shall include a transport
    address to be used for set-up of the T.120 connection if it expects the
    initiator to originate the T.120 call (this will always be the case if
    it did not receive a transport address from the initiator). Otherwise,
    the transport address shall be absent. In all cases, the transport
    address for the T.120 connection shall be carried in the separateStack
    parameter.

will change to:

    In the openLogicalChannelAck, the responder shall include a transport
    address, even if it expects the initiator to originate the T.120 call.
    In all cases, the transport address shall be carried in the
    separateStack parameter, and shall remain valid for the duration of
    the logical channel.



CHANGE #3:
In the next two paragraphs, the text explains how the t120SetupProcedure is
to be used.  For each choice, in each paragraph, there is a sentence
describing when to include a transport address.  All of these sentences will
be removed, since the transport address will always be included.


CHANGE #4:
In the paragraph on how the responder uses the t120SetupProcedure, the
following sentence will be added:

    If neither endpoint has a preference, the T.120 call should be
    established in the same direction as the H.323 call.


If these changes are OK with everyone, I will merge them into the document
posted on Tuesday before providing it to the editors of H.323 and H.245.

Thanks.

------------------------------------
Pat Galvin
pgalvin at DataBeam.com
Phone: +1-910-854-3551
Fax: +1-910-854-1983



More information about the sg16-avd mailing list