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

[REISENBAUER Andreas <[e-mail]>]

Hi Antti,
thank you for your very specific feedback.
We, the authors, do not want to resign the work on draft-ietf-payload-tetra.

For this reason I will raise a new version of the draft that should cover your concerns. May I have your early feedback before I press the "submit" button?

So in detail:
> Abstract totally ignores existence of Generic Speech Format and section 4 ignores the RTP part.
You are right it does not take "ETSI TS 100 392-3-8 V1.3.1" into account. It rather allows the format given in "ETSI TS 100 392-3-6 V1.1.1". But still there is nothing bad with this format is it?

> The draft still talks about historical specifications (FSTE, OSTE) all over.
As these formats are in use and there is no significant change with the Generic Speech Format

> Section 3 claims erroneously that the EN 300 395-2 specifies some wire formats where it really specifies the TETRA codec.
You are right! Nevertheless section 3 may contain both the codec itself plus the wire format - agreed?
What do you think about rephrasing section 3 in this sense:
   The TETRA codec is used as vocoder for TETRA systems.  The TETRA
   codec is designed for compressing 30ms of audio speech data into 137
   bits [ETSI-TETRA-Codec].  The TETRA codec is designed in such a way that on the air
   interface two of these 30ms samples are transported together (sub-
   block 1 and sub-block 2).  The codec allows that data of the first
   30ms voice frame can be stolen and used for other purposes, e.g. for
   the exchange of dynamically updated key-material in end-to-end
   encrypted voice sessions.  Codec payload serialisation as a wire format is specified
   for TDM lines with 2048 kBit/s within traditional circuit mode based
   TETRA system.  For this purpose two optional formats are defined
   [ETSI-TETRA-ISI], the first format is called FSTE (First Speech
   Transport Encoding Format), the other format is called OSTE
   (Optimized Speech Transport Encoding Format).  These two formats
   differ mainly insofar that the OSTE format transports an additional 5
   bit frame number, which provides timing information from the air
   interface to the receiving side in order to save the need for
   buffering due to different transports speed on air and in 64 kbit/s
   circuit switched networks.  The RTP payload format is defined such
   that the value of this frame number can be transported.

> 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.
Sorry – did not get the point. May I ask you to rephrase? It is intended to differentiate the 2 different framings (FSTE and OSTE) with this indicator

> 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. 
You are right! Probably my very last attempt was totally wrong – I will revert the changes according references to TS 100 392 – control bits are in alignment of version 1.1.1 of this standard. I tend to change TS 100 392 to change to an informative rather than a normative reference – the only thing which is not thoroughly specified within this draft is frame number, which could easily added to section 4.3.5. What do you think?

> Section 4.3.4 seems to suggest the TETRA End to end encryption is decrypted in some intermediate entity. Is this correct? 
Correct this is one valid option. Maybe we add encrypted payload as another option at a later stage (most probably via a dedicated payload).

> 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.
Did not get it. Frame number starts with frame #1 – value “0” is reserved in both the draft and TS 100 392. Nevertheless adding a tiny table could be a justification to remove TS 100 392 from the normative references

> Section 4.3.6 Audio signal relevance references a document that is not publically available.
As the signal relevance is thoroughly specified within the draft (at least cited BDBOS BIP-20 does not provide information in), I will simply remove all trails to BDBOS-BIP20

All the best
Andreas

-----Original Message-----
From: Tuominen, Antti <[e-mail]> 
Sent: Freitag, 13. Dezember 2019 20:11
To: REISENBAUER Andreas <[e-mail]>; Roni Even (A) <[e-mail]>; [e-mail]; [e-mail]
Cc: Klaus-Peter Höhnsch ([e-mail]) <[e-mail]>; Brandhuber Udo ([e-mail]) <[e-mail]>; Joachim Hagedorn ([e-mail]) <[e-mail]>
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

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:[e-mail]]
Sent: Friday, December 13, 2019 6:53 PM
To: Roni Even (A); Tuominen, Antti; mailto:[e-mail]; mailto:[e-mail]
Cc: Klaus-Peter Höhnsch (mailto:[e-mail]); Brandhuber Udo (mailto:[e-mail]); Joachim Hagedorn (mailto:[e-mail])
Subject: RE: [payload] I-D Action: draft-ietf-payload-tetra-03.txt

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) <mailto:[e-mail]>
Sent: Donnerstag, 12. Dezember 2019 14:26
To: REISENBAUER Andreas <mailto:[e-mail]>; Tuominen, Antti <mailto:[e-mail]>; mailto:[e-mail]; mailto:[e-mail]
Cc: Klaus-Peter Höhnsch (mailto:[e-mail]) <mailto:[e-mail]>; Brandhuber Udo (mailto:[e-mail]) <mailto:[e-mail]>; Joachim Hagedorn (mailto:[e-mail]) <mailto:[e-mail]>
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:[e-mail]]
> Sent: Friday, July 26, 2019 10:27 PM
> To: Tuominen, Antti; mailto:[e-mail];
> mailto:[e-mail]; Roni Even (A)
> Cc: Klaus-Peter Höhnsch (mailto:[e-mail]);
> Brandhuber Udo (mailto:[e-mail]); Joachim Hagedorn
> (mailto:[e-mail])
> 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 <mailto:[e-mail]> On Behalf Of internet- 
> mailto:[e-mail]
> Sent: Freitag, 26. Juli 2019 21:05
> To: mailto:[e-mail]
> Cc: mailto:[e-mail]
> 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
> mailto:[e-mail]
> 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.