* You are viewing Posts Tagged ‘dtmf’

Parking In Asterisk 12.0.0

Hi

I’m trying to get the rebuilt parking functionality to work in Asterisk
12.0.0.

In Asterisk 11.6.0 I managed to get a call to get parked by adding a dynamic feature in features.conf for the DMTF sequence *# which called a macro in extensions.conf, which then runned the ParkAndAnnounce application, and the call got parked.

The syntax for ParkAndAnnounce I used was this (I don’t want any announcement to be played):

exten => s,n,ParkAndAnnounce(,3600,SIP/100)


In the new Asterisk-version, the ParkAndAnnounce application gets called, but the call isn’t parked.

The only error I can see in the messages file is a DEBUG entry saying that the channel “failed to join Bridge”, like this:

[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994
bridge_channel_internal_join: Bridge
9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001)
failed to join Bridge


Anyone else that has tried to convert old parking functionality into Asterisk 12.0.0 ?



features.conf:

parkswitch => *#,callee/caller,Macro(parkswitch)


extensions.conf:

[default]
….

include => parkedcalls

[macro-parkswitch]
exten => s,1,ParkAndAnnounce(,,PARKED,SIP/100)


messages:

[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847
create_dtmf_frame: Creating BEGIN DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read:
DTMF begin ‘*’ received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4061 __ast_read:
DTMF begin passthrough ‘*’ on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165
ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847
create_dtmf_frame: Creating END DTMF Frame: 42 (*), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:3964 __ast_read:
DTMF end ‘*’ received on SIP/at-tcty-ssw-00000000, duration 240 ms
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4005 __ast_read:
DTMF end accepted with begin ‘*’ on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4034 __ast_read:
DTMF end passthrough ‘*’ on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: bridge_channel.c:1174
bridge_channel_feature: DTMF feature string on
0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now ‘*’
[Jan 30 21:00:00] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847
create_dtmf_frame: Creating BEGIN DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4050 __ast_read:
DTMF begin ‘#’ received on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:00] DTMF[7114][C-00000000]: channel.c:4054 __ast_read:
DTMF begin ignored ‘#’ on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2847
create_dtmf_frame: Creating END DTMF Frame: 35 (#), at x.x.x.x:9530
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:3964 __ast_read:
DTMF end ‘#’ received on SIP/at-tcty-ssw-00000000, duration 230 ms
[Jan 30 21:00:01] DTMF[7114][C-00000000]: channel.c:4034 __ast_read:
DTMF end passthrough ‘#’ on SIP/at-tcty-ssw-00000000
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1174
bridge_channel_feature: DTMF feature string on
0x7f6b8c10f998(SIP/at-tcty-ssw-00000000) is now ‘*#’
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: bridge_channel.c:1185
bridge_channel_feature: DTMF feature hook 0x7f6b8c1d9480 matched DTMF
string ‘*#’ on 0x7f6b8c10f998(SIP/ssw-00000000)
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:2165
ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165
ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:305 ast_app_exec_macro:
SIP/vpn-sbc-00000001 Original location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: pbx.c:4875
pbx_extension_helper: Launching ‘ParkAndAnnounce’
— Executing [s@macro-parkswitch:1]
ParkAndAnnounce(“SIP/vpn-sbc-00000001″, “,,PARKED,SIP/100″) in new stack
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486
find_best_technology: Bridge technology softmix does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486
find_best_technology: Bridge technology simple_bridge does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:486
find_best_technology: Bridge technology native_rtp does not have any capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:505
find_best_technology: Chose bridge technology holding_bridge
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:771
bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology constructor
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge.c:779
bridge_base_init: Bridge 9f437397-4864-4351-bf29-b37e6ccacf12: calling holding_bridge technology start
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_roles.c:272
setup_bridge_role: Set role ‘holding_participant’
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1977
bridge_channel_internal_join: Bridge
9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001) is joining
*[Jan 30 21:00:01] DEBUG[7118][C-00000000]: bridge_channel.c:1994
bridge_channel_internal_join: Bridge
9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-00000001)
failed to join Bridge*
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app_macro.c:428 _macro_exec:
Spawn extension (macro-parkswitch,s,1) exited non-zero on
‘SIP/vpn-sbc-00000001′ in macro ‘parkswitch’
== Spawn extension (macro-parkswitch, s, 1) exited non-zero on
‘SIP/vpn-sbc-00000001′ in macro ‘parkswitch’
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:308 ast_app_exec_macro:
Macro exited with status -1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: app.c:322 ast_app_exec_macro:
SIP/vpn-sbc-00000001 Ending location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:2165
ast_rtp_update_source: Setting the marker bit due to a source update
[Jan 30 21:00:01] DEBUG[7119]: taskprocessor.c:484
tps_taskprocessor_destroy: destroying taskprocessor
‘423a711c-02c7-4b54-ab39-33e6c64e32c3′
[Jan 30 21:00:01] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284
ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:02] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284
ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:05] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284
ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:07] DEBUG[7118][C-00000000]: res_rtp_asterisk.c:3284
ast_rtcp_read: Got RTCP report of 76 bytes
[Jan 30 21:00:10] DEBUG[7114][C-00000000]: res_rtp_asterisk.c:3284
ast_rtcp_read: Got RTCP report of 76 bytes

