Subject: Re: Define a unicast RTP session.

From: [email-masked]
Date: Mon, 28 Aug 2000 12:11:44 -0500

Jonathan Rosenberg wrote:

>[email-masked] wrote:
>>
>> Hello,
>>
>> A simple question:
>>
>> If there is a single conversation between two RTP implementations, i.e.
two
>> oppositely directed RTP packet flows, using UDP over _unicast_ IP, how
many
>> sessions are there: one or two?
>
>Two.

>Jonathan D. Rosenberg                       72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
>http://www.dynamicsoft.com

I am surprised.  I expected the answer to be "one" because . . .

   Doesn't the definition of a _single_ RTP session in RFC 1889 say/imply
   that for unicast there will be several (RTP/RTCP) destination transport
   addresses per session (one for each participant), which at least differ
   in their network part?
   Doesn't the SSRC collision logic apply (in a trivial way) to unicast
   sessions too, i.e. there can be a collision between the two sources in a
   two participant session?  If a session was from sender to receiver only,
   how could senders detect a collision in a session of any size, besides
   the "roundabout " way of RTCP?  Or was collision detection through RTCP
   intended?
   It seems that the design of RTCP permits sessions to contain
   bidirectional flows, since the sender reports also contain receiver
   information, thus correlating two opposite flows.  The H.323
   recommendation seems to imply the same, by mandating a single
   destination port ("common channel") for sender and receiver reports from
   a single endpoint.
   More argumentum ad H.323.  Paragraph eight of section 6.2.8.2 says that
   one can open a "reverse logical channel" (RTP flow) and add it to an
   existing RTP session.  Thus there would then be two oppositely directed
   flows in an RTP session.
   William Stallings, in _High Speed Networks_ (p. 287) defines a single
   unicast RTP session to contain a _set_ of IP addresses, with a common
   RTP destination port.  Again, this implies bidirectional flow to me.
   Finally, how shall two oppositely directed RTP flows in a two-party
   conversation appear in the RTP MIB session table, as two entries or as
   one?  Your answer suggests two entries.  Is that what the MIB authors
   want?

I read the SIP glossary, appendix and some of SDP.  They say there may be
one or more RTP sessions in an SDP session, but do not comment on the
nature of an RTP session.  The mechanics of SDP session negotiation may be
critical here; I haven't digested that yet.  Still, I venture that a
unicast RTP session defined by multiple destination transport addresses
(one unique pair for each participant) fits in with SIP and SDP usage.  So
I am still trying to understand your answer.

Vince Virgilio

---

From: Ralph Neff <[email-masked]>
Date: Mon, 28 Aug 2000 14:33:11 -0700

Vince,

Thanks for bringing this up; I was wondering the same thing
myself.  However, I think it should be clarified that the
text you included from the FAQ is not actually in the RTP
spec (rfc1889), but rather in a revision to rfc1889 that is
currently in internet-draft stage in avt.  This draft can
be found at:

http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-new-08.txt

The original rfc1889 seems (to me at least) to imply that
all participants in a unicast session are supposed to use a
single "common port pair" (see Section 3 of rfc1889, definition
of an RTP Session).  I think the text of the new draft makes
much more sense.

-Ralph Neff

-----------(original message)--------------
>    Section 10 of RFC 1889 says:
> 
>      In a unicast session, applications SHOULD be prepared to receive RTP
>      data and control on one port pair and send to another.  Note that the
>      SSRC values used for each source are always different
> 
> This is what I've been looking for, something that explicitly says there
> can be bidirectional unicast RTP sessions.  And that the destination ports
> can differ.
>
> Vince Virgilio

---

From: Mark Baugher <[email-masked]>
Date: Tue, 29 Aug 2000 18:34:13 -0700

I am sorry but I realized while driving home that what I just said was wrong.  For unicast, there are two rtpSessionTable entries at each endpoint.  There is a session entry for the stream that the particular endpoint is sending and one for the stream that it is receiving.   I apologize for this confusion.

Mark
>Date: Tue, 29 Aug 2000 17:21:33 -0700
>To: [email-masked]
>From: Mark Baugher <[email-masked]>
>Subject: Re: Define a unicast RTP session.
>
>>
>> > - Finally, how shall two oppositely directed RTP flows in a two-party
>There are two rtpSessionTable entries, one in each endpoint's RTP MIB of the unicast connection.  At each particular endpoint, there will be an rtpSenderTable entry for the session data that the endpoint is sending, and there will an rtpRcvrTable entry for the session data that the endpoint is receiving.
>
>Mark

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

---

From: [email-masked]
Date: Wed, 30 Aug 2000 10:18:29 -0500

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: "Strahm, Bill" <[email-masked]>
Date: Wed, 30 Aug 2000 10:01:38 -0700

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

---

From: [email-masked]
Date: Wed, 30 Aug 2000 17:04:29 -0500

So that others can follow the thread . . .

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

"Strahm, Bill" <[email-masked]> on 08/30/2000 03:49:24 PM

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

The problem is that you are referencing a Internet Draft that I cannot use
until it has been standardized.  I am only willing to talk about what is
ACTUALLY in 1889 to base the RTP MIB RFC on...

Some comments below...

> Sent: Wednesday, August 30, 2000 12:52 PM
> To: Strahm, Bill
> Subject: RE: Fwd: Re: Define a unicast RTP session.
>
>
>
> 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.

Yes section 3 has many different interpretations... I have even heard
something call Uni-Multicast where I broadcast all of my streams to
everyone
else unicast, they all do the same and this is all supposed to be 1
session...  (all based on the Section 3 definition of an RTP session)  Very
ugly...

> 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"?
Well in that Draft 9 may change everything... This text is not in 1889, so
I
am not considering it for the RTP MIB RFC.  When Draft #n becomes standard,
and we move the RTP MIB to the next standard level I would consider
changing
the sematics...

> 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.
>
>
> interpretation, I believe that there is.  However in the case
> of the RTP
> MIB

---

From: [email-masked]
Date: Thu, 31 Aug 2000 08:58:35 -0500

Hi Mark,

I apologize.  Won't happen again.

Vince Virgilio

Mark Baugher wrote:
>Vincent
>   If I wanted my note to you posted to rem conf, I would have done that
myself.