Current RTP-MIB definition precludes multi-unicast RTP session?
Hello,
I see a problem with current "RTP session" definition in RTP MIB <draft-ietf-avt-rtp-mib-09.txt>. This MIB definition precludes multi-unicast RTP session which is clearly permissible under section 3 of RFC 1889:
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.
Hence each participant in an RTP session could have a different RTP receive address. The only requirement from the specs is that the RTP and RTCP port pair used by all participants has to be the same. For example, I can have the following RTP session with three participants, each receiving RTP packets on a different IP address:
participant A : receive RTP on 103.403.25.45 port 6000 participant B : receive RTP on 103.403.33.34 port 6000 participant C : receive RTP on 103.403.25.98 port 6000
So for participant A, he will send to two remote addresses: 103.403.33.34:6000 (that B listens to) and 103.403.25.98:6000 (that C listens to).
However, the current RTP session MIB draft (page 10) has the following structure:
RtpSessionEntry ::= SEQUENCE { rtpSessionIndex Integer32, rtpSessionDomain TDomain, rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionSenderJoins Counter32, rtpSessionReceiverJoins Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus }
This definition allows only a single remote address. This is contradictory to RFC 1889 which clearly permits multiple remote addresses in a single RTP session.
Will the authors of this MIB give some clarification? Thanks.
Regards, Tim Chen
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (1)
-
Tim Chen