Current RTP-MIB definition precludes multi-unicast RTP session?
Tim Chen
scc at TRILLIUM.COM
Tue May 2 20:19:04 EDT 2000
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 at mailbag.intel.com
More information about the sg16-avd
mailing list