Subject: FW: Current RTP-MIB definition precludes multi-unicast RTP sessio n?

From: Tim Chen <[email-masked]>
Date: Wed, 3 May 2000 08:42:46 -0700

> 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
> 
>

---

From: "Strahm, Bill" <[email-masked]>
Date: Wed, 3 May 2000 09:06:36 -0700

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:[email-masked]]
> Sent: Tuesday, May 02, 2000 5:19 PM
> To: [email-masked]
> Cc: [email-masked]'; [email-masked]';
> [email-masked]'; Michael Bird
> Subject: Current RTP-MIB definition precludes multi-unicast 
> RTP session?
> 
> 
> Hello,
> 
> 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. 
> 
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

---

From: Tim Chen <[email-masked]>
Date: Wed, 3 May 2000 09:45:19 -0700

Bill,

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.

> is indeed what we have here)

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, 
rtpSessionIndex, rtpSenderSSRC".

The MIB draft should specify clearly how the multi-unicast 
RTP session scenario should be handled and clarify some 
of these inconsistencies.

Regards,
Tim Chen

---

From: "Strahm, Bill" <[email-masked]>
Date: Wed, 3 May 2000 10:17:16 -0700

I think you are going a little overboard on your definition of "One Session"

First off I do not see how you could have a third party monitor setup to
catch all of the unicast streams involved.  Third party monitors were
designed to handle multicast cases where you can setup the monitor to
receive the multicast address/port combination that is needed to get the
management data.

I do not believe that your multi-unicast session is held up in the RTP Spec
From RFC 1889 Sec 3 Definitions

   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.  In a multimedia session,
        each medium is carried in a separate RTP session with its own
        RTCP packets. The multiple RTP sessions are distinguished by
        different port number pairs and/or different multicast
        addresses.

From this reading each of the A->B A->C is a seperate RTP Session ( there
are different destination transport address pairs).

If you want to define a seperate definition of an RTP session as Where one
endpoint unicasts the same information to multiple destination addresses on
the same port, I do not see this definition supported by the RTP spec, and I
do not see how this can work because B and C will not see each others RTCP
packets to create a single session to be managed.

Bill
> Sent: Wednesday, May 03, 2000 9:45 AM
> To: 'Strahm, Bill'; [email-masked]'; [email-masked]
> Cc: Michael Bird
> Subject: RE: Current RTP-MIB definition precludes multi-unicast RTP
> sessio n?
> 
> 
> Bill,
> 

Third party monitors were not designed for Unicast applications.  How do you
expect to get the Unicast RTCP information to this third party monitor
somewhere else in the network ???

> rtpSessionIndex, rtpSenderSSRC".
Again I say that the A->B stream is seperate than the A->C stream.  Looking
at endpoint A we have a table that has two entries in the RtpSessionEntry
one for each stream, and we have uniqueness.  From B we have one entry in
the RtpSessionEntry table (for the A->B stream) and no knowledge of the A->C
stream (we can't see it so we can't manage it from here).  The same thing
applies for C.

---

From: "Baugher, Mark" <[email-masked]>
Date: Wed, 3 May 2000 12:03:59 -0700

hi Tim
  Here's the first part of the RFC 1889 definition that
you cite:

> communicating
> > pair of destination transport addresses (one network 
> 

It reads that "For each participant, the session is defined by
a particular pair of destination transport addresses."  I think
you are interpreting this to mean a "set of pairs," which
is not what RFC 1889 says.  The MIB maintains management 
information for a participant, if it is a host, or
for all participants in the case of a multicast monitor.
A mixer or translator may have a different view of a
session, but the RTP MIB draft document states that mixers 
and translators are for further study.

Mark

> Sent: Wednesday, May 03, 2000 8:43 AM
> To: [email-masked]'
> Subject: FW: Current RTP-MIB definition precludes multi-unicast RTP
> sessio n?
> 
> 
> 
> > Hello,
> > 
> communicating

---

From: Tim Chen <[email-masked]>
Date: Wed, 3 May 2000 12:58:11 -0700

Mark,

Thank you for your reply.  Please find my comments inline:

> a particular pair of destination transport addresses."  

Here the pair of addresses refer to the receiving RTP and
RTCP address for that participant,  NOT a local RTP address
and a remote RTP address as in the current MIB draft.  
That is clear if we look at the entire sentence in the specs:

"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)."

So it is quite clear from the specs that each participant
in a session should receive RTP on one address/port and
RTCP on the same network address but another port.  However, the
specs explicitly mention that the receive addresses for
each participant need not be the same:

"The destination transport address pair may be 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."

So the specs allow for a scenario where I have user A, B and
C each using a different transport address pair to receive
RTP and RTCP packets to participate in a single RTP session.  
This is quite a valid scenario for a 3-way conference
call.  Under the current MIB definition, I cannot treat
this as a single RTP session.  

> I think
> is not what RFC 1889 says.  

I hope the above explanation clarifies my interpretation
of the RFC 1889's definition of a RTP session.

> The MIB maintains management 

Regards,
Tim Chen

---

From: "Baugher, Mark" <[email-masked]>
Date: Wed, 3 May 2000 19:19:05 -0700

Tim

> and a remote RTP address as in the current MIB draft.  

I agree though the RTP MIB draft does correctly support
the RTP/RTCP port pair in its definitions.  Your statement
might lead someone to think otherwise.  The MIB does
not support multipoint unicast addresses for an RTP
session from an RTP end system.  In the RTP MIB,
a "unicast RTP session" is an association between
two endpoints.

> RTP and RTCP packets to participate in a single RTP session.  

Yes, an RTP session can have multiple unicast endpoints.  The
spec discusses this in the context of a translator.  Yo 

> this as a single RTP session. 

I think it would be cleaner to call this an RTP translator
function and write a translator MIB for it.

Mark