Subject: [AVT] comments on draft-ietf-avt-rfc2833bis-06.txt

From: "Mundra, Satish" <[email-masked]>
Date: Tue, 30 Nov 2004 16:50:34 -0600

I have following comments on this draft:

1. Section 2.5.1.2 states:
   "Timing information is contained in the RTP timestamp, allowing 
   precise recovery of inter-event times.  Thus, the sender does not 
   need to maintain precise or consistent time intervals between event 
   packets." 

The section refers to "event packets" as those belonging to same event.
I 
think a sender needs to maintain consistent interval between event
packets 
as a receiver relies on the inter-arrival times to decide how long to
extend 
the tone when there are no event packets received. For e.g. if the
interval is 
changed from 10ms to 50ms then a receiver could timeout before the event
packet 
sent at new interval arrives. 

2. Section 2.5.1.4 states:
   "A sender MAY delay setting the "E" bit until retransmitting the last

   packet for a tone, rather than setting the bit on its first 
   transmission. This avoids having to wait to detect whether the tone 
   has indeed ended.  Once the sender has set the "E" bit for a packet, 
   it MUST continue to set the "E" bit for any further retransmissions 
   of that packet."

How is above different from a sender that does not re-transmit packets
with 
E-bit set? Assuming that receiver is using section2.5.2.2 alogorithm-2
for 
playout, isn't delaying the setting of E-bit going to cause tone
extension 
by 5*inter-arrival periods if the packet with E-bit set was lost ? 

3. Section 2.6.2 states:  
      "This approach allows dumb gateways that do not understand this

      format to function. See also the discussion in section 1."

This statement should be removed, as gateways first need to negotiate
the 
payloads via out-of-band means, hence the situation where dumb gateway
receives 
payload format that it does not understand should not arise.

4. Section 2.6.2 states:
   "The audio redundancy mechanism described in RFC 2198 [N-2] MAY be 
   used to recover from packet loss across events. For the suggested 
   packet gap of 50 ms, the effective data rate is r times 64 bits (32 
   bits for the redundancy header and 32 bits for the telephone-event 
   payload) plus 8 bits for the primary encoding every 50 ms or (r times

   1280 + 160) bits/second, where r is the number of redundant events 
   carried in each packet. The value of r is an implementation trade-
   off, with a value of 5 suggested."

I think calculations are for "effective increase in data rate" when
redundancy
is used and not effective data rate. The primary payload of 4 bytes is
not 
included in the above data rate.

5. Section 5.1 states:
   "Gateways which send signalling events via RTP MAY send both named 
   signals (section named) and the tone representation (section tones) 
   as a single RTP session, using the redundancy mechanism defined in 
   RFC 2198 [N-2] to interleave the two representations. It is generally

   a good idea to send both, since it allows the receiver to choose the 
   appropriate rendering." 
   
I think "a single RTP session" above should be changed to "in a single
RTP packet".

6. Section 5.2 states:
  "Events and Audio
      "The source sends events and encoded audio packets (e.g., PCMU or 
      the codec used for speech signals) for the same time instant. In 
      that mode, events are treated as redundant encodings for the 
      encoded audio stream."

As noted in section 2.5.2.2, encoded audio packets preceding the encoded

events can cause spurious digits/events and this mode allows the encoded

audio packets after the recognition of events and is probably going to 
increase the probability of spurious digits. Section 5.2 also recommends

using encoded tones rather than encoded audio for rendering tones. 
Why not disallow this mode?

7. Section 2.6 states: 
      "Section 2.6.2 describes how a summary of earlier events MAY be 
      carried in RFC 2198 redundancy payloads.  This is particularly 
      useful for sequences of short events, e.g., digits dialed by a 
      modem or autodialer or in-band tone signaling sequences (section 
      3.2 or 3.5)."

There is no section 3.5 in the new draft. What about redundancy when the

digits are not dialed by auto-dialer or modem and inter-digit interval
and 
dialing duration are not small, for e.g., calling card calls ? 

Regards,

Satish Mundra

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt