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

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 notice your Volume is set to 0; that seems like a likely reason to not be hearing any sound?

Answer 2

I recommend you to start with the RFC 4733 for two reasons:

1. It obsolotes the RFC 2833.
2. 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 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:

1. I needed redundancy of packets.
2. Setting all 'E's to 0 meant that repeated same key events were ignored.
3. 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