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

[REISENBAUER Andreas <[e-mail]>]

Hi Ralf,
Thanks a lot for your comments. As we also had a chat on the phone I hope I've hit all your proposals with the uploaded version 01 of draft-ietf-payload-tetra-01

Pls let me know if I missed anything or did not put it in as clear as it could be

Br
Andreas

From: payload [mailto:[e-mail]] On Behalf Of [e-mail]
Sent: Montag, 28. Mai 2018 21:41
To: [e-mail]
Subject: [payload] Review 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-05-23 by
Ralf Dux
[e-mail]<mailto:[e-mail]>



General Comment:

>From my point of view the draft-ietf-payload-tetra-00 document describes the payload
format and used protocols correctly and completely. With this information a developer
should be able to implement the payload protocol.

But one important point needs clarification.
If the content of RTP packets are not going to be restricted to one or two TETRA frames (30ms or 60ms speech content)
the meaning of the control bits and the relationship to resulting or originating FSTE/OSTE packets on the E1 line
must be described for cases where more than two TETRA records are in an RTP frame.


Review Comments:

4.3.3.  CTRL: Control bit(5 bits)
Wording line 285: "document" should be added
General: Clarification needed for cases where more than two TETRA frames are in the RTP packet.
285    NOTE: The meaning of C4 and C5 is outside the scope of the present document
286
287 4.3.4.  C bit: Failed Crypto operation indication


5.  Payload example
Wording line 358: "of" should be replaced by "the"
356    The following example shows how a first and a consecutive 30 ms frame
357    is combined into a single 60ms RTP packet.  Note: This example shows
358    the usage of OSTE mapping.
359
360       0                   1                   2                   3


6.  Congestion Control Considerations
Clarification needed line 415: What is acceptable and what shall be done if the current loss rate is not??
414    used is: users of this payload format MUST monitor packet loss to
415    ensure that the packet loss rate is within acceptable parameters.
416
417 7.  Payload Format Parameters


7.1.  Media Type Definition
Line 455: Clarification needed for cases where more than two TETRA frames are in the RTP packet.
454       size.  If this parameter is not present, the sender MAY
455       encapsulate any number of speech frames into one RTP packet.
456    ptime:
457       see RFC 4566 [RFC4566].


8.1.  Offer/Answer Considerations
Line 535: Clarification needed for cases where more than two TETRA frames are in the RTP packet.
   o  Integer multiples of 30ms SHALL be used for ptime..  It is
      recommended to use packet size of 60ms.  Even if there is no good
      reason why not doing so, there is no need that ptime and maxptime
      parameters are negotiated symmetrically..

Kind regards
Ralf Dux

DEUTSCHE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH
Ralf Dux
System Engineer
Security
Hausanschrift: Überseering 2, 22297 Hamburg
Postanschrift: 22297 Hamburg
mailto: [e-mail]<mailto:[e-mail]>
www.t-systems..de/dths<http://www.t-systems.de/dths>

DEUTSCHE TELEKOM HEALTHCARE AND SECURITY SOLUTIONS GMBH
Geschäftsführung: Peter Böttcher, Holger Lesch, Arndt Lorenz
Handelsregister: Amtsgericht Bonn HRB 20695
Sitz der Gesellschaft: Bonn
WEEE-Reg.-Nr. DE50335567

GROSSE VERÄNDERUNGEN FANGEN KLEIN AN - RESSOURCEN SCHONEN UND NICHT JEDE E-MAIL DRUCKEN.

Hinweis: Diese E-Mail und/oder die Anhänge sind vertraulich und ausschließlich für den bezeichneten Adressaten bestimmt. Die Weitergabe oder Kopieren dieser E-Mail ist strengstens verboten. Wenn Sie diese E-Mail irrtümlich erhalten haben, informieren Sie bitte unverzüglich den Absender und vernichten Sie die Nachricht und alle Anhänge. Vielen Dank