Toby, Jim, Pete and all others!
During the implementation of Fast Connect Procedure, we found two pitfalls regarding the use of Transport Addresses as it are currently defined. For compatibility sake I provide following > clarifications for your revision:
1. In chapter 8.1.7.1 Proposal, Selection, and Opening of Media Channels is written: "The mediaChannel element shall be set appropriately according to the calling endpoint requirements; different values may be used in alternative proposals if desired."
As a part of the "Fast Connect Procedure", it is the responsibility of the called endpoint to decide about the coupling of proposed incoming and outgoing media streams for each SessionId. According to RTP/RTCP specifications, such a couple uses a common RTCP channel. Besides there are implementations, that rely on dependency between RTP and RTCP ports values. As a result of all that, "different values" for proposed (by the calling endpoint) mediaChannels can NOT be used within the same SessionId. It means that in the SETUP message all alternative OpenLogicalChannel structures, that propose a channel for transmission from the called endpoint to the calling endpoint, shall contain not only the same sessionID value but also the same mediaChannel value.
2. The "Fast Connect Procedure" doesn't explicitly define how the RTCP port values are provided. In order to support the general case (including one direction media transmission) and in accordance with (1) above, the following procedures shall be performed in addition to the described in H.323.
In the SETUP message, each OpenLogicalChannel which proposes a channel for transmission from the calling endpoint to the called endpoint, shall contain mediaControlChannel element (indicating the reverse RTCP channel) into the H2250LogicalChannelParameters element of the forwardLogicalChannelParameters structure. In the SETUP message, each OpenLogicalChannel which proposes a channel for transmission from the called endpoint to the calling endpoint, shall contain mediaControlChannel element (indicating the RTCP channel going in the same direction) into the H2250LogicalChannelParameters element of the reverseLogicalChannelParameters structure. All mediaControlChannel elements inserted by the calling endpoint for the same sessionID for both directions shall have the same value.
When accepting a proposed channel for transmission from the calling endpoint to the called endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a valid mediaControlChannel element (indicating the RTCP channel going in the same direction) into the H2250LogicalChannelParameters element of the forwardLogicalChannelParameters structure. When accepting a proposed channel for transmission from the called endpoint to the calling endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a valid mediaControlChannel element (indicating the reverse RTCP channel) into the H2250LogicalChannelParameters element of the reverseLogicalChannelParameters structure. All mediaControlChannel elements inserted by the called endpoint for the same sessionID for both directions shall have the same value.
I propose that we put such sort of clarifications into H.323 Implementers Guide. What is your opinion and what is the procedural way to do that?
Best Regards,
Orit Levin RADVision Inc. E Mail: orit@radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516