Re: [AVT] 2833bis

[Flemming Andreasen <fandreas@cisco.com>]

Thanks for the update Henning. Some comments etc. below

Questions/Comments
================
p.5: After the sentence "A compliant implementation MUST support the events
listed in Table 1 with the exception of "flash"."  the implementation note
"Implementations can support events 0 through 15 (DTMF) by simply ignoring the
packets, but MUST declare all event numbers that are meaningful to it in the
fmtp parameter, including 0 through 15."
should be added (and/or perhaps in Section 3.9). Also on p. 25 (Optional
parameters).

p.6-8: There seem to be some minor inconsistencies and ambiguities introduced
by the new state event concept.
- Timestamp: It's not clear if the duration value "0" can only be used with
state events or not.
- duration: The definition states "...has so far lasted as long as indicated by
this parameter.", however this is inconsistent with the duration "0", and also
seems inconsistent with the definition of state events under the "E:" (end bit)
definition that follows:
- E (end bit):  The new text seems to imply that state event can be sent with
an "anticipated or good till cancelled duration", i.e. not necessarily just the
duration so far, however as noted, this is inconsistent with the "duration"
parameter. It's also not entirely clear if this is only allowed for state
events (I assume so). Rephrasing parts of the paragraph might aid in the
understanding here too.

- V.21 data bits:  It would be nice if we had a more efficient way of sending
V.21 data bits which also doesn't require us to use RFC 2198 redundancy. We
could for example define two new events (one for each V.21 channel) that simply
use the (otherwise unused) volume field to encode the actual bit values. That
would enable us to send 20 ms of V.21 data bits in a single event.
Alternatively, we could consider encoding it in the duration field as well
(e.g. have volume indicate number of bits and duration the actual bits), but
that seems more inconsistent (it would on the other hand allow us to encode up
to the recommended 50 ms).

- States in tables:  Which events are states is open for debate I guess, but
the fewer we have, the better it would seem. A guiding principle for whether
something can be a state should be that there must be an easy and reliable way
of getting rid of that state (not least considering the special duration "0").
Thus for every state event there must be another state event (or something
else, e.g. non-RFC 2833 media) that can obsolete that state event. With that in
mind, there seems to be (only ?) two additional events that qualify, namely
on-hook and off-hook in table 4.
Question: Do all of the ABCD signaling events define a state ? How do you "turn
off" the individual ABCD states ?

- Flash hook, on-hook, and off-hook: If we actually use on-hook and off-hook as
states, then how should we signal flash-hook ? Do we keep the state as
off-hook, and then send a flash-hook, or do we change off-hook to on-hook to
off-hook ? In the latter case, do we still send the flash-hook event ?


Other:
=====
RTP continuity:     Continuity tests are being performed in the PSTN to verify
the operation of the trunk over which your call is setup. It turns out, that
it's very useful to have a similar capability to verify continuity of an RTP
session. While RTCP does offer some help in this area, it's not a complete
solution for a couple of reasons; 1) the RTP and RTCP destination ports differ,
2) you can't force the other party to actually send you an RTCP packet when you
would like to (e.g. immediately to verify RTP continuity on call setup). If we
had something like a "ping" and a "pong" event, it would be very helpful (if
you get a "ping", you send a "pong"). Comments ?



Nits:
====
p.2:  "sytems" => "systems"
p. 6: The paragraph "The special duration..." should probably be moved to the
paragraph that describes the "duration" field.
p. 7: "duration: Duration of this digit" => "duration: Duration of this event"
p. 17: "a duration of 80 to.  80 ms" ?
p. 17: It may be worth spelling out "MF" and "MFC" to make it clear it's not an
editorial error. Also "Note that trunk" => "Note that a trunk"
p. 18-19: The R2 MFC table has been split by table 5.
p. 23: Table 7 has some formatting problems.


-- Flemming


Henning Schulzrinne wrote:

> After much delay, I finally got started on 2833bis. The draft should
> appear in the archives shortly, but you can also find it at
>
> http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-00.txt
> http://www.cs.columbia.edu/~hgs/rtp/drafts/draft-ietf-avt-rfc2833bis-00.ps
>
> I'm sure I accidentally ignored one or more of the comments received in
> the last year or two, but maybe this will help people to recall their
> pet peeve with 2833.
>
> Henning
>
> _______________________________________________
> 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