[cisco-voip] MTP resources Codecs mismatch and DTMF relay

[abbas Wali]

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.


What was happening that calls coming on phones and as soon as the receiver
was lifted, the called party was hearing a fast busy.

Initially we had to restart the whole cluster and it used to settled down.



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.



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.



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.



Below are some of the points which emphasizes my points



   1.  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)**
   2. * *For the DTMF –the gateways are configured with  *mgcp dtmf-relay
   voip codec all mode out-of-band *while some of the SIP trunks are set to
   RFC 2833. I believe these are two different modes which again requires MTP
   for translation.

* *

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.





Just to add we are using CUCM 8.5. we have some 7k phones. we have MGCP
gateways. And SIP trunks to 3rd party IVR’s and another neighbour CUCM 7.

Any help will be appreciated.




-- 
@bbas..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20120925/77d1286d/attachment.html>