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@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@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@10.5.64.254:5060
Caller-ID: "IS-Evansville" <4523>
Need Destroy: 0
Last Message: Rx: ACK
Promiscuous Redir: No
Route: sip:4523@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@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-----