[patch] Incoming RFC 2833 DTMF detection

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi!

When testing my pjsip app with another SIP gateway I noticed not all DTMF events were coming through. I particular of subsequent events with the *same* digit only the first was recognized; all subsequent events did not trigger a callback to my application.

A patch is attached to this message; the following is an explanation.

=====================================================================

Inspection of the RTP packets (with Wireshark) and the code in the on_rx_rtp and handle_incoming_dtmf functions (in pjmedia/src/pjmedia/stream.c) reveals that:
- The SIP gateway sends several RTP packets for one DTMF event, but all of these always have the *same* value for the duration field: 800. Other gateways incrementally increase the duration in each subsequent packet of one event (see sections 3.4 - 3.6 of RFC 2833, http://www.ietf.org/rfc/rfc2833.txt).
- PJSIP considers any subsequent DTMF packet with the same digit and an *equal* or larger duration as pertaining to the same event as the previous packet.
So this explains why subsequent events for the same digit are discarded; the durations of the packets are always equal.

There are various ways a new event could be detected:
- all packets belonging to the same event have the same timestamp field (in the RTP header)
- first packet has market bit set (in the RTP header)
- last packet of an event has an 'end' bit set (in the RFC 2833 payload); note: usually at least three duplicates of this packet are sent
- the first packet of a new event may have a smaller duration than that of the last packet

The attached patch considers all subsequent packets with the same timestamp (and digit) as one event.

The only case that it would not handle correctly is if the packets for two events would somehow overlap; this may be fixed by changing
	pj_ntohl(hdr->ts) == stream->last_dtmf_ts
in the patch to
	pj_ntohl(hdr->ts) <= stream->last_dtmf_ts
but then we'd have to rely on proper ordering of the timestamps.

Regards,

Bram
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pjsip_incoming_dtmf.patch
URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20100501/2f282946/attachment.patch>


[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux