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@trillium.com] Sent: Wednesday, May 03, 2000 9:45 AM To: 'Strahm, Bill'; 'rem-conf@es.net'; ITU-SG16@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@mailbag.intel.com