My comments inline ______________________________________________ Bill Strahm Programming today is a race between bill.strahm@ software engineers striving to build intel.com bigger and better idiot-proof programs, (503) 264-4632 and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.--Rich Cook I am not speaking for Intel. And Intel rarely speaks for me

-----Original Message----- From: Tim Chen [mailto:scc@trillium.com] Sent: Tuesday, May 02, 2000 5:19 PM To: ITU-SG16@mailbag.cps.intel.com Cc: 'mbaugher@passedge.com'; 'bill.strahm@intel.com'; 'irina@ennovatenetworks.com'; Michael Bird Subject: 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.

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 Bill Strahm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com