<div dir="ltr"><div><div><div><br>Hey Wes,<br><br></div>The packet capture was done on the CUCM itself via CLI command: "utils network capture".  Also, I filtered the capture to traffic only coming from the VG224, which is why you do not see any other streams.  It was, however, going to our SBC.  So the call flow was: Analog Phone > VG224 > CUCM (MTP) > SBC > PSTN.<br>
<br></div>The negotiated CODEC was in fact g729, and both sides support it.  The MGCP SDP shows g729 and the SBC sends back g729 in the SIP SDP.  The only thing that is different in caps is DTMF.  MGCP was trying 100 while SBC wanted to do 101.<br>
<br></div>As for the garble: I wasn't experiencing any voice quality issues that I could hear, but I was experiencing double DTMF going out to the PSTN.  Not sure if an artifact of the MTP, or simply a misonconfiguration on the VG224's MGCP package.  Like I said it's the fm package I was missing that ultimately fixed the issue.  The MTP is no longer used, and the double DTMF is gone. I didn't find very much info on what the fm packages does, only that it fixes DTMF and Faxing issues when communicating with a SIP device.<br>
<div class="gmail_extra"><br></div><div class="gmail_extra">Thanks for the late Friday afternoon reply Wes.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk <span dir="ltr"><<a href="mailto:wsisk@cisco.com" target="_blank">wsisk@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Interesting observations.<br>
<br>
I am not aware of any changes around CM's software MTP only doing G.711.<br>
<br>
The packet capture shows RTP coming into(?) to the MTP. I do not see any sign of anything egressing the MTP.<br>
<br>
ccm has internal logic that attempts to connect RTP streams even if codec negotiation fails. This is controlled by a service parameter. You may be seeing an artifact of this behavior where no codec was common but the streams attempted to setup anyway.  Streaming codecs to the MTP that it does not support typically results in garble or silence on the egress leg.<br>

<br>
/wes<br>
<div><div class="h5"><br>
<br>
On Jan 11, 2013, at 3:11 PM, Anthony Holloway wrote:<br>
<br>
Hi All,<br>
<br>
I have a wireshark capture off of my CUCM 8.6(2) which shows that it is receiving a g729 audio stream from my VG224.<br>
<br>
Long story short, according to the CUCM SRND, the CUCM MTP can only terminate g711, and yet, attached is a screenshot of the wireshark capture which clearly shows it terminating g729.<br>
<br>
What piece of this puzzle am I missing?  Also, the CUCM traces read like the MTP is being invoked on that CUCM.  It's due to the lack of the fm package on my VG224 and a mismatch in DTMF to the PSTN (SIP).  I had a fun time resolving that, as you can probably imagine.<br>

<br>
Thanks and Happy Friday!<br>
<br>
<br>
</div></div><cucm-mtp-g729-redacted.png><cucm-mtp-redacted.png><cucm-sub02b-redacted.png>_______________________________________________<br>
<div class="HOEnZb"><div class="h5">cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
<br>
</div></div></blockquote></div><br></div></div>