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
3 thoughts on - Parking In Asterisk 12.0.0
I have converted the normal Park application and I can only alert you about the syntax change. I suspect also in the ParkAndAnnounce command, the parameters are ordered completely different.
Leandro
2014-01-30 Anders Larsson:
Please go ahead an open an issue for this – issues.asterisk.org.
The problem here is that you are attempting to enter into a Parking bridge while you are still technically in a bridge. The DTMF features that account for the ‘normal’ mechanism of doing this – the one touch parking feature – recognize that you are in a bridge and do a safe transfer from the existing bridge to the parking bridge. By jumping out to a macro/gosub and directly going in through the ParkAndAnnounce application, you are bypassing that logic. The code in bridge_channel_internal_join is preventing you from going into the parking bridge as it knows that you have not yet safely left the bridge you are in.
We’ll take a look and see if there’s a way to allow this to happen again. For now, you should use the one touch parking feature.
Matt
Thank you for reply, Matt and Leandro!
The reasons I’m not using “one step parking” is that it will “speak”
which parking extension it has parked the call on and I also want a channel variable to be set about the parked call, which I need in the agi-script (ParkAndAnnounce with a not valid dial string and setting a MASTER_CHANNEL() variable in the Macro solves these issues for me).
Maybe I could do a hack in the Asterisk source to achive this if there is no other solution.
The reason I tried to upgrade from 11.6 to 12.0 was that I experienced problems with lost (ignored) DTMF events after Asterisk has released the DTMF events for what it think can be a potential dynamic feature. This problem seems to be gone in Asterisk 12.0…
[Jan 30 11:13:48] DEBUG[29442][C-00000000]: features.c:3740
feature_interpret: Feature interpret: chan=SIP/at-tcty-ssw-00000000, peer=SIP/vpn-sbc-00000001, code=*8, sense=1, features=0, dynamic=parkswitch#parkswitch
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:2833
create_dtmf_frame: Creating BEGIN DTMF Frame: 50 (2), at 85.30.63.134:15870
[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4171 __ast_read:
DTMF begin ‘2’ received on SIP/at-tcty-ssw-00000000
*[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4185 __ast_read:
DTMF begin ignored ‘2’ on SIP/at-tcty-ssw-00000000*
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:3165
ast_rtcp_read: Got RTCP report of 80 bytes
[Jan 30 11:13:49] DEBUG[29445][C-00000000]: res_rtp_asterisk.c:2833
create_dtmf_frame: Creating END DTMF Frame: 50 (2), at 85.30.63.134:15870
I spoke to Olle E Johansson about this issue today and he pointed me to a SVN branch he has made for Asterisk 1.8 which should solve the ignored DTMF events
(http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-duration-1.8/)
I have now quickly tested his code and it seems to work, so I will propably go with Asterisk 1.8.
Thanks again.
— Anders