[AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms
Fernando Boronat Seguí <fboronat@dcom.upv.es> Tue, 11 October 2011 09:54 UTC
Return-Path: <fboronat@dcom.upv.es>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9691621F8D23; Tue, 11 Oct 2011 02:54:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.439
X-Spam-Level:
X-Spam-Status: No, score=-0.439 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fcB8Rpv4qqqI; Tue, 11 Oct 2011 02:54:31 -0700 (PDT)
Received: from marfik.cc.upv.es (marfik.cc.upv.es [158.42.249.9]) by ietfa.amsl.com (Postfix) with ESMTP id 6934D21F8C98; Tue, 11 Oct 2011 02:54:27 -0700 (PDT)
Received: from smtpx.upv.es (smtpxv.cc.upv.es [158.42.249.46]) by marfik.cc.upv.es (8.13.6/8.13.6) with ESMTP id p9B9sOax011485 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 11 Oct 2011 11:54:24 +0200
Received: from smtp.upv.es (celaeno.cc.upv.es [158.42.249.55]) by smtpx.upv.es (8.14.3/8.14.3) with ESMTP id p9B9sOwW016751; Tue, 11 Oct 2011 11:54:24 +0200
Received: from [127.0.0.1] (fboronat2114.pc.upv.es [158.42.145.157]) by smtp.upv.es (8.13.6/8.13.6) with ESMTP id p9B9sNY3022508; Tue, 11 Oct 2011 11:54:23 +0200
Message-ID: <4E941250.2080500@dcom.upv.es>
Date: Tue, 11 Oct 2011 11:54:24 +0200
From: Fernando Boronat Seguí <fboronat@dcom.upv.es>
Organization: UNIVERSIDAD POLITÉCNICA DE VALENCIA
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: avt@ietf.org, xrblock-request@ietf.org
Content-Type: multipart/alternative; boundary="------------020902020101000503040600"
X-Mailman-Approved-At: Tue, 11 Oct 2011 07:49:55 -0700
Subject: [AVTCORE] Possible Additional functionalities for draft-brandenburg-avt-rtcp-for-idms
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: fboronat@dcom.upv.es
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 11 Oct 2011 09:54:34 -0000
Dear Group members, As this is our first mail to the list, we introduce ourselves. We are Fernando Boronat and Mario Montagud, co-authors of the Internet Draft (I-D) "RTCP for inter-destination media synchronization" (draft-ietf-avtcore-idms-01.txt). As the I-D was accepted as a WG document, any changes will have to be approved by the AVTCORE group. So, we would like to know if you consider appropriate to introduce some additional functionalities to the proposed IDMS approach in the I-D. In many distributed applications it is required that all the receivers start the playout of the media stream almost simultaneously (we refer this as Coarse Sync) and, after that, all of them play-out the media in a synchronous way (we refer this as Fine Sync). Those processes are essential for acquiring IDMS. A Global Initial Playout Instant for all the geographically distributed receivers (SCs) in a media session could prevent from an initial playout time discrepancy (asynchrony) at the beginning of the playout of the media stream/s (if a fixed global initial buffering delay is set) mainly due to the variable network delays from the media server to each one of the SCs. Thus, we are thinking about including a new section in the I-D about possible packets for Coarse Sync for both the initial playout instant (at the begining of a media session) and the initial instant at each stage in which the session can be divided (we consider that a stage ends when no streams are transmitted during a fixed interval (it could be defined depending on the applications), and that the next stage starts when data is transmitted again). This technique has been considered in some previous IDMS works (see reference [Boronat09] in the I-D), but using proprietary protocols. The methods we propose here are based on the use of already defined and standard RTCP packets, which would avoid the introduction of proprietary closed solutions. Regarding the Initial Playout Instant, we have primarily thought about the use of already proposed RTCP XR packets (RFC 3611): 1. Use of RTCP XR with RRTR and DLRR report blocks (defined RFC 3611) for measuring the delay between MSAS and SCs, allowing MSAS to estimate the RTT for all the SCs, then calculate a common initial playout instant and then communicate it to all SCs by sending them an RTCP IDMS Packet (defined in the I-D). The RTCP IDMS packet must include the RTP Timestamp of the first MU to be sent by the source and its proper playout instant, which will be common for all of them. MSAS may estimate its round trip time (RTT) to the SCs by sending them an RTCP XR with the Receiver Reference Time Report Block and forcing (according to RFC 3611) them to reply by sending an RTCP XR with a DLRR Report Block. Notice that both XR blocks are defined in RFC 3611 to be used in the opposite way we propose. If this solution is not considered appropriate we could think about another solution based on the packets already defined in the I-D, but maybe we would need to change the format adding new field/s. 2. Once joined the session, if it is not started yet, all the SCs could start sending RTCP XR with IDMS block (until they receive the Initial Playout Instant indication, sent using the RTCP IDMS Packet) as it is defined in the I-D, but including only the essential timing information (e.g. the wallclock time at which the packet is sent by the SC) to let the MSAS estimate the one-way network delays (not round-trip as in the previous case) for each SC (assuming symmetric delays as in TCP) and calculate the Initial Playout Instant. For that purpose, some field of the RTCP XR IDMS block should be used to indicate the XR IDMS block is carrying out temporal information for Coarse Sync, and not for reporting about arrival/playout timing of a specific RTP packet. From the Initial Instant they will continue playing the streams and sending the RTCP XR with IDMS complete block (as currently defined in the I-D). It could be a possible solution. The process of the calculation of the optimum Initial Playout Instant must take into consideration some factors such as the maximum and minimum estimated delays, jitter values, expected duration of the session, or probable clock deviations, in order to allow enough buffered MUs to start the playout and to maintain it continuously, thus avoiding underflow/overflow situations (playout discontinuities), during the session. This process is out of the scope of the ID. With the introduction of the Coarse Sync functionality, the IDMS proposal can counteract the effect of the delay variability at the beginning of the playout of the media stream/s in each one of the stages in which a media session can be divided. We prefer the first method because there is no need to define new IDMS control messages (or to include some fields to already defined packets), but the use of already defined RTCP reports (RFC 3611) can be adapted for that purpose. Moreover, with the use of the first method, SCs do not have to send control messages once they join the session, which may possibly result on inefficient control traffic overhead. They will only have to send RTCP XR DLRR messages in response to a new incoming RTRR message from the source, which is who really knows the initial transmission time for the RTP media stream. Moreover, the Initial Playout Instant can be sent to the receivers by using the RTCP IDMS packet, already introduced in the I-D. Feedback will be much appreciated. Regards ======================================================================== Dr. Fernando Boronat Seguí IEEE Senior Member Profesor Titular / Lecturer Dept. Comunicaciones Tlf.-+34+962 849 300 Ext.-49341 Tlf. directo -+34+962 849 341 Fax.-+34+962 849 309 (Compartido) UNIVERSIDAD POLITÉCNICA DE VALENCIA-CAMPUS DE GANDIA Calle Pararaninfo, 1, CP. 46730, Grao de Gandia (Valencia), SPAIN ========================================================================
- [AVTCORE] Possible Additional functionalities for… Fernando Boronat Seguí
- [AVTCORE] Possible Additional functionalities for… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Kevin Gross
- Re: [AVTCORE] Possible Additional functionalities… Qin Wu
- Re: [AVTCORE] Possible Additional functionalities… Magnus Westerlund
- Re: [AVTCORE] Possible Additional functionalities… Qin Wu
- Re: [AVTCORE] Possible Additional functionalities… Kevin Gross
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Qin Wu
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Kevin Gross
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí
- Re: [AVTCORE] Possible Additional functionalities… Magnus Westerlund
- Re: [AVTCORE] Possible Additional functionalities… Fernando Boronat Seguí