COLP updates:

* Initial connect does not cause COLP exchange because it has already been
done (unless the 'I' option inhibits/blocks it) by Dial, Queue, or
FollowMe.

* Local channel optimization must not cause COLP exchange because no
parties are changing communication associations.

* Transfers cause COLP exchange.  As far as the protocols are concerned,
COLP updates are transfers.

* Transfers to an application must perform a COLP update.  e.g., Party A
is transferred to voicemail.

* Changing from a multi-party bridge to a two party bridge needs to
perform a COLP exchange.

* Moving channels between bridges needs to perform a COLP exchange on the
two bridges involved.

* ConfBridge joins/leaves do not cause COLP updates.  (Bridge technology
is not Native or 1-1mix.)


Scenarios:

* Initial connect: A calls B
1) Dial initially placed
A - Dial - B
2) B answers
3) Dial passes the initial COLP from B to A,
	does ast_indicate(Answer) on A,
	and then bridges A and B together without COLP exchange.
A - Bridge - B

* Initial connect: A calls B through local channel.
1) Dials are initially placed
A - Dial - L;1 -- L;2 - Dial - B
2) B answers
3) Dial passes the initial COLP from B to L;2,
	does ast_indicate(Answer) on L;2,
	and then bridges L;2 and B together without COLP exchange.
A - Dial - L;1 -- L;2 - Bridge - B
4) Dial passes the initial COLP from L;1 to A,
	does ast_indicate(Answer) on A,
	and then bridges A and L;1 together without COLP exchange.
A - Bridge - L;1 -- L;2 - Bridge - B

* Local optimization:
A - Bridge - L;1 -- L;2 - Bridge - B
L;1 and L;2 optimize themselves out without COLP exchange
A - Bridge - B

* External transfer of two bridged calls:
B1 - Bridge1 - A
B2 - Bridge2 - C
Either a bridge merge of Bridge1 and Bridge2 or
	a move/swap of B1-C or B2/A will cause a COLP exchange.
A - Bridge - C

* External transfer of a bridged call and a call to an application:
B1 - Bridge - A
B2 - Voicemail
Party A is masqueraded into B2.  A COLP update needs to be sent to A
	because dialplan may have setup COLP information for Voicemail.
A - Voicemail

* Multi-party bridge to two-party bridge conversion:
A - Bridge - B
	\--- C
1) Party C hangs up.
A COLP exchange between A and B is done.  The channel drivers for A and B
should filter out any redundant COLP updates from the core because the
three party bridge may have been a two party bridge between A and B
initially.


Some implementation details:

* ast_bridge_join()/ast_bridge_impart() needs a COLP exchange request flag
to support initial connect.

* ast_bridge_merge()/ast_bridge_move() needs a COLP exchange request flag
to support transfers and local channel optimization.

* bridge_reconfigured() needs a COLP exchange request flag.  This function
should be where the COLP exchange is actually done for bridges.  The COLP
exchange request will actually do an exchange if there are two parties in
the bridge, the current bridge technology is Native or 1-1mix, and neither
are in the process of leaving it (bridge_channel->state == WAIT).  The
actual push/pull routines do not need to deal with COLP at all.

* Channel drivers should filter out redundant COLP updates since they
likely need to remember what has been sent out over the wire before.