summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2014-12-01main/stasis: Allow subscriptions to use a threadpool for message deliveryMatthew Jordan
Prior to this patch, all Stasis subscriptions would receive a dedicated thread for servicing published messages. In contrast, prior to r400178 (see review https://reviewboard.asterisk.org/r/2881/), the subscriptions shared a thread pool. It was discovered during some initial work on Stasis that, for a low subscription count with high message throughput, the threadpool was not as performant as simply having a dedicated thread per subscriber. For situations where a subscriber receives a substantial number of messages and is always present, the model of having a dedicated thread per subscriber makes sense. While we still have plenty of subscriptions that would follow this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into the following two categories: * Large number of subscriptions, specifically those tied to endpoints/peers. * Low number of messages. Some subscriptions exist specifically to coordinate a single message - the subscription is created, a message is published, the delivery is synchronized, and the subscription is destroyed. In both of the latter two cases, creating a dedicated thread is wasteful (and in the case of a large number of peers/endpoints, harmful). In those cases, having shared delivery threads is far more performant. This patch adds the ability of a subscriber to Stasis to choose whether or not their messages are dispatched on a dedicated thread or on a threadpool. The threadpool is configurable through stasis.conf. Review: https://reviewboard.asterisk.org/r/4193 ASTERISK-24533 #close Reported by: xrobau Tested by: xrobau ........ Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01app_record: Fix bug where using the 'k' option and hanging up would trim 1/4 ↵Joshua Colp
of a second of the recording. The Record dialplan function trims 1/4 of a second from the end of recordings in case they are terminated because of DTMF. When hanging up, however, you don't want this to happen. This change makes it so on hangup this does not occur. ASTERISK-24530 #close Reported by: Ben Smithurst patches: app_record_v2.diff submitted by Ben Smithurst (license 6529) Review: https://reviewboard.asterisk.org/r/4201/ ........ Merged revisions 428653 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428654 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428655 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428656 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-12-01channel: Extend size of buffer for codecs in "core show channeltype" CLI ↵Joshua Colp
command. The static buffer for codecs when invoking the "core show channeltype" CLI command did not have enough room for all codecs. This has been extended so it does. ASTERISK-24542 #close Reported by: snuffy patches: channeltype-tech.diff submitted by snuffy (license 5024) Review: https://reviewboard.asterisk.org/r/4204/ ........ Merged revisions 428632 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-24test_channel_feature_hooks.c: Fix unit test for DTMF hooks.Richard Mudgett
Fix the failing /channels/features/test_features_channel_dtmf unit test. DTMF emulation does not work without a stream of packets to prod the emulation code. Review: https://reviewboard.asterisk.org/r/4199/ ........ Merged revisions 428604 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428605 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-24DTMF hooks: Leaving channels need to push any collected digits into the bridge.Richard Mudgett
Any partially collected DTMF digits for a DTMF hook need to be pushed into the bridge when a channel leaves the bridging system as if there were a timeout. Review: https://reviewboard.asterisk.org/r/4199/ ........ Merged revisions 428601 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428602 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428603 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21manager: Fix could not extend string messages.Richard Mudgett
When shutting down Asterisk that has an active AMI connection, you get several "failed to extend from %d to %d" messages because use of the EVENT_FLAG_SHUTDOWN attempts to add all AMI permission strings to the event. * Created MAX_AUTH_PERM_STRING to use when creating stack based struct ast_str variables used with the authority_to_str() and user_authority_to_str() functions instead of a variety of magic numbers that could be too small. * Added a special check for EVENT_FLAG_SHUTDOWN to authority_to_str() so it will not attempt to add all permission level strings. Review: https://reviewboard.asterisk.org/r/4200/ ........ Merged revisions 428570 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428571 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428572 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21sorcery: Make is_object_field_registered handle field names that are regexes.George Joseph
As a result of https://reviewboard.asterisk.org/r/3305, res_sorcery_realtime was tossing database fields that didn't have an exact match to a sorcery registered field. This broke the ability to use regexes as field names which manifested itself as a failure of res_pjsip_phoneprov_provider which uses this capability. It also broke handling of fields that start with '@' in realtime but I don't think anyone noticed. This patch does the following... * Modifies ast_sorcery_fields_register to pre-compile the name regex. * Modifies ast_sorcery_is_object_field_registered to test the regex if it exists instead of doing an exact strcmp. * Modifies res_pjsip_phoneprov_provider with a few tweaks to get it to work with realtime. Tested-by: George Joseph Review: https://reviewboard.asterisk.org/r/4185/ ........ Merged revisions 428543 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428544 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21sip.conf.sample - note that media_address does not change listen address, ↵Olle Johansson
just the SDP git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-21main/bridge_basic: Fix features regressions introduced by r428165Matthew Jordan
In r428165, two bugs were introduced: * Prior to entering the features retry loop, the buffer that holds the collected digits is wiped. However, this inadvertently wipes out the first collected digit on the first pass through, which is obtained in ast_stream_and_wait. This caused all of the features tests to fail. * If ast_app_dtget returns a hangup (-1), the loop would retry incorrectly. If we detect a hangup, we have to stop trying the feature. This patch fixes both issues. Review: https://reviewboard.asterisk.org/r/4196/ ........ Merged revisions 428505 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20Fix error with mixed address family ACLs.Mark Michelson
Prior to this commit, the address family of the first item in an ACL was used to compare all incoming traffic. This could lead to traffic of other IP address families bypassing ACLs. ASTERISK-24469 #close Reported by Matt Jordan Patches: ASTERISK-24469-11.diff uploaded by Matt Jordan (License #6283) AST-2014-012 ........ Merged revisions 428402 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 428417 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428422 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428425 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20AST-2014-018 - func_db: DB Dialplan function permission escalation via AMI.Kevin Harwell
The DB dialplan function when executed from an external protocol (for instance AMI), could result in a privilege escalation. Asterisk now inhibits the DB function from being executed from an external interface if the live_dangerously option is set to no. ASTERISK-24534 Reported by: Gareth Palmer patches: submitted by Gareth Palmer (license 5169) ........ Merged revisions 428331 from http://svn.asterisk.org/svn/asterisk/branches/1.8 ........ Merged revisions 428363 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428409 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428413 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20PJSIP ACLs: Fix ACLs not loading on startup and apply/acl issues on contactJonathan Rose
The biggest problem this patch fixes is that ACLs weren't previously being loaded when the res_pjsip_acl module was loaded. Yikes. In addition, the ACL options contact_permit and contact_acl were effectively interpreted as contact_deny and this patch fixes that as well. AST-1418 #close Reported by: Thomas Thompson Review: https://reviewboard.asterisk.org/r/4120/ ASTERISK-24531 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4171/ ........ Merged revisions 428333 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428343 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20AST-2014-017 - app_confbridge: permission escalation/ class authorization.Kevin Harwell
Confbridge dialplan function permission escalation via AMI and inappropriate class authorization on the ConfbridgeStartRecord action. The CONFBRIDGE dialplan function when executed from an external protocol (for instance AMI), could result in a privilege escalation. Also, the AMI action “ConfbridgeStartRecord” could also be used to execute arbitrary system commands without first checking for system access. The AMI “ConfbridgeStopRecord” has also been updated to only run under a system authorization. Asterisk now inhibits the CONFBRIDGE function from being executed from an external interface if the live_dangerously option is set to no. Also, the “ConfbridgeStartRecord” AMI action is now only allowed to execute under a user with system level access. ASTERISK-24490 Reported by: Gareth Palmer ........ Merged revisions 428332 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428334 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428339 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20AST-2014-016: Fix crash when receiving an in-dialog INVITE with Replaces in ↵Joshua Colp
res_pjsip_refer. The implementation of INVITE with Replaces in res_pjsip_refer did not expect them to occur in-dialog. As a result it would incorrectly attempt to hang up a channel it thought was under its control. In reality the channel would be under the control of another thread. When the other thread accessed the channel it would be accessing freed memory and could crash. This change makes res_pjsip_refer not act on an in-dialog INVITE with Replaces. ASTERISK-24528 #close Reported by: Joshua Colp ........ Merged revisions 428304 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428305 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-20AST-2014-015: Fix race condition in chan_pjsip when sending responses after ↵Joshua Colp
a CANCEL has been received. Due to the serialized architecture of chan_pjsip there exists a race condition where a CANCEL may be received and processed before responses (such as 180 Ringing, 183 Session Progress, and 200 OK) are sent. Since the session is in an unexpected state PJSIP will assert when this is attempted. This change makes it so that these responses are not sent on disconnected sessions. ASTERISK-24471 #close Reported by: yaron nahum ........ Merged revisions 428301 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428302 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19stringfields: Fix bug in ast_string_fields_copy.Corey Farrell
ast_string_fields_copy relies on the fact that __ast_string_field_release_active never previously zeroed pool->used, so keeping the existing pointer was "ok". Now that existing pools can be reset to 'empty', it is important to set each field to __ast_string_field_empty after releasing the memory. ASTERISK-24535 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4186/ ........ Merged revisions 428272 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428273 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428274 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19ast_str: Fix improper member access to struct ast_str members.Richard Mudgett
Accessing members of struct ast_str outside of the string manipulation API routines is invalid since struct ast_str is supposed to be treated as opaque. Review: https://reviewboard.asterisk.org/r/4194/ ........ Merged revisions 428244 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428245 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428246 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19res_pjsip_sdp_rtp: Add support for optimistic SRTP.Joshua Colp
Optimistic SRTP is the ability to enable SRTP but not have it be a fatal requirement. If SRTP can be used it will be, if not it won't be. This gives you a better chance of using it without having your sessions fail when it can't be. Encrypt all the things! Review: https://reviewboard.asterisk.org/r/3992/ ........ Merged revisions 428222 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19alembic: Fix alembic migration for 'moh_passthrough' option in res_pjsip.Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-19res_pjsip_refer: Ensure Refer-To is NULL terminated and parse it as a URI.Joshua Colp
There is no guarantee that when we get a Refer-To that it will be NULL terminated. As the URI parsing function requires it to be we now NULL terminate it. Additionally parsing the Refer-To as a 'To' header is needless and it can simply be done as a URI. This also fixes a problem where certain Refer-To headers would not be parsed as a 'To' header causing the REFER to fail. ASTERISK-24508 #close Reported by: Beppo Mazzucato Review: https://reviewboard.asterisk.org/r/4187/ ........ Merged revisions 428195 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428196 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-18parking_tests.c: Add missing newline on a unit test message.Richard Mudgett
........ Merged revisions 428168 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428169 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428170 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-17Allow for transferer to retry when dialing an invalid extension.Mark Michelson
This allows for a configurable number of attempts for a transferer to dial an extension to transfer the call to. For Asterisk 13, the default values are such that upgrading between versions will not cause a behaivour change. For trunk, though, the defaults will be changed to be more user-friendly. Review: https://reviewboard.asterisk.org/r/4167 ........ Merged revisions 428145 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-17chan_sip: Fix theoretical leak of p->refer.Corey Farrell
If transmit_refer is called when p->refer is already allocated, it leaks the previous allocation. Updated code to always free previous allocation during a new allocation. Also instead of checking if we have a previous allocation, always create a clean record. ASTERISK-15242 #close Reported by: David Woolley Review: https://reviewboard.asterisk.org/r/4160/ ........ Merged revisions 428117 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428118 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428119 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-17apps/app_confbridge: Ensure 'normal' users hear message when last marked leavesMatthew Jordan
When r428077 was made for ASTERISK-24522, it failed to take into account users who are neither wait_marked nor end_marked. These users are *also* supposed to hear the 'leader has left the conference' message. Granted, this behaviour is a bit odd; however, that is how it used to work... and behaviour changes are not good. This patch ensures that if there are any 'normal' users present when the last marked user leaves the conference, the message will still be played to them. Note that this regression was caught by the Asterisk Test Suite's confbridge_nominal test, which has a quirky combination of users. ........ Merged revisions 428113 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428114 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428115 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-17app_confbridge: Don't play leader leaving prompt if no one will hear itMatthew Jordan
Consider the following: - A marked user in a conference - One or more end_marked only users in the conference When the marked users leaves, we will be in the conf_state_multi_marked state. This currently will traverse the users, kicking out any who have the end_marked flags. When they are kicked, a full ast_bridge_remove is immediately called on the channels. At this time, we also unilaterally set the need_prompt flag. When the need_prompt flag is set, we then playback a sound to the bridge informing everyone that the leader has left; however, no one is left in the bridge. This causes some odd behaviour for the end_marked users - they are stuck waiting for the bridge to be unlocked. This results in them waiting for 5 or 6 seconds of dead air before hearing that they've been kicked. Unfortunately, we do have to keep the bridge locked while we're playing back the 'leader-has-left' prompt. If there are any wait_marked users in the conference, this behaviour can't be easily changed - but we do make the case of the end_marked users better with this patch. Review: https://reviewboard.asterisk.org/r/4184/ ASTERISK-24522 #close Reported by: Matt Jordan ........ Merged revisions 428077 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 428078 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428079 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-16chan_pjsip: Remove AOR check when dialing and one is specified.Joshua Colp
The AOR value may contain the name of an AOR or a full SIP URI. Checking if the AOR exists can't be done as a result of this. ........ Merged revisions 428051 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428052 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-16chan_sip: Fix bug where DTLS configuration from general would copy dtlsenable.Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-15cel/cel_odbc: Provide microsecond precision in 'eventtime' column when possibleMatthew Jordan
This patch adds microsecond precision when inserting a CEL record into a table with an "eventtime" column of type timestamp, instead of second precision. The documentation (configs/cel_odbc.conf.sample) was already saying that the eventtime column included microseconds precision, but that was not the case. Also, without this patch, if you had a table with an "eventtime" column of type varchar, you had millisecond precision. With this patch, you also get microsecond precision in this case. Review: https://reviewboard.asterisk.org/r/3980 ASTERISK-24283 #close Reported by: Etienne Lessard patches: cel_odbc_time_precision.patch uploaded by Etienne Lessard (License 6394) ........ Merged revisions 427952 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427953 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427954 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-15chan_pjsip: Add additional log message when an AOR is specified when dialing ↵Joshua Colp
and it does not exist. ASTERISK-24499 #close Reported by: Rusty Newton ........ Merged revisions 428007 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 428008 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428009 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-15chan_motif / chan_pjsip: Fix incorrect "No such module" messages when reloading.Joshua Colp
For chan_motif the direct return value of the underlying config options framework was passed back. This can relay various states which the module loader would not interpet as success. It has been changed so only on errors will it report back an error. For chan_pjsip the code implemented a dummy reload function which always returned an error. This has been removed as all configuration is held within res_pjsip instead. ASTERISK-23651 #close Reported by: Rusty Newton ........ Merged revisions 427981 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427982 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-15res_pjsip: Enforce requirements for session timer minimum expiration period ↵Joshua Colp
and normal expiration period. This change enforces the requirements in PJSIP for session timer configuration. The minimum expiration period must be 90 seconds or higher and the normal expiration period can not be lower than the minimum expiration period. If either of these were done the code would assert at session setup time. ASTERISK-24336 #close Reported by: Leon Rowland ........ Merged revisions 427978 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427979 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-15chan_sip: Add support for setting DTLS configuration in the general section.Joshua Colp
Configuration of DTLS in the general section will be applied to any users or peers. If configuration exists at their level it overrides the general section values. ASTERISK-24128 #close Reported by: Michael K. patches: dtls_default_settings.patch submitted by Michael K. (license 6621) Review: https://reviewboard.asterisk.org/r/3867/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14tests/test_cel: Unlock bridge on off nominal pathsMatthew Jordan
If the test fails due to memory allocation errors, we may as well attempt to unlock the bridge on the way out. ........ Merged revisions 427927 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Documentation: Revise explanation of cdr.conf option 'Unanswered'Jonathan Rose
ASTERISK-24279 #close Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/4109/ ........ Merged revisions 427901 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427902 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14stun: correct attribute string padding to match rfcScott Griepentrog
When sending the USERNAME attribute in an RTP STUN response, the implementation in append_attr_string passed the actual length, instead of padding it up to a multiple of four bytes as required by the RFC 3489. This change adds separate variables for the string and padded attributed lengths, and performs padding correctly. Reported by: Thomas Arimont Review: https://reviewboard.asterisk.org/r/4139/ ........ Merged revisions 427874 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427875 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427876 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427877 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Fix race condition that could result in ARI transfer messages not being sent.Mark Michelson
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 ........ Merged revisions 427848 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427870 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14app_confbridge: Play "leader has left" sound even when musiconhold is enabled.Joshua Colp
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 ........ Merged revisions 427845 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427846 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427847 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-14Fix race condition where duplicated requests may be handled by multiple threads.Mark Michelson
This is the Asterisk 13 version of the patch. The main difference is in the pubsub code since it was completely refactored between Asterisk 12 and 13. Review: https://reviewboard.asterisk.org/r/4175 ........ Merged revisions 427841 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-13res_pjsip_exten_state: PJSIPShowSubscriptionsInbound causes crashKevin Harwell
When using a non-default sorcery wizard (in this instance realtime) for outbound registrations and after adding in an appropriate call to ast_sorcery_apply_config() (since it is missing) Asterisk will crash after a stack overflow occurs due to the code infinitely recursing. The fix entails removing the outbound registration state dependency from the outbound registration sorcery object and instead keeping an in memory container that can be used to lookup the state when needed. ASTERISK-24514 Reported by: Mark Michelson Review: https://reviewboard.asterisk.org/r/4164/ ........ Merged revisions 427814 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427815 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-13Stasis: Fix StasisEnd message orderingKinsey Moore
This change corrects message ordering in cases where a channel-related message can be received after a Stasis/ARI application has received the StasisEnd message. The StasisEnd message was being passed to applications directly without waiting for the channel topic to empty. As a result of this fix, other bugs were also identified and fixed: * StasisStart messages were also being sent directly to apps and are now routed through the stasis message bus properly * Masquerade monitor datastores were being removed at the incorrect time in some cases and were causing StasisEnd messages to not be sent * General refactoring where necessary for the above * Unsubscription on StasisEnd timing changes to prevent additional messages from following the StasisEnd when they shouldn't A channel sanitization function pointer was added to reduce processing and AO2 lookups. Review: https://reviewboard.asterisk.org/r/4163/ ASTERISK-24501 #close Reported by: Matt Jordan ........ Merged revisions 427788 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427789 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427790 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-13main/rtp_engine: Fix crash when processing more than one RTCP report info blockMatthew Jordan
Asterisk - in res_rtp_asterisk - only understands a single RTCP report info block. When the RTCP information was refactored in the RTP Engine to be pushed over the Stasis message bus, I put in the hooks into the engine to handle multiple RTCP report info blocks, in the hope that a future RTP implementation would be able to provide that data. Unfortunately, res_rtp_asterisk has a tendency to "lie": (1) It will send RTCP reports with a reception_report_count greater than 1 (which is pulled directly from the RTCP packet itself, so that part is correct) (2) It will only provide a single report block When the rtp_engine goes to convert this to a JSON blob, hilarity ensues as it looks for a report block that doesn't exist. This patch updates the rtp_engine to be a bit more skeptical about what it is presented with. While this could also be fixed in res_rtp_asterisk, this patch prefers to fix it in the engine for two reasons: (1) The engine is designed to work with multiple RTP implementation, and hence having it be more robust is a good thing (tm) (2) res_rtp_asterisk's handling of RTCP information is "fun". It should report the correct reception_report_count; ideally it should also be giving us all of the blocks - but it is *definitely* not designed to do that. Going down that road is a non-trivial effort. Review: https://reviewboard.asterisk.org/r/4158/ ASTERISK-24489 #close Reported by: Gregory Malsack Tested by: Gregory Malsack ASTERISK-24498 #close Reported by: Beppo Mazzucato Tested by: Beppo Maazucato ........ Merged revisions 427762 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427763 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-12Fix leak in AMI Action BridgeCorey Farrell
Add missing reference cleanup for newly created bridge. ASTERISK-24281 Reported by: Stefan Engström Review: https://reviewboard.asterisk.org/r/4154/ ........ Merged revisions 427736 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427737 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-12pbx: Fix off-nominal case where a freed extension may still be used.Joshua Colp
If during the operation of adding an extension a priority is added but fails it is possible for the extension to be freed but still exist in the PBX core. If this occurs subsequent lookups may try to access the extension and end up in freed memory. This change removes the extension from the PBX core when the priority addition fails and then frees the extension. ASTERISK-24444 #close Reported by: Leandro Dardini Review: https://reviewboard.asterisk.org/r/4162/ ........ Merged revisions 427709 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427710 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427711 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-12Fix compiler error when using ./configure --enable-dev-mode --enable-coverageCorey Farrell
When DONT_OPTIMIZE is enabled with dev-mode, it causes a shadow compilation to be done with output to /dev/null. This can cause errors with coverage when GCC attempts to write to /dev/null.gcno. This change disables coverage for the shadow compilation. ASTERISK-24502 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4151/ ........ Merged revisions 427682 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427683 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427684 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-09manager: Fix HTTP connection reference leaks.Corey Farrell
Fix reference leak that happens if (session && !blastaway). ASTERISK-24505 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4153/ ........ Merged revisions 427641 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427642 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427643 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427644 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-09channels/chan_mgcp: Fix regression which causes gateways to be skippedMatthew Jordan
In r227276, a while loop was turned into a for loop. Unfortunately, a portion of the while loop was left in the code such that, when a static gateway is encountered in the list of MGCP gateways, the next gateway would be skipped. At best, we would simply flip past a gateway; at worst, this could lead to a crash. ASTERISK-24500 #close Reported by: Xavier Hienne patches: chan_mgcp.patch uploaded by Xavier Hienne (License 6657) ........ Merged revisions 427613 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427614 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427615 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427616 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-09addons/chan_mobile: Increase buffer size of UCS2 encoded SMS messagesMatthew Jordan
When UCS2 character encoding is used, one symbol in national language can be expanded to 4 bytes. The current buffer used for receiving message in do_monitor_phone is 256 bytes, which is not large enough for incoming messages. For example: * AT+CMGR phone response prefix '+CMGR: "REC UNREAD","+7**********",,"14/10/29,13:31:39+12"\r\n' - 60 bytes * SMS body with UCS2 encoding (max) - 280 bytes * AT+CMGR phone response suffix '\r\n\r\nOK\r\n' - 8 bytes * Terminating null character - 1 byte This results in a needed buffer size of 349 bytes. Hence, this patch opts for a 350 byte buffer. ASTERISK-24468 #close Reported by: Dmitriy Bubnov patches: chan_mobile-1_8.diff uploaded by Dmitriy Bubnov (License 6651) chan_mobile-trunk.diff uploaded by Dmitry Bubnov (License 6651) ........ Merged revisions 427607 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427610 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427611 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-09app_voicemail: Fix enhancement that allowed multiple recipients in To: headerMatthew Jordan
An issue existed in r420577, which added multiple recipients to voicemail emails. The patch, when looking at the intended recipients, looked ahead for the '|' character inside a while loop which already had pulled out the appropriate field parsing on the '|' character. This would cause it to skip the recipients. This patch fixes it such that it relies completely on the while loop to parse through the e-mail fields. Note that the original author of the patch looked at this fix and approved it. ASTERISK-24250 #close Reported by: abelbeck patches: voicemail-420577-to-comma-fix.diff uploaded by abelbeck (License 5903) ........ Merged revisions 427585 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-09bridge_native_rtp: Fix T.38 issues with remote bridgesMatthew Jordan
After r425242 the fax/sip/directmedia_reinvite_t38 test started failing due to the surviving channel not being re-INVITEd back from T.38 to audio. This patch fixes that bug - a deeper explanation of what happened follows. When two RTP channels are in a native bridge, the bridging layer will investigate each via the get_rtp_info glue callback. This callback returns the native bridge preference of the channel *at that moment in time* (that part is key). At different points during the bridging, the native bridging layer will inform the RTP capable channels of the status of the bridge via the update_peer glue callback. In a T.38 scenario with audio direct media, the sequence of events will often look like the following: * SIP/A and SIP/B both have audio and enter a native bridge. * Asterisk re-INVITEs audio between SIP/A and SIP/B directly (via an update_peer callback). * SIP/A sends a re-INVITE to T.38, which causes Asterisk to send a re-INVITE to T.38 to SIP/B. Assuming everyone 200 OKs the process, the UDPTL stack receives UDPTL packets in Asterisk from both endpoints. From the perspective of the channels, we are now in a local bridge for T.38, even though we are technically still in a remote bridge in bridge_native_rtp. (YAY!) * When one side hangs up, bridge_native_rtp is told to stop bridging. It then re-evaluates the channels and asks them how they are bridged - and since T.38 is enabled, they reply with a Local bridge (which is correct), but is wrong because the audio portion is still technically in a remote bridge. * Asterisk releases the surviving channel, whose audio is *not* re-INVITED back to Asterisk as bridge_native_rtp incorrectly assumes that it was in a local bridge. Ironically, prior to r425242, this used to work mostly due to a fluke in the bridging layer. The purpose of the get_rtp_info callback shouldn't be modified: it should tell the bridging layer what kind of bridge the channel prefers at that moment in time. If you have T.38 enabled, that *must* be a local bridge, as the UDPTPL stack must be in the media path. As such, this patch does not modify that part of the code. However, we have to tell the channels to re-evaluate themselves when they come out of a native bridge, since we can no longer trust the get_rtp_info callbacks when the native bridge is being stopped. Something else may have changed in the channels, and they may now be lying to us. As such, this patch makes it so that we unilaterally tell the channels that they are no longer bridged via the update_peer callback. This is actually what the channels expect anyway: code in both chan_sip and chan_pjsip's callbacks look at the T.38 state and - if they were in T.38 - send a re-INVITE to get the audio back to Asterisk. Review: https://reviewboard.asterisk.org/r/4157/ ........ Merged revisions 427582 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427583 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-11-08chan_console: Fix reference leaks to pvt.Corey Farrell
Fix a bunch of calls to get_active_pvt where the reference is never released. ASTERISK-24504 #close Reported by: Corey Farrell Review: https://reviewboard.asterisk.org/r/4152/ ........ Merged revisions 427554 from http://svn.asterisk.org/svn/asterisk/branches/11 ........ Merged revisions 427555 from http://svn.asterisk.org/svn/asterisk/branches/12 ........ Merged revisions 427557 from http://svn.asterisk.org/svn/asterisk/branches/13 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-04 23:19:28 +0000