protocolIdentifier omnipresence

Paul Long plong at SMITHMICRO.COM
Tue Mar 17 18:46:07 EST 1998


Orit, your proposal seems fine to me on first reading. The way to get this
into the implementor's guide would be to submit the text you have below as a
written contribution to a rapporteur's meeting so that it can be approved,
and then the editor of the implementor's guide will include the text.

        -- Toby

> -----Original Message-----
> From: Orit Levin [SMTP:orit at RADVISION.COM]
> Sent: Thursday, March 12, 1998 7:33 AM
> To:   ITU-SG16 at MAILBAG.INTEL.COM
> Subject:      Fast Connect and mediaChannel
>
> > 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 at radvision.com
> 575 Corporate Dr., Suite 420            Tel:    201-529-4300 ext. 230
> Mahwah, NJ 07430                        Fax:    201-529-3516




More information about the sg16-avd mailing list