MTP required to use G.729 and RFC 2833 over a SIP trunk?

Unanswered Question
Oct 18th, 2010
User Badges:

I have a CUCM 7.0 cluster with a SIP trunk to a 2811 CME router.   When I switch the codec in CME to G.729 I lose DTMF functionality.  I noticed in the SIP message traces that CUCM doesn't attempt to negotiate RFC 2833 (telephony-event in the sdp) anywhere to any endpoints (SIP trunk or not).   I've seen some resources and documentation which imply that an MTP may be required to enable RFC 2833 and I can see CUCM failing to allocate an MTP in the trace logs.


Here's my router mgcp and sccp configuration:


mgcp
mgcp call-agent 10.0.20.60 2427 service-type mgcp version 0.1
mgcp dtmf-relay voip codec all mode nte-ca
mgcp rtp unreachable timeout 1000 action notify
mgcp modem passthrough voip mode nse
mgcp package-capability mf-package
mgcp package-capability rtp-package
no mgcp package-capability res-package
mgcp package-capability sst-package
mgcp package-capability pre-package
mgcp package-capability fm-package
no mgcp timer receive-rtcp
mgcp sdp simple
mgcp rtp payload-type g726r16 static
mgcp rtp payload-type nte 101
!
mgcp profile default
!
sccp local GigabitEthernet0/0
sccp ccm 10.0.20.60 identifier 1 priority 1 version 4.1
sccp
!
sccp ccm group 1
 associate ccm 1 priority 1
 associate profile 4 register XCODE_VRT01
 associate profile 3 register MTP_VRT01_G729
 associate profile 2 register MTP_VRT01_G711
 associate profile 1 register MTP0015627f9a98
!
dspfarm profile 4 transcode
 codec g711ulaw
 codec g711alaw
 codec g729ar8
 codec g729abr8
 codec g729br8
 codec g729r8
 maximum sessions 4
 associate application SCCP
!
dspfarm profile 1 mtp
 codec g729br8
 maximum sessions software 24
 associate application SCCP
!
dspfarm profile 2 mtp
 codec g711ulaw
 maximum sessions software 24
 associate application SCCP
!
dspfarm profile 3 mtp
 codec g729r8
 maximum sessions software 24
 associate application SCCP


Here's a show sccp showing that they've been successfully registered (and I can also see them being tried in the trace files):


SCCP Admin State: UP
Gateway IP Address: 10.0.20.50, Port Number: 2000
IP Precedence: 5
User Masked Codec list: None
Call Manager: 10.0.20.60, Port Number: 2000
                Priority: 1, Version: 4.1, Identifier: 1

Software MTP Oper State: ACTIVE - Cause Code: UNKNOWN
Active Call Manager: 10.0.20.60, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 1
Reported Max Streams: 48, Reported Max OOS Streams: 0
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30

Software MTP Oper State: ACTIVE - Cause Code: UNKNOWN
Active Call Manager: 10.0.20.60, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 2
Reported Max Streams: 48, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30

Software MTP Oper State: ACTIVE - Cause Code: UNKNOWN
Active Call Manager: 10.0.20.60, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 3
Reported Max Streams: 48, Reported Max OOS Streams: 0
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30

Transcoding Oper State: ACTIVE - Cause Code: NONE
Active Call Manager: 10.0.20.60, Port Number: 2000
TCP Link Status: CONNECTED, Profile Identifier: 4
Reported Max Streams: 8, Reported Max OOS Streams: 0
Supported Codec: g711ulaw, Maximum Packetization Period: 30
Supported Codec: g711alaw, Maximum Packetization Period: 30
Supported Codec: g729ar8, Maximum Packetization Period: 60
Supported Codec: g729abr8, Maximum Packetization Period: 60
Supported Codec: g729br8, Maximum Packetization Period: 60
Supported Codec: g729r8, Maximum Packetization Period: 60
Supported Codec: rfc2833 dtmf, Maximum Packetization Period: 30


Here's the dial-peer configuration for CME:

dial-peer voice 1 voip
 destination-pattern 9.+T
 voice-class sip dtmf-relay force rtp-nte
 voice-class sip early-offer forced
 session protocol sipv2
 session target ipv4:10.0.20.60
 dtmf-relay rtp-nte
 codec g729br8



Curiously, I don't see any meaningful counters being hit when I try to call and the MTP is queried for capabilities:



SCCP Application Service(s) Statistics:

