<div dir="ltr"><div><div><div><div><div>Thanks Pete.  I'll see if I can answer or reply to each of your questions or points.<br><br><b>"are you SURE this isn't just a device hearing g.729 hold music while you've got or had the Duplex Streaming service parameter
enabled?"</b><br></div>No, this is a call from an analog device to a PSTN device, and the call is well established and in progress with two way audio.<br><br><b>"Do
you have the skinny signalling to go with it showing what it was
specifically set up for use as?"</b><br></div>I'm not sure I understand where the skinny signaling comes in.  The VG224 is MGCP, the SBC is a SIP trunk, and the MTP is local to the CUCM.  Could you help me understand?  I do have traces off the CUCM if that answers your question.<br>
<br><b>"Also, I beleive MGCP Endpoints have an initial "state" when they begin call setup. i think not using g.729 actually entails a switch from 729 to another codec, and perhaps a small delay is causing some packets to be transmitted using g.729? maybe? that's a complete stretch but who knows =)"</b><br>
</div>Again, this is an established call.  I get the call setup, verify two way audio, and then take the capture.<br><br><b>"I don't think you're really goign to get an answer unless you can recreate the issue"</b><br>
</div>I can.  I have the VG224 in my cubicle.  Check out the adapter I'm using!  Photo attached.  =)<br><br><b>"and we can see traces."</b><br>I can't upload traces to the list, but if this goes to a TAC case, I will certainly give them up at that time.<br>
<br><b>"you'll also want a packet capture of the registration of the media device"</b><br></div><div>This is a good idea.  I'll give it a try and see what it reports.<br><br><b>"you coudl be doing duplex audio while one of those is playing"</b><br>
</div><div>I'm not sure what that means, or how that would even work, but you sound excited.  =)<br><br><b>"anyway, can you reproduce it"</b><br></div><div>Yes.  I can reproduce it at will.<br><br></div><div>
Thanks for asking the questions and commenting.<br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Jan 11, 2013 at 3:24 PM, Peter Slow <span dir="ltr"><<a href="mailto:peter.slow@gmail.com" target="_blank">peter.slow@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">PS> ..Also, are you SURE this isn't just a device hearing g.729 hold<br>
music while you've got or had the Duplex Streaming service parameter<br>
enabled? ...'Cause that would totally explain this packet capture. Do<br>
you have the skinny signalling to go with it showing what it was<br>
specifically set up for use as?<br>
<br>
Also, I beleive MGCP Endpoints have an initial "state" when they begin<br>
call setup. i think not using g.729 actually entails a switch from 729<br>
to another codec, and perhaps a small delay is causing some packets to<br>
be transmitted using g.729? maybe? that's a complete stretch but who<br>
knows =)<br>
<br>
I don't think you're really goign to get an answer unless you can<br>
recreate the issue and we can see traces. you'll also want a packet<br>
capture of the registration of the media device, so if you can make<br>
the MTP register to a different callmanager than what it's running on,<br>
using its CUCM group, we could take a look at what capabilities it was<br>
registering with and if it says it supports 729 now =) ..you'll wnat<br>
to look at the skinny registration of the MTP, ANN ooh, ANN<br>
announcements are in 7.29 also, i think? you coudl be doing duplex<br>
audio while one of those is playing =)....<br>
<br>
anyway, can you reproduce it or verify or deny any of those guesses?<br>
<br>
Very Interesting,<br>
-Pete<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Fri, Jan 11, 2013 at 4:08 PM, Anthony Holloway<br>
<<a href="mailto:avholloway%2Bcisco-voip@gmail.com">avholloway+cisco-voip@gmail.com</a>> wrote:<br>
><br>
> Hey Wes,<br>
><br>
> The packet capture was done on the CUCM itself via CLI command: "utils<br>
> network capture".  Also, I filtered the capture to traffic only coming from<br>
> the VG224, which is why you do not see any other streams.  It was, however,<br>
> going to our SBC.  So the call flow was: Analog Phone > VG224 > CUCM (MTP) ><br>
> SBC > PSTN.<br>
><br>
> The negotiated CODEC was in fact g729, and both sides support it.  The MGCP<br>
> SDP shows g729 and the SBC sends back g729 in the SIP SDP.  The only thing<br>
> that is different in caps is DTMF.  MGCP was trying 100 while SBC wanted to<br>
> do 101.<br>
><br>
> As for the garble: I wasn't experiencing any voice quality issues that I<br>
> could hear, but I was experiencing double DTMF going out to the PSTN.  Not<br>
> sure if an artifact of the MTP, or simply a misonconfiguration on the<br>
> VG224's MGCP package.  Like I said it's the fm package I was missing that<br>
> ultimately fixed the issue.  The MTP is no longer used, and the double DTMF<br>
> is gone. I didn't find very much info on what the fm packages does, only<br>
> that it fixes DTMF and Faxing issues when communicating with a SIP device.<br>
><br>
> Thanks for the late Friday afternoon reply Wes.<br>
><br>
> On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk <<a href="mailto:wsisk@cisco.com">wsisk@cisco.com</a>> wrote:<br>
>><br>
>> 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<br>
>> sign of anything egressing the MTP.<br>
>><br>
>> ccm has internal logic that attempts to connect RTP streams even if codec<br>
>> negotiation fails. This is controlled by a service parameter. You may be<br>
>> seeing an artifact of this behavior where no codec was common but the<br>
>> streams attempted to setup anyway.  Streaming codecs to the MTP that it does<br>
>> not support typically results in garble or silence on the egress leg.<br>
>><br>
>> /wes<br>
>><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<br>
>> receiving a g729 audio stream from my VG224.<br>
>><br>
>> Long story short, according to the CUCM SRND, the CUCM MTP can only<br>
>> terminate g711, and yet, attached is a screenshot of the wireshark capture<br>
>> which clearly shows it terminating g729.<br>
>><br>
>> What piece of this puzzle am I missing?  Also, the CUCM traces read like<br>
>> the MTP is being invoked on that CUCM.  It's due to the lack of the fm<br>
>> package on my VG224 and a mismatch in DTMF to the PSTN (SIP).  I had a fun<br>
>> time resolving that, as you can probably imagine.<br>
>><br>
>> Thanks and Happy Friday!<br>
>><br>
>><br>
>><br>
>> <cucm-mtp-g729-redacted.png><cucm-mtp-redacted.png><cucm-sub02b-redacted.png>_______________________________________________<br>
>> 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>
><br>
><br>
> _______________________________________________<br>
> 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>