Subject: RE: Define a unicast RTP session.

From: [email-masked]
Date: Wed, 30 Aug 2000 15:40:06 -0500

And the plot thickens.

Respectfully, I believe the RTP RFC, especially with the subsequent drafts,
is very clear in its definition of _a_ session.  First, the definition is
singular.  It becomes plural only when discussing different media types.

Also, section 7.1 of the latest RTP internet draft (#8) discusses
transport-level "clouds", which are defined by a single multicast address,
or two unicast addresses.  Later, in appendix B, this text is interpreted
to apply to a session; that it means distinct [destination] port pairs may
be used for the two ends of a unicast session.  The same appendix entry
also supports my interpretation of the definition of a session in section
3; the one you quoted.

Similarly, section 11 of the same draft says the same, that there may be
two different destination port pairs in a unicast session (emphasis and
commentary added):

   _In a unicast session_ [singular], _both_ participants need to identify
   a port pair for _receiving_ [thus both may send] RTP and RTCP packets.
   Both participants MAY use the same port pair.  A participant MUST NOT
   assume that the source port of the incoming RTP or RTCP packet can be
   used as the destination port for outgoing RTP or RTCP packets [thus two
   differnt dest port pairs per session permitted].  When RTP data packets
   are being sent in both directions [in one session], each participant
   MUST send RTCP SR packets to the port that the other participant has
   specified for reception of RTCP.  The RTCP SR packets combine sender
   information for the outgoing data plus reception report information for
   the incoming data.  If a side is not actively sending data, an RTCP RR
   packet is sent instead.

That is not ambiguous.  Must I say "to me"?

This poses no problems to the MIB.  In host mode, there would be one entry
in the session table, and, given bidirectional flow, corresponding ones in
the sender and receiver tables, as Mark said initially.  The assignment of
local and remote addresses in the session entry would be obvious.  Local is
where the agent runs (the network part) and where RTP packets are received;
remote is where RTP packets are sent.  Both addresses are considered
destination addresses, depending on your perspective, which, in a session,
can change.  The local participant considers the remote address his
destination address, and considers the local address the other
participant's destination address.  The other participant interprets his
session entry in the same way.  But who cares, this has no teeth.
Moreover, the MIB does not say anywhere that a session is defined by one
destination transport address (but, instead, I am willing to accept that
from you); it refers back to the RTP RFC definitions, covered above.  Even
so, were a session defined this way, a single entry would be made out of
two using the interpretive scheme above, and assigning the local and remote
address appropriately.

Also, local would always truly mean local, and the sense of remote would be
as stable.  The first sentence of the definition of rtpSessionLocAddr seems
to expect this: "The local address used by the RTP system."  If there were
two session entries, one per flow direction, one session entry would have
the local address assigned using the network address of the local system.
The other entry would have the local address assigned using the network
address of the remote system.  The latter seems to be in tension with the
first sentence of the description of rtpSessionLocAddr.  If
rtpSessionLocAddr were _not_ assigned thus, there would be a collision in
the inverse session table.  One remote/local pair would map to two session
indices.  So rtpSessionLocAddr must be assigned this way, under your
definition of a session.  True; intended?  But if we use the bidirectional
definition of a session, there would be no tension (if there ever was) with
the definition of rtpSessionLocAddr.

So things fall into place nicely.  In host mode, assuming bidirectional
flow, objects senderJoins and receiverJoins would both be valid where they
wouldn't be given your take on sessions.  Your way, outbound sessions (host
mode) would only increment senderJoins, and inbound sessions would only
increment receiverJoins, since only host-monitor mode, not host mode,
tracks remote receivers or senders.  However, I do notice a loophole, in
the descriptions of rtpSenderTable and rtpReceiverTable.  They state that,
regardless of mode (mode not mentioned), receiving hosts may add entries to
the sender table and sending hosts may add entries to the receiver table.
Hm.  I think this blurs the line some between host and host-monitor mode.

Vince Virgilio

"Strahm, Bill" <[email-masked]> on 08/30/2000 12:01:38 PM

To:   "[email-masked]'" <[email-masked]>, Mark
      Baugher <[email-masked]>
cc:   [email-masked]
Subject:  RE: Fwd: Re: Define a unicast RTP session.

I think I'll step in as another one of the RTP MIB authors who had to
wrangle with this issue...

We took the definition from 1889 quite literally From section 3

   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.

Therefore in the case of unicast there ARE two sessions, because there are
two different destination transport addresses.  Did we get it right, I hope
so (we are on track to have an RFC issued).  Is there room for a LOT of
interpretation, I believe that there is.  However in the case of the RTP
MIB
a session is defined by a destination address, how would you put both
sessions into the MIB as one entry if they have separate destination
addresses ?

Now this is different in Multicast because the destination address for ALL
flows is a multicast address that is common for all senders.

Bill

______________________________________________
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: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, August 30, 2000 8:18 AM
> To: Mark Baugher
> Cc: [email-masked]
> Subject: Re: Fwd: Re: Define a unicast RTP session.
>
>
>
> 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
>
>
>

---

From: Christophe Leske <[email-masked]>
Date: Wed, 30 Aug 2000 14:05:03 -0700

Could someone pls point me to the resource where i can unsubscribe from this
list?
I was interested in tapping mbone, it turns out that no commercial provider in
the SF bay area DOES provide mbone access.

I never got any answers of this list, and worse yet, i am getting spam and sex
emails.

Thank you, i got enough of this.

--
Regards,
Christophe Leske

m  a  c  r  o  m  e  d  i  a
Director QA engineer-Dataman
phone : [415] 832 - 7497
[email-masked]
"What we do in life echoes in eternity."