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

From: Tom Taylor <[email-masked]>
Date: Wed, 01 Dec 2004 22:31:39 -0500

Thank you very much for taking the trouble to review this document.  My responses
are inline, marked with [PTT].

Mundra, Satish wrote:
> 
> 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.
> 
[PTT begin]
Good point.  How about if I add the following text to that paragraph:

"However, depending on the playout algorithm used, any increase in time interval 
between sending of event packets may result in gaps in or premature termination of 
tone playout.  As a result, a new event packet for a continuing event SHOULD be 
sent before the receiving end might be expected to complete playout of the 
duration indicated by the packets already sent.  Moreover, the duration reported 
in the initial event packet SHOULD be larger than the expected inter-event packet 
interval, to provide a buffer against packet delays at the receiving end."
[PTT end]

> 
> 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 ?

[PTT] I think that's just 3*inter-arrival periods, based on the advice in 2.5.2.2. 
  Don't forget that the final packet and its retransmissions will all indicate the 
same total event duration, regardless of the setting of the E-bit.  I agree that 
if the E-bit appears in the first packet reflecting the end of the event and that 
packet is not lost, there will be NO tone extension.  How about if I modify the 
text above to say that:

"A sender MAY delay setting the "E" bit until the first retransmission of the 
final packet of a tone, ..."

This is slightly more precise, and results in the E-bit being set for both 
retransmissions.  If one packet is lost, the worst-case extension is now just 
2xinter-arrival interval.

> 
> 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.
> 
[PTT] OK with me.  This is original RFC 2833 text, but perhaps these days we have 
a clearer idea of our architecture.

> 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.

[PTT] Agreed.

> 
> 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".

[PTT] Agreed.

> 
> 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?

[PTT] The apparently contradictory advice at the end of 5.2 actually refers to 
receiver behaviour, where the earlier part refers to sender strategy.  I would 
expect the type of situation where you would send both tones and events would be a 
data transmission case such as transmission of V.21 bits, where the receiver is 
going to have to make a transition to audio anyway and the combined encoding 
allows it to pick the point at which it does that.  Another point to consider: by 
an argument you made earlier, combinations like this will occur only with the 
receiver's consent (as a result of out-of-band negotiation).

I'd suggest that maybe I should add a few words to say that where the RTP packet 
contains both audio and event data, the receiver must decide when to transition to 
event playout and when to audio based on consideration of the type of events being 
reported.

> 
> 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 ?
> 
[PTT] Thanks for the catch -- the 3.5 reference goes out.  To justify the 
reference to section 3.2 I'll add some mention of data signals.  As to your main 
point, I'm not sure how much extra information redundancy gives you when most of 
it is just earlier reports of the same event.  This does let you catch 'M' and 'E' 
bits that might otherwise be lost, but in between, the latest event report pretty 
well tells you all you need to know.  So redundancy is less useful in the case of 
spread-out events than when they have short duration and follow one another at 
short intervals.
> 
> Regards,
> 
> Satish Mundra
> 
> 
> _______________________________________________ Audio/Video Transport Working
> Group [email-masked] https://www1.ietf.org/mailman/listinfo/avt
> 
> 

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel Networks
Phone +1 613 763 1496  (ESN 393-1496)
E-mail: [email-masked]

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