those two events should not be assumed to be in a specific order, that is correct, they can come in either order. A channel could be parked before or after we see progress.  In some cases you might even see an answer without progress I think.  This depends on what we get from the remote endpoint and when.  You may be able to force things in dial plan to wait for progress depending on how your dial plan is structured and how you are executing things, but would need a better understanding of callflow to say any more

On Wednesday, December 23, 2015, 张顺通 <shuntongzhang@gmail.com> wrote:
sorry，park is ahead.

2015-12-24 09:40:28.238697  CHANNEL_PARK 3043677952
2015-12-24 09:40:28.238697   CHANNEL_PROGRESS  3042203392


2015-12-24 10:28 GMT+08:00 张顺通 <shuntongzhang@gmail.com>:
I met a problem
when I register PROCESS and PARK event use switch_event_bind_removable.
In my view,In normal sequence，PROCESS call back first and PARK callback second.
But sometims PARK is callback first and PROCESS callback second. And in different thread.

The out-of-order problem Bothers me.

my dialplan:
<action application="ring_ready" />
<action application="park" />

event time is same,but out of order and in different
last number is thread number
2015-12-24 09:40:28.238697   CHANNEL_PROGRESS  3042203392

2015-12-24 09:40:28.238697  CHANNEL_PARK 3043677952