Hi Casner
Whatever you have stated is right. You have considered the two cases.
The second case is valid with multicast conference or with Unicast
conference using the same RTP port pair to send and receive data from
other participants. The first case will always result into three
separate multiparty sessions is separate RTP unicast
port pair is used to receive data from the other two participants.
1) Consider the unicast conference between three parties each using
separate RTP port pair to establish
RTP session with each. In this case each RTP port pair session will
send the RTCP report to the one
participant from which it is receiving data and not to the other
participant who is sending the data to the
other RTP port pair.
Hence a single RTP session should not be possible using distinct pair
of ports in receive data from other
participants in unicast mode. If this is correct then it contradicts
the following line.
"In the unicast case, a participant may
receive from all other participants in the session using the same
pair of ports, or may use a distinct pair of ports for each."
Kindly let me know if I am missing something.
-Vivek
Stephen Casner wrote:
On Wed, 11 Aug 2004, Oren Peleg wrote:
Sorry, still confused ... at the next paragraph it is written that a
three-way conference where each participant sends to each other, both
RTP & RTCP, is defined as three different RTP session, while according
to the fact here below that a single RTP session participant may have
distinct port pairs when communicating with other participants ... what
am I missing???
That paragraph offers two alternative ways to use RTP. The following
sentence applies to both of them:
For example, consider a three-party conference implemented using
unicast UDP with each participant receiving from the other two
on separate port pairs.
The first way to use RTP in this setting is:
If each participant sends RTCP feedback about data received from
one other participant only back to that participant, then the
conference is composed of three separate point-to-point RTP
sessions.
The second way to use RTP in this setting is:
If each participant provides RTCP feedback about its
reception of one other participant to both of the other
participants, then the conference is composed of one multi-party
RTP session. The latter case simulates the behavior that would
occur with IP multicast communication among the three
participants.
I think your problem is that you are expecting the RTP spec to
constrain its use to one, narrow mode of operation. It would be
inappropriate to do this because RTP is a fundamental protocol, like
TCP, that may be used with a wide variety of applications. The last
paragraph of the RTP session definition explains this:
The RTP framework allows the variations defined here, but a
particular control protocol or application design will usually
impose constraints on these variations.
So, the constraints you are seeking will come from another
specification that defines how RTP will be used in a particular
application.
On Thu, 12 Aug 2004, Vivek Mudgil wrote:
Oren has made a right point. The line
", or may use a distinct pair of ports for each"
contradicts the RTP session definition at other places. It requires a
closer look. Especially, how an implementation of this would satisfy
the distinguishing feature of RTP Session:
"The distinguishing feature of an RTP session is that each maintain
a full, separate space of SSRC identifiers (defined next). The set
of participants included in one RTP session consists of those that
can receive an SSRC identifier transmitted by any one of the
participants either in RTP as the SSRC or a CSRC (also defined
below) or in RTCP"
I see no contradiction here. When distinct pairs of ports are used
for multiple participants in a single RTP session, then separate
copies of the same SSRC identifier must be transmitted to each
participant (in RTP as the SSRC or CSRC, or in RTCP). This is as
described in the "second way to use RTP" above.
-- Steve
|