<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns="http://www.w3.org/TR/REC-html40">

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">
<meta name=Generator content="Microsoft Word 11 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman";}
a:link, span.MsoHyperlink
        {color:blue;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {color:purple;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:Arial;
        color:windowtext;}
@page Section1
        {size:8.5in 11.0in;
        margin:1.0in 1.25in 1.0in 1.25in;}
div.Section1
        {page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=EN-US link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Hi,<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>I have noticed a problem with some IP phones and am unsure
how to correct this issue in fs.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>There are no settings on the IP phone that would correct the
problem experienced.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Vender notes<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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 &#8220;duration&#8221; in each packet increases by 80. Duration is in
&#8220;samples&#8221;, 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.
<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>Since the Polycom sends exactly one packet in each 20 ms
time slot, even during a DTMF event, that works with the FS.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'>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.<o:p></o:p></span></font></p>

<p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><font
size=2 color="#1f497d" face=Calibri><span style='font-size:11.0pt;font-family:
Calibri;color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Note the issue was noticed when the information was leaving
our freeswitch and heading out to the carrier.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>We use bypass media and passive dtmf is set to true.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Any assistance would be great.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'>Thanks.<o:p></o:p></span></font></p>

<p class=MsoNormal><font size=2 face=Arial><span style='font-size:10.0pt;
font-family:Arial'><o:p>&nbsp;</o:p></span></font></p>

</div>

</body>

</html>