[Asterisk-Users] DTMF tones from CCME phone

[Walker West]

I have a set of phones attached to a Cisco Call Manager Express (CCME) router via SCCP.  The CCME router is registering the extensions via SIP to an Asterisk server.  From an SCCP attached phone on the CCME router, I can successfully call SIP extensions defined on the Asterisk PBX and vice versa.  I cannot, however, get DTMF tones from the CCME phone to applications running on the Asterisk server (such as Comedian mail).  I've tried the G.711 u-law and G.711 A-law codecs and am using rfc2833 as my DTMF relay method (inband does not work either).

The level of Asterisk I'm running is 1.0.1.  Here's an extensions.conf definition for one of the phones passed through the CCME router (10.5.64.254 is the address of the router):

[4523]
mailbox=8023 at default
type=friend
host=dynamic
context=default
canreinvite=no
qualify=1000
boot=dynamic
defaultip=10.5.64.254
port=5060
dtmfmode=rfc2833
disallow=all
allow=ulaw

The Cisco router is a 2611XM with IOS 12.3(8)T3.  Here's the definition that allows the phone to access Comedian mail:

dial-peer voice 8023 voip
 application session
 destination-pattern 8023
 session protocol sipv2
 session target ipv4:10.0.0.89
 dtmf-relay rtp-nte
 codec g711ulaw
 no vad

Here's a list of the available dtmf-relay methods on the Cisco:

fl2611xm(config-dial-peer)#dtmf ?
  cisco-rtp          Cisco Proprietary RTP
  h245-alphanumeric  DTMF Relay via H245 Alphanumeric IE
  h245-signal        DTMF Relay via H245 Signal IE
  rtp-nte            RTP Named Telephone Event RFC 2833
  sip-notify         DTMF Relay via SIP NOTIFY messages

As you can see, both ends are defined to use the same codec and dtmf-relay method.  Indeed, when the call is in progress, the Asterisk 'sip show channel' command reports:

  * SIP Call
  Direction:              Incoming
  Call-ID:                6EA51A30-1EE911D9-954C9F0E-7DBDE696 at 10.5.64.254
  Our Codec Capability:   524302
  Non-Codec Capability:   1
  Their Codec Capability:   4
  Joint Codec Capability:   4
  Format                  ULAW
  Theoretical Address:    10.5.64.254:5060
  Received Address:       10.5.64.254:56930
  NAT Support:            No
  Our Tag:                2019357054
  Their Tag:              60D61C5B-18FF
  SIP User agent:
  Username:               4523
  Original uri:           sip:4523 at 10.5.64.254:5060
  Caller-ID:              "IS-Evansville" <4523>
  Need Destroy:           0
  Last Message:           Rx: ACK
  Promiscuous Redir:      No
  Route:                  sip:4523 at 10.5.64.254:5060
  DTMF Mode:              rfc2833

. . . and the equivalent Cisco 'show sip calls' command reports:

Call 1
SIP Call ID                : 6EA51A30-1EE911D9-954C9F0E-7DBDE696 at 10.5.64.254
   State of the call       : STATE_ACTIVE (7)
   Substate of the call    : SUBSTATE_NONE (0)
   Calling Number          : 4523
   Called Number           : 8023
   Bit Flags               : 0x10120030 0x100000
   Source IP Address (Sig ): 10.5.64.254
   Destn SIP Req Addr:Port : 10.0.0.89:5060
   Destn SIP Resp Addr:Port: 10.0.0.89:5060
   Destination Name        : 10.0.0.89
   Number of Media Streams : 1
   Number of Active Streams: 1
   RTP Fork Object         : 0x0
   Media Stream 1
     State of the stream      : STREAM_ACTIVE
     Stream Call ID           : 8634
     Stream Type              : voice+dtmf (1)
     Negotiated Codec         : g711ulaw (160 bytes)
     Codec Payload Type       : 0
     Negotiated Dtmf-relay    : rtp-nte
     Dtmf-relay Payload Type  : 101
     Media Source IP Addr:Port: 10.5.64.254:16550
     Media Dest IP Addr:Port  : 10.0.0.89:17106
     Orig Media Dest IP Addr:Port : 0.0.0.0:0

The Cisco indicates the 'negotiated' codec and dtml-relay method are set as I intended.  It even lists the stream type as 'voice+dtmf', seemingly indicating that out-of-band (OOB) DTMF is in place.  Comedian mail never acknowledges any buttons were pressed; it repeats the choices a few times and disconnects.

Thank you for taking the time to read this somewhat wordy message.  I'm very new to Asterisk and VOIP; has anyone else had this problem or have some ideas I can use to determine what's happening to the DTMF digits?

-- 
Walker West

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

mQGiBDn1wxYRBACHupH8ZKhbV1jbp3NjNMDTM3wMk1DzZ7zGSbn9UiLQzTCSHjnp
vi0Uxb9pKDbRjDdMko3pJMLyv6O7OJBq0P0sLqBngXoSAMWVDYrjcaJIk+EipYpo
5cFnYSVqIrKeyv3oAlPp2AtCpvIK/FJ0UQkF+/Dnhm1Opg2aI+ZMuGp7qwCgh2n1
If2Tg2hv7aralodHnDpqd+kD/iuHFFvcAqA3W/RFSkDupYfCtTltrR19gGMnxjuu
YHNGWy8NQNgXaVAxfyq8kShSfnsvSZMowmXKMPhjZUFBOnVGR8chtbw2pmeKuf7A
H7bWn4qecFL422dBQqBDCIBbk0mwVTXiQT1KspBrbHzQ1QcbiSnAN/iPHShnBSGR
kfAyA/9YeN20l7KXVkz8vqhx+HR8cjKiH/aoJOhRITWJDhL+i8MZ4u0njjgR/yB2
7mDvwX443vgAHGALLi9isOJiwA2N1rkRs2ro0753RlyUr8ElT6svPOilwV9NZ9+Z
yu8XaeunKq19alGW6Il5dZXKc9m+PDmbCuZD1RlZLWn4gdBcX7QeV2Fsa2VyIFdl
c3QgPHd3ZXN0QGRhbGNvbi5jb20+iFcEExECABcFAjn1wxYFCwcKAwQDFQMCAxYC
AQIXgAAKCRCNO6NYMl0DMfKjAJ9pLOLC6JmZBPZ0PZOGaanuWQGmZACdGB8pWOyV
Qz8HLShAxyFP9kjawGe5AQ0EOfXDMBAEAJKBrWt87yi7a/ucRXVAvCmt3eMXFjqs
fSb/Z8uujTE65Mre8oofHHe5fLJxGsLirOLlY0kCyYDBkRW0pMw2meV7ikhL7bu6
3Iy2ABUW1Mo6DU2mPhkSFqodGCqz5o5XV4zltHuRpdHbojF/i3nFVF26MS6VCA6d
TmGooT3vvzuXAAMFA/4jq0t+R+c4Zv9BGwgmxpWjOvPZO93Y0ulpYo85wRoORRGd
GtiIxD7IK/L8JIRE5PYGuoUJxrBWvH2/WRVlMAouroaw/9qWvq2+nZKbgW3MJQq7
Gz7bwKjoz+KteVDb4FZ1s6fnidos8BJVF5LRmQ8oxpt+HE6+bLYqs5KsK6/FG4hG
BBgRAgAGBQI59cMwAAoJEI07o1gyXQMxrj0Ani5RnY+8ajuYMEFCph8SRG/BUxrn
AJ4iRECzBRm98AQc37uvXnI3ppzdUQ==
=XdVT
-----END PGP PUBLIC KEY BLOCK-----