[asterisk-dev] Asterisk-11 DTMF bug ?

[Matt Fredrickson]

On Tue, Apr 4, 2017 at 4:23 PM, Mark Murawski
<markm-lists at intellasoft.net> wrote:
> So... more information.
>
> directmedia=no
> directrtpsetup=no
>
> In this situation below, asterisk is the B2BUA.  Call comes in from Polycom,
> then gets routed out to ITSP via Dial()
>
> When the polycom directly calls into dialplan that handles media, asterisk
> *does* process the DTMF
> ie: Polycom calls into Read()
>
> [2017-04-04 17:21:41.557] [C-0000175d]  Got  RTP RFC2833 from
> 10.0.90.6:8110 (type 101, seq 016608, ts 3618850425, len 000004, mark 1,
> event 00000003, end 0, duration 00160)
>
>
>
>
> On 04/04/2017 04:52 PM, Mark Murawski wrote:
>>
>> Er, small correction.  Asterisk clearly shows RTP *flowing*, but not
>> receiving DTMF from 10.0.90.6
>>
>>
>>
>>
>> On 04/04/17 16:37, Mark Murawski wrote:
>>>
>>> Hey,
>>>
>>> So, I'm seeing an issue where a Polycom IP-550 with 4.1.1 firmware is
>>> sending RFC2833 DTMF packets as shown in the capture attached. I can
>>> send pcaps as necessary, if needed.
>>>
>>> 10.0.90.6 is the Polycom 10.0.90.1 is Asterisk.
>>>
>>> So of course you do:
>>>>
>>>> rtp set debug 10.0.90.6
>>>
>>>
>>> And then get the below, while the polycom is sending digits. The packet
>>> capture clearly shows DTMF going to 10.0.90.1, but Asterisk is not
>>> picking them up.
>>>
>>> [2017-04-04 14:14:18.830] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.830] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.850] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.850] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.870] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.870] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:18.890] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:18.890] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> ...
>>> [2017-04-04 14:14:22.210] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.210] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.230] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.230] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.250] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.250] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>> [2017-04-04 14:14:22.270] VERBOSE[21403][C-00001424] res_rtp_asterisk.c:
>>> [2017-04-04 14:14:22.270] [C-00001424] Sent RTP P2P packet to
>>> 10.0.90.6:2242 (type 00, len 000160)
>>>
>>>
>>> I am running 11.20 on this particular box, for some specific reasons.
>>> I'm currently working out some other issues with the newer/latest 11's,
>>> so I'm on this for now.
>>>
>>> Before I start digging into the code, are there any known issues with
>>> DTMF/RFC2833 in this version?  Any workarounds I can implement?

Hey Mark,

First off, thanks for reaching out to the Asterisk community to talk
about the trouble you're having :-)

This actually is a development related mailing list - so primarily for
development of Asterisk C source code level discussions, project
policy related discussions, and sometimes protocol development related
discussions.

Your question appears to be configuration or at the very least debug
related, rather than development related.  I would try referring it to
the asterisk-users mailing list or the community.asterisk.org forums
instead.

I think you probably should add more data about your Asterisk
configuration in this case, as well as your expectations as to what
should be working and what is not working, as that is not clear to me
from your description.  Are you not seeing DTMF bridged between the
two parties in the call, or is some other DTMF triggered behavior you
expect Asterisk to be demonstrating not occurring?  These are
questions I would hope to be answered when posting a follow up on one
of the other lists.

Hope that helps, and best wishes to you in resolving your problem! :-)

-- 
Matthew Fredrickson
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA