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.

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

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