[cisco-voip] CUCM MTP and g729

Sat Jan 12 12:45:23 EST 2013

I got a customer running 8.5.1SU2 and it's not doing IP Voice Media Streaming App MTP with Pass-Thru.  Just had a big TAC case with T38 and took awhile for the TAC lead to come to that conclusion.  A IOS Software MTP was needed to fix it.

I've looked previously and haven't found any details about fix/improvement (eg what's new) around IP Voice Media Streaming App in newer versions.

From: cisco-voip-bounces at puck.nether.net [mailto:cisco-voip-bounces at puck.nether.net] On Behalf Of Ryan Ratliff
Sent: Friday, January 11, 2013 5:03 PM
To: Anthony Holloway
Cc: Cisco VoIP Group
Subject: Re: [cisco-voip] CUCM MTP and g729

Check the capabilities the MTP advertises to CUCM when it registers.  At some point (8.5 maybe?) IP Voice Media Streaming App began supporting audio passthrough, which would explain what you are seeing.

-Ryan

On Jan 11, 2013, at 4:36 PM, Anthony Holloway <avholloway+cisco-voip at gmail.com<mailto:avholloway+cisco-voip at gmail.com>> wrote:

Thanks Pete.  I'll see if I can answer or reply to each of your questions or points.

"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?"
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.

"Do you have the skinny signalling to go with it showing what it was specifically set up for use as?"
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.

"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 =)"
Again, this is an established call.  I get the call setup, verify two way audio, and then take the capture.

"I don't think you're really goign to get an answer unless you can recreate the issue"
I can.  I have the VG224 in my cubicle.  Check out the adapter I'm using!  Photo attached.  =)

"and we can see traces."
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.

"you'll also want a packet capture of the registration of the media device"
This is a good idea.  I'll give it a try and see what it reports.

"you coudl be doing duplex audio while one of those is playing"
I'm not sure what that means, or how that would even work, but you sound excited.  =)

"anyway, can you reproduce it"
Yes.  I can reproduce it at will.
Thanks for asking the questions and commenting.

On Fri, Jan 11, 2013 at 3:24 PM, Peter Slow <peter.slow at gmail.com<mailto:peter.slow at gmail.com>> wrote:
PS> ..Also, 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? ...'Cause that would totally explain this packet capture. Do
you have the skinny signalling to go with it showing what it was
specifically set up for use as?

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 =)

I don't think you're really goign to get an answer unless you can
recreate the issue and we can see traces. you'll also want a packet
capture of the registration of the media device, so if you can make
the MTP register to a different callmanager than what it's running on,
using its CUCM group, we could take a look at what capabilities it was
registering with and if it says it supports 729 now =) ..you'll wnat
to look at the skinny registration of the MTP, ANN ooh, ANN
announcements are in 7.29 also, i think? you coudl be doing duplex
audio while one of those is playing =)....

anyway, can you reproduce it or verify or deny any of those guesses?

Very Interesting,
-Pete

On Fri, Jan 11, 2013 at 4:08 PM, Anthony Holloway
<avholloway+cisco-voip at gmail.com<mailto:avholloway%2Bcisco-voip at gmail.com>> wrote:
>
> Hey Wes,
>
> 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.
>
> 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.
>
> 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.
>
> Thanks for the late Friday afternoon reply Wes.
>
> On Fri, Jan 11, 2013 at 2:48 PM, Wes Sisk <wsisk at cisco.com<mailto:wsisk at cisco.com>> wrote:
>>
>> Interesting observations.
>>
>> I am not aware of any changes around CM's software MTP only doing G.711.
>>
>> The packet capture shows RTP coming into(?) to the MTP. I do not see any
>> sign of anything egressing the MTP.
>>
>> 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.
>>
>> /wes
>>
>>
>> On Jan 11, 2013, at 3:11 PM, Anthony Holloway wrote:
>>
>> Hi All,
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> Thanks and Happy Friday!
>>
>>
>>
>> <cucm-mtp-g729-redacted.png><cucm-mtp-redacted.png><cucm-sub02b-redacted.png>_______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
> https://puck.nether.net/mailman/listinfo/cisco-voip
>

_______________________________________________
cisco-voip mailing list
cisco-voip at puck.nether.net<mailto:cisco-voip at puck.nether.net>
https://puck.nether.net/mailman/listinfo/cisco-voip

itevomcid
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130112/e4c67d11/attachment.html>