DTMF problem with VoiceMail

Asterisk Asterisk Support
1

Yes, I’ve searched the forum, but… :frowning:

I’m running Asterisk 1.4 with the number of SIP phones.
If I have dtmfmode set by default (i.e. rfc2833) then DTMF codes are not recognized by Asterisk voicemail. If I will dial my provider’s voicemail system over SIP trunk then everything will be OK.

If I will set dtmfmode = inband (for SIP phone only) and set the SIP phone itself to use inband then only local voicemail will work, but not provider’s system.

If I will configure the phone to use info and set dtmfmode = info for that peer then Asterisk will report an error.

Any suggestions?

2

remember, dtmf can be set on a per-peer basis, which is what you should do. I would suggest use rfc2833 everywhere you can, and set your phone to use RFC. If that doesn’t work set your carrier to use RFC and have the phone use info. Asterisk will convert it as long as it is set differently on each side.

3

Hi

Have you actulally set it or are you assuming its set ?

IE in the peers and the general section you have dtmfmode=rfc2833 ?

If not set it. Are the phones set to RFC2833 ?

As mentioned with all set to rfc it “should” work, you carrier may need info, Who is the carrier ?

Ian

4

Yes, I have configured rfc2833 explicitly for both my SIP phone and my SIP trunk. Local VM does not work.

Now I’ve changed the phone to info and put dtmfmode = info in users.conf and this is what I see:

Receiving INFO!
[Jan 29 01:38:47] WARNING[7936]: chan_sip.c:10723 handle_request_info: Unable to parse INFO message from 10199998-2105a8c0-2710-45bd25f1-14ce66f … tthead.lan. Content

<— Transmitting (no NAT) to 192.168.5.33:10000 —>
SIP/2.0 415 Unsupported media type

Why?

5

Hi

what phones ae ou using ?

6

I’m using unlocked VTech ip8100 phone.

7

i’ve always set dtmfmode=auto in [general] of sip.conf, rfc2833 for local phones, and auto for SIP trunks … never had a problem.

8

Does not help :frowning:

Set the phone itself to inband
auto in [general]
auto or inband for the phone & auto for SIP trunk in users.conf

Local VM does work, provider’s VM - doesn’t.

9

The same problem with PAP2 v.2 :frowning:
Any ideas?

10

After I’ve enabled debug output I can see that the Asterisk itself is receiving DTMF from the SIP-phone, but for some reasons those digits are not passed to VoiceMail. Any suggestions?

-- Executing [86@longdistance:1] VoiceMailMain("SIP/12-081ba2d8", "") in new stack
[Jan 30 17:57:58] DEBUG[29778]: app_voicemail.c:6120 vm_execmain: Before ast_answer
    -- Playing 'vm-login' (language 'en')
[Jan 30 17:58:02] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '#' received on SIP/12-081ba2d8
[Jan 30 17:58:11] DEBUG[29778]: app_voicemail.c:6028 vm_authenticate: Before find user for mailbox 12
    -- Playing 'vm-password' (language 'en')
[Jan 30 17:58:14] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '1' received on SIP/12-081ba2d8
[Jan 30 17:58:14] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '2' received on SIP/12-081ba2d8
[Jan 30 17:58:15] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '1' received on SIP/12-081ba2d8
[Jan 30 17:58:15] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '2' received on SIP/12-081ba2d8
[Jan 30 17:58:17] DTMF[29778]: channel.c:2148 __ast_read: DTMF begin '#' received on SIP/12-081ba2d8
    -- Incorrect password '' for user '12' (context = default)
    -- Playing 'vm-incorrect-mailbox' (language 'en')

Then I compared this output with the call from the old good PAP2.
This is the difference:

[Jan 30 18:11:37] DTMF[29833]: channel.c:2148 __ast_read: DTMF begin '2' received on SIP/11-081b68a0
[Jan 30 18:11:37] DTMF[29833]: channel.c:2128 __ast_read: DTMF end '2' received on SIP/11-081b68a0

In the first example DTMF end is missing! Why? Thanks!

11

ok, this is the cause:

My 2 boxes, PAP2 ver.2 & VTech ip8100, both based on the same hw & sw, are sending rfc2833 packets in a manner which is different from the other devices like PAP2 ver.1 for example.

From the RFC:
bit E: If set to a value of one, the “end” bit indicates that this packet contains the end of the event.

So, my 2 boxes are not sending End of Event packets, but it seems that Asterisk cannot handle this.