Pairing of RTP channels

OKUBO Sakae okubo at GITI.WASEDA.AC.JP
Wed Oct 10 04:00:14 EDT 2001


Dear SG16 experts,

In the context of AVD-2134 "UDP port number assignment in the H.323
system", I have a couple of questions on the RTP/RTCP and H.323/H.245
design philosophies behind the pairing of a forward direction RTP channel
and its CORRESPONDING reverse direction RTP channel.

RTP transmission is uni-directional, but its associated RTCP channels are
bi-directional. Even if media RTP packets flow one way, its RTCP packets
flow two ways conveying receiving report and sender info. Presumably to
reduce the number of ports and the number of UDP packets for RTCP, two RTP
channels in different directions are paired. If terminal A is sending a
media to terminal B and receiving the same type of media from terminal B,
RTCP SR packets contain both sender info regarding media transmission from
A to B and reception report regarding media transmission from B to A.

The first question is: Q1 - What two RTP transmissions are paired? From the
RTP/RTCP design point of view, any pair seems alright as far as they are
dealing with the same type of media like audio, video, data. Is this
understanding correct?

Related to this question, we saw the attached posting referring to "Section
6.2.8.2 Logical channel signalling" of H.323. The correspondence of two
media channels of different directions is given by sessionID in H.245.
Default sessionIDs 1, 2 and 3 are defined for audio, video and data.

The second question is: Q2 - What are these pre-assigned sessionIDs meant
for? sessionID=1 audio is almost certain that it is for bi-directional
conversational speeches (or "main audio"). How about sessionID=2 video? It
will probably be for bi-directional participants images for videophone and
videoconferencing (or "main video"). One way video may deliver participants
images, but the reverse direction video may deliver VTR presentation. Even
for this case, sessionID=2 can be used. So the notion of "main video" may
help us. Or the former video uses sessionID=2 and the latter video uses
sessionID=4, for example? How about data? sessionID=3 is for T.120 or
another data?

A related question is: Q3 - Can the slave side send a media with one of
those pre-assigned sessonIDs, audio with sessionID=1 for example? H.245
stipulates that the master side assigns sessionID values and that the slave
starts OpenLogicalCannel (OLC) with sessionID=0 and the master assigns a
sessionID value. The master should always start OLC in the H.323
communication? If the slave starts OLC with sessionID=1, the master
acknowledges the OLC or rejects it? In any case, both terminals should have
the same understanding on what is the media for sessionID=1, 2, 3.

Since H.323/H.245 is flexible in the number of media channels
simultaneously used, we may have a case of multiple audios or multiple
videos in a single H.323 communication. Let us take a case of terminal A
sending only a conversational speech while terminal B sending a
conversational speech plus a presentation sound. A natural thinking is that
two way speeches are paired with sessionID=1. However it may be OK that one
way speech and reverse direction presentation sound are paired with
sessionID=1 and the remaining reverse direction speech is widowed with
sessionID=5?

The above notion of main audio and auxiliary audios does not give a
solution? Each terminal define its main audio transmission as well as
multiple auxiliary audio transmissions if available. Two way main audios
are paired with sessionID=1, two way auxiliary audios are paired next
regardless of their contents in the order of OLCs with sessionID=x assigned
by the master, and so on. One way auxiliary audio may remain without its
corresponding auxiliary audio.

If we have common understanding or common practice on the above questions,
then it will be worth documenting it in some part of H.323.

Best regards,

OKUBO Sakae
*********************************************************
Global Information and Telecommunication Institute (GITI)
Waseda University
29-7 Waseda University Bldg.
1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo
169-0051 Japan
        e-mail: okubo at giti.waseda.ac.jp
        Tel: +81 3 3204 8194
        Fax: +81 3 5286 3832
*********************************************************

>Date:         Mon, 13 Aug 2001 15:06:54 -0400
>From: Medhavi Bhatia <mbhatia at NEXTONE.COM>
>Subject:      RTCP port in H.323 logical channels
>
>Hi,
>
>A question about mediaControl ports in Logical channels:
>
>Can an endpoint A open a logical channel to another endpoint B (in non
>fast start mode), specify control channel port X, and respond to B's OLC
>with a media control port Y, where X and Y are different ? Assuming the
>OLCs are for the same sessions.
>
>The H.323 spec specifies that X and Y must be the same for fast start
>scenarios. For a non fast start case, if they must be different, what is
>the behavior of the endpoint B in that case ?
>
>thanks - Medhavi.
>
>                     ----------
>
>Date:         Mon, 13 Aug 2001 18:27:20 -0400
>From: Anatoli Levine <alevine at RADVISION.COM>
>Organization: RADVISION Inc.
>Subject:      Re: RTCP port in H.323 logical channels
>Comments: To: Medhavi Bhatia <mbhatia at nextone.com>
>
>Medhavi,
>
>X and Y can't be different. According to H.323 standard:
>"6.2.8.2 Logical channel signalling
>...
>Logical channels shall be opened using the following procedure:
>...
>If a corresponding reverse channel is opened for a given existing RTP
>session (identified by the RTP sessionID), the mediaControlChannel
>Transport Addresses exchanged by the openLogicalChannel process shall be
>identical to those used for the forward channel. "
>
>Anatoli

                     ----------

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list