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@DataBeam.com Phone: +1-910-854-3551 Fax: +1-910-854-1983