[AVT] Review comments on draft-ietf-avt-rfc2833bis-03.txt (part 1)

[Tom Taylor <taylor@nortelnetworks.com>]

Need the brief IETF copyright declaration at the beginning?

Abstract: isn't this intended to replace rather than merely update RFC 2833?

Page 2 first para: suggest "and" instead of "as well as" to provide more balance in 
the list of applications in the first sentence, and "In the second application.." 
rather than "Secondly.." further down.  Otherwise the reader is left searching for 
the second application.

Page 3 second-last para, last sentence, might be rephrased: "Busy tone is generated 
by the ISDN terminal or, for analog instruments, by the caller's switch, triggered 
by the appropriate ISUP message."

Page 4 first para might better read: "If a gateway cannot provide a tone 
representation, it SHOULD send the named signals and also send the audio tones as 
regular RTP audio packets ...".

Page 4, second-last para seems to have been cut off after "RFC 2198 [4] is used to".

Page 4 last para, first sentence: suggest replacing "to generate tone signals again" 
with "to regenerate the tones from the named events".  In the second sentence, add 
"their peer" in front of "Internet end systems".

Section 3.2 "Events and audio" bullet: missing "source" before "sends".

Last sentence of section 3.2: suggest replacing "in general should not interfere" by 
"are unlikely to interfere".

Section 3.3, compliance (immediately after the bullets).
First point: I'd suggest a subheading at this point: "3.3.1 Implementation 
considerations".

First para after bullets: to make things easier for the reader, add indication that 
Table 2 is in section 3.10.  To make it even easier, indicate that these are all 
DTMF events.  Suggested phrasing:
"A compliant implementation MUST support the DTMF events listed in Table 2 (section 
3.10)."
I don't mention the "Flash" exception because I don't think "Flash" belongs in 
section 3.10/Table 2.  (Further discussion below.)

Third para after bullets: change "render all tones in Table 6 the same ..." to 
"render all the country-specific line events in Table 6 (section 3.13) using the 
same tone ...".

Final para before 3.4: move up to immediately follow the bullets, particularly if 
the suggestion to add sub-heading 3.3.1 is accepted.

As a further improvement, add a final para to the main 3.3 (before the 3.3.1 
sub-heading), defining state transition events and describing the meaning of the 
"State?" column in the tables.  The text for this latter should be moved here from 
section 3.4, "Duration", where people can easily miss it.  Here's a suggestion:

"Certain events represent transitions into particular states.  They are indicated by 
the presence of "Yes" values in the column headed "State?" in the event tables 2 
through 6.  Notes to the tables indicate which states are mutually exclusive (that 
is, which states are terminated when a given state is reported).  Notes may also 
indicate other state-related restrictions on what events can be reported."

You can keep your current state number idea instead, but I personally feel that 
notes put the restrictions across more straightforwardly.

Section 3.4, "Timestamp": the statement
"The receiver calculates jitter for RTCP receiver reports based on all packets with 
a given timestamp."
is presumably a note for information rather than normative text.  Hence it seems 
appropriate to put "Note: " in front of this statement.  The sentence following this 
one seems to be completely off topic and could be omitted.

Section 3.4, "Duration":  as suggested above, move the general description of state 
transition events to 3.3.  Thus the second para becomes:
"The special duration value of zero is reserved to indicate that the event lasts 
"forever", i.e., is a state and is considered to be effective until updated. Only 
events marked with a "Yes" in the "state?" column in the tables below are allowed to 
use a duration value of zero. Other named events with such a duration SHOULD be 
ignored."

Soft-state: should we indicate any action for the receiver?  I see two possibilities:
- the receiver SHOULD consider the state "unknown" once it has expired without 
refresh, or
- the receiver MAY assume persistence of the state even if it has not been refreshed 
within the specified duration.

Section 3.4, E bit: the third para is mostly redundant.  Why not just say: "For 
named RTP events labeled "state" in Tables 2 through 6, sending of a packet with the 
"E" bit set is OPTIONAL."

I think the paragraphs following this one, beginning with "Receiver implementations 
MAY use different algorithms ..." and ending just before the R-bit description, 
might logically constitute a new subsection: "3.4.1 Use of payload data to generate 
tones".  This section would follow the R-bit description.

Within those paras, para beginning "Alternatively, ...": rephrase slightly to make 
clear the three stopping conditions for a tone:
"Alternatively, the receiver can start a tone and play it until
- it receives a packet with the "E" bit set, or
- it receives the next tone, indicated by a new timestamp value, or
- a given amount of time passes.
This is more robust ..."

Final para of that set, beginning "If a receiver has extended a tone ...": I suggest 
changing "when" to "if" and "that event" to "the same event instance".  Thus the 
sentence would read (with some additional words at the end):

"If a receiver has extended a tone by the maximum extension duration and started 
playing silence, it MUST NOT resume playing the tone if later packets arrive for the 
same event instance, as this would cause spurious events to be detected downstream."


Section 3.6, second para, last line has garbled punctuation -- or is it just that 
"in order to" begins a new sentence and a capital is needed?

If I understand that quotation from Q.24 (can't bring it up at the moment to check 
it), the part about "signalling velocity" means that the minimum interval from the 
start of one tone signal to the start of the next should be 93 ms.  Perhaps this is 
how it should be stated?

More from tomorrow's campsite.

Tom Taylor


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt