Current RTP-MIB definition precludes multi-unicast RTP sessio n?

[Strahm, Bill]

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 at trillium.com]
> Sent: Tuesday, May 02, 2000 5:19 PM
> To: ITU-SG16 at mailbag.cps.intel.com
> Cc: 'mbaugher at passedge.com'; 'bill.strahm at intel.com';
> 'irina at 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 at mailbag.intel.com