> 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(a)radvision.com
575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230
Mahwah, NJ 07430 Fax: 201-529-3516
