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
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
