[cisco-voip] CUCM MTP and g729

[Peter Slow]

the skinny signalling is between the MTP and the CUCM - thats how it
knows what RTP streams to send and expect and which ones to tie with
which. you can tell a CUCM MTP on server A to register with CUCM on
server B - this forces that MTPS skinny signalling over the wire so
you can get a packet capture of it. use the CM group on the device
pool of the MTP, ANN conference or MoH device to do this - it will
work for all of those types of endpoints. seeing the skinny signalling
in your packet catpure woudl be a very easy way of proving
specifically what service that RTP is destined for.

easier than looking at traces anyway =)

...this is also how you'd get a packet capture of the registration of
those devices. that would allow you to see which ones were reporting
729 support.

there HAVE been a couple instances here and there where CUCM
mistakenly signals one device to use a codec that the other device
doesnt support, but thats typically a very very complex call flow and
probably not what's happening here. There is liekly a more simple
explanation =)

-Pete

On Fri, 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
>> >
>
>