Hi,

I have noticed a problem with some IP phones and am unsure how to correct this issue in fs.

There are no settings on the IP phone that would correct the problem experienced.

If anyone has any suggestions please let me know. Note this problem is experienced with git versions from late last year and from January this year.

Vender notes

The sequence of DTMF event messages we send is actually pretty logical when you look at it closely. We send three packets with 0 duration to announce the beginning of the DTMF event. This mirrors the 3 packets sent at the end with the final duration. The Polycom does the latter, but not the former. In between we send a packet with a new duration every 10ms. The “duration” in each packet increases by 80. Duration is in “samples”, 80 make up 10 ms. Once the codec knows that the DTMF event has ended, it begins the sequence of 3 redundant end packets showing the final duration. So, looking at the sequence of durations, the normal last three are supplanted by the 3 redundant end packets. The Polycom does the same thing.

The difference between us and the Polycom is that the PC sends exactly one packet every 20 ms in the stream, in place of the audio packet that would have been sent. We, OTOH, 1) send the DTMF event packets as soon as they are ready, 2) do not send the same number of packets as the audio codec would have. As a result, we send a different number of packets during a DTMF event than during normal audio.

The Freeswitch appears to assume that all packets in an RTP stream represent the same amount of time, 20ms in this case. During our DTMF event, this is not the case. If you look at the rtp coming into the FS and going out, our first 5 DTMF packets arrive very soon after the last audio packet. The FS delays them and sent each one in a 20ms slot. But DTMF packets do not map linearly to the timeline. Therefore distorts the stream of packets. Our DTMF packets arrive spread over a much longer time than the actual duration of the DTMF event. That is almost certainly the cause of the problem.

Since the Polycom sends exactly one packet in each 20 ms time slot, even during a DTMF event, that works with the FS.

When you think about it, the whole reason for RTP is to handle changes in latency, missing packets and so on, it does not make sense for the FS to force every packet into a 20 ms timeslot.

The answer is simply for the FS to forward DTMF packets immediately instead of delaying them for a 20 ms timeslot. IMHO, all RTP packets should be forwarded this way.

I am pretty sure about what is happening in our phone that causes the timing oddities. When a DTMF event physically starts, the codec starts sending DTMF packets. However, the DTMF packets have no encoding latency, so the first packets seem to arrive immediately after the last audio packet. Then when the latency has fallen to zero, packets go out every 10 ms with corresponding increases in duration. AT the end, the encoding latency must be re-established so there is a gap in the time line after the last DTMF event is received and the first audio packet.

Note the issue was noticed when the information was leaving our freeswitch and heading out to the carrier.

We use bypass media and passive dtmf is set to true.

Any assistance would be great.

Thanks.