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

[REISENBAUER Andreas <[e-mail]>]

Good evening Roni,
Thank you for your careful review!
Do you think I should push an update of the draft as "draft-df-stecker-expertenforum-payload-tetra-01" _before_ we see each other in London?
At least I prepared a version here, which is almost "ready-to-ship"

Would be great if you can find some minutes for a short face to face meeting in London. I will arrive at Wednesday 21st afternoon

I took your bullets as a checklist and put some comments on

All the best
Andreas

From: payload [mailto:[e-mail]] On Behalf Of Roni Even (A)
Sent: Sonntag, 18. März 2018 11:31
To: [e-mail]
Subject: [payload] review of draft-df-stecker-expertenforum-payload-tetra-00

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"
done

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

3. In section 3 what are E1 lines?
Reformulated
Corrected another error here as well - reference to [3] instead of ETS 300 395...

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.
The idea here is:
Source of the signal typically is the mobile unit
Signal is propagated over the air and via TETRA ground infrastructure (circuit switched) towards the gateway where it is converted to RTP
Information sink consumes RTP (fully agree timing information is derived from RTP)
But as data corruption may also have happened along the entire communication line (including the over the air section) it would be good, if sink is informed about end-2-end codec packets delivery to provide best audio quality

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

6.  For clarity maybe move section 4.4 before section 4.2 (or include 4.4 in the beginning of 4.2)
Totally makes sense - moved 4.4

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?
Have you got an idea how we could handle this?
The meaning of those bits is not entirely clear - could also be a matter of who is the receiver...
So could be used to tunnel some information from source to sink along the entire infrastructure
Treating them as reserved?

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.
Originally we intended to support encrypted TETRA payload via RTP as well (maybe I'll come back later with another draft which adds this payload)
Signal flow is: Mobile does encryption (audio encryption in addition to TETRA over the air encryption) - air transport - TETRA network - proprietary TETRA ground infrastructure interface (circuit mode 2Mbit/s lines) - gateway (doing the decryption and conversion to RTP) - RTP - control room
So in this sense it is decryption towards RTP which might fail for whatever reason
Or it is encryption of the RTP receiver towards TDM infrastructure (indication towards TDM which is outside the scope of what we specify here)
Tried to clarify it a little bit

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?
Strongly related to point 8 - tried to clarify both

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."
Verbally incorporated your proposal

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>]."
changed

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.
Uuups - forgot to remove this - we have introduced this parameter to be prepared for any incompatible changes to be introduced while becoming an RFC (hopefully). As we are already using the payload as drafted here
Simply deleted now

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
Do you think it is enough simply to refer to section 10 (without noting "this RFC") as I've done it several times within this draft already? If OK this would save the efforts for the note ...

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

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.
correct - removed

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?
Integer multiples of 30ms are allowed, no need to be symmetric - clarified in the document

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
uuups - wishful thinking - thank you - corrected, we simply reject the option for the receiver to select ptime

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


Roni Even as individual