[Freeswitch-users] dtmf problems

[Jason Holden]

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.

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20120720/3cc6586d/attachment.html