[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-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 <ldardini at 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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-users/attachments/20140131/776478f5/attachment.html>