[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

 

  _____