<![CDATA[Parked calls lingering in FOP2]]>I just added parked calls to FOP2, and restarted, logged in and out and all that..

My parked calls are lingering there after they are gone. Am I supposed to have hints for parked calls?

http://wewt.net/old/gallery/forum/fop2.jpg

Also, using DAHDI/1, DAHDI/2, etc didn't work for me.. I put in DAHDI/i1, etc.. that works,. but it shows the whole channel name..

]]>http://localhost:4567/topic/657/parked-calls-lingering-in-fop2RSS for NodeTue, 27 Oct 2026 09:52:49 GMTMon, 21 Feb 2011 23:55:29 GMT60<![CDATA[Reply to Parked calls lingering in FOP2 on Fri, 04 Mar 2011 19:21:10 GMT]]>callevents=yes is set.

Before the next MeetMe conference I will do a fop2_server -X 3 and send you the output.

EDIT: changed "post here" to "send you"

]]>http://localhost:4567/post/2855http://localhost:4567/post/2855Fri, 04 Mar 2011 19:21:10 GMT<![CDATA[Reply to Parked calls lingering in FOP2 on Fri, 04 Mar 2011 18:59:35 GMT]]>The lingering in parking is most probably because callevents is not set to yes in sip.conf. Not sure about meetmes. To everyone with those issues, please be absolutely sure that in the [general] section in sip.conf you have

callevents=yes

]]>http://localhost:4567/post/2854http://localhost:4567/post/2854Fri, 04 Mar 2011 18:59:35 GMT<![CDATA[Reply to Parked calls lingering in FOP2 on Fri, 04 Mar 2011 15:15:14 GMT]]>I get the same behavior with lingering MeetMe users visible after the conference has ended. We are using SIP transfers. We have version 2.20

Will it be possible to support SIP transfers to conferences and parking lots or will I have to retrain the users to use the native asterisk transfer methods?

]]>http://localhost:4567/post/2853http://localhost:4567/post/2853Fri, 04 Mar 2011 15:15:14 GMT<![CDATA[Reply to Parked calls lingering in FOP2 on Thu, 24 Feb 2011 12:33:52 GMT]]>Forgot to ask what your asterisk version was. In general you should try to avoid using native sip transfers but instead use the builtin asterisk transfer feature, or park from fop2 itself. Anyways, when did you download the beta, last week, or last month? If you can reproduce it every time, you can start fop2 in debug mode with the command:

/usr/local/fop2/fop2_server -X 3

and send pirvately your capture to me. Quick explanation:

In fop 2.11 we take the AMI park events to the letter, that means that when you do a native transfers to a park extension, the ami event is ParkedChannel: YOURSELF (not the bridged channel), and a millisecond after that: UnparkedChannel: YOURSELF. And it actually makes some sense, because you are dialing the parking extension to hear the parking lot, but the event signals the channel being parked as your own, and just destroys it moment later. Fop then showed the call for a brief moment, and then removes it because ami says so.

In fop 2.20 I tried to do a workaround, detecting when the park event shows that you are parking yourself, and mantaining the park relations and status internally. I did some updates on that behaviour in the last month, so you might want to update if you are not using a recent fop 2.20 version.

]]>http://localhost:4567/post/2852http://localhost:4567/post/2852Thu, 24 Feb 2011 12:33:52 GMT<![CDATA[Reply to Parked calls lingering in FOP2 on Tue, 22 Feb 2011 23:10:20 GMT]]>I'm using 2.20. Just purchased it last week.

We're using the transfer button on the Polycom..

]]>http://localhost:4567/post/2851http://localhost:4567/post/2851Tue, 22 Feb 2011 23:10:20 GMT<![CDATA[Reply to Parked calls lingering in FOP2 on Tue, 22 Feb 2011 21:06:14 GMT]]>How are you parking calls ? What fop2 version are you using ? Try to use the latest fop 2.20 and avoid using native sip transfers...

]]>http://localhost:4567/post/2850http://localhost:4567/post/2850Tue, 22 Feb 2011 21:06:14 GMT