[asterisk-dev] DTMF queuing

[James Lamanna]

I'm throwing this back over to the -dev side.
I've received no feedback on -users, and you guys will have a more
intimate understand of how Asterisk processes DTMF.

Thanks


---------- Forwarded message ----------
From: James Lamanna <jlamanna at gmail.com>
Date: Wed, Jan 28, 2009 at 7:30 PM
Subject: Re: [asterisk-dev] DTMF queuing
To: John Todd <jtodd at digium.com>
Cc: asterisk-users at lists.digium.com


[moving to asterisk-users by request]

On Tue, Jan 27, 2009 at 12:56 AM, John Todd <jtodd at digium.com> wrote:
>
> On Jan 26, 2009, at 7:38 PM, James Lamanna wrote:
>
>>> On Jan 26, 2009, at 8:53 PM, James Lamanna wrote:
>>>
>>>> Hi,
>>>> Is it just me, or does DTMF queuing not work properly?
>>>> I'm consistently faced with the issue that users (and myself) will
>>>> dial digits quickly and all I get in the logs are:
>>>>
>>>> end 'X' put into dtmf queue on SIP/xxxxxxxxxx
>>>> etc...
>>>
>>>
>>> What version are you talking about?  If it's not 1.4.23, please try
>>> that, as there are some related fixes in that version.
>>
>> Sorry, I neglected to mention this is on 1.4.18.1.
>> I will try and test 1.4.23 and see if things are better.
>> In the meantime, I'll report my findings to see if you guys can better
>> explain
>> to me what is going on.
>>
>> The best DTMF combination (between phone and asterisk) I have found is:
>>
>> sip.conf - dtmfmode=info
>> Phone (SPA962) - DTMF Mode = Auto
>>
>> This works very well for outbound SIP and Zap trunks and on both ulaw
>> and g726 codecs.
>> However, this does NOT work for any prompt that is internal to asterisk
>> that
>> needs to detect DTMF (Voicemail, Authenticate, etc..).
>> The only way for these prompts to work is to explicitly put
>> SIPDTMFMode(inband)
>> in the dial plan. Of course, this breaks when the codec is g726. Why
>> do these prompts not work with this setup?
>> I've also noticed that when in this mode, nothing is put into the dtmf
>> log.
>> Does that mean that the phone and asterisk have negotiated inband
>> (though if this was the case why would it work with g726..)?
>>
>> Thanks.
>> (please CC me directly since I'm on digest mode at the moment).
>
>
> Actually, I'm a little surprised you get DTMF working at all in this
> combination.
>
> Setting dtmfmode=info means that Asterisk will be looking for SIP INFO
> messages that contain DTMF events.  Have you watched the SIP channel debug
> during DTMF events, or set up a tshark or other interceptor to watch port
> 5060 as you send DTMF?   Perhaps you've got a few things mucking up the
> works there.  What does RFC2833 get you if you set all the gear to that?
>
> Try setting everything to RFC2833 and try again.  I'd also suggest follow-up
> messages go to asterisk-users and not to this list, as this is not sounding
> particularly like a question for the -dev list where core Asterisk code is
> involved, and you'll probably get more answers over on -users.

Still haven't had a chance to upgrade to 1.4.23, however I did try
setting everything to rfc2833.
Works ok @1.4.22.1, but not as good as the info/Auto combination.

I looked at the SIP signaling trace, and I see no sign of INFO headers
in the signaling packets.
What's going on here then? I see no payload 101 packets in the RTP
stream either.
So I guess it negotiated inband? (then why would it work
while in g726 - am I just getting lucky??)
I have verified that the RTP payload packets have type 2 which is g726aal2.
Note, It is getting transmitted inband, if I switch back to ulaw and
look at the packets, I can see no audio
until I press a digit.

And why doesn't this get detected by Asterisk for any of its internal
applications?

-- James

>
> JT
>
> ---
> John Todd                       email:jtodd at digium.com
> Digium, Inc. | Asterisk Open Source Community Director
> 445 Jan Davis Drive NW -  Huntsville AL 35806  -   USA
> direct: +1-256-428-6083         http://www.digium.com/
>
>
>
>