Subject: Re: Fwd: Re: Define a unicast RTP session.

From: [email-masked]
Date: Wed, 30 Aug 2000 17:06:36 -0500

Again, so that others can follow . . . here's that latest, warts and all.

---------------------- Forwarded by Vincent Virgilio/Natural
MicroSystems/US on 08/30/2000 05:06 PM ---------------------------

Vincent Virgilio
08/30/2000 04:55 PM

To:   [email-masked], [email-masked]
cc:
Subject:  Re: Fwd: Re: Define a unicast RTP session.

Of course, the below comment about uni-multicast is quite dumb if the
session index has to map to a single session table entry . . .

Vince Virgilio

---------------------- Forwarded by Vincent Virgilio/Natural
MicroSystems/US on 08/30/2000 04:54 PM ---------------------------

Vincent Virgilio
08/30/2000 04:29 PM

To:   Mark Baugher <[email-masked]>
cc:   [email-masked]
Subject:  Re: Fwd: Re: Define a unicast RTP session.  (Document link:
      Vincent Virgilio)

Hi Mark (and Bill),

When you say "bidirectional, unicast RTP streams" you mean two opposite
flows, right?  According to Bill, the definition of an RTP session in
section 3 of RFC 1889 is unclear whether such a scenario constitutes one or
two sessions.  I say one, he says two.  I used subsequent drafts of the RFC
to prove my point.  Bill rightly pointed out that was invalid of me to do
so.  Still, on further inspection, I maintain that the original section 3
definition is singular (which implies multiple unicast destinations per
session), and that the first paragraph of section 7.1 in the same document
explicitly says that there is such a thing as a two-party bidirectional
unicast session.  Within that paragraph, "clouds" and sessions are equated,
and a cloud may be defined by a pair of unicast network addresses.

I don't think things get ugly for uni-multicast; the tables just get
bigger.  Then, given the definition that permits multiple destination
addresses per session, there would be multiple entries in the session table
for a single session, each containing the same session index, but a unique
remote address.  The local address would remain the same across all such
entries.  To gets statistics for the whole session, accumulate across all
entries with same index.  The impact on sender and receiver tables is
negligible, in size only, I think.

Even so, uni-multicast is not explicitly allowed by RFC 1889.  The session
definition in section 3 is constrained to two participants in the first
paragraph of section 7.1.

What do you guys think?  Actually, your session definition would greatly
simplify some work I'm about to do.  Which is to say, I have no vested
interest in this argument!  I have nothing to do with "H-media" people at
all.

Vince Virgilio

Mark Baugher <[email-masked]> on 08/30/2000 04:02:49 PM

To:   [email-masked], [email-masked]
cc:
Subject:  Re: Fwd: Re: Define a unicast RTP session.

hi
   We had H-media MIB participation in the RTP MIB.  I did not mean to say
that unicast was difficult, but that there seems to be some confusion since
the issue has popped up a few times on the list.  I don't think the person
or persons who raised the issue were always satisfied with the outcome.
One obvious source of confusion is that you cannot talk about a unicast
"session" for bidirectional, unicast RTP streams since there are two
sessions, not one, in this scenario.  So I don't know of any ready-made
nomenclature for distinguishing two sessions in bidirectional unicast RTP
communications from two unrelated, unidirectional, unicast sessions.  It's
not hard, per se.  It works though I find myself getting confused when
switching from unicast to multicast.  could be a personal problem, however.

Mark

At 03:48 PM 8/30/00 -0500, [email-masked] wrote:

>Hi Mark,
>
>I had no idea that this question was so difficult.  Obviously you have the
>last say in how your MIB should be implemented.  I am concerned, though,
>that the view of a system given by the MIB will differ from the
>configuration negotiated through H.323.  For example, there could be twice
>as many sessions observed in the former as negotiated in the latter.
>
>Vince Virgilio
>
>
>
>
>
>Mark Baugher <[email-masked]> on 08/30/2000 03:42:07 PM
>
>To:   [email-masked]
>cc:
>Subject:  Re: Fwd: Re: Define a unicast RTP session.
>
>
>Vincent
>    Bill said what I think in his note.  I think there is a lot of
confusion
>about unicast in RTP.
>
>Mark
>At 10:18 AM 8/30/00 -0500, you wrote:
>
> >Hi Mark,
> >
> >Thanks for the response.
> >
> >There seems to be plenty of evidence that unicast sessions can be
> >bidirectional, which means that both endpoints in a two party call would
>be
> >participating in the same single session.  In fact, this may be the
>typical
> >case.  If each entry in the RTP MIB session table identifies a unique
> >session, shouldn't there, then, be one MIB session entry at each
endpoint?
> >If the mode were simply host, and not host-monitor, each endpoint would
> >have this one session table entry, along with one entry in the sender
>table
> >and another in the receiver table (all with the same session index) -
> >again, assuming bidirectional flow in the session.
> >
> >Please advise!
> >
> >Vince Virgilio
>
>
>Mark Baugher
>PGP Fingerprint
>01AB 9388 D69F A8E6 DD38  4D9B D558 79F3 7D45 6B1C
>
>

Mark Baugher
PGP Fingerprint
01AB 9388 D69F A8E6 DD38  4D9B D558 79F3 7D45 6B1C

---

From: Mark Baugher <[email-masked]>
Date: Wed, 30 Aug 2000 16:09:26 -0700

Vincent
   If I wanted my note to you posted to rem conf, I would have done that myself.

Mark

Mark Baugher
PGP Fingerprint