<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">Thank you for reply, Matt and Leandro!<br>
<br>
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).<br>
<br>
Maybe I could do a hack in the Asterisk source to achive this if
there is no other solution.<br>
<br>
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...<br>
<br>
[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<br>
[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<br>
[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4171
__ast_read: DTMF begin '2' received on SIP/at-tcty-ssw-00000000<br>
<b>[Jan 30 11:13:49] DTMF[29445][C-00000000]: channel.c:4185
__ast_read: DTMF begin ignored '2' on SIP/at-tcty-ssw-00000000</b><br>
[Jan 30 11:13:49] DEBUG[29445][C-00000000]:
res_rtp_asterisk.c:3165 ast_rtcp_read: Got RTCP report of 80 bytes<br>
[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<br>
<br>
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
(<a class="moz-txt-link-freetext" href="http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-duration-1.8/">http://svnview.digium.com/svn/asterisk/team/oej/rana-dtmf-duration-1.8/</a>)<br>
<br>
I have now quickly tested his code and it seems to work, so I will
propably go with Asterisk 1.8.<br>
<br>
Thanks again.<br>
<br>
-- Anders<br>
<br>
</div>
<blockquote
cite="mid:CAN2PU+4LetvdnkRFDipAKR_CFxL=Bxk8YQytsdz_G3p2N_GVCw@mail.gmail.com"
type="cite">
<pre wrap="">On Thu, Jan 30, 2014 at 2:58 PM, Leandro Dardini <a class="moz-txt-link-rfc2396E" href="mailto:ldardini@gmail.com"><ldardini@gmail.com></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">
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
</pre>
</blockquote>
<br>
</body>
</html>