Re: [AVTCORE] Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)
<aurelien.sollaud@orange.com> Wed, 17 December 2014 09:56 UTC
Return-Path: <aurelien.sollaud@orange.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8D811A8751 for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 01:56:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.599
X-Spam-Level:
X-Spam-Status: No, score=-1.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a2FWwcUhTnE for <avt@ietfa.amsl.com>; Wed, 17 Dec 2014 01:56:55 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C2EE1A86FA for <avt@ietf.org>; Wed, 17 Dec 2014 01:56:54 -0800 (PST)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 8FCB118C486; Wed, 17 Dec 2014 10:56:52 +0100 (CET)
Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 755AD2380D3; Wed, 17 Dec 2014 10:56:52 +0100 (CET)
Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0210.002; Wed, 17 Dec 2014 10:56:52 +0100
From: aurelien.sollaud@orange.com
To: Julius Friedman <juliusfriedman@gmail.com>
Thread-Topic: Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)
Thread-Index: AQHQGICWfFab9a8WMUGtVKfmQZKc/ZyTjKzQ
Date: Wed, 17 Dec 2014 09:56:51 +0000
Message-ID: <3572_1418810212_54915364_3572_14092_1_719DF432C01EA6418EBA5185063A1661140A9765@PEXCVZYM12.corporate.adroot.infra.ftgroup>
References: <CACFvNHXwCPVwg7RTqoQ-aR=YomiJqn-BW3B8+E8FzLJRcUFq4Q@mail.gmail.com>
In-Reply-To: <CACFvNHXwCPVwg7RTqoQ-aR=YomiJqn-BW3B8+E8FzLJRcUFq4Q@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.197.38.6]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2014.12.17.70030
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/CSv5s0xbR2vCW8X5ilTX2AauqOo
X-Mailman-Approved-At: Wed, 17 Dec 2014 10:03:39 -0800
Cc: "avt@ietf.org" <avt@ietf.org>
Subject: Re: [AVTCORE] Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
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: Wed, 17 Dec 2014 09:56:57 -0000
Hello > Please indicate why this is necessary if I am multiplexing and rtcp is enabled. My nat will not timeout. Exactly. There is no trick here, the only RECOMMENDED method in the RFC 6263 is RTP-RTCP multiplexing, where regular RTCP traffic will maintain the NAT binding alive. Aurelien De : Julius Friedman [mailto:juliusfriedman@gmail.com] Envoyé : lundi 15 décembre 2014 17:03 À : SOLLAUD Aurélien IMT/OLN Cc : avt@ietf.org Objet : RE: Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263) Thanks for the update. I see ice is excluded but if stun etc was also excluded then it should be indicated in the same place. Please indicate why this is necessary if I am multiplexing and rtcp is enabled. My nat will not timeout. If I am a translator version 0 will not be ignored. Senders octet count will be wrong unless the packet is skipped. All of my previous points still apply and sending a header only repeated would be more complaint no matter the case of use. I will follow errata if I need to but first the points need addressing. Thanks. On Dec 15, 2014 10:54 AM, <aurelien.sollaud@orange.com> wrote: > > Hello > > > > I don’t know what version of the draft you are referring to, but this document was published as RFC 6263 in June 2011. So you may check this final release. > > > > In particular the Introduction section states that ICE and STUN are out of scope. > > > > Aurelien > > > > De : Julius Friedman [mailto:juliusfriedman@gmail.com] > Envoyé : lundi 15 décembre 2014 16:37 > À : draft-ietf-avt-app-rtp-keepalive@tools.ietf.org > Objet : Mail regarding draft-ietf-avt-app-rtp-keepalive > > > > Hello guys, > > Based on the fact this draft cites keep alive are not recommended I would to chime in. > > I would also like to indicate this process causes detected loss in the sender report unless the keep alive packet is not counted. > > Since rtcp is enabled what is timing out? The port mapping for the rtp port? What if im multiplexing on the same port then how does this matter? > > Specifically for non multiplexing why wouldn't ice or stun have their own methods of keeping the port mapping alive? And why should a rtp client have to handle this? > > This seems like a ice or stun change more than rtp. > > Furthermore couldn't you just send a header only packet with the last sequence number etc which should also be Ignored and in a more complaint way. > > Translators may not ignore version 0 packets or dynamic payload types undefined in the sdp. > > Sincerely, > Julius Richard Friedman > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
- Re: [AVTCORE] Mail regarding draft-ietf-avt-app-r… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avt-app-r… Julius Friedman
- Re: [AVTCORE] Mail regarding draft-ietf-avt-app-r… aurelien.sollaud
- Re: [AVTCORE] Mail regarding draft-ietf-avt-app-r… aurelien.sollaud