Current RTP-MIB definition precludes multi-unicast RTP sessio n?

[Strahm, Bill]

I think you are going a little overboard on your definition of "One Session"

First off I do not see how you could have a third party monitor setup to
catch all of the unicast streams involved.  Third party monitors were
designed to handle multicast cases where you can setup the monitor to
receive the multicast address/port combination that is needed to get the
management data.

I do not believe that your multi-unicast session is held up in the RTP Spec
>From RFC 1889 Sec 3 Definitions

   RTP session: The association among a set of participants
        communicating with RTP. For each participant, the session is
        defined by a particular pair of destination transport addresses
        (one network address plus a port pair for RTP and RTCP). The
        destination transport address pair may be common for all
        participants, as in the case of IP multicast, or may be
        different for each, as in the case of individual unicast network
        addresses plus a common port pair.  In a multimedia session,
        each medium is carried in a separate RTP session with its own
        RTCP packets. The multiple RTP sessions are distinguished by
        different port number pairs and/or different multicast
        addresses.

>From this reading each of the A->B A->C is a seperate RTP Session ( there
are different destination transport address pairs).

If you want to define a seperate definition of an RTP session as Where one
endpoint unicasts the same information to multiple destination addresses on
the same port, I do not see this definition supported by the RTP spec, and I
do not see how this can work because B and C will not see each others RTCP
packets to create a single session to be managed.

Bill
> -----Original Message-----
> From: Tim Chen [mailto:scc at trillium.com]
> Sent: Wednesday, May 03, 2000 9:45 AM
> To: 'Strahm, Bill'; 'rem-conf at es.net'; ITU-SG16 at mailbag.cps.intel.com
> Cc: Michael Bird
> Subject: RE: Current RTP-MIB definition precludes multi-unicast RTP
> sessio n?
>
>
> Bill,
>
> Thank you for your reply.  However, I am not
> convinced that multi-unicast RTP session MIB is
> properly handled in the current RTP MIB draft.
> Please find my comments below.
>
> > I see each one of these as seperate channels, with
> different feedback
> > streams.  Therefor participant A would have a RtpSessionEntry
> > for A->B and
> > A->C, participant B would have B->A and B->C etc.  Yes this
> > doesn't scale
> > very well as you add many participants, but then neither
> does sending
> > multiple copies of the same stream, so I think it is a wash.
> >
> > To clarify.  The RtpReceiverEntry needs to have the feedback
> > for just ONE
> > receiver anyway, so why not model it as multiple unicast
> > flows (since that
> > is indeed what we have here)
> >
> > I do not see a problem
>
> The issue I am raising is that we are dividing up what is truly
> a single RTP session as defined in RFC 1889 with multiple RTP
> sessions
> in MIB.  The RTP MIB draft has changed the definition of a
> RTP session.
>
> Let's say if I want to implement a monitor for the above
> example where A is sending to both B and C in a RTP session.
> I send a MIB request for a RTP session and according to the
> current MIB specs, I will be getting back only a single stream
> in the RTP session (say A->B).  I cannot be certain if
> another stream (A->C) exists for this RTP session
> unless I dump the whole MIB and try to correlate all the
> "MIB RTP session" with the local address of A.

Third party monitors were not designed for Unicast applications.  How do you
expect to get the Unicast RTCP information to this third party monitor
somewhere else in the network ???

> In addition, the reverse sender table mapping is non unique.
> Let's continue with the above example and look at the
> sender A.  Sender A's send address is common to the stream
> A->B and A->C.  Then using sender A's rtpSessionDomain and
> rtpSenderAddr,
> I can map to the session index corresponding either to the
> (A->B) stream
> or the session index corresponding to the (A->C) stream.  This
> is contradictory to the statement in the MIB rtpSenderInverseEntry
> that "Each entry corresponds to exactly one entry in the
> rtpSenderTable - the entry containing the index pair,
> rtpSessionIndex, rtpSenderSSRC".
>
Again I say that the A->B stream is seperate than the A->C stream.  Looking
at endpoint A we have a table that has two entries in the RtpSessionEntry
one for each stream, and we have uniqueness.  From B we have one entry in
the RtpSessionEntry table (for the A->B stream) and no knowledge of the A->C
stream (we can't see it so we can't manage it from here).  The same thing
applies for C.
> The MIB draft should specify clearly how the multi-unicast
> RTP session scenario should be handled and clarify some
> of these inconsistencies.
>
> Regards,
> Tim Chen
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com