Re: [AVTCORE] Mail regarding draft-ietf-avt-app-rtp-keepalive (rfc6263)
Julius Friedman <juliusfriedman@gmail.com> Mon, 15 December 2014 16:03 UTC
Return-Path: <juliusfriedman@gmail.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 1470F1A7D84 for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
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 Sg03KHB6cbcJ for <avt@ietfa.amsl.com>; Mon, 15 Dec 2014 08:03:35 -0800 (PST)
Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 530A01A710D for <avt@ietf.org>; Mon, 15 Dec 2014 08:02:52 -0800 (PST)
Received: by mail-pa0-f48.google.com with SMTP id rd3so12081786pab.21 for <avt@ietf.org>; Mon, 15 Dec 2014 08:02:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=O2QEvmq2p3fNCPQD+UiTXdsejVMH3Pgb/bwbM2yY9Kk=; b=PEg+BqYuSTIgcJ+yGy0Lfp3DBCR4HvNjz/tzhXMF8bTUxiKZ+5Dfa6RKflkIPiBo82 HMIdvfjYGJMnI8h8upq+Ji+Nl6NQWDB73+4NQD4f1jmn3gIRVeYhM8ulByoGS2Z0o/wu ENgzgI9t2nJkmQuTmZNG+vJ/SgxcY73Bucsjq37ywPhI71qHDb07ZQSvmBFmq16K9y9R 71kyDRUNPqXfaN0P3orwsvyHrh63gSzy9f947In1aPv1O9SwgaJKankak7uUBs9mxbg9 MM8dYnlqfDU23mB7t0lwaxPuTZBfXn8MXWQYnIzX6nalxz0f7WxKF7abXFV76Lb6Wndb uJoA==
MIME-Version: 1.0
X-Received: by 10.68.236.67 with SMTP id us3mr31964013pbc.121.1418659371312; Mon, 15 Dec 2014 08:02:51 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 08:02:51 -0800 (PST)
Received: by 10.70.117.99 with HTTP; Mon, 15 Dec 2014 08:02:51 -0800 (PST)
Date: Mon, 15 Dec 2014 11:02:51 -0500
Message-ID: <CACFvNHXwCPVwg7RTqoQ-aR=YomiJqn-BW3B8+E8FzLJRcUFq4Q@mail.gmail.com>
From: Julius Friedman <juliusfriedman@gmail.com>
To: aurelien.sollaud@orange.com
Content-Type: multipart/alternative; boundary="047d7b2e11b1e26f3d050a435f8e"
Archived-At: http://mailarchive.ietf.org/arch/msg/avt/b4OMYN6dfNIYBOkKh1aiCe9VnEw
Cc: 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: Mon, 15 Dec 2014 16:03:38 -0000
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.
- 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