Re: [payload] Latest MELP RTP Payload draft (UNCLASSIFIED)
"Victor Demjanenko, Ph.D." <victor.demjanenko@vocal.com> Fri, 19 August 2016 18:42 UTC
Return-Path: <victor.demjanenko@vocal.com>
X-Original-To: payload@ietfa.amsl.com
Delivered-To: payload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D9ED12D92B for <payload@ietfa.amsl.com>; Fri, 19 Aug 2016 11:42:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.9
X-Spam-Level:
X-Spam-Status: No, score=-0.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MSGID_MULTIPLE_AT=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=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 jX9wPlTSUw40 for <payload@ietfa.amsl.com>; Fri, 19 Aug 2016 11:42:22 -0700 (PDT)
Received: from cuda.olm1.com (cuda.olm1.com [72.236.255.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89FD512DA86 for <payload@ietf.org>; Fri, 19 Aug 2016 11:42:21 -0700 (PDT)
X-ASG-Debug-ID: 1471632139-092fd35b162c770001-U2jSCT
Received: from host105.olm1.com (host105.olm1.com [72.236.255.15]) by cuda.olm1.com with ESMTP id M7HeXKHxxcjxHxr3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 19 Aug 2016 14:42:19 -0400 (EDT)
X-Barracuda-Envelope-From: victor.demjanenko@vocal.com
X-Barracuda-Apparent-Source-IP: 72.236.255.15
Received: from ClintonLT (rrcs-72-43-202-98.nys.biz.rr.com [72.43.202.98]) by host105.olm1.com (Postfix) with ESMTPSA id 3DC12B4357D; Fri, 19 Aug 2016 14:42:19 -0400 (EDT)
From: "Victor Demjanenko, Ph.D." <victor.demjanenko@vocal.com>
To: "'Lee, John'" <John.Lee@dynetics.com>, payload@ietf.org, draft-ietf-payload-melpe@ietf.org
References: <B10392C77B29E944883B3C56F3C9C033B80EE3FD@Pele.in.dynetics.com>, <133601d1f7eb$fdd624a0$f9826de0$@demjanenko@vocal.com> <20160818053154.7073877.99795.1928@dynetics.com>
In-Reply-To: <20160818053154.7073877.99795.1928@dynetics.com>
Date: Fri, 19 Aug 2016 14:42:06 -0400
X-ASG-Orig-Subj: RE: Latest MELP RTP Payload draft (UNCLASSIFIED)
Message-ID: <00b801d1fa49$63531180$29f93480$@demjanenko>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_00B9_01D1FA27.DC417180"
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AdHuekjWp8YznbmBRxKbRxxuIWjH4gJcN/4QAEmphcsATcD8AA==
Content-Language: en-us
X-Barracuda-Connect: host105.olm1.com[72.236.255.15]
X-Barracuda-Start-Time: 1471632139
X-Barracuda-Encrypted: ECDHE-RSA-AES256-GCM-SHA384
X-Barracuda-URL: https://72.236.255.32:443/cgi-mod/mark.cgi
X-Virus-Scanned: by bsmtpd at olm1.com
X-Barracuda-BRTS-Status: 1
X-Barracuda-Spam-Score: 0.01
X-Barracuda-Spam-Status: No, SCORE=0.01 using global scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=5.0 tests=HTML_MESSAGE, MSGID_MULTIPLE_AT
X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.32157 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- 0.01 MSGID_MULTIPLE_AT Message-ID contains multiple '@' characters 0.00 HTML_MESSAGE BODY: HTML included in message
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/S7P1AXifDDIhONBNnT8Hc_nexMs>
Cc: "'SHERIDAN, LARRY M (Michael) JR CTR USARMY RDECOM AMRDEC (US)'" <larry.m.sheridan.ctr@mail.mil>, "'Dave Satterlee (Vocal)'" <Dave.Satterlee@vocal.com>
Subject: Re: [payload] Latest MELP RTP Payload draft (UNCLASSIFIED)
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Audio/Video Transport Payloads working group discussion list <payload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/payload>, <mailto:payload-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/payload/>
List-Post: <mailto:payload@ietf.org>
List-Help: <mailto:payload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/payload>, <mailto:payload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 19 Aug 2016 18:42:24 -0000
Hi John, Thank you for your comments and confirming this special case. As you may have seen a revised draft (03) has been posted. I think this should be close to final. We are awaiting Roni and Ali to advise on the next step(s). Thanks to everyone on this mailing group for your support and comments. Victor & David From: Lee, John [mailto:John.Lee@dynetics.com] Sent: Thursday, August 18, 2016 1:32 AM To: Victor Demjanenko, Ph.D. Cc: victord@vocal.com; daves@vocal.com; SHERIDAN, LARRY M (Michael) JR CTR USARMY RDECOM AMRDEC (US) Subject: RE: Latest MELP RTP Payload draft (UNCLASSIFIED) Victor, I don't believe it would break anything, but it might introduce a new edge case that would need to be considered by our vendors. I don't think we can speak for them. Worst case scenario, we end up levying a separate requirement on our systems prohibiting something that is permitted (but not required) in the RFC to ensure interoperability. So, I do not think there is a problem with proceeding if that behavior is desired. From: Victor Demjanenko, Ph.D. Sent: Tuesday, August 16, 2016 8:28 AM To: Lee, John Cc: victord@vocal.com; daves@vocal.com Subject: [EXTERNAL] RE: Latest MELP RTP Payload draft (UNCLASSIFIED) Hi John, You have always been quick with responses and appreciate that. We have one item that we would like your opinion on before we change/clarify in our next draft. It has been pointed out that according to our spec the MELP RTP packet may contain no speech coder frame and no comfort noise frame. We can either prohibit this or we can permit it. One possibly useful permission is to us an empty frame to indicate an otherwise idle receiver. This would indicate the absence of a radio receive signal. One can argue that this is the role of RTP keep-alive but the keep-alive mechanism could be from a different layer in some implementation? Do you have any comments or preference? Will be break anything if we allow an empty MELP RTP packet? A quick response would be helpful as we are about to post a revised draft. Thanks, Victor From: Lee, John [mailto:John.Lee@dynetics.com] Sent: Monday, August 8, 2016 5:24 PM To: payload@ietf.org; draft-ietf-payload-melpe@ietf.org Cc: victord@vocal.com; daves@vocal.com Subject: Latest MELP RTP Payload draft (UNCLASSIFIED) Dave and Victor, I concur with the latest draft. Thanks, John Lee JSIL Cert Center (O) 256-955-8969 (BB) 256-698-8985 _____ The information contained in this message, and any attachments, may contain privileged and/or proprietary information that is intended solely for the person or entity to which it is addressed. Moreover, it may contain export restricted technical data controlled by Export Administration Regulations (EAR) or the International Traffic in Arms Regulations (ITAR). Any review, retransmission, dissemination, or re-export to foreign or domestic entities by anyone other than the intended recipient in accordance with EAR and/or ITAR regulations is prohibited.
- Re: [payload] Latest MELP RTP Payload draft (UNCL… Victor Demjanenko, Ph.D.
- [payload] Fwd: Latest MELP RTP Payload draft (UNC… Dave Satterlee (Vocal)