– Anders

Reading DTMF Sent By Callee During A SIP Call

Hi everyone,

I am looking for advice about the design of a SIP-based intercom. I
count on your help, as my current attempts are not fruitful (yet).

This will be a pretty long message, so here’s my fundamental question:

Is there a way to interpret DTMF tones sent by the calee
(not the caller) while a voice call is in progress?






Here’s the desired scenario:

- there is a box with speakers and a mic
Asterisk is running on a computer inside that box
– the box is embedded in a door
– There are two user accounts, UserA and userB
– UserA is a client that runs on the server*
– UserA calls UserB and they are having a voice conversation


Throughout the call, Asterisk must react to DTMF tones sent by userB;
such that an action is executed when a specific key is pressed.

The idea is to build an intercom that would enable me to open a door remotely, by relying entirely on SIP, so there would be no need to have some additional communication channel to send the “open door”
signal.




I have previously implemented IVRs using `Background` and jumped to specific extensions, when a button was pressed. But in that case, the extensions are dialed by the caller; whereas now the input must from the person who answered the call.

If I use `Dial` and `Read` – the latter is only executed after `Dial`
terminates – so this is not suitable.


`Background` behaves like I need – but it plays back a predefined file, so it is not suitable for an interactive conversation.



* Having a SIP client on the same machine as the Asterisk server itself is not possible, because both won’t be able to bind to port
5060. My guess is that the solution is to originate a call from the CLI; but I haven’t gotten to that part yet.




Thank you for your patience, I am looking forward to your feedback, Alex

Broadcasting DTMF To Confbridge Users Or DTMF Passthrough

Hi,

Trying to properly broadcast / relay DTMF digits to other confbridge users, but does not appear to work. Goal is to have a conference user be able to receive the DTMF, so it has the effect of being ‘broadcasted.’

I have the following set up in ‘confbridge.conf':
dtmf_passthrough=yes

From logger.conf, I can see the DTMF tones via setting “console => dtmf”. When I dial into the conference bridge with a SIP UA and dial 9, for example, this is what I see:

sip1*CLI>
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4164 __ast_read: DTMF begin ‘9’ received on SIP/3002-0000003d
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4175 __ast_read: DTMF begin passthrough ‘9’ on SIP/3002-0000003d
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4078 __ast_read: DTMF end ‘9’ received on SIP/3002-0000003d, duration 110 ms
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4119 __ast_read: DTMF end accepted with begin ‘9’ on SIP/3002-0000003d
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4134 __ast_read: DTMF end ‘9’ detected to have actual duration 59 on the wire, emulation will be triggered on SIP/3002-0000003d
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4141 __ast_read: DTMF end ‘9’ has duration 59 but want minimum 80, emulating on SIP/3002-0000003d
[Dec 19 01:29:50] DTMF[22561][C-000005ba]: channel.c:4198 __ast_read: DTMF end emulation of ‘9’ queued on SIP/3002-0000003d sip1*CLI>

So what is missing here or how to identify / troubleshoot? Is there an application that needs to pass the DTMF from the SIP user in sip.conf to the conference application?

Thanks in advance, Jason

Trouble With Upgrading – RBS T1

Upgrading an ancient customer installation… was running 1.4.23.1
(Trixbox) with Zaptel 1.4.12.9 and a Sangoma A102D, which has been running fine for 5+ years. Customer getting anxious about hardware failure, so we built a new box and installed 1.8.24.0, Dahdi 2.7.0.1, and a new Sangoma A104D. The single active span is an RBS T1
B8ZS/ESF/E&M Wink.

I tried to move one span over one night which was working fine on the old box. Once plugged in there were no alarms, Sangoma wanpipemon utility showed “connected”. I tried calling in on a DID number, and in the ‘full’ log, with debug and verbose set to 100:

