Re: [payload] Comment on RTP Payload Format for the TETRA Audio Codec

"Roni Even (A)" <roni.even@huawei.com> Thu, 03 May 2018 07:46 UTC

Return-Path: <roni.even@huawei.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 C00C1126CB6 for <payload@ietfa.amsl.com>; Thu, 3 May 2018 00:46:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.226
X-Spam-Level:
X-Spam-Status: No, score=-2.226 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DEAR_SOMETHING=1.973, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, 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 t1ihMl-g2OgT for <payload@ietfa.amsl.com>; Thu, 3 May 2018 00:46:47 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 136FA126C26 for <payload@ietf.org>; Thu, 3 May 2018 00:46:47 -0700 (PDT)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 1970EE0BD3B6F for <payload@ietf.org>; Thu, 3 May 2018 08:46:43 +0100 (IST)
Received: from DGGEMM402-HUB.china.huawei.com (10.3.20.210) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.382.0; Thu, 3 May 2018 08:46:44 +0100
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM402-HUB.china.huawei.com ([10.3.20.210]) with mapi id 14.03.0361.001; Thu, 3 May 2018 15:46:22 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: Juergen Machui <Juergen.Machui@accellonet.com>, "payload@ietf.org" <payload@ietf.org>
Thread-Topic: Comment on RTP Payload Format for the TETRA Audio Codec
Thread-Index: AdPip7iD5IrbfUgRSPOgqQFc6TcVNwACpBxg
Date: Thu, 3 May 2018 07:46:22 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD87F577@DGGEMM506-MBS.china.huawei.com>
References: <CEDD4124F5F4AC4F85CFF86AB45D3C3C06E28AE3746F@srv-sbs2008>
In-Reply-To: <CEDD4124F5F4AC4F85CFF86AB45D3C3C06E28AE3746F@srv-sbs2008>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.72]
Content-Type: multipart/related; boundary="_004_6E58094ECC8D8344914996DAD28F1CCD87F577DGGEMM506MBSchina_"; type="multipart/alternative"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/payload/MyCuPghgcwFfI42TbdYQGKpVlzY>
Subject: Re: [payload] Comment on RTP Payload Format for the TETRA Audio Codec
X-BeenThere: payload@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 03 May 2018 07:46:50 -0000

Jurgen thanks,
Can you also verify that section 4 and 5 of the draft defining the  payload format and payload header cover your use case
Thanks
Roni Even
Payload WG co-chair

From: payload [mailto:payload-bounces@ietf.org] On Behalf Of Juergen Machui
Sent: Thursday, May 03, 2018 9:27 AM
To: payload@ietf.org
Subject: [payload] Comment on RTP Payload Format for the TETRA Audio Codec

Dear sir,

please allow me to comment on the
Internet-Draft RTP Payload Format for TETRA Audio codec April 2018.

The international community strives to establish standards for the interfacing of radio systems an control centers.
This need is growing as control centers do typically communicate via more than one radio media.
In this context we encounter Tetra systems in most control center projects,
unfortunately using different interface definitions for both speech transport and signaling purposes.

This fact represents an enormous cost factor to manufacturers and users of control center technology.
Tetra interfaces move to pure IP definitions and there is a real danger that the variety if interface definitions will grow further.
A well established standard for voice transport can help to reduce the impact of this trend.

The present draft seems to me a practical way to handle this issue.
I strongly recommend to adopt it.

Best regards

Jürgen Machui


[cid:image001.png@01D1B806.B3085F80]

accellonet GmbH, Geschäftsführer
Nadistrasse 35, 80809 München

Tel:     +49 (0) 89 3506 2592
Mobil: +49 (0) 175 220 3864

www.accellonet.com<http://www.accellonet.com/>
Amtsgericht Memmingen, HRB 12995, Ust-IdNr.: DE253847299
Geschäftsführer: Jürgen Machui, Felix Wiederspahn

Der Inhalt dieser E-Mail ist ausschließlich für den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe des Inhalts dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen.

This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or organization to whom they are addressed. Should you not be the intended addressee of this e-mail or his or her representative, please note that publication, replication of the contents by any means or further communication of the content is not permissible. Should you have received this e-mail in error, please notify the sender.