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@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@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@RADVISION.COM Organization: RADVISION Inc. Subject: Re: RTCP port in H.323 logical channels Comments: To: Medhavi Bhatia mbhatia@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@mailbag.intel.com
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
participants (2)
-
OKUBO Sakae -
Paul E. Jones