Re: [payload] Comments for RTP Payload Format for the TETRA Audio Codec
Andreas Ahland <Andreas.Ahland@selectric.de> Mon, 29 October 2018 10:04 UTC
Return-Path: <andreas.ahland@selectric.de>
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 5EAE3130E42
for <payload@ietfa.amsl.com>; Mon, 29 Oct 2018 03:04:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.889
X-Spam-Level:
X-Spam-Status: No, score=-1.889 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001,
SPF_PASS=-0.001, T_FILL_THIS_FORM_SHORT=0.01, URIBL_BLOCKED=0.001]
autolearn=ham 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 qsX-lKWzpBEm for <payload@ietfa.amsl.com>;
Mon, 29 Oct 2018 03:04:22 -0700 (PDT)
Received: from mail.selectric.de (mail.selectric.de [62.214.68.130])
(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 D3286130E3A
for <payload@ietf.org>; Mon, 29 Oct 2018 03:04:21 -0700 (PDT)
Received: from [172.27.0.206] (port=30005 helo=mail.selectric.de)
by mail.selectric.de with esmtps (TLSv1:DHE-RSA-AES256-SHA:256)
(Exim 4.82_1-5b7a7c0-XX)
(envelope-from <Andreas.Ahland@selectric.de>) id 1gH4PB-0003BB-30
for payload@ietf.org; Mon, 29 Oct 2018 11:04:17 +0100
Received: from SNSMS-MAIL.SELECTRIC.local (172.27.0.230) by
Exchange.SELECTRIC.local (172.27.0.206) with Microsoft SMTP Server (TLS) id
14.3.352.0; Mon, 29 Oct 2018 11:04:17 +0100
Received: from SNSMS-MAIL.SELECTRIC.local (172.27.0.230) by
SNSMS-MAIL.SELECTRIC.local (172.27.0.230) with Microsoft SMTP Server
(version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id
15.1.1261.35; Mon, 29 Oct 2018 11:04:16 +0100
Received: from SNSMS-MAIL.SELECTRIC.local ([fe80::29b2:bc57:84d:2a76]) by
SNSMS-MAIL.SELECTRIC.local ([fe80::29b2:bc57:84d:2a76%3]) with mapi id
15.01.1261.035; Mon, 29 Oct 2018 11:04:16 +0100
From: Andreas Ahland <Andreas.Ahland@selectric.de>
To: REISENBAUER Andreas <Andreas.Reisenbauer@frequentis.com>,
"payload@ietf.org" <payload@ietf.org>
Thread-Topic: Comments for RTP Payload Format for the TETRA Audio Codec
Thread-Index: AdQEqoxULyfORiHgTUOj3c7djfCvqhqSrrRAAB5O8HA=
Date: Mon, 29 Oct 2018 10:04:16 +0000
Message-ID: <dc84984838bb4d8089455824f23fbdf7@selectric.de>
References: <241B4017E078564291873F7B3BC19822079DFB1C@exchange.SELECTRIC.local>
<8d19e2bdf6d747438c6a1e5b6c191624@frequentis.com>
In-Reply-To: <8d19e2bdf6d747438c6a1e5b6c191624@frequentis.com>
Accept-Language: de-DE, en-US
Content-Language: de-DE
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [172.27.2.176]
x-exclaimer-md-config: 827ec8a1-e582-4c5c-a2bc-191fa2f2bce5
x-exclaimer-md-bifurcation-instance: 0
x-exclaimer-md-search-key: j0V9y3jYLkScN5N6DzrTTw==
Content-Type: multipart/related;
boundary="_005_dc84984838bb4d8089455824f23fbdf7selectricde_";
type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/YGq9Rh7Ap9Ma3ds3hPl8u0XXa0A>
Subject: Re: [payload] Comments for RTP Payload Format for the TETRA Audio
Codec
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.29
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: Mon, 29 Oct 2018 10:04:26 -0000
Hi Andreas, thank you for your comments, I like your solution. Mit freundlichen Grüßen / Best regards Dr.-Ing. Andreas Ahland SELECTRIC Nachrichten-Systeme GmbH Leitung Technik / CTO Haferlandweg 18 48155 Münster tel ) +49 251 6183-196 fax ) +49 251 6183-197 [Anmeldung Newsletter]<https://www.selectric.de/shop/customer/account/create/> Sitz der Gesellschaft (Company Premises): Muenster | Registergericht (Register Court): Amtsgericht Muenster | HRB-Nr. 1264 Geschaeftsfuehrer (General Managers): Michael Heussner, Hendrik Pieper Von: REISENBAUER Andreas <Andreas.Reisenbauer@frequentis.com> Gesendet: Sonntag, 28. Oktober 2018 20:42 An: Andreas Ahland <Andreas.Ahland@selectric.de>de>; payload@ietf.org Betreff: RE: Comments for RTP Payload Format for the TETRA Audio Codec Hi Andreas, Sorry for the late response to your valuable review comments… I am currently working on the next version of the draft and would like to address your comments in that way: Chapter 4.3.3 I would like to add this note at the end of the chapter describing the “R” Bits (audio signal relevance): NOTE: Receiver **SHOULD** consider stolen or erroneous blocks as not available for audio decoding as indicated by control bits independent of audio signal relevance bits. This states it is the receiver’s responsibility to produce this overall relevance indicator (I suspect especially the combination with the error indication could be unambiguous for the sender) Chapter 6 If I got this chapter right it is more talking about prevention of packet loss by controlling congestion. Your approach more explains receiver’s strategy to cope with packet loss and blocks indicating errors which is not directly addressed by “congestion control”. So if you are not too angry, I would not change this chapter. Does this approach address your comments? All the best Andreas From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Andreas Ahland Sent: Freitag, 15. Juni 2018 15:45 To: payload@ietf.org<mailto:payload@ietf.org> Subject: [payload] Comments for RTP Payload Format for the TETRA Audio Codec Review Comments for RTP Payload Format for the TETRA Audio Codec draft-ietf-payload-tetra-00 2018-06-15 by Andreas Ahland andreas.ahland@selectric.de<mailto:andreas.ahland@selectric.de> I think it is a good description of how to transport tetra encoded speech over IP. Review Comments: Chapter 4.3.3. CTRL: Control bit(5 bits) vs 4.3.6. R: Audio Signal Relevance: Do control bits need evaluation or is this already handled in Audio Signal Relevance? If not, it should be noted that “stolen” marks a Tetra block as unusable for audio decoding. When encoding Tetra to RTP, all control bits should be set to 0 to announce correct audio data. Chapter „6. Congestion Control Considerations“ could mention that packet losses have the same effect for audio decoding as if some blocks are marked defective or stolen and thus are not available for audio decoding. It could be noted that Tetra does block encoding and decoding and that each of the 137 bits form a complete block which can be decoded by itself. Mit freundlichen Grüßen / Best regards Dr.-Ing. Andreas Ahland SELECTRIC Nachrichten-Systeme GmbH Leitung Technik / CTO Haferlandweg 18 48155 Münster tel ) +49 251 6183-196 fax ) +49 251 6183-197 [Anmeldung Newsletter]<https://www.selectric.de/shop/customer/account/create/> Sitz der Gesellschaft (Company Premises): Muenster | Registergericht (Register Court): Amtsgericht Muenster | HRB-Nr. 1264 Geschaeftsfuehrer (General Managers): Michael Heussner, Hendrik Pieper
- [payload] Comments for RTP Payload Format for the… Andreas Ahland
- Re: [payload] Comments for RTP Payload Format for… REISENBAUER Andreas
- Re: [payload] Comments for RTP Payload Format for… Andreas Ahland