Subject: [AVT] RFC 2833 and data events

From: Tom Taylor <[email-masked]>
Date: Mon, 10 Jan 2005 20:48:43 -0500

While working out a detailed example of the use of data events (V.8 negotiation 
preceding V.34 modem signalling), I came upon a couple of issues that have caused 
me to add new text to the data event codes document (which I meant to have out 
this morning, but it's coming along....).

The first issue is the impact of having a short event duration that isn't an 
integer multiple of timestamp units.  This comes up with V.21 bits, which last 3.3 
ms, a number not really compatible with an 8000 Hz sampling rate.  I have added 
the following text noting the consequences and imposing requirements on 
implementations:

"The time to transmit one V.21 bit at the nominal rate of 300 bits/s is 3.33 ms, 
or 26.67 timestamp units at the default 8000 Hz sampling rate for the 
telephone-events payload type.  Because this duration is not an integral number of 
timestamp units, accurate reporting of the beginning of the event and the event 
duration is impossible.  Sending gateways SHOULD round V.21 event starting times 
to the nearest whole timestamp unit.

"When sending multiple consecutive V.21 events in a succession of packets, the 
sending gateway MUST ensure that individual event durations reported do not cause 
the last event of one packet to overlap with the first event of the next, taking 
into account the respective initial event timestamps.  To accomplish this, the 
sending gateway MUST derive the individual event durations as the succession of 
differences between the event starting times (so that, at 8000 Hz, every third 
event has reported duration 26 units, the remainder 27 units).

"Where a receiving gateway recognizes that a packet reports a consecutive series 
of V.21 bit events, it MUST play them out at a uniform rate despite the variations 
in their reported durations."

---

The second problem comes up in reporting the phase reversal transitions between 
ANSam and /ANSam, or ANS and /ANS.  The current text implies that at the point of 
transition one immediately sends off an event report indicating, e.g., the end of 
ANSam, then (continuing this example) sends a second report indicating /ANSam. 
Looking at this while constucting my example, I found it natural to wait after 
sending the first report for a complete packetization interval before sending the 
second one.  However, this will result in an unwanted break in tone playout at the 
far end.

To illustrate the problem: suppose that the transition from ANSam to /ANSam occurs 
half-way through a packetization interval.  If the final event report for ANSam is 
sent immediately, the far end upon receiving it will have half a packetization 
interval worth of tone to play out.  If the sender waits a full packetization 
interval to send out the first /ANSam report, there will be an unwanted gap of 
half a packetization interval between the two tones, with potentially undesirable 
effects (such as failure to disable echo cancellors).

One answer is to maintain the normal packetization interval right through the 
transition, reporting both the end of ANSam and initial segment of /ANSam in the 
same packet.  I will add advice to this effect.  However, this is probably just a 
specific instance of a broader requirement to maintain continuity of tone output 
for data transmission.  Does anyone want to provide expert guidance on when gaps 
are tolerable and when they are not?

-- 
Tom Taylor
Carrier VoIP Standards Development
Nortel
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