[payload] review of draft-df-stecker-expertenforum-payload-tetra-00

["Roni Even (A)" <[e-mail]>]

Hi,
I read the draft and have some comments.

1. in the abstract you can remove the sentence about the storage mode and in the first sentence remove "to be used"

2. In the introduction (section 1 ) add the reference to TETRA in the first sentence.

3. In section 3 what are E1 lines?

4. Last secntence of section 3 -  Is it used, what is the use case for carrying  OSTE in RTP where there is timing information is RTP.

5.  In section 4 "or together  within one RTP frame " maybe say RTP packet.

6.  For clarity maybe move section 4.4 before section 4.2 (or include 4.4 in the beginning of 4.2)

7. About the note at the end of 4.3 , what out of scope means? Is it meant to say MUST be ignored by the RTP receiver?

8.  In section 4.2.4 "This bit may be set to "1" if an encryption or a decryption operation could not be performed successfully".  Since this is the sent RTP stream,  I can understand cannot encrypt this half block, what does it mean cannot decrypt.

9. In section 4.2.4 -" If a receiver decides to forward the TETRA audio data to   OSTE or FSTE"  . How is the decision made and should he forward this sub block or the whole audio stream?

10. in section 6 maybe use the following text "Since UDP does not provide congestion control, applications that use  RTP over UDP SHOULD implement their own congestion control above the
   UDP layer [RFC8085<https://tools.ietf.org/html/rfc8085>] and MAY also implement a transport circuit  breaker [RFC8083<https://tools.ietf.org/html/rfc8083>]3>].  Work in the RMCAT working group [RMCAT<https://tools.ietf.org/html/rfc8130#ref-RMCAT>] describes
   the interactions and conceptual interfaces necessary between the  application components that relate to congestion control, including   the RTP layer, the higher-level media codec control layer, and the
   lower-level transport interface, as well as components dedicated to   congestion control functions."

11. section 7 use "per the media type   registration template from RFC 6838<https://tools.ietf.org/html/rfc6838> [RFC6838<https://tools.ietf.org/html/rfc6838>]."

12.  in section 7.1 - drgw-fe - Why do you need to specify it here and register this parameter. If you are sending rtp payload with subtype name tetra it is this rtp payload.

13.  In section 7.1 - security consideration should say see section 10 of RFCXXXX (this RFC) and a note to RFC editor to replace RFCXXXX with the number of this RFC

14. In section 8 - we do not use the term MIME but media type or media subtype.

15. in the example at the end of section 8 the a=fmtp:99 is not needed if you do not have any optional parameters.

16.  in 8.1 add reference to RFC3264. Also about maxptime. Do they need to be symmetric, is it allowed to use values that are not 60?

17. In section 8.2 Multiple TETRA rtpmap values MAY be used to convey TETRA-coded voice at different packet  rates. Does not work if you want to use ptime and maxptime since there can be one for media section, it is a=maxptime:60 and not a=rtpmap:xx ptime:60

18. in section 9 add at the end of first sentence "from section 7.1"



Roni Even as individual















________________________________