[AVT] Comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-01
Roni Even <Even.roni@huawei.com> Tue, 04 May 2010 15:31 UTC
Return-Path: <Even.roni@huawei.com>
X-Original-To: avt@core3.amsl.com
Delivered-To: avt@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F1AD3A6C34 for <avt@core3.amsl.com>; Tue, 4 May 2010 08:31:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.106
X-Spam-Level: **
X-Spam-Status: No, score=2.106 tagged_above=-999 required=5 tests=[BAYES_50=0.001, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WoE3sgZb6soB for <avt@core3.amsl.com>; Tue, 4 May 2010 08:31:58 -0700 (PDT)
Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id 10E503A694D for <avt@ietf.org>; Tue, 4 May 2010 08:31:58 -0700 (PDT)
Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1W008J0J4JKT@szxga04-in.huawei.com> for avt@ietf.org; Tue, 04 May 2010 23:31:32 +0800 (CST)
Received: from huawei.com ([172.24.2.119]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0L1W0053SJ4GYQ@szxga04-in.huawei.com> for avt@ietf.org; Tue, 04 May 2010 23:31:30 +0800 (CST)
Received: from windows8d787f9 (bzq-79-178-51-57.red.bezeqint.net [79.178.51.57]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0L1W00B2OJ4A00@szxml02-in.huawei.com>; Tue, 04 May 2010 23:31:28 +0800 (CST)
Date: Tue, 04 May 2010 18:30:12 +0300
From: Roni Even <Even.roni@huawei.com>
To: 'IETF AVT WG' <avt@ietf.org>
Message-id: <014101caeb9e$b7181790$254846b0$%roni@huawei.com>
MIME-version: 1.0
X-Mailer: Microsoft Office Outlook 12.0
Content-type: multipart/alternative; boundary="Boundary_(ID_aiuLJDbmZ3nqhEZe+BQGLg)"
Content-language: en-us
Thread-index: AcrrnoT/t6v9a+TWSWuuFKb3DmmfaQ==
Cc: 'Colin Perkins' <csp@csperkins.org>, "'Bill Ver Steeg (versteb)'" <versteb@cisco.com>
Subject: [AVT] Comments on draft-ietf-avt-ports-for-ucast-mcast-rtp-01
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Audio/Video Transport Working Group <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 04 May 2010 15:31:59 -0000
Hi, I reviewed the draft. I have Colin in the cc list since I am looking for his feedback on the first two item 1. Section 4 present the proposed solution is to send two RTCP feedback messages [RFC4585] but we should remember that the RTP session will start later. The first messages MUST be a compound RTCP message but according to RFC 4585 they can be minimal compound RTCP messages (One SR or RR and one SDES with only the CNAME and the FB message). Still just to be sure that we can use the RTCP feedback in this mode and define how to populate the fields. 2. In section 3.4 KA recommendation we can look at RTCP timing saying that "the fixed minimum reporting interval MAY be scaled to 360 divided by the session bandwidth in kilobits/second. This minimum is smaller than 5 seconds for bandwidths greater than 72 kb/s" and for video this is usually the case. As for other cases I assume that since the SDP defines the BW for the media and when there is no media sent using it for higher RTCP rate is probably OK. Note that the RTCP packet will be small and it is a unicast session. Other 3. In section 1 "This solution allows receivers to choose their desired RTP and RTCP receive ports for every unicast session when they are running RTP applications using both unicast and multicast services." Maybe add and there is no offer answer exchange. I am not sure we want to endorse this solution for cases were offer answer is possible. 4. I saw Tom's comment on c1 but is also appears in section 3 "The public ports of the client are denoted by c1' and c2'." Roni Even As individual _____