<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:m="http://schemas.microsoft.com/office/2004/12/omml" 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 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"Comic Sans MS";
panose-1:3 15 7 2 3 3 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 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","serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"Balloon Text Char";
margin:0in;
margin-bottom:.0001pt;
font-size:8.0pt;
font-family:"Tahoma","sans-serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.BalloonTextChar
{mso-style-name:"Balloon Text Char";
mso-style-priority:99;
mso-style-link:"Balloon Text";
font-family:"Tahoma","sans-serif";}
span.EmailStyle22
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:873929604;
mso-list-template-ids:2019821514;}
@list l0:level1
{mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level2
{mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level3
{mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level4
{mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level5
{mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level6
{mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level7
{mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level8
{mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l0:level9
{mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l1
{mso-list-id:2064060877;
mso-list-template-ids:1241686790;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I believe his OOB (MGCP) to 2833 (SIP handsets) is using the MTPs, but not 100% sure, but a CCM Trace would show MRM and Media invoking MTP based on the SDPs. I know an end to end sip (handsets and sip trunks) with2833 doesn’t need MTPs. I would considering switching from MGCP to SIP Trunk myself.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] <b>On Behalf Of </b>Eric Pedersen<br><b>Sent:</b> Wednesday, September 26, 2012 10:59 AM<br><b>To:</b> abbas Wali; cisco-voip@puck.nether.net<br><b>Subject:</b> Re: [cisco-voip] MTP resources Codecs mismatch and DTMF relay<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><o:p> </o:p></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>I'm pretty sure you'll always need MTPs with RFC 2833 because DTMF is carried in the RTP stream. Can you use KPML on your SIP trunks to the IVRs? <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> cisco-voip-bounces@puck.nether.net [mailto:cisco-voip-bounces@puck.nether.net] <b>On Behalf Of </b>abbas Wali<br><b>Sent:</b> 25 September 2012 11:55 AM<br><b>To:</b> cisco-voip@puck.nether.net<br><b>Subject:</b> [cisco-voip] MTP resources Codecs mismatch and DTMF relay<o:p></o:p></span></p></div><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Recently we had a major VOIP fault which was escalated to TAC. Whom also spent some good time before realizing that we were running out of MTP resources at busy times. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>What was happening that calls coming on phones and as soon as the receiver was lifted, the called party was hearing a fast busy. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Initially we had to restart the whole cluster and it used to settled down. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>In the end we have to increase the MTP resources in the Service Parameters from 24 to 48 for each of the nodes, since then this fault has gone away. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Just going back into recent past –we believed that this issue started after we enabled MTP resource requirements for the SIP trunks, who at that time were struggling with the DTMF relays. So by enabling it for the SIP trunks we got into contentions for the rest of the network. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>My question is (and I have overheard somewhere) that if your cluster is configured properly, you will never require the use of MTP resources (or may be in a very lesser amount). Also I feel like some mis configuration on the SIP trunks which has forced us to get help from the MTP resources to support the DTMF relays. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Below are some of the points which emphasizes my points<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><ol start=1 type=1><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'><span style='font-size:7.0pt'> </span>PCM type for our E1 cards are set to A-Law but when we make an VOIP to VOIP call internally it shows the codec as ULaw. (so to me it looks like that we are using MTP to convert from A to U for incoming PSTN calls)<o:p></o:p></li><li class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0 level1 lfo3'><b><span style='font-size:7.0pt'> </span></b>For the DTMF –the gateways are configured with <b><u>mgcp dtmf-relay voip codec all mode out-of-band </u></b>while some of the SIP trunks are set to RFC 2833. I believe these are two different modes which again requires MTP for translation. <o:p></o:p></li></ol><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b> </b><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I believe if we make the codecs even by forcing the CUCM to use A Law internally as well and also use one single mode for the DTMF relays then we should not require to increase the MTP resources.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Just to add we are using CUCM 8.5. we have some 7k phones. we have MGCP gateways. And SIP trunks to 3<sup>rd</sup> party IVR’s and another neighbour CUCM 7.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Any help will be appreciated. <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='margin-bottom:12.0pt'><br clear=all><br>-- <br><span style='font-size:13.5pt;font-family:"Comic Sans MS";color:#000099'>@bbas.. </span><o:p></o:p></p><p class=MsoNormal><br><br><span style='color:white'>itevomcid</span> <o:p></o:p></p><pre>The contents of this message may contain confidential and/or privileged<o:p></o:p></pre><pre>subject matter. If this message has been received in error, please contact<o:p></o:p></pre><pre>the sender and delete all copies. Like other forms of communication,<o:p></o:p></pre><pre>e-mail communications may be vulnerable to interception by unauthorized<o:p></o:p></pre><pre>parties. If you do not wish us to communicate with you by e-mail, please<o:p></o:p></pre><pre>notify us at your earliest convenience. In the absence of such<o:p></o:p></pre><pre>notification, your consent is assumed. Should you choose to allow us to<o:p></o:p></pre><pre>communicate by e-mail, we will not take any additional security measures<o:p></o:p></pre><pre>(such as encryption) unless specifically requested.<o:p></o:p></pre><pre><o:p> </o:p></pre></div></body></html>