Subject: RE: [AVT] RE: RTP/RTCP Port Sharing (Was: Comedia Issues.)

From: "Christian Huitema" <[email-masked]>
Date: Tue, 17 Jul 2001 19:40:18 -0700

> Out of curiosity, what kind of timeouts do these NAT bindings 
> typically have?

Between 30 seconds and 15 minutes. Depends on the implementation.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 18 Jul 2001 12:47:50 -0400

> -----Original Message-----
> From: Michael Thomas [mailto:[email-masked]]
> Sent: Wednesday, July 18, 2001 6:23 AM
> To: Lawrence Conroy
> Cc: Leonid Rosenboim; [email-masked]; Ross Finlayson; [email-masked]
> Subject: Re: [AVT] Re: RTP/RTCP Port Sharing (Was: Comedia Issues.)
> 
> 
> Lawrence Conroy writes:
>  > There are some obscure scenarios in which packet traffic 
> is actually carried
>  > on connection-oriented bearers, and each new packet flow 
> *may* need a heavy
>  > weight setup procedure. 
> 
>    I guess that depends on your description of "obscure". 
>    Dean rightly surmised I was thinking about the DOCSIS cable
>    MAC/PHY and the ability to use unsolicited grants for RTP
>    traffic. DOCSIS is pretty widely deployed these days, not
>    to mention an ITU standard. Nor are TDM-like slotting 
>    arrangements likely to vanish on certain kinds of media
>    any time soon. The sin of the PSTN was to insist that
>    there was exactly one way to build a shared media and that
>    was with 64k TDM slots. That's not the same thing as saying
>    that TDM is inherently bad under all circumstances.

I'm just curious how this will work; what if the PC is busy and doesn't get
around to sending media for 100ms (yeah, its bad, I know, but it can
happen), so it sends a burst of 100ms worth of data. Are you saying that
DOCSIS modems will discard the data? Buffer it up, and send it at a constant
packet rate? That makes delays worse...

Anyway, that said, if we have a way to make sure there is always data on the
RTP channel (even while being held, which is a big problem), then my main
motivation for RTP/RTCP on the same port goes away. I could have sworn there
was some other reason for wanting it, but it eludes me at the moment.

However, I definitely need a way to signal the RTCP port, so Christians
draft is really important.

-Jonathan R.
---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: John Lazzaro <[email-masked]>
Date: Wed, 18 Jul 2001 11:54:16 -0700

> Lawrence Conroy writes:
>
> In this case one can simply not deal with RTCP (for
> very simple "two party" cases in which there's no absolute need for it).

At least one codec uses information coded in the RTCP RR packets as an
integral part of the forward-channel coding scheme, see Appendix A of
this paper for details:

http://www.cs.berkeley.edu/~lazzaro/sa/pubs/pdf/nossdav01.pdf

While the trick we use (using the "extended highest sequence number 
received" RR field to control resilency coding) is specialized for our
application domain (MIDI control of MPEG 4 Structured Audio), I can
easily imagine designing a mainstream audio or video codec that uses
this approach -- perhaps one already exists, although I'm not aware of one.

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------