Re: [AVT] draft-ietf-avt-app-rtp-keepalive

Cullen Jennings <fluffy@cisco.com> Fri, 24 September 2010 16:43 UTC

Return-Path: <fluffy@cisco.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 8457D3A687F for <avt@core3.amsl.com>; Fri, 24 Sep 2010 09:43:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.498
X-Spam-Level:
X-Spam-Status: No, score=-110.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 cUlALzxxu5+c for <avt@core3.amsl.com>; Fri, 24 Sep 2010 09:43:00 -0700 (PDT)
Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 47B533A69A2 for <avt@ietf.org>; Fri, 24 Sep 2010 09:43:00 -0700 (PDT)
Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAD5xnEyrR7Ht/2dsb2JhbACiQnGqSpwohUMEhFA2hTSCfg
X-IronPort-AV: E=Sophos;i="4.57,230,1283731200"; d="scan'208";a="191579948"
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 24 Sep 2010 16:43:32 +0000
Received: from [192.168.4.3] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o8OGhVSM009093; Fri, 24 Sep 2010 16:43:31 GMT
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <AANLkTi=UztSubYNJXYz1nqt_8dMCKRvgxbh3zW5YrDn=@mail.gmail.com>
Date: Fri, 24 Sep 2010 10:43:30 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <EC00F853-D3D0-4AD5-9391-C1679F4CC668@cisco.com>
References: <D091CEDE-8109-48BB-914B-35BF7C774507@cisco.com> <30547_1266831534_4B8250AE_30547_739_12_51D96D3F30495C4BAF8D190702F9B933B7DD9A@ftrdmel1> <23AD963C-0128-45BD-8C71-D1D5C6197FD2@cisco.com> <AANLkTineARJ-jZTwCSJk=xV+G69mP+Y7KMtHfhTAw3zb@mail.gmail.com> <AANLkTimnmmxExjeTk5jvmvuZ4c-7iYU21-uJpvza=TTY@mail.gmail.com> <1427F337-AA76-4AB0-B77F-3E038977FCC1@cisco.com> <AANLkTi=UztSubYNJXYz1nqt_8dMCKRvgxbh3zW5YrDn=@mail.gmail.com>
To: Xavier Marjou <xavier.marjou@orange-ftgroup.com>
X-Mailer: Apple Mail (2.1081)
Cc: IETF AVT WG <avt@ietf.org>
Subject: Re: [AVT] draft-ietf-avt-app-rtp-keepalive
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: Fri, 24 Sep 2010 16:43:01 -0000

Thanks. Sorry I missed that when I reviewed the minutes. When I read the minutes, I did not realize it meant the draft would be useless for places where RTCP mux does not work. 


On Sep 24, 2010, at 8:58 AM, Xavier Marjou wrote:

> Extracted from http://tools.ietf.org/wg/avt/minutes?item=minutes77.html , here is the text I was referring to:
> 
> 
>           Comment 2
>           ---------
>           The proposed resolution is to remove the recommendation for a
>           fallback solution. Robert Sparks accepted this proposal.
>           
>           ...
>           
>           Keith Drage summed up: the proposal to remove the recommendation
>           while retaining documentation of the alternative and associated
>           drawbacks is accepted. The author should send a text proposal to the
>           list and we would go on from there.
> 
> 
> 
> On Fri, Sep 24, 2010 at 3:16 PM, Cullen Jennings <fluffy@cisco.com> wrote:
> 
> Can you point me to the minutes from the IETF 77 discussion where this consensus was reached ?
> 
> 
> On Sep 24, 2010, at 6:50 AM, Xavier Marjou wrote:
> 
> > So I meant:
> > "The discussion during the next IETF (IETF-77) resulted in recommending only RFC5761 and "only" documenting other mechanisms."
> >
> > On Fri, Sep 24, 2010 at 2:49 PM, Xavier Marjou <xavier.marjou@orange-ftgroup.com> wrote:
> > I have just posted an updated version of the draft with a TCP timeout of 7200 seconds and no indication about DCCP timeout.
> > This is inline with you first two comment below, as well as with the feedback from the BEHAVE WG.
> >
> > For RTCP, the original idea was indeed to make recommendations when RTCP is not used. This raised a lot of concerns during the IESG review. The discussion during the newt IETF (IETF-77) resulted in recommending only RFC5761 and "only" recommending other mechanisms. This was reflected in version -08 and was not changed in today's -09 version.
> >
> > Cheers,
> > Xavier
> >
> >
> >
> > On Fri, Sep 17, 2010 at 10:07 PM, Cullen Jennings <fluffy@cisco.com> wrote:
> >
> > With regrades to the a few of the discuss on the 08 version of this draft
> >
> > For the TCP timeout, I recommend 7200 seconds. This matches the TCP keep alive used by default by many OS and will work well with the case I am aware of.
> >
> > For the DCCP timeout, I would suggest we have pretty much zero experience with firewalls and NATs with DCCP support so it would be premature to recommend anything here and we should make no recommendation for DCCP.
> >
> > For the topic or RTCP being out of scope. I would point out RTCP has existing ways of regularly sending packets covered by the RTCP spec and this specification makes no changes to theses.  I'm not disagreeing with Magnus, just saying that the RTCP is not a problem, it's the RTP we have problems with.
> >
> > I note that the WG had recommendation for what to do when the RTCP could not be used but the IESG has removed theses. This seems critical given the fact that a larger percentage of the deployed equipment does support RTCP. I think the specification needs to add back in what to do when there is not RTCP support or it needs to be brought back to the WG for discussion.
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> >
> >
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 


Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html