The AMI's DTMF events are not raised when DTMF originator is a PJSIP channel

The AMI’s DTMF event are not raised when DTMF originator is a PJSIP channel. I ha has been monitoring AMI DTMF events (DTMFBegi amd DTMFEnd).

I have 2 endpoints one using SIP and the other PJSIP , I make a call beteween these two devices, But If I dial any DTMF key on the PJSIP device while in the call with the SIP device no DTMF event is raised, But it works when I dail any DTMF key from the SIP endpoint.

These are the events generated when I dial a key on the SIP device while in a call with the PJSIP device

0 : Event: DTMFBegin
1 : Privilege: dtmf,all
2 : Channel: SIP/102-00000000
3 : ChannelState: 6
4 : ChannelStateDesc: Up
5 : CallerIDNum: 102
6 : CallerIDName: Ambiorix
7 : ConnectedLineNum: 6001
8 : ConnectedLineName:
9 : AccountCode:
10 : Context: internal
11 : Exten:
12 : Priority: 1
13 : Uniqueid: 1456968280.1
14 : Digit: 2
15 : Direction: Received
16 :
17 :
0 : Event: DTMFBegin
1 : Privilege: dtmf,all
2 : Channel: PJSIP/6001-00000000
3 : ChannelState: 6
4 : ChannelStateDesc: Up
5 : CallerIDNum: 6001
6 : CallerIDName:
7 : ConnectedLineNum: 102
8 : ConnectedLineName: Ambiorix
9 : AccountCode:
10 : Context: internal
11 : Exten: 102
12 : Priority: 4
13 : Uniqueid: 1456968280.0
14 : Digit: 2
15 : Direction: Sent

I think it should happen on the same way when I pressed any key from the PJSIP device, but not event is raised

Those are core events so they should be raised as well. Does DTMF still work? What is the configuration and scenario?

DTMF is not working on PJSIP. That is the reason why DTMF events are not raised.

[global]
type=global
debug=yes
keep_alive_interval=20
disable_tcp_switch=yes

[transport-udp]
type=transport
protocol=udp
bind=0.0.0.0:5065
protocol=udp
local_net=10.0.0.0/255.0.0.0
local_net=10.0.0.0/8
external_signaling_address=65.181.118.232
external_media_address=65.181.118.232

[6001]
type=endpoint
context=internal
disallow=all
allow=ulaw
allow=alaw
auth=6001
aors=6001
direct_media=no
media_address=186.150.101.237
force_rport=yes
rtp_symmetric=yes
rewrite_contact=yes
ice_support=no
dtmf_mode=rfc4733

[6001]
type=auth
auth_type=userpass
password=1930133133
username=6001

[6001]
type=aor
max_contacts=20
qualify_frequency=5

What DTMF method is in use by the endpoint? Does specifying it explicitly using dtmf_mode in the endpoint work?

on the endpoint secion dtmf_mode=rfc4733

Does “rtp set debug on” show the RTP traffic coming in including the DTMF?

PJSIP  rtp debug 

Sent RTP packet to      186.150.101.237:8006 (type 00, seq 012877, ts 253760, len 000160)
Sent RTP packet to      186.150.101.237:8006 (type 00, seq 012878, ts 253920, len 000160)



Working  DTMF on SIP

Got  RTP RFC2833 from   186.150.101.237:56692 (type 101, seq 003392, ts 2000640, len 000004, mark 1, event 00000002, end 0, duration 00160)
[Mar  4 13:42:41] DTMF[6159][C-000002e3]: channel.c:4050 __ast_read: DTMF begin '2' received on SIP/102-00000015
[Mar  4 13:42:41] DTMF[6159][C-000002e3]: channel.c:4054 __ast_read: DTMF begin ignored '2' on SIP/102-00000015

Media does not appear to be received from the remote device. Can you provide the SIP messages to and from?

<— Received SIP request (927 bytes) from UDP:186.150.101.237:55393 —>
INVITE sip:10@65.181.118.232:5065;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 186.150.101.237:55393;branch=z9hG4bK-d8754z-e2b0f734cd5cba67-1—d8754z-
Max-Forwards: 70
Contact: sip:6001@186.150.101.237:55393;transport=UDP
To: sip:10@65.181.118.232:5065;transport=UDP
From: sip:6001@65.181.118.232:5065;transport=UDP;tag=fb143a76
Call-ID: NTc2YTM5ZDI1ZjdlZWNhNTkzODU0ZmE4NzQyODAwOGM.
CSeq: 1 INVITE
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, MESSAGE, OPTIONS, INFO, SUBSCRIBE
Content-Type: application/sdp
Supported: replaces, norefersub, extended-refer, timer, X-cisco-serviceuri
User-Agent: Z 3.6.25251 r25476
Allow-Events: presence, kpml
Content-Length: 245

v=0
o=Z 0 0 IN IP4 186.150.101.237
s=Z
c=IN IP4 186.150.101.237
t=0 0
m=audio 8016 RTP/AVP 3 110 8 0 98 101
a=rtpmap:110 speex/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv

That’s the INVITE from the device, that is not what we have told the remote device which is the important part. If the NAT stuff is not working correctly and we aren’t telling them the public IP address then we may not get any RTP from them.

I agreed with you , that is a nat problem. I will work on fixing any nat issue and let you know. Thanks for you help