[Dec 5 00:51:37] VERBOSE[5283] sig_analog.c: — Starting simple switch on ‘DAHDI/9-1′
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.17E+04, Et=1.45E+06, s/n= 0.01
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.76E+03, Et=1.10E+06, s/n= 0.00
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.06E+04, Et=1.39E+06, s/n= 0.01
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=4.68E+03, Et=1.40E+06, s/n= 0.00
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= -nan
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= -nan
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= -nan
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= -nan
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=0.00E+00, Et=0.00E+00, s/n= -nan
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.30E+10, Et=2.11E+12, s/n= 0.01
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: analog_exception 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Exception on 15, channel 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: __analog_handle_event 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Got event UNKNOWN/OTHER(131127) on channel 9 (index 0)
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: DTMF Down ‘7’
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Begin DTMF digit: 0x37 ‘7’
on DAHDI/9-1
[Dec 5 00:51:38] DEBUG[5283] chan_dahdi.c: Begin DTMF digit: 0x37 ‘7’
on DAHDI/9-1
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF begin ‘7’ received on DAHDI/9-1
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF begin ignored ‘7’ on DAHDI/9-1
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=2.02E+10, Et=4.01E+12, s/n= 0.01
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=1.88E+10, Et=3.89E+12, s/n= 0.00
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=4.78E+10, Et=1.17E+12, s/n= 0.04
[Dec 5 00:51:38] DEBUG[5283] dsp.c: tone 1100, Ew=5.10E+03, Et=6.26E+06, s/n= 0.00
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: analog_exception 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Exception on 15, channel 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: __analog_handle_event 9
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Got event UNKNOWN/OTHER(262199) on channel 9 (index 0)
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: Detected digit ‘7’
[Dec 5 00:51:38] DEBUG[5283] sig_analog.c: End DTMF digit: 0x37 ‘7’ on DAHDI/9-1
[Dec 5 00:51:38] DEBUG[5283] chan_dahdi.c: End DTMF digit: 0x37 ‘7’ on DAHDI/9-1
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF end ‘7’ received on DAHDI/9-1, duration 0 ms
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF end accepted without begin
‘7’ on DAHDI/9-1
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF end passthrough ‘7’ on DAHDI/9-1
[Dec 5 00:51:38] DEBUG[5283] chan_dahdi.c: Enabled echo cancellation on channel 9
[Dec 5 00:51:38] VERBOSE[5283] sig_analog.c: — Unknown extension
‘7’ in context ‘from-pstn’ requested


At this point I hear ‘invalid extension’ and get hung up on, but if you grep out all the DTMF events from this call, you get:

root@astsouth:/var/log/asterisk# grep ‘DTMF end’ /tmp/foo | grep received
[Dec 5 00:51:38] DTMF[5283] channel.c: DTMF end ‘7’ received on DAHDI/9-1, duration 0 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘1’ received on DAHDI/9-1, duration 80 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘5’ received on DAHDI/9-1, duration 80 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘7’ received on DAHDI/9-1, duration 80 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘6’ received on DAHDI/9-1, duration 80 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘0’ received on DAHDI/9-1, duration 80 ms
[Dec 5 00:51:41] DTMF[5283] channel.c: DTMF end ‘0’ received on DAHDI/9-1, duration 80 ms

And ‘715-7600′ is the DID number I dialed. So why is the new box immediately answering the call before it gets all the ANI digits? I’ve poured over all Sangoma’s docs online for debugging RBS lines – I’m not having any transmission errors, no overruns, and even the audio of
‘invalid extension’ seems clear before it hangs up on me.

The next maintenance window I swapped out the A104D for a Digium TE122.
Exactly the same issue! Some problem with Dahdi then?

Any ideas?

Thanks,

Jeff LaCoursiere SunFone

DTMF Relay In Meetme Is Not Reliable

Hello List,

I am facing some issue while passing DTMF (RFC2833 set globally in sip.conf) in meetme (asterisk 1.8). The issue I have observed that – if two users tries to pass DTMF simultaneously at the same time from their phones only one DTMF is detected in asterisk and broadcasted to other users. Other DTMF lost somewhere. We have tested only with sip phones.

Can someone help me with this, or is there any configuration option that can resolve this problem? I want asterisk receive the DTMFs send at the same time and to pass those either by queuing them or by some other means. We can not use confbridge at this moment as we have developed the application on meetme. Please help!

Regards, Rajib

Help – DTMF Relay In Meetme Is Not Reliable

Hello List,

I am facing some issue while passing DTMF (RFC2833 set globally in sip.conf) in meetme (asterisk 1.8). The issue I have observed that – if two users tries to pass DTMF simultaneously at the same time from their phones only one DTMF is detected in asterisk and broadcasted to other users. Other DTMF lost somewhere. We have tested only with sip phones.

Can someone help me with this, or is there any configuration option that can resolve this problem? I want asterisk receive the DTMFs send at the same time and to pass those either by queuing them or by some other means. We can not use confbridge at this moment as we have developed the application on meetme. Please help!

Regards,