Fix a possible race condition where duplicate requests may be handled by separate threads.

If an endpoint retransmits a request, it's possible due to temporary load
that Asterisk may end up processing both requests at the same time in separate
threads. One thread will successfully handle the request, while the other thread
fails to handle the request since the first thread already registered the
transaction with the PJSIP core.

The fix here is to detect the duplicated transaction failure and to silently
absorb the request since another thread should be properly handling the request.

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



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@427840 f38db490-d61c-443f-a65b-d21fe96a405b
res_pjsip_pubsub: Add some casting so that it builds once again.


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@427843 f38db490-d61c-443f-a65b-d21fe96a405b
app_confbridge: Play "leader has left" sound even when musiconhold is enabled.

Currently if the leader of a conference bridge leaves any participant
that has musiconhold enabled will not hear the "leader has left" sound.
This is because musiconhold is started and THEN the sound is played.

This change makes it so that the sound is played and THEN musiconhold
is started. This provides a better experience for users as they may not
have known previously why they went back to musiconhold.

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

Merged revisions 427844 from http://svn.asterisk.org/svn/asterisk/branches/11


git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@427845 f38db490-d61c-443f-a65b-d21fe96a405b
Fix race condition that could result in ARI transfer messages not being sent.

From reviewboard:

"During blind transfer testing, it was noticed that tests were failing
occasionally because the ARI blind transfer event was not being sent.
After investigating, I detected a race condition in the blind transfer
code. When blind transferring a single channel, the actual transfer
operation (i.e. removing the transferee from the bridge and directing
them to the proper dialplan location) is queued onto the transferee
bridge channel. After queuing the transfer operation, the blind transfer
Stasis message is published. At the time of publication, snapshots of
the channels and bridge involved are created. The ARI subscriber to the
blind transfer Stasis message then attempts to determine if the bridge
or any of the involved channels are subscribed to by ARI applications.
If so, then the blind transfer message is sent to the applications. The
way that the ARI blind transfer message handler works is to first see
if the transferer channel is subscribed to. If not, then iterate over
all the channel IDs in the bridge snapshot and determine if any of
those are subscribed to. In the test we were running, the lone
transferee channel was subscribed to, so an ARI event should have been
sent to our application. Occasionally, though, the bridge snapshot did
not have any channels IDs on it at all. Why?

The problem is that since the blind transfer operation is handled by a
separate thread, it is possible that the transfer will have completed and
the channels removed from the bridge before we publish the blind transfer
Stasis message. Since the blind transfer has completed, the bridge on
which the transfer occurred no longer has any channels on it, so the
resulting bridge snapshot has no channels on it. Through investigation of
the code, I found that attended transfers can have this issue too for the
case where a transferee is transferred to an application."

The fix employed here is to decouple the creation of snapshots for the transfer
messages from the publication of the transfer messages. This way, snapshots
can be created to reflect what they are at the time of the transfer operation.

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



git-svn-id: http://svn.asterisk.org/svn/asterisk/branches/12@427848 f38db490-d61c-443f-a65b-d21fe96a405b