Subject: Re: [payload] Comments for RTP Payload Format for the TETRA Audio Codec

From: REISENBAUER Andreas <[email-masked]>
Date: Sun, 28 Oct 2018 19:41:52 +0000

Hi Andreas,
Sorry for the late response to your valuable review comments…

I am currently working on the next version of the draft and would like to address your comments in that way:

Chapter 4.3.3
I would like to add this note at the end of the chapter describing the “R” Bits (audio signal relevance):
NOTE: Receiver **SHOULD** consider stolen or erroneous blocks as not available for audio decoding as indicated by control bits independent of audio signal relevance bits.
This states it is the receiver’s responsibility to produce this overall relevance indicator (I suspect especially the combination with the error indication could be unambiguous for the sender)

Chapter 6
If I got this chapter right it is more talking about prevention of packet loss by controlling congestion. Your approach more explains receiver’s strategy to cope with packet loss and blocks indicating errors which is not directly addressed by “congestion control”. So if you are not too angry, I would not change this chapter.

Does this approach address your comments?

All the best
Andreas

From: payload [mailto:[email-masked]] On Behalf Of Andreas Ahland
Sent: Freitag, 15. Juni 2018 15:45
To: [email-masked]
Subject: [payload] Comments for RTP Payload Format for the TETRA Audio Codec

Review Comments for

            RTP Payload Format for the TETRA Audio Codec
                      draft-ietf-payload-tetra-00

2018-06-15 by
Andreas Ahland
[email-masked]<mailto:[email-masked]>

I think it is a good description of how to transport tetra encoded speech over IP.

Review Comments:

Chapter 4.3.3. CTRL: Control bit(5 bits) vs 4.3.6. R: Audio Signal Relevance: Do control bits need evaluation or is this already handled in Audio Signal Relevance? If not,  it should be noted that “stolen” marks a Tetra block as unusable for audio decoding. When encoding Tetra to RTP, all control bits should be set to 0 to announce correct audio data.

Chapter „6. Congestion Control Considerations“ could mention that packet losses have the same effect for audio decoding as if some blocks are marked defective or stolen and thus are not available for audio decoding. It could be noted that Tetra does block encoding and decoding and that each of the 137 bits form a complete block which can be decoded by itself.

Mit freundlichen Grüßen / Best regards

Dr.-Ing. Andreas Ahland

SELECTRIC Nachrichten-Systeme GmbH

Leitung Technik / CTO

Haferlandweg 18
48155 Münster
tel

)

 +49 251 6183-196

fax

)

 +49 251 6183-197

[Anmeldung Newsletter]<https://www.selectric.de/shop/customer/account/create/>

Sitz der Gesellschaft (Company Premises): Muenster | Registergericht (Register Court): Amtsgericht Muenster | HRB-Nr. 1264
Geschaeftsfuehrer (General Managers): Michael Heussner, Hendrik Pieper

---

From: Andreas Ahland <[email-masked]>
Date: Mon, 29 Oct 2018 10:04:16 +0000

Hi Andreas,

thank you for your comments, I like your solution.

Dr.-Ing. Andreas Ahland

Haferlandweg 18
48155 Münster

tel     )        +49 251 6183-196
fax     )        +49 251 6183-197

Sitz der Gesellschaft (Company Premises): Muenster | Registergericht (Register Court): Amtsgericht Muenster | HRB-Nr. 1264
Geschaeftsfuehrer (General Managers): Michael Heussner, Hendrik Pieper
Von: REISENBAUER Andreas <[email-masked]>
Gesendet: Sonntag, 28. Oktober 2018 20:42
An: Andreas Ahland <[email-masked]>; [email-masked]
Betreff: RE: Comments for RTP Payload Format for the TETRA Audio Codec

Hi Andreas,

Chapter 4.3.3

Chapter 6

All the best
Andreas

From: payload [mailto:[email-masked]] On Behalf Of Andreas Ahland
Sent: Freitag, 15. Juni 2018 15:45
To: [email-masked]<mailto:[email-masked]>
Subject: [payload] Comments for RTP Payload Format for the TETRA Audio Codec

Review Comments for

2018-06-15 by
Andreas Ahland

Review Comments:

Dr.-Ing. Andreas Ahland

Leitung Technik / CTO

Haferlandweg 18
48155 Münster
tel

)

 +49 251 6183-196

fax

)

 +49 251 6183-197