Profile Identifier: 1, Service Type: Software MTP
TCP packets rx 123, tx 126
Unsupported pkts rx 0, Unrecognized pkts rx 0
Register tx 1, successful 1, rejected 0, failed 0
KeepAlive tx 120, successful 120, failed 0
OpenReceiveChannel rx 0, successful 0, failed 0
CloseReceiveChannel rx 0, successful 0, failed 0
StartMediaTransmission rx 0, successful 0, failed 0
StopMediaTransmission rx 0, successful 0, failed 0
Reset rx 0, successful 0, failed 0
MediaStreamingFailure rx 0
Switchover 0, Switchback 0


Profile Identifier: 2, Service Type: Software MTP
TCP packets rx 101, tx 112
Unsupported pkts rx 0, Unrecognized pkts rx 0
Register tx 5, successful 1, rejected 4, failed 0
KeepAlive tx 94, successful 94, failed 0
OpenReceiveChannel rx 0, successful 0, failed 0
CloseReceiveChannel rx 0, successful 0, failed 0
StartMediaTransmission rx 0, successful 0, failed 0
StopMediaTransmission rx 0, successful 0, failed 0
Reset rx 0, successful 0, failed 0
MediaStreamingFailure rx 0
Switchover 0, Switchback 0


Profile Identifier: 3, Service Type: Software MTP
TCP packets rx 102, tx 117
Unsupported pkts rx 0, Unrecognized pkts rx 0
Register tx 7, successful 1, rejected 6, failed 0
KeepAlive tx 93, successful 93, failed 0
OpenReceiveChannel rx 0, successful 0, failed 0
CloseReceiveChannel rx 0, successful 0, failed 0
StartMediaTransmission rx 0, successful 0, failed 0
StopMediaTransmission rx 0, successful 0, failed 0
Reset rx 0, successful 0, failed 0
MediaStreamingFailure rx 0
Switchover 0, Switchback 0


Profile Identifier: 4, Service Type: Transcoding
TCP packets rx 51, tx 60
Unsupported pkts rx 0, Unrecognized pkts rx 0
Register tx 4, successful 1, rejected 3, failed 0
KeepAlive tx 45, successful 45, failed 0
OpenReceiveChannel rx 0, successful 0, failed 0
CloseReceiveChannel rx 0, successful 0, failed 0
StartMediaTransmission rx 0, successful 0, failed 0
StopMediaTransmission rx 0, successful 0, failed 0
Reset rx 0, successful 0, failed 0
MediaStreamingFailure rx 0
Switchover 0, Switchback 0


Any help getting DTMF working with G.729 over this SIP trunk would be greatly appreciated!

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
zangelo_vbar Mon, 10/18/2010 - 15:34
User Badges:

It looks like my MTP selection is failing here:



10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::getResourcesAllocated -- Logging RegionB=VB10K Caps and MTP/XCoder Region=Houston Caps|
10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::logCapabilitiesinTrace -- MTP/XCoder Device Caps = 4 257 |
10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::logCapabilitiesinTrace -- Device Caps = 4 |
10/18/2010 17:13:46.031 CCM|RegionsServer::MatchCapabilities -- kbps=8, capACount=1, capBCount=2|
10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::getResourcesAllocated -- No matching caps for either side A or side B, MTP not allocated|
10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::getResourcesAllocated -- match1=1 match2=0|
10/18/2010 17:13:46.031 CCM|MediaTerminationPointControl(98)::getResourcesAllocated -- allocateErrBitset=0x41|
10/18/2010 17:13:46.032 CCM|MediaTerminationPointControl(98)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=29769911, errBitset=0x45|
1


The caps for the MTP are listed as "4 257", but the caps for the VB10K region (the region with the SIP trunk) are only "4".  The other region, "Houston", has many more caps, including the 257 that I apparently need.  How does CUCM determine these caps?

Steven Holl Tue, 10/19/2010 - 11:31
User Badges:
  • Cisco Employee,

CUCM will need to invoke an MTP on SIP trunk calls with RTP-NTE, unless the other endpoint can support RTP-NTE.  Most IP phones support RTP-NTE, so the RTP-NTE can go directly to the phone without an MTP for those scenarios. When the call goes to something like an H323 trunk, or something else which can't terminate RTP-NTE, then CUCM will invoke the MTP to pull the DTMF out of the media path and put it in the signaling path.


In the MRGL on the SIP trunk, you should make sure that the first MRG in the MRGL only contains g.729 IOS software MTPs.  Make sure there aren't any transcoders or g711 MTPs in this MRG.  You can have a transcoder in the MRGL as long as it is in its own MRG and below the MTP MRG.  Ensure that you don't have any non-g729 MTPs in this device's MRGL at all, since you're doing g.729 on this trunk.


The call itself establishes when the parties answer, right?  Just making sure you don't have a codec mismatch anywhere.

Actions

This Discussion