[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Working group last call: draft-ietf-avt-rfc2833bis-03.txt
Greetings. Please find review comments for 2833bis-03 below (some more
nit-picking than others).
Section 2, 7th and 8th paragraph, Section 3.2 first half.
- The discussion in Section 2 about what representation to send seems to
ignore any negotiation that may have taken place. It is also somewhat
contrary to the first part of Section 3.2, which says that the source is free
to choose any of the four approaches. I think a bigger issue here is that the
document does not have an offer/answer section.
Section 3, 4th paragraph
- Last sentence says "RFC 2198 [4] is used to". Either something is missing
here or this should be deleted.
Section 3.2, first list item (Events and audio)
- It is not clear to me whether redundancy encoding (RFC 2198) is used here
or not and it should probably be spelled out.
Section 3.2, first item in list
OLD: PCMU or the codec
NEW: PCMU or another codec
^^^^^^^^
Section 3.3, second paragraph
- Text currently says "MUST support the events listed in Table 2 with the
exception of flash". We discussed this for 2833 in the past, and agreed that
(in practice) only the events you actually declare support for are supported
(there was an implementation note to that effect at
http://www.cs.columbia.edu/~hgs/rtp/payload.html in the past, but this URL no
longer works). In other words, you don't necessarily have to support all DTMF
tones to support RFC2833bis.
Section 3.3, second last paragraph:
- There is no normative language in this section, but nevertheless, it would
probably be worthwhile clarifying that this has no bearing on implementations
(in fact, I don't agree completely with the statements in this paragraph and
would consider removing it).
Section 3.5, duration field bullet
- Text says "all but the last event have the maximum duration expressible in
the duration field". Should then explain what the last event actually has in
this field.
Section 3.5, E field bullet, second paragraph:
- Text says "until retransmitting the last packet for a tone". There should
either be a forward reference to Section 3.6 to explain what "retransmit"
means (since it's not just a single packet retransmission, but rather a
resend of the event with a new sequence number or use of 2198) or it should
be explained here.
Section 3.5, E field bullet, third paragraph:
- Text says "the appearance of a different named event implies the end of the
previous state". That's not entirely accurate; only if the new event belongs
to the same "state class" as the old state will the state be changed (e.g.
receipt of a DTMF digit does not end the off-hook state).
Section 3.5, E field bullet, second last paragraph:
- Text says "A slight extension of tone durations and shortening of pauses is
generally harmless". "Generally" is the keyword here, as there are cases
where it is not harmless and implementations need to do their absolute best
to maintain the original timing - this may be worth pointing out.
Section 3.6, 4th paragraph:
- Text says "If an event has ended and there bas been no new event in the
last interval, the event with final duration SHOULD be sent a total of three
times at the interval used by the source for the updates". When subevents had
been sent, the duration will not really be the "final duration". Also, let's
say a new event occurs after I sent the final event two times; do I still
send the old event a third time ?
Section 3.6, 4th paragraph, last sentence:
- Text says "The last update is also repeated at the end of subevents, as
there is no other way to detect the duration of the event". Does this also
apply if a new event happens right after the end of the subevent ? Either
way, it's probably worth clarifying.
Section 3.9:
- There should be offer/answer considerations here (probably a separate
sub-section). In particular, how the "fmtp" parameter is processed should be
discussed (e.g. seems reasonable that, within the context of offer/answer, it
is actually negotiated). Also, for sendonly or sendrecv streams, it seems
reasonable the events can not only be received, but also sent.
Section 3.10, second paragraph:
- Text says "The Flash event must only be sent when the state is off hook".
What does "state" refer to here (e.g. do we have to have an off-hook state
signaled via the 2833bis off-hook event in order to use this) ? Also, "must"
should probably be "MUST".
Section 3.11, /ANSam event, third paragraph
- Let's say we send ANS, get a phase reversal, and then send /ANS. The text
is not entirely clear on what happens from here. If the expected phase
reversals continue to occur, I believe we continue sending the /ANS which
should probably be stated. Also, in that case, is it still one and the same
event, and hence the timestamp continues unchanged ? If I don't get the
expected phase reversal, do I then send ANS again ? Clarification on these
points would be good.
Section 3.11, V8bis signals
- I know little about V8bis and could easily be wrong here, but some of the
V8bis signals look suspicious to me, so unless somebody that knows about this
has reviewed it, I'd be concerned. It seems that only a subset of the V8bis
signals are included and that you would need more to implement some of the
V8bis state transitions (see e.g. Figure 11 in V8.bis). Also, based on a
cursory look at V8bis, the definition of CRDi does not seem correct (if I
understand correctly, CRDi would not be issued in response to CRe; CRDr
would). Tones affected by this comment are: CRDi, CRDr, CRe, ESi, ESr, MRdi,
MRdr, MRe.
Section 3.11, CI:
- Text says "To fully express the call indicator, it would be followed by a
call function octet, composed of individual V.21 bit events". It's unclear if
the expectation here is to include the stop and start bit as well (producing
10 bits) or whether only the call function octet itself is expected to be
sent, in which case the start and stop bits will have to be generated by the
receiver if the tone is to be sent out.
Section 3.11, Table 3:
- For the "V.25, echo canceller disable" row, it's not clear whether the
"ANS, /ANS, ANS, /ANS" indication refers to the ITU-T spec or the 2833bis. I
assume it's the former, since the representation in 2833bis would rather be
"ANS, /ANS........" (I believe). If so, this should probably be clarified.
Section 3.12, 3.13, and 5:
- The example in Section 5 surprised me a little inasmuch as it included
silence as part of the tone. Thinking further about this, it leads to a more
general question about how some of the "tones" in Section 3.12 and 3.13 (and
maybe others, e.g. seems similar to the /ANS, /ANSam question), which are
actually not just tones, but tone patterns, are represented and rendered. In
the case of ringing, is each "event" a single ring, a single ring-cycle, or
does it continue ? What about trailing silence in a tone pattern in general ?
For example, confirmation tone as defined in GR-506-CORE ends with a steady
application of tone off, so when does it end ? I think we need more
description of these issues in general in the definition of these kinds of
tones.
Section 3.13:
- At a minimum, we need to have references for the tones in this section (and
preferably some text too). Right now these event numbers could be anything.
Section 3.14, ABCD transitional and Trunk Unavailable
- Text says "At the time of a transition, the same ABCD information is sent 3
times at an interval of 5 ms". Seems a bit strange to me that the general
retransmission strategy is not being used here. What is the reasoning behind
this ? A similar comment applies to the "Trunk unavailable" event.
Section 3.14, Continuity Tones:
- Both the 1780 and the 2010 can be either sent or received (depending on the
switch configuration at either end).
Section 3.14:
- I have asked another person to review this section as well, so there may be
additional comments here.
Section 4.3:
- May be worth describing how the Marker bit is used.
Section 7, and References
- Reference to RFC 1889 and RFC 1890 should be replaced with RFC 3550 and RFC
3551.
Normative References:
- [3]: Latest version of V.8 is 11/00
- [9]: Latest version of T.30 is 07/03
- [11]: Latest version of V.8bis is 11/00
- [16]: Latest version of Q.440 is 11/88 (not 11/98)
- [17]: Latest version of Q.140 is 11/88 (not 11/98)
- [18]: Latest version of Q.151 is 11/88 (not 11/98)
- [19]: Latest version of I.366.2 is 11/00
- [20]: Latest version of Q.400 is 11/88 (not 11/98)
- [21]: Latest version of Q.411 is 11/88 (not 11/98)
- [22]: Latest version of Q.421 is 11/88 (not 11/98)
- [24]: Latest version of E.180 is 03/98. Also delete "Recommendation
Supplement 2 to" from the text.
In addition to the above, I have some strictly editorial comments which I
will send separately to just the author.
-- Flemming
Colin Perkins wrote:
> On Monday, Jul 28, 2003, at 02:15 Europe/London, Colin Perkins wrote:
> > This is to announce a working group last call on the RTP Payload for
> > DTMF
> > Digits, Telephony Tones and Signals <draft-ietf-avt-rfc2833bis-03.txt>.
> > Please send any final comments on this draft to the mailing list by
> > 11th
> > August 2003. If no substantive technical issues are raised, we intend
> > to
> > submit this draft for publication as a proposed standard RFC to
> > obsolete
> > RFC 2833.
> >
> > Note that this draft will not be advanced until we receive at least one
> > valid review from someone not directly involved with production of the
> > draft (i.e., not an author or contributor).
>
> This is to solicit reviews of the draft-ietf-avt-rfc2833bis-03.txt. As
> noted above, we will not advance the draft until at least one valid
> technical review, from someone not directly involved with the
> production of the draft, is received.
>
> --
> Colin Perkins
> http://csperkins.org/
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt