"RFC 2833 RTP Event" Consecutive Events and the E "End" Bit - voip

Question

Why do I get a dtmf sound when the E bit is 0 and no sound when it is 1? (RTP packets appear in wireshark either way)
Background:
I can send out a RFC 2833 dtmf event as outlined at http://www.ietf.org/rfc/rfc2833.txt
obtaining the following behaviour when the E bit is NOT set:
If for example keys 7874556332111111145855885#3 are pressed, then ALL events are sent and show up in a program like wireshark, however only 87456321458585#3 sound.
So the first key (which I figure could be a separate issue) and any repeats of an event (ie 11111) are failing to sound.
In section 3.9, figure 2 of the above linked document, they give a 911 example where all but the last event have the E bit set.
When I set the 'E' bit to 1 for all numbers, I never get an event to sound.
I have thought of some possible causes but do not know if they are the reason:
1) figure 2 shows payload types of 96 and 97 sent. I have not sent these headers. In section 3.8, codes 96 and 97 are described as "the dynamic payload types 96 and 97 have been assigned for the redundancy mechanism and the telephone event payload respectively"
2) In section 3.5, "E:", "A sender MAY delay setting the end bit until retransmitting the last packet for a tone, rather than on its first transmission" Does anyone have an idea of how to actually do this?
3) I have a separate output stream that also plays so wonder if it might be interfering with hearing this stream.
4) have also fiddled around with timestamp intervals and the RTP marker.
Any help is greatly appreciated. Here is a sample wireshark event capture of the relevant areas:
6590 31.159045000 xx.x.x.xxx --.--.---.-- RTP EVENT Payload type=RTP Event, DTMF Pound # (end)
Real-Time Transport Protocol
Stream setup by SDP (frame 6225)
Setup frame: 6225
Setup Method: SDP
10.. .... = Version: RFC 1889 Version (2)
..0. .... = Padding: False
...0 .... = Extension: False
.... 0000 = Contributing source identifiers count: 0
0... .... = Marker: False
Payload type: telephone-event (101)
Sequence number: 0
Extended sequence number: 65536
Timestamp: 2000
Synchronization Source identifier: 0x15f27104 (368210180)
RFC 2833 RTP Event
Event ID: DTMF Pound # (11)
1... .... = End of Event: True
.0.. .... = Reserved: False
..00 0000 = Volume: 0
Event Duration: 1000
Please note: A volume of zero is the loudest obtainable level as explained in the ietf.org/rfc/rfc2833.txt specification:
"volume: For DTMF digits and other events representable as tones,
this field describes the power level of the tone, expressed
in dBm0 after dropping the sign. Power levels range from 0 to
-63 dBm0. The range of valid DTMF is from 0 to -36 dBm0 (must
accept); lower than -55 dBm0 must be rejected (TR-TSY-000181,
ITU-T Q.24A). Thus, larger values denote lower volume. This
value is defined only for DTMF digits. For other events, it
is set to zero by the sender and is ignored by the receiver."
The issue is when the "End of Event" bit is switched on.

Answer 1

I recommend you to start with the RFC 4733 for two reasons:
It obsolotes the RFC 2833.
The chapter 5. is a great source to understand how a DTMF digit is produced.
Here is my understanding of how a DTMF digit should be sent:
A start packet is emitted. It has its M flag set and the E flag cleared. The timestamp for the event is set.
One or more continuation packets are emitted (as long as the user pressed the digit). They have theirs M And E flags cleared. They use the timestamp defined in the start packet, but their sequence numbers and their duration are incremented (see the RFC for the intervals).
An end packet is sent (when the user stop pressing the digit). It has it M flag cleared and its E flag set.
Why should several packets be sent for one event ? Because the network is not always perfect and some loss can occur:
The RFC states (2.5.1.2. "Transmission of Event Packets") that:
For robustness, the sender SHOULD
retransmit "state" events
periodically.
And (2.5.1.4. "Retransmission of Final Packet") that:
The final packet for each event and
for each segment SHOULD be sent a
total of three times at the interval
used by the source for updates.
This ensures that the duration of the
event or segment can be recognized
correctly even if an instance of the
last packet is lost.
As for your problem:
If for example keys
7874556332111111145855885#3 are
pressed, then ALL events are sent and
show up in a program like wireshark,
however only 87456321458585#3 sound.
So the first key (which I figure could
be a separate issue) and any repeats
of an event (ie 11111) are failing to
sound.
Without a WireShark trace, it is hard to tell what is going on, but I suspect that the repeating 1 digits are ignored because there is not distinction between successive events; the first 1 digit is recognized and the others are considered as retransmissions of the event.

Answer 2

I notice your Volume is set to 0; that seems like a likely reason to not be hearing any sound?

Answer 3

beauty! thanks a lot laurent. i have implemented a working solution based on your recommendations. (just posting as another answer to get better text formatting - I will give you the bounty)
to sum up what was wrong:
I needed redundancy of packets.
Setting all 'E's to 0 meant that repeated same key events were ignored.
Setting all 'E's to 1 meant that I signaled the end of an event, but not the actual event - hence the silence.
Here is a summarized flow example:
Event_ID M E Timestamp Duration Sequence_number
3 1 0 400 400 1
3 0 0 400 800 2
3 0 0 400 1200 3
3 0 0 400 1600 4
3 0 1 400 1600 5
3 0 1 400 1600 6
3 0 1 400 1600 7
7 1 0 800 400 8
7 0 0 800 800 9
7 0 0 800 1200 10
7 0 0 800 1600 11
7 0 1 800 1600 12
7 0 1 800 1600 13
7 0 1 800 1600 14
*note: just looked at the suggested rfc4733 first example in section 5 and it is great! much better than the 2833 ones