how many port pairs in a call/conference?

Jim Toga jim.toga at INTEL.COM
Wed Jun 24 20:25:38 EDT 1998


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 at intel.com         mailto:james.toga at itu.ch         ***
***  PGP keyID 36 07 86 49 7D 74 DF 57  50 CB BA 32 08 9C 7C 41 ***
*****************************************************



More information about the sg16-avd mailing list