how many port pairs in a call/conference?
OK, I thought these were easy questions but maybe people wonder 'what does he mean by RTP Session?' Let me rephrase:
(A) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in a two-party call with two-way audio?
(B) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in an n-party conference with everybody sending and receiving audio and using distributed multi-unicast?
Marcel Graf IBM Zurich Research Lab
I'm trying to find an answer to the question (A) "how many RTP Sessions are there for a two-party call with two-way audio?", and to the related question (B) "how many RTP Sessions are there for an n-party conference with each participant being an audio Source and an audio Sink and using distributed multi-unicast?".
What I already know is that, assuming unidirectional Logical Channels, in the first case there are two Logical Channels, and in the second case there are n*(n - 1) Logical Channels.
H.245 says about the sessionID: "The sessionID is a unique RTP or T.120 Session Identifier in the conference. It is used by the transmitter to refer to the session to which the logical channel applies. Only the master can create the session identification. By convention, there are three primary sessions. The first primary session with a session identification of 1 is the audio session, the second primary session with a session identification of 2 is the video session, and the third primary session with a session identification of 3 is the data session."
Can I interpret this paragraph as saying that in case (A) there is only one RTP Session, and in case (B) there is only one RTP Session, too?
If that is correct, then the following paragraph from H.323 section 6.2.8.2 "Logical channel signalling" comes into play: "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. Should a collision occur where both ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel attempt may then be retried at a later time."
What type of conflict does this paragraph refer to? Given there is a single RTP Session, and (multi-)unicast is used, each endpoint chooses the RTP and RTCP port it is listening on independently of the others. (The paragraph can't be talking about multicast, because it is the MCs responsibility to allocate multicast addresses.)
I also made the following observation: The "primary session convention" established in the cited H.245 paragraph seems to be contradicted by the samples shown in H.323 Appendix I "Sample MC to Terminal Communication Mode Command" which uses the sessionIDs 2 and 3 differently. Maybe the convention is only meant for two-party calls?
Marcel Graf IBM Zurich Research Lab
Marcel,
In general, a particular endpoint would allocate one pair of endpoints whether it was in a p-p or multicast conference.
jimt.
At 10:58 AM 6/24/98 +0100, you wrote:
OK, I thought these were easy questions but maybe people wonder 'what does he mean by RTP Session?' Let me rephrase:
(A) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in a two-party call with two-way audio?
(B) How many (RTP port, RTCP port) pairs does an H.323 endpoint allocate in an n-party conference with everybody sending and receiving audio and using distributed multi-unicast?
Marcel Graf IBM Zurich Research Lab
I'm trying to find an answer to the question (A) "how many RTP Sessions are there for a two-party call with two-way audio?", and to the related question (B) "how many RTP Sessions are there for an n-party conference with each participant being an audio Source and an audio Sink and using distributed multi-unicast?".
What I already know is that, assuming unidirectional Logical Channels, in the first case there are two Logical Channels, and in the second case there are n*(n - 1) Logical Channels.
H.245 says about the sessionID: "The sessionID is a unique RTP or T.120 Session Identifier in the conference. It is used by the transmitter to refer to the session to which the logical channel applies. Only the master can create the session identification. By convention, there are three primary sessions. The first primary session with a session identification of 1 is the audio session, the second primary session with a session identification of 2 is the video session, and the third primary session with a session identification of 3 is the data session."
Can I interpret this paragraph as saying that in case (A) there is only one RTP Session, and in case (B) there is only one RTP Session, too?
If that is correct, then the following paragraph from H.323 section 6.2.8.2 "Logical channel signalling" comes into play: "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. Should a collision occur where both ends attempt to establish conflicting RTP sessions at the same time, the master endpoint shall reject the conflicting attempt as described in Recommendation H.245. The rejected OpenLogicalChannel attempt may then be retried at a later time."
What type of conflict does this paragraph refer to? Given there is a single RTP Session, and (multi-)unicast is used, each endpoint chooses the RTP and RTCP port it is listening on independently of the others. (The paragraph can't be talking about multicast, because it is the MCs responsibility to allocate multicast addresses.)
I also made the following observation: The "primary session convention" established in the cited H.245 paragraph seems to be contradicted by the samples shown in H.323 Appendix I "Sample MC to Terminal Communication Mode Command" which uses the sessionIDs 2 and 3 differently. Maybe the convention is only meant for two-party calls?
Marcel Graf IBM Zurich Research Lab
***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@itu.ch *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************
participants (2)
-
grm＠ZURICH.IBM.COM -
Jim Toga