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@mailbag.intel.com