Handle an originated channel being sent into a non-empty bridge

Originated channels are a bit odd - they are technically a dialed channel (thus
the party B or peer) but, since there is no caller, they are treated as the
party A. When entering into a bridge that already contains participants, the CDR
engine - if the CDR record is in the Dial state - attempts to match the person
entering the bridge with an existing participant. The idea is that if you dialed
someone and the person you dialed is already in the bridge, you don't need a new
CDR record, the existing CDR record describes the relationship.

Unfortunately, for an originated channel, there is no Party B. If no one was in
the bridge this didn't cause any issues; however, if participants were in the
bridge the CDR engine would attempt to match a non-existant Party B on the
channel's CDR record and explode.

This patch fixes that, and a unit test has been added to cover this case.



git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@393164 f38db490-d61c-443f-a65b-d21fe96a405b
Add stasis publications for blind and attended transfers.

This creates stasis messages that are sent during a blind or
attended transfer. The stasis messages also are converted to
AMI events.

Review: https://reviewboard.asterisk.org/r/2619

(closes issue ASTERISK-21337)
Reported by Matt Jordan



git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@393182 f38db490-d61c-443f-a65b-d21fe96a405b
Fix overlapping enum ast_bridge_feature_flags.

Things may no longer behave in an unexpected fashion.  Local channel
optimization to holding bridges will work again.


git-svn-id: http://svn.asterisk.org/svn/asterisk/trunk@393184 f38db490-d61c-443f-a65b-d21fe96a405b