Re: [asterisk-users] Parking in Asterisk 12.0.0

[Anders Larsson]

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-]: features.c:3740 
feature_interpret: Feature interpret: chan=SIP/at-tcty-ssw-, 
peer=SIP/vpn-sbc-0001, code=*8, sense=1, features=0, 
dynamic=parkswitch#parkswitch
[Jan 30 11:13:49] DEBUG[29445][C-]: 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-]: channel.c:4171 __ast_read: 
DTMF begin '2' received on SIP/at-tcty-ssw-
*[Jan 30 11:13:49] DTMF[29445][C-]: channel.c:4185 __ast_read: 
DTMF begin ignored '2' on SIP/at-tcty-ssw-*
[Jan 30 11:13:49] DEBUG[29445][C-]: res_rtp_asterisk.c:3165 
ast_rtcp_read: Got RTCP report of 80 bytes
[Jan 30 11:13:49] DEBUG[29445][C-]: 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


On Thu, Jan 30, 2014 at 2:58 PM, Leandro Dardini ldard...@gmail.com wrote:

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



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



-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
   http://www.asterisk.org/hello

asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-users

[asterisk-users] Parking in Asterisk 12.0.0

[Anders Larsson]

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-]: bridge_channel.c:1994 
bridge_channel_internal_join: Bridge 
9f437397-4864-4351-bf29-b37e6ccacf12: 0x16e3768(SIP/vpn-sbc-0001) 
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-]: 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-]: channel.c:4050 __ast_read: 
DTMF begin '*' received on SIP/at-tcty-ssw-
[Jan 30 21:00:00] DTMF[7114][C-]: channel.c:4061 __ast_read: 
DTMF begin passthrough '*' on SIP/at-tcty-ssw-
[Jan 30 21:00:00] DEBUG[7114][C-]: 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-]: 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-]: channel.c:3964 __ast_read: 
DTMF end '*' received on SIP/at-tcty-ssw-, duration 240 ms
[Jan 30 21:00:00] DTMF[7114][C-]: channel.c:4005 __ast_read: 
DTMF end accepted with begin '*' on SIP/at-tcty-ssw-
[Jan 30 21:00:00] DTMF[7114][C-]: channel.c:4034 __ast_read: 
DTMF end passthrough '*' on SIP/at-tcty-ssw-
[Jan 30 21:00:00] DEBUG[7114][C-]: bridge_channel.c:1174 
bridge_channel_feature: DTMF feature string on 
0x7f6b8c10f998(SIP/at-tcty-ssw-) is now '*'
[Jan 30 21:00:00] DEBUG[7114][C-]: 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-]: channel.c:4050 __ast_read: 
DTMF begin '#' received on SIP/at-tcty-ssw-
[Jan 30 21:00:00] DTMF[7114][C-]: channel.c:4054 __ast_read: 
DTMF begin ignored '#' on SIP/at-tcty-ssw-
[Jan 30 21:00:01] DEBUG[7114][C-]: 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-]: channel.c:3964 __ast_read: 
DTMF end '#' received on SIP/at-tcty-ssw-, duration 230 ms
[Jan 30 21:00:01] DTMF[7114][C-]: channel.c:4034 __ast_read: 
DTMF end passthrough '#' on SIP/at-tcty-ssw-
[Jan 30 21:00:01] DEBUG[7114][C-]: bridge_channel.c:1174 
bridge_channel_feature: DTMF feature string on 
0x7f6b8c10f998(SIP/at-tcty-ssw-) is now '*#'
[Jan 30 21:00:01] DEBUG[7114][C-]: bridge_channel.c:1185 
bridge_channel_feature: DTMF feature hook 0x7f6b8c1d9480 matched DTMF 
string '*#' on 0x7f6b8c10f998(SIP/ssw-)
[Jan 30 21:00:01] DEBUG[7114][C-]: 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-]: 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-]: app.c:305 ast_app_exec_macro: 
SIP/vpn-sbc-0001 Original location: default,,1
[Jan 30 21:00:01] DEBUG[7118][C-]: pbx.c:4875 
pbx_extension_helper: Launching 'ParkAndAnnounce'
-- Executing [s@macro-parkswitch:1] 
ParkAndAnnounce(SIP/vpn-sbc-0001, ,,PARKED,SIP/100) in new stack
[Jan 30 21:00:01] DEBUG[7118][C-]: bridge.c:486 
find_best_technology: Bridge technology softmix does not have any 
capabilities we want.
[Jan 30 21:00:01] DEBUG[7118][C-]: 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-]: 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-]: bridge.c:505 
find_best_technology: Chose bridge technology holding_bridge
[Jan 30 21:00:01] DEBUG[7118][C-]: 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-]: bridge.c:779 
bridge_base_init: Bridge