Re: [AVT] Final edits to RTP spec and A/V profile

John Lazzaro <lazzaro@CS.Berkeley.EDU> Thu, 16 January 2003 19:30 UTC

Received: from www1.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21705 for <avt-archive@odin.ietf.org>; Thu, 16 Jan 2003 14:30:58 -0500 (EST)
Received: (from mailnull@localhost) by www1.ietf.org (8.11.6/8.11.6) id h0GJkC517647 for avt-archive@odin.ietf.org; Thu, 16 Jan 2003 14:46:12 -0500
Received: from www1.ietf.org (localhost.localdomain [127.0.0.1]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJd9J17281; Thu, 16 Jan 2003 14:39:09 -0500
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by www1.ietf.org (8.11.6/8.11.6) with ESMTP id h0GJbDJ16880 for <avt@optimus.ietf.org>; Thu, 16 Jan 2003 14:37:13 -0500
Received: from snap.CS.Berkeley.EDU (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21483 for <avt@ietf.org>; Thu, 16 Jan 2003 14:21:28 -0500 (EST)
Received: (from lazzaro@localhost) by snap.CS.Berkeley.EDU (8.9.3/8.9.3-ZUUL) id LAA17554 for avt@ietf.org; Thu, 16 Jan 2003 11:24:31 -0800
Date: Thu, 16 Jan 2003 11:24:31 -0800
From: John Lazzaro <lazzaro@CS.Berkeley.EDU>
Message-Id: <200301161924.LAA17554@snap.CS.Berkeley.EDU>
To: avt@ietf.org
Subject: Re: [AVT] Final edits to RTP spec and A/V profile
Sender: avt-admin@ietf.org
Errors-To: avt-admin@ietf.org
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>

> Jonathan Rosenberg <jdrosen@dynamicsoft.com> writes:
>
> I suspect each unicast connection is treated as a separate RTP session.

Sfront currently ships with multi-unicast support, and the  
implementation is a hybrid of both approaches. A sender does
sent the same RTP packet to each receiver, and in this way
everything but the lowest layers of the stack believes a 
true multicast session is underway. Sfront needs to do this,
because it lets a sender create and maintain one recovery
journal system for all receivers, a big efficiency improvement
over N recovery journal systems.

However, a receiver doesn't send RTCP RR packets describing  
a sent stream to all other participants, only to the original
sender. This is for efficiency ...                         

BTW, Appendix B of the MWPP guidelines document:

http://www.ietf.org/internet-drafts/draft-lazzaro-avt-mwpp-coding-guidelines-01.txt

Covers this topic in detail ... 

-------------------------------------------------------------------------
John Lazzaro -- Research Specialist -- CS Division -- EECS -- UC Berkeley
lazzaro [at] cs [dot] berkeley [dot] edu     www.cs.berkeley.edu/~lazzaro
-------------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt