[cisco-voip] CUCM MTP and g729

Tue Jan 15 11:08:14 EST 2013

Here is the trace from the MTP registering, showing that it supports
pass-through:

10:49:20.397 |StationInit: (0000001) CapabilitiesRes capCount=6 *caps=
258(0)*
...
10:49:20.397
|MediaTerminationPointControl(1)::wait_capabilities_StationCapRes - Device
= SUB02B_MTP - *Pass-Through Supported = 1*|[redacted]

Looks like it's the 258 you and Ryan spoke of.  Mystery solved!  Thanks to
all who provided input.

On Sat, Jan 12, 2013 at 3:43 PM, Peter Slow <peter.slow at gmail.com> wrote:

> Ryan, that's awesome, didn't know that.
>
> Anthony, it looks like the pass through codec Ryan is talking about is
> registered as codec number 258. Look for that in the capabilitiesresponse
> message.
>
> Sent from my iPad
>
> On Jan 12, 2013, at 12:45 PM, "Jason Aarons (AM)" <
> jason.aarons at dimensiondata.com> wrote:
>
> 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<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> 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> 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> 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> 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
> >> https://puck.nether.net/mailman/listinfo/cisco-voip
> >>
> >
> >
> > _______________________________________________
> > cisco-voip mailing list
> > cisco-voip at puck.nether.net
> > https://puck.nether.net/mailman/listinfo/cisco-voip
> >****
>
> ** **
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip****
>
> ** **
>
>
>
> itevomcid ****
>
> _______________________________________________
> cisco-voip mailing list
> cisco-voip at puck.nether.net
> https://puck.nether.net/mailman/listinfo/cisco-voip
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130115/b7c28c69/attachment.html>