Subject: Re: Define a unicast RTP session.

From: [email-masked]
Date: Mon, 28 Aug 2000 15:46:28 -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

I (Vince) put forth one more desparate point.

There is something that satisfies my expectation very nicely; in fact, I
think it meets and proves it!

From the RTP FAQ
(http://www.cs.columbia.edu/~hgs/rtp/faq.html#unicast_ports):

   Q: How are ports assigned for [here it comes] bidirectional unicast RTP sessions?

   A: Each side in a bidirectional RTP connection [indeed such a creature
   exists] assigns their source ports independently, i.e., there is no
   assumption that if Alice sends audio to Bob on port 5000 (and RTCP on
   5001), Alice also has to receive audio on port 5000. (Imposing such a
   restriction on ports would make it difficult for a host to participate
   in several independent RTP sessions using different tools.) Each side in
   a unicast session simply indicates to the other side where it wants to
   receive RTP packets, e.g., using SDP.

   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 17:21:33 -0700

> >one?  Your answer suggests two entries.  Is that what the MIB authors
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