Current RTP-MIB definition precludes multi-unicast RTP sessio n?
scc at TRILLIUM.COM
Wed May 3 12:45:19 EDT 2000
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,
The MIB draft should specify clearly how the multi-unicast
RTP session scenario should be handled and clarify some
of these inconsistencies.
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com
More information about the sg16-avd