I have seen an issue where the DTMF digits that were being press, some of the digits were being triplicated. Example: user presses 79546 and what it was being interpretted as was 77795. The only thing different we could find was that the event duration increases by 80 on each of the three end bits for the 7. A patch was put in to mask the last two digits, and it worked. I didn't see anything specific in the RFC stating that the digits rely on the event duration staying the same. And when I look at calls that work, the event duration never changes. Any ideas? asked 11 Mar '13, 10:54  Engineer1976 |
One Answer:
RTP events are funny things. The idea is that at the start the RTP timestamp is fixed and a duration is incremented with the RTP packet rate. The '..' indicates the packetizing delay. In this way you can encode the duration of the keypress, without knowing it in advance, or interrupt the RTP stream for the duration, which doesn't help the receiver. There's a specific way to annotate the end of a keypress. There's a marker in the RTP event signaling the end, and to prevent it from getting lost (it's UDP after all) it is advised to repeat the final RTP event three times. So that would look something like this. Three RTP event packets with the final marker (!) set, in rapid succession, there's no packetizing delay, nor increment of the timestamp or duration. After that the the normal RTP time stamping resumes, adjusted for the time consumed by the event. If your RTP event source doesn't work this way you should talk to the supplier. answered 11 Mar '13, 16:00  Jaap ♦ |
Is the equpment detecting the tones on the IP side or after coversion to TDM? if it's the later the duration mathers.
So, this is on an Avaya Experience Portal. It appears to be being presented to it with the different durations. And in the pcap file that is pulled off, when looking at the DTMF tones I see the event duration increasing on the end bits of the first digit. So the AEP is interpretting that as three different 7's.