Certain carriers (Symbio, Verizon) have a tendency to send slightly bogus RFC 2833 DTMF packets. These messages have end packets with a shorter duration than the final non-end DTMF packet. The way that PJSIP interprets these packets ends up creating duplicated incoming DTMF events. as an example, this is what occurs for a single digit 7 press (extracted from actual packet capture): +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | event |E|R| volume | duration | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DTMF 7 |0|0| 10 | 240 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 320 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 480 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 640 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 800 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 960 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 1120 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 1280 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 1440 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 1600 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |0|0| 10 | 1760 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |1|0| 10 | 1680 | <-- mis-detected as a second DTMF 7 +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |1|0| 10 | 1680 | +---------------+-+-+-----------+-------------------------------+ | DTMF 7 |1|0| 10 | 1680 | +---------------+-+-+-----------+-------------------------------+ Attached is a patch for pjsip 2.2.1 for rtp.h and stream.c, which cause it to monitor the end bits. In the event that an end bit is send, and the digit remains the same as the last received digit, the duration field being different is not used to determine that a new digit was pressed. We have used this patch in production for the last 3 years (since 2.0.1) and it has resolved duplicated DTMF issues for us. regards ?doug wadsworth -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150317/79f379b9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: dtmf.patch Type: application/octet-stream Size: 2743 bytes Desc: not available URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150317/79f379b9/attachment.patch> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150317/79f379b9/attachment-0001.html>
