Re: [AVTCORE] [payload] I-D Action: draft-ietf-payload-tetra-03.txt

Hi Roni,

The big problem I have with this one is that in TETRA there are only two standardized interfaces, the Air Interface (TETRA AI) and the Inter-System Interface (TETRA ISI). Within a TETRA SwMI all manufacturers are free to use whatever proprietary wire formats and transport technology they see fit. Now what the draft-ietf-payload-tetra is doing is specifying a part of a third interface (mainly towards control rooms if I've understood correctly). The draft is based on a premise that all TETRA SwMIs are E1-based and use the historical TETRA ISI audio formats FSTE and OSTE. Neither is true.

When we specified the audio/TETRA_ACELP in ETSI TCCE WG3 and registered it with IANA we deliberately said it could be used by any "Devices or applications that send or receive TETRA ACELP encoded audio over RTP/IP", not only TETRA ISI. Now I find it rather unfortunate that we are seeing fragmentation of the wire formats. There will be yet another format to carry TETRA audio between TETRA systems and Mission Critical Push-To-Talk (MCPTT) terminals over the Inter-Working Function (IWF). The reason for this is that due to LTE SPS (Semi-Persistent Scheduling) not allowing the 30ms or 60ms TETRA timings. 

I have a number of comments to the text and I am very sorry that Andreas' mail seems to have gotten buried in my inbox while I was on vacation in the summer. I'll just quickly answer the Andreas' points about the Generic Speech Format being confusing.

The call reference is an optional field. If it is not applicable to your needs, you leave it out.

Traffic type is very much unnecessary, but could not be removed due to  backwards compatibility reasons.

Frame number is still relevant. Reason for having a frame number is the AI behavior. When a frame is sent from the AI to wire, the framing rate of 170/3 ms is preserved. AI receives (or sends) 18 frames in 1020ms, of which every 18th frame is signaling/sync. On the wire there is a gap in place of the 18th frame. The receiver needs to know where the gap is in order to avoid the gap in playback. If a voice frame is not originated through the AI, framing rate of 60ms may be used (exactly 17 frames in 1020ms with no gaps). 


Best regards,
Antti

-----Original Message-----
From: Roni Even (A) [mailto:[email protected]] 
Sent: Thursday, December 12, 2019 3:26 PM
To: REISENBAUER Andreas; Tuominen, Antti; [email protected]; [email protected]
Cc: Klaus-Peter Höhnsch ([email protected]); Brandhuber Udo ([email protected]); Joachim Hagedorn ([email protected])
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

Hi Andreas,
Before sending the document to publication I would like to clarify the difference between this document and the ETSI one. My understanding is that the difference is in the payload header as specified in section 4.

I think it is time to send the document to publication but since it has been sometime since the last WGLC I will have a short WGLC before publication  request

Let me know if this is OK with you
Roni Even 
AVTcore co-chair

> -----Original Message-----
> From: REISENBAUER Andreas
> [mailto:[email protected]]
> Sent: Friday, July 26, 2019 10:27 PM
> To: Tuominen, Antti; [email protected]; [email protected];
> Roni Even (A)
> Cc: Klaus-Peter Höhnsch ([email protected]);
> Brandhuber Udo ([email protected]); Joachim Hagedorn
> ([email protected])
> Subject: FW: [payload] I-D Action: draft-ietf-payload-tetra-03.txt
> 
> Hi Antti, Roni, payload working group
> 
> I did an update of the draft-ietf-tetra. Thanks a lot for your comments Antti -
> according your feedback we changed references from the historical ETSI TS
> 100 392-3-6 to ETSI TS 100 392-3-8. Indeed we did not change the control bit
> structure. As it is well defined in our draft-ietf-payload-tetra we do not need
> a bit equivalency to any ETSI standard.
> 
> According Antti's comment regarding, it seems a bit superfluous to specify
> another slightly different format:
> There is one single specification (ETSI TS 100 392-3-8 ) addressing both circuit
> switched lines as well as for transport via RTP and it specifically addresses the
> application of a TETRA Intersystem Interface rather than a generic TETRA
> audio payload for RTP. Because of this fact the cited standard is little more
> TDM-stylish rather than pure RTP. There are attributes included as part of the
> payload which are either superfluous or at least confusing for pure RTP
> communications (e.g. call reference, traffic type which identifies codec,
> frame number – supposed to handle slipped frames in SDH). For this reasons
> we (the authors) of this draft think it is worth to specify a pure IP way to
> propagate TETRA payload via RTP and therefore ask IANA to register
> “audio/TETRA” as a valid payload type according the specification given here.
> 
> Best regards
> Andreas
> 
> 
> -----Original Message-----
> From: payload <[email protected]> On Behalf Of internet-
> [email protected]
> Sent: Freitag, 26. Juli 2019 21:05
> To: [email protected]
> Cc: [email protected]
> Subject: [payload] I-D Action: draft-ietf-payload-tetra-03.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Audio/Video Transport Payloads WG of the
> IETF.
> 
>         Title           : RTP Payload Format for the TETRA Audio Codec
>         Authors         : Andreas Reisenbauer
>                           Udo Brandhuber
>                           Joachim Hagedorn
>                           Klaus-Peter Höhnsch
>                           Stefan Wenk
> 	Filename        : draft-ietf-payload-tetra-03.txt
> 	Pages           : 15
> 	Date            : 2019-07-26
> 
> Abstract:
>    This document specifies a Real-time Transport Protocol (RTP) payload
>    format for TETRA encoded speech signals.  The payload format is
>    designed to be able to interoperate with existing TETRA transport
>    formats on non-IP networks.  A media type registration is included,
>    specifying the use of the RTP payload format and the storage format.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-payload-tetra/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-payload-tetra-03
> https://datatracker.ietf.org/doc/html/draft-ietf-payload-tetra-03
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-payload-tetra-03
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> _______________________________________________
> payload mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/payload
The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised.
If you are not the intended recipient, please notify Airbus immediately and delete this e-mail.
Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately.
All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free.
_______________________________________________
Audio/Video Transport Core Maintenance
[email protected]
https://www.ietf.org/mailman/listinfo/avt