Pairing of RTP channels

[Paul E. Jones]

Mr. Okubo,

I will provide you with my *opinion* and welcome comments to the contrary.

> 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?

If two endpoints are sending media for the same session (audio, video,
etc.), both use the same RTP port pair to exchange "sender reports".  If
only one endpoint is sending on the session and the other is listening, the
sender sends "sender reports" and the receiver sends "receiver reports".
The information contained in each is different, but the reason for sending
these messages is to convey some information about the packet loss, etc., on
the session.

> 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?

Session id 3 could be for T.120, but it could also be for fax.  The "master"
or MC in the call should complain if the session IDs do not properly align.
So, if one side tries to open T.120 on session 3 and the other side tries to
open fax, the master/MC should complain.  However, given that neither of
these use RTP/RTCP, it really doesn't matter.  Your video case is more
interesting.  However, it does not matter if the codecs are symmetrical or
not, so unless there is something "special" about the video stream, it's
perfectly OK if the two video streams (one from each side) are different in
nature.. video is video.

> 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.

Both sides should understand sessionIDs 1, 2, and 3 to be audio, video, and
data, respectively.  However, the master/MC should assign session IDs for
all other sessions.

> 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?

I would assume that the conversational speech would be proposed by both
sides as sessionID=1 and that the other audio session would be proposed with
sessionID=0 to be assigned by the master/MC.

> 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.

I believe you are correct.

> 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.

I suspect that nobody has encountered this issue in practice... or perhaps
they have, as you're raising the question.  In any case, I completely agree
with you that further clarification would be wonderful.

Paul

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