RFC 4733 event duraton in the end bit - events

Question

In reading RFC 4733, it doesn't clearly state whether the event duration should not increment in the final 3 e-bits. It seems the important information in the event is the m-bit, timestamp, and e-bit. If the event duration does increment in the final 3 e-bits, would it make sense to consider each of the 3 e-bits as seperate events and triplicate the tones? Or should the first e-bit received be the end of the event and the last 2 ebits be disgarded? I have a wireshark capture that shows the event duration incrementing in the 3 ebits and I am tyring to make sense of this.

Answer 1

Given that the final packet of the event may be transmitted three times, the duration field should monotonically increase. In the discussion in the comments we thus see three packets, each with the E bit set, and durations of 720, 800 and 880. This indicates that the packets are sent 80ms apart, because the duration field in the packet indicates that the event "has so far lasted as long as indicated by this parameter".
However, it's still a single event, so your playout of the event should last for the duration of the first packet you receive.
For example, you're seeing three packets arrive, but if the first packet (with duration 720) didn't arrive, you'd see the second packet (with duration 800), and you should play the tone for 800ms.
That said, I'd expect the sender to send the end packet with the same duration, rather than what you're seeing. That might be a bug in the sender. (Transmission must cause an increment in duration, but this is retransmission.)

Answer 2

The sender is clearly breaking the RFC since
the 'E' bit should be set when the event has ended
the duration is increased according to the duration of the event
If the duration is still increasing then clearly the event has not ended but if the E bit was set the event has ended - i.e. contradiction
On the other hand (from 2.5.2.2)
once the receiver has received the end of the event it should stop playing the tone.
A receiver SHOULD NOT restart a tone once playout has stopped.
The receiver MAY determine on the basis of retained history and the timestamp and event code of the current packet that it corresponds to an event already played out and lapsed. In that case, further reports for the event MUST be ignored
i.e. You can tell that the event has already played out from the timestamp and should not repeat the event in this case

Answer 3

The example in the RFC 4733 is given in Table 5
https://datatracker.ietf.org/doc/rfc4733/
+-------+-----------+------+--------+------+--------+--------+------+
| Time | Event | M | Time- | Seq | Event | Dura- | E |
| (ms) | | bit | stamp | No | Code | tion | bit |
+-------+-----------+------+--------+------+--------+--------+------+
| 0 | "9" | | | | | | |
| | starts | | | | | | |
| 50 | RTP | "1" | 0 | 1 | 9 | 400 | "0" |
| | packet 1 | | | | | | |
| | sent | | | | | | |
| 100 | RTP | "0" | 0 | 2 | 9 | 800 | "0" |
| | packet 2 | | | | | | |
| | sent | | | | | | |
| 150 | RTP | "0" | 0 | 3 | 9 | 1200 | "0" |
| | packet 3 | | | | | | |
| | sent | | | | | | |
| 200 | RTP | "0" | 0 | 4 | 9 | 1600 | "0" |
| | packet 4 | | | | | | |
| | sent | | | | | | |
| 200 | "9" ends | | | | | | |
| 250 | RTP | "0" | 0 | 5 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | first | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
| 300 | RTP | "0" | 0 | 6 | 9 | 1600 | "1" |
| | packet 4 | | | | | | |
| | second | | | | | | |
| | retrans- | | | | | | |
| | mission | | | | | | |
If you look at the last 2, you see they both have the "E" bit set, and that the duration is set to 1600 (8000 * 200/1000).
I hope that helps!