Although the ISDN/Q.850/Q.931 hangup cause code is already part of the ARI
and AMI hangup and channel destroyed events, it can be helpful to know what
the actual channel technology code was if the call was unsuccessful.
For PJSIP, it's the SIP response code.
* A new "tech_hangupcause" field was added to the ast_channel structure along
with ast_channel_tech_hangupcause() and ast_channel_tech_hangupcause_set()
functions. It should only be set for off-nominal terminations.
* chan_pjsip was modified to set the tech hangup cause in the
chan_pjsip_hangup() and chan_pjsip_session_end() functions. This is a bit
tricky because these two functions aren't always called in the same order.
The channel that hangs up first will get chan_pjsip_session_end() called
first which will trigger the core to call chan_pjsip_hangup() on itself,
then call chan_pjsip_hangup() on the other channel. The other channel's
chan_pjsip_session_end() function will get called last. Unfortunately,
the other channel's HangupRequest events are sent before chan_pjsip has had a
chance to set the tech hangupcause code so the HangupRequest events for that
channel won't have the cause code set. The ChannelDestroyed and Hangup
events however will have the code set for both channels.
* A new "tech_cause" field was added to the ast_channel_snapshot_hangup
structure. This is a public structure so a bit of refactoring was needed to
preserve ABI compatibility.
* The ARI ChannelHangupRequest and ChannelDestroyed events were modified to
include the "tech_cause" parameter in the JSON for off-nominal terminations.
The parameter is suppressed for nominal termination.
* The AMI SoftHangupRequest, HangupRequest and Hangup events were modified to
include the "TechCause" parameter for off-nominal terminations. Like their ARI
counterparts, the parameter is suppressed for nominal termination.
DeveloperNote: A "tech_cause" parameter has been added to the
ChannelHangupRequest and ChannelDestroyed ARI event messages and a "TechCause"
parameter has been added to the HangupRequest, SoftHangupRequest and Hangup
AMI event messages. For chan_pjsip, these will be set to the last SIP
response status code for off-nominally terminated calls. The parameter is
suppressed for nominal termination.
When an endpoint is created in the core of Asterisk a subscription
was previously created alongside it to monitor any channels being
destroyed that were related to it. This was done by receiving all
channel snapshot updates for every channel and only reacting when
it was indicated that the channel was dead.
This change removes this logic and instead provides an API call
for directly removing a channel from an endpoint. This is called
when channels are destroyed. This operation is fast, so blocking
the calling thread for a short period of time doesn't have any
noticeable impact.
Full details: http://s.asterisk.net/dc679ec3
The previous proof-of-concept showed that the cpp_map_name_id alternate
storage backed performed better than all the others so this final PR
adds only that option. You still need to enable it in menuselect under
the "Alternate Channel Storage Backends" category.
To select which one is used at runtime, set the "channel_storage_backend"
option in asterisk.conf to one of the values described in
asterisk.conf.sample. The default remains "ao2_legacy".
UpgradeNote: With this release, you can now select an alternate channel
storage backend based on C++ Maps. Using the new backend may increase
performance and reduce the chances of deadlocks on heavily loaded systems.
For more information, see http://s.asterisk.net/dc679ec3
