[cisco-voip] CUCM MTP and g729

Fri Jan 11 16:36:13 EST 2013

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
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130111/675b1648/attachment.html>