RE: [AVT] RFC3550 RTP Session defintion Qi

["Oren Peleg" <OrenP at audiocodes.com>]

If I understand you correctly, the session is identified by the
receiver, and not as a generic graph topology. Let me explain using
example:

Lets take the 3-way conference example. Lets call the 3-way conference
participants A, B and C. Lets say that A is sending same RTCP report to
both B & C. From A perspective, he is in one RTP session with B & C.
Lets say that B is sending different RTCP reports to A & C. From B
perspective he is in 2 different sessions with A & C.
So, we have here A & B that are being participating in an RTP sessions
with each other, while not the same one ... am I right?

It looks to me that if the RTP standard is fundamental, it should not
include the RTP session as a definition and only explain the
participants behavior, while letting the above application to define its
own specific RTP sessions definitions (E.g. Megaco Context). If the RTP
standard wishes to give some session-like capabilities, perhaps a
session ID should have been added to the RTP header, helping the
application distinguishing between different sessions & also might
suggest some RTP level session manipulations as well.

Regards,

Oren P.

-----Original Message-----
From: casner at packetdesign.com [mailto:casner at packetdesign.com] On Behalf
Of Stephen Casner
Sent: Thursday, August 12, 2004 8:58 AM
To: Vivek Mudgil
Cc: Oren Peleg; avt at ietf.org
Subject: Re: [AVT] RFC3550 RTP Session defintion Qi

On Thu, 12 Aug 2004, Vivek Mudgil wrote:

> 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 second case is also valid if each participant uses distinct port
pairs to receive data from other participants.  Why do you think
otherwise?

> The first case will always result into three separate multiparty
> sessions is [if?] separate RTP unicast port pair is used to receive
> data from the other two participants.

Why always?

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

The RTCP report could be sent to the both other participants.  It
makes no difference if the other participants are both receiving RTCP
on the same port or different ports.  As the examples in the RFC text
are attempting to explain, it is this choice (whether to send to only
one participant or to all of them) that determines whether there is
one RTP session or multiple RTP sessions.

> Hence a single RTP session should not be possible using distinct
> pair of ports in receive data from other participants in unicast
> mode.

No, as explained above.

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

You make an assumption about how RTCP can be sent, but I don't see the
justification for that assumption.

                                                        -- Steve

************************************************************************************************************
This email and any files transmitted with it are confidential material.
They are intended solely for the use of the designated individual or entity to whom they are addressed.
If the reader of this message is not the intended recipient,
you are hereby notified that any dissemination,use,
distribution or copying of this communication is strictly prohibited and may be unlawful.

If you have received this email in error please notify postmaster at audiocodes.com and permanently delete the e-mail and files.


***********************************************************************************************************

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt