Re: [AVTCORE] [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:[email protected]] 
Sent: Friday, December 13, 2019 6:53 PM
To: Roni Even (A); 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 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 protected]> 
Sent: Donnerstag, 12. Dezember 2019 14:26
To: REISENBAUER Andreas <[email protected]>; Tuominen, Antti <[email protected]>; [email protected]; [email protected]
Cc: Klaus-Peter Höhnsch ([email protected]) <[email protected]>; Brandhuber Udo ([email protected]) <[email protected]>; Joachim Hagedorn ([email protected]) <[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