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

From: "Roni Even (A)" <[email-masked]>
Date: Thu, 12 Dec 2019 13:25:39 +0000

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-masked]]
> Sent: Friday, July 26, 2019 10:27 PM
> To: Tuominen, Antti; [email-masked]; [email-masked];
> Roni Even (A)
> Cc: Klaus-Peter Höhnsch ([email-masked]);
> Brandhuber Udo ([email-masked]); Joachim Hagedorn
> ([email-masked])
> 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-masked]> On Behalf Of internet-
> [email-masked]
> Sent: Freitag, 26. Juli 2019 21:05
> To: [email-masked]
> Cc: [email-masked]
> 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-masked]
> https://www.ietf.org/mailman/listinfo/payload

---

From: "Tuominen, Antti" <[email-masked]>
Date: Thu, 12 Dec 2019 15:20:42 +0000

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-masked]] 
Sent: Thursday, December 12, 2019 3:26 PM
To: REISENBAUER Andreas; Tuominen, Antti; [email-masked]; [email-masked]
Cc: Klaus-Peter Höhnsch ([email-masked]); Brandhuber Udo ([email-masked]); Joachim Hagedorn ([email-masked])
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

Hi Andreas,

> ftp://ftp.ietf.org/internet-drafts/
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.

---

From: REISENBAUER Andreas <[email-masked]>
Date: Fri, 13 Dec 2019 16:52:45 +0000

Hi Roni,
you are totally right - it is the header embedded in the payload as described in chapter 4 in which they both differ - and consecutively chapter 5 (the payload example). 
ETSI TS 100 392-3-8 does not address the other chapters like Congestion Control Considerations, payload format parameters, mapping to SDP and security considerations.

Your proposal sounds brilliant to me - totally OK with it
All the best
Andreas

-----Original Message-----
From: Roni Even (A) <[email-masked]> 
Sent: Donnerstag, 12. Dezember 2019 14:26
To: REISENBAUER Andreas <[email-masked]>; Tuominen, Antti <[email-masked]>; [email-masked]; [email-masked]
Cc: Klaus-Peter Höhnsch ([email-masked]) <[email-masked]>; Brandhuber Udo ([email-masked]) <[email-masked]>; Joachim Hagedorn ([email-masked]) <[email-masked]>
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

Hi Andreas,

> To: Tuominen, Antti; [email-masked]; 
> [email-masked]; Roni Even (A)
> 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
> 
> 
> This draft is a work item of the Audio/Video Transport Payloads WG of 
> the IETF.
> 
> 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.
>

---

From: "Tuominen, Antti" <[email-masked]>
Date: Fri, 13 Dec 2019 19:11:29 +0000

Hi Andreas, Roni, all,

https://www.iana.org/assignments/media-types/audio/TETRA_ACELP does address all the required considerations.

Here are my concerns about the draft text:
Abstract totally ignores existence of Generic Speech Format and section 4 ignores the RTP part.
The draft still talks about historical specifications (FSTE, OSTE) all over. 
Section 3 claims erroneously that the EN 300 395-2 specifies some wire formats where it really specifies the TETRA codec.
Section 4.3.2 F bit should refer to framing rate of either 170/3ms or 60ms, since there is no difference in the actual data.
Section 4.3.3 Control bits are copied from the historical documents, not the ETSI TS 100 392-3-8 even though that is used as reference. 
Section 4.3.4 seems to suggest the TETRA End to end encryption is decrypted in some intermediate entity. Is this correct? 
Section 4.3.5 Frame number use unnecessarily differs with ETSI TS 100 392-3-8 recommendation to start with frame number 1 for 60ms framing rate so that the receiver would always act the same way for both framing rates.
Section 4.3.6 Audio signal relevance references a document that is not publically available.

Best regards,
Antti

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

Hi Roni,

-----Original Message-----
From: Roni Even (A) <[email-masked]> 
Sent: Donnerstag, 12. Dezember 2019 14:26
To: REISENBAUER Andreas <[email-masked]>; Tuominen, Antti <[email-masked]>; [email-masked]; [email-masked]
Cc: Klaus-Peter Höhnsch ([email-masked]) <[email-masked]>; Brandhuber Udo ([email-masked]) <[email-masked]>; Joachim Hagedorn ([email-masked]) <[email-masked]>
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

Hi Andreas,