how many RTP Sessions in a call/conference?

Fri Jun 19 12:59:13 EDT 1998

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

More information about the sg16-avd mailing list