[asterisk-commits] bebuild: tag 12.8.0-rc1 r429100 - in /tags/12.8.0-rc1: ./ contrib/realtime/my...
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Mon Dec 8 11:10:38 CST 2014
Author: bebuild
Date: Mon Dec 8 11:10:35 2014
New Revision: 429100
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=429100
Log:
Importing files for 12.8.0-rc1 release.
Added:
tags/12.8.0-rc1/.lastclean (with props)
tags/12.8.0-rc1/.version (with props)
tags/12.8.0-rc1/ChangeLog (with props)
tags/12.8.0-rc1/contrib/realtime/mysql/mysql_cdr.sql (with props)
tags/12.8.0-rc1/contrib/realtime/mysql/mysql_config.sql (with props)
tags/12.8.0-rc1/contrib/realtime/mysql/mysql_voicemail.sql (with props)
tags/12.8.0-rc1/contrib/realtime/oracle/oracle_cdr.sql (with props)
tags/12.8.0-rc1/contrib/realtime/oracle/oracle_config.sql (with props)
tags/12.8.0-rc1/contrib/realtime/oracle/oracle_voicemail.sql (with props)
tags/12.8.0-rc1/contrib/realtime/postgresql/postgresql_cdr.sql (with props)
tags/12.8.0-rc1/contrib/realtime/postgresql/postgresql_config.sql (with props)
tags/12.8.0-rc1/contrib/realtime/postgresql/postgresql_voicemail.sql (with props)
tags/12.8.0-rc1/contrib/realtime/sqlserver/mssql_cdr.sql (with props)
tags/12.8.0-rc1/contrib/realtime/sqlserver/mssql_config.sql (with props)
tags/12.8.0-rc1/contrib/realtime/sqlserver/mssql_voicemail.sql (with props)
Added: tags/12.8.0-rc1/.lastclean
URL: http://svnview.digium.com/svn/asterisk/tags/12.8.0-rc1/.lastclean?view=auto&rev=429100
==============================================================================
--- tags/12.8.0-rc1/.lastclean (added)
+++ tags/12.8.0-rc1/.lastclean Mon Dec 8 11:10:35 2014
@@ -1,0 +1,1 @@
+40
Propchange: tags/12.8.0-rc1/.lastclean
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/12.8.0-rc1/.lastclean
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/12.8.0-rc1/.lastclean
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/12.8.0-rc1/.version
URL: http://svnview.digium.com/svn/asterisk/tags/12.8.0-rc1/.version?view=auto&rev=429100
==============================================================================
--- tags/12.8.0-rc1/.version (added)
+++ tags/12.8.0-rc1/.version Mon Dec 8 11:10:35 2014
@@ -1,0 +1,1 @@
+12.8.0-rc1
Propchange: tags/12.8.0-rc1/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/12.8.0-rc1/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/12.8.0-rc1/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/12.8.0-rc1/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/tags/12.8.0-rc1/ChangeLog?view=auto&rev=429100
==============================================================================
--- tags/12.8.0-rc1/ChangeLog (added)
+++ tags/12.8.0-rc1/ChangeLog Mon Dec 8 11:10:35 2014
@@ -1,0 +1,32964 @@
+2014-12-08 Asterisk Development Team <asteriskteam at digium.com>
+
+ * Asterisk 12.8.0-rc1 Released.
+
+2014-12-08 15:41 +0000 [r429061] Kinsey Moore <kmoore at digium.com>
+
+ * res/stasis/app.c, main/channel_internal_api.c,
+ res/stasis/stasis_bridge.c, res/stasis/app.h,
+ include/asterisk/channel.h, res/res_stasis.c, main/channel.c:
+ Stasis: Fix StasisStart/End order and missing events This
+ corrects several bugs that currently exist in the stasis
+ application code. * After a masquerade, the resulting channels
+ have channel topics that do not match their uniqueids **
+ Masquerades now swap channel topics appropriately * StasisStart
+ and StasisEnd messages are leaked to observer applications due to
+ being published on channel topics ** StasisStart and StasisEnd
+ publishing is now properly restricted to controlling apps via app
+ topics * Race conditions exist where StasisStart and StasisEnd
+ messages due to a masquerade may be received out of order due to
+ being published on different topics ** These messages are now
+ published directly on the app topic so this is now a non-issue *
+ StasisEnds are sometimes missing when sent due to masquerades and
+ bridge swaps into and out of Stasis() ** This was due to
+ StasisEnd processing adjusting message-sent flags after Stasis()
+ had already exited and Stasis() had been re-entered ** This was
+ corrected by adjusting these flags prior to sending the message
+ while the initial Stasis() application was still shutting down
+ Review: https://reviewboard.asterisk.org/r/4213/ ASTERISK-24537
+ #close Reported by: Matt DiMeo
+
+2014-12-06 18:15 +0000 [r429028-429032] Matthew Jordan <mjordan at digium.com>
+
+ * res/res_monitor.c, /: res/res_monitor: Reset in/out sample counts
+ on Monitor start When repeatedly starting/stopping a Monitor on a
+ channel, the accumulated in/out sample counts are never reset to
+ 0. This can cause inadvertent jumps in the recordings, as the
+ code in the channel core will determine incorrectly that a jump
+ in the recorded file position should occur. Setting the sample
+ counts to 0 simply reflects the initial state a Monitor should be
+ in when it is started, as this is the initial count that would be
+ on the channels at that time. ASTERISK-24573 #close Reported by:
+ Nuno Borges patches: 24573.patch uploaded by Nuno Borges (License
+ 6116) ........ Merged revisions 429031 from
+ http://svn.asterisk.org/svn/asterisk/branches/11
+
+ * /, apps/app_meetme.c: apps/app_meetme: Apply default values on
+ initial load with no config file When the app_meetme module is
+ loaded without its configuration file, the module settings aren't
+ initialized. In particular, this impacts the use of logging
+ realtime members. This patch guarantees that we always set the
+ default module settings on initial load. Review:
+ https://reviewboard.asterisk.org/r/4242/ ASTERISK-24572 #close
+ Reported by: Nuno Borges patches: 24572.patch uploaded by Nuno
+ Borges (License 6116) ........ Merged revisions 429027 from
+ http://svn.asterisk.org/svn/asterisk/branches/11
+
+2014-12-05 17:05 +0000 [r428999] George Joseph <george.joseph at fairview5.com>
+
+ * include/asterisk/sorcery.h, tests/test_sorcery.c, main/sorcery.c,
+ include/asterisk/test.h: sorcery: Add additional observer
+ capabilities. Add new global, instance and wizard observers.
+ instance_created wizard_registered wizard_unregistered
+ instance_destroying instance_loading instance_loaded
+ wizard_mapped object_type_registered object_type_loading
+ object_type_loaded wizard_loading wizard_loaded Tested-by: George
+ Joseph Review: https://reviewboard.asterisk.org/r/4215/
+
+2014-12-04 17:12 +0000 [r428864-428972] Matthew Jordan <mjordan at digium.com>
+
+ * main/test.c: main/test: Fix compilation issue on 32-bit systems
+ On a 32-bit system, a type of intmax_t will result in a
+ compilation warning when formatted as a 'long int'. Use the
+ format specifier of %jd (which was what was used originally in
+ manager.c) to format the JSON extracted integer on both
+ 32-/64-bit systems.
+
+ * main/test.c, main/manager.c: main/test: Fix race condition
+ between AMI topic and Test Suite topic This patch fixes a race
+ condition between the raising of test AMI events (which drive
+ many tests in the Asterisk Test Suite) and other AMI events.
+ Prior to this patch, the Stasis messages published to the test
+ topic were not forwarded to the AMI topic. Instead, the code in
+ manager had a dedicated handler for test messages that was
+ independent of the topics forwarded to the AMI topic. This
+ results in no synchronization between the test messages and the
+ rest of the Stasis messages published out over AMI. In some test
+ with very tight timing constraints, this can result in out of
+ order messages and spurious test failures. Properly forwarding
+ the Test Suite topic to the AMI topic ensures that the messages
+ are synchronized properly. This patch does that, and moves the
+ message handling to the Stasis definition of the Test Suite
+ message in test.c as well. Review:
+ https://reviewboard.asterisk.org/r/4221/
+
+ * tests/test_cel.c: tests/test_cel: Add
+ test_cel_attended_transfer_bridges_link to racey tests Despite
+ failing less often, the ordering of the ATTENDEDTRANSFER event
+ and the BRIDGE_EXIT event for the Alice and David channels is not
+ defined. This makes the test still fail.
+
+ * tests/test_cel.c: tests/test_cel: Fix CEL unit test failures
+ caused by attended transfer changes When the publication of
+ attended transfer messages were pushed to another thread, some
+ subtle race conditions were introduced with the CEL unit tests.
+ This patch fixes one of them, and pushes the other to
+ ASTERISK-22367, which already exists to fix another bouncy CEL
+ unit test. In particular, this patch fixes the
+ test_cel_attended_transfer_bridges_link test, and defers the
+ test_cel_attended_transfer_bridges_swap test to the
+ aforementioned JIRA issue. ASTERISK-22367
+
+ * apps/app_voicemail.c, /: apps/app_voicemail: Fix crash with IMAP
+ when streams are opened simultaneously The UW IMAP library is
+ instrinsically not thread-safe, and relies upon higher level
+ applications to guarantee thread safety. For the most part, this
+ is provided by the vms object, which provides locking for
+ individual streams. Unfortunately, this is not sufficient for
+ calls to mail_open which create the IMAP stream. mail_open can,
+ on some systems, call into a UW IMAP specific function for
+ determining the address of a system based on a hostname,
+ ip_nametoaddr. In the ip6_unix implementation of this function,
+ static variables are used to hold parsing buffers. This can cause
+ a crash if multiple threads attempt to convert a hostname to an
+ address at the same time. Locking on a single mail stream is not
+ sufficient to prevent simultaneous access to these static
+ variables. In the IMAP library, this function can be called from
+ the mail_open and imap_status functions. As the imap_status
+ function is not used by app_voicemail, locking on access to
+ mail_open is sufficient to prevent any mangling of the buffers.
+ Review: https://reviewboard.asterisk.org/r/4188/ ASTERISK-24516
+ #close Reported by: David Duncan Ross Palmer Tested by: David
+ Duncan Ross Palmer patches: ASTERISK-24516.diff uploaded by David
+ Duncan Ross Palmer (License 6660) ........ Merged revisions
+ 428863 from http://svn.asterisk.org/svn/asterisk/branches/11
+
+2014-12-02 21:49 +0000 [r428836] George Joseph <george.joseph at fairview5.com>
+
+ * CHANGES: CHANGES: Add item for new 'pjsip show identif(y|ies)
+ commands Tested-by: George Joseph
+
+2014-12-02 17:02 +0000 [r428788] Matthew Jordan <mjordan at digium.com>
+
+ * pbx/pbx_loopback.c, /: pbx/pbx_loopback: Speed up switches by
+ avoiding unneeded lookups This patch makes a small rearrangement
+ to only do dialplan lookups during loopback switches if the
+ pattern matches. Prior to this patch, the dialplan lookups were
+ always performed, even when the result would be discarded.
+ Dialplan lookups can be very costly if remote switches - like
+ DUNDi - are present. In those cases extension matching is sped up
+ considerably, making the issue of lost digits more manageable. As
+ collateral damage, 6 trailing spaces were killed. Review:
+ https://reviewboard.asterisk.org/r/4211 ASTERISK-24577 #close
+ Reported by: Birger Harzenetter patches: ast-loopback.patch
+ uploaded by Birger Harzenetter (License 5870) ........ Merged
+ revisions 428787 from
+ http://svn.asterisk.org/svn/asterisk/branches/11
+
+2014-12-02 12:20 +0000 [r428760] Joshua Colp <jcolp at digium.com>
+
+ * res/res_pjsip_refer.c: res_pjsip_refer: Fix issue where native
+ bridge may not occur upon completion of a transfer. There are two
+ methods within res_pjsip_refer for keeping track of the state of
+ a transfer. The first is a framehook which looks at frames
+ passing by to determine the state. The second subscribes to know
+ when the channel joins a bridge. In the case when the channel
+ joins the bridge the framehook is *NOT* removed and this prevents
+ the native RTP bridging technology from getting used. This change
+ gets the channel and if it still exists remove the framehook.
+ Review: https://reviewboard.asterisk.org/r/4218/
+
+2014-12-02 00:35 +0000 [r428725-428733] George Joseph <george.joseph at fairview5.com>
+
+ * main/config.c, include/asterisk/config.h: config: Create
+ ast_variable_find_in_list() Add const char
+ *ast_variable_find_in_list(const struct ast_variable *list, const
+ char *variable); ast_variable_find() requires a config category
+ to search whereas ast_variable_find_in_list() just needs the root
+ list element which is useful if you don't have a category.
+ Tested-by: George Joseph Review:
+ https://reviewboard.asterisk.org/r/4217/
+
+ * res/res_pjsip_endpoint_identifier_ip.c,
+ res/res_pjsip/pjsip_cli.c: res_pjsip_endpoint_identifier_ip: Add
+ 'show identify(ies)' cli commands While troubleshooting other
+ things I realized there were no pjsip cli commands for identify.
+ This patch adds them. It also also fixes a reference leak when a
+ 'show endpoint' displayed identifies and properly sets the return
+ code if load_module can't allocate a cli formatter structure.
+ Tested-by: George Joseph Review:
+ https://reviewboard.asterisk.org/r/4212/
+
+2014-12-01 15:53 +0000 [r428681] Matthew Jordan <mjordan at digium.com>
+
+ * res/res_pjsip_refer.c, channels/chan_mgcp.c, main/stasis_cache.c,
+ channels/chan_sip.c, include/asterisk/stasis_internal.h,
+ configs/stasis.conf.sample (added), include/asterisk/stasis.h,
+ UPGRADE.txt, res/parking/parking_applications.c, res/res_xmpp.c,
+ include/asterisk/stasis_message_router.h, channels/sig_pri.c,
+ channels/chan_iax2.c, apps/app_queue.c, res/res_jabber.c,
+ res/res_stasis_device_state.c, main/endpoints.c,
+ res/parking/parking_bridge_features.c, main/stasis.c,
+ channels/chan_dahdi.c, main/stasis_message_router.c,
+ channels/chan_skinny.c, res/res_pjsip_mwi.c,
+ main/stasis_channels.c, res/res_pjsip_pubsub.c,
+ tests/test_stasis.c: main/stasis: Allow subscriptions to use a
+ threadpool for message delivery 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
+
+2014-12-01 13:40 +0000 [r428654] Joshua Colp <jcolp at digium.com>
+
+ * /, apps/app_record.c: app_record: Fix bug where using the 'k'
+ option and hanging up would trim 1/4 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
+
+2014-11-24 20:26 +0000 [r428601] Richard Mudgett <rmudgett at digium.com>
+
+ * main/bridge.c, main/bridge_channel.c: DTMF hooks: Leaving
+ channels need to push any collected digits into the bridge. 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/
+
+2014-11-21 18:59 +0000 [r428571] Richard Mudgett <rmudgett at digium.com>
+
+ * main/manager.c, /: manager: Fix could not extend string messages.
+ 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
+
+2014-11-21 17:41 +0000 [r428543] George Joseph <george.joseph at fairview5.com>
+
+ * res/res_pjsip_phoneprov_provider.c, tests/test_sorcery.c,
+ main/sorcery.c: sorcery: Make is_object_field_registered handle
+ field names that are regexes. 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/
+
+2014-11-20 16:36 +0000 [r428422] Mark Michelson <mmichelson at digium.com>
+
+ * /, main/acl.c: Fix error with mixed address family ACLs. 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
+
+2014-11-20 16:33 +0000 [r428334-428409] Kevin Harwell <kharwell at digium.com>
+
+ * /, funcs/func_db.c: AST-2014-018 - func_db: DB Dialplan function
+ permission escalation via AMI. 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
+
+ * apps/app_confbridge.c, /: AST-2014-017 - app_confbridge:
+ permission escalation/ class authorization. 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. 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
+
+2014-11-20 15:46 +0000 [r428333] Jonathan Rose <jrose at digium.com>
+
+ * res/res_pjsip_acl.c: PJSIP ACLs: Fix ACLs not loading on startup
+ and apply/acl issues on contact 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/
+
+2014-11-20 14:54 +0000 [r428301-428304] Joshua Colp <jcolp at digium.com>
+
+ * res/res_pjsip_refer.c: AST-2014-016: Fix crash when receiving an
+ in-dialog INVITE with Replaces in 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
+
+ * channels/chan_pjsip.c: AST-2014-015: Fix race condition in
+ chan_pjsip when sending responses after 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
+
+2014-11-19 19:30 +0000 [r428272] Corey Farrell <git at cfware.com>
+
+ * include/asterisk/stringfields.h: stringfields: Fix bug in
+ ast_string_fields_copy. 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/
+
+2014-11-19 16:56 +0000 [r428245] Richard Mudgett <rmudgett at digium.com>
+
+ * res/res_calendar.c, main/manager.c, /, channels/chan_sip.c,
+ channels/sip/security_events.c: ast_str: Fix improper member
+ access to struct ast_str members. 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
+
+2014-11-19 11:50 +0000 [r428195] Joshua Colp <jcolp at digium.com>
+
+ * res/res_pjsip_refer.c: res_pjsip_refer: Ensure Refer-To is NULL
+ terminated and parse it as a URI. 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/
+
+2014-11-18 18:54 +0000 [r428168] Richard Mudgett <rmudgett at digium.com>
+
+ * res/parking/parking_tests.c: parking_tests.c: Add missing newline
+ on a unit test message.
+
+2014-11-17 15:59 +0000 [r428118] Corey Farrell <git at cfware.com>
+
+ * /, channels/chan_sip.c: chan_sip: Fix theoretical leak of
+ p->refer. 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
+
+2014-11-17 15:27 +0000 [r428078-428114] Matthew Jordan <mjordan at digium.com>
+
+ * /, apps/confbridge/conf_state_multi_marked.c:
+ apps/app_confbridge: Ensure 'normal' users hear message when last
+ marked leaves 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
+
+ * tests/test_cel.c: tests/test_cel: Fix CEL unit tests This is a
+ backport of the test_cel portion of r427870, which was not
+ applied to the 12 branch. This fixes the compilation issues with
+ the CEL unit tests introduced by the API changes needed to fix
+ publication of blind transfer messages.
+
+ * /, apps/confbridge/conf_state_multi_marked.c: app_confbridge:
+ Don't play leader leaving prompt if no one will hear it 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
+
+2014-11-16 21:11 +0000 [r427978-428051] Joshua Colp <jcolp at digium.com>
+
+ * channels/chan_pjsip.c: chan_pjsip: Remove AOR check when dialing
+ and one is specified. 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.
+
+ * channels/chan_pjsip.c: chan_pjsip: Add additional log message
+ when an AOR is specified when dialing and it does not exist.
+ ASTERISK-24499 #close Reported by: Rusty Newton
+
+ * channels/chan_pjsip.c, channels/chan_motif.c: chan_motif /
+ chan_pjsip: Fix incorrect "No such module" messages when
+ reloading. 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
+
+ * res/res_pjsip/pjsip_configuration.c: res_pjsip: Enforce
+ requirements for session timer minimum expiration period 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
+
+2014-11-15 16:56 +0000 [r427953] Matthew Jordan <mjordan at digium.com>
+
+ * cel/cel_odbc.c, /: cel/cel_odbc: Provide microsecond precision in
+ 'eventtime' column when possible 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
+
+2014-11-14 17:41 +0000 [r427901] Jonathan Rose <jrose at digium.com>
+
+ * configs/cdr.conf.sample, main/cdr.c: Documentation: Revise
+ explanation of cdr.conf option 'Unanswered' ASTERISK-24279 #close
+ Reported by: Matt Jordan Review:
+ https://reviewboard.asterisk.org/r/4109/
+
+2014-11-14 15:49 +0000 [r427875] Scott Griepentrog <sgriepentrog at digium.com>
+
+ * main/stun.c, /: stun: correct attribute string padding to match
+ rfc 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
+
+2014-11-14 15:00 +0000 [r427848] Mark Michelson <mmichelson at digium.com>
+
+ * res/stasis/app.c, main/bridge.c, main/bridge_basic.c,
+ include/asterisk/stasis_bridges.h, apps/app_queue.c, main/cel.c,
+ main/stasis_bridges.c: 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
+
+2014-11-14 14:55 +0000 [r427843-427845] Joshua Colp <jcolp at digium.com>
+
+ * /, apps/confbridge/conf_state_multi_marked.c: 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
+
+ * res/res_pjsip_pubsub.c: res_pjsip_pubsub: Add some casting so
+ that it builds once again.
+
+2014-11-14 14:21 +0000 [r427840] Mark Michelson <mmichelson at digium.com>
+
+ * res/res_pjsip.c, res/res_pjsip_pubsub.c, res/res_pjsip_session.c,
+ include/asterisk/res_pjsip.h: 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
+
+2014-11-13 21:56 +0000 [r427814] Kevin Harwell <kharwell at digium.com>
+
+ * res/res_pjsip_outbound_registration.c: res_pjsip_exten_state:
+ PJSIPShowSubscriptionsInbound causes crash 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/
+
+2014-11-13 15:42 +0000 [r427788] Kinsey Moore <kmoore at digium.com>
+
+ * res/stasis/app.h, res/res_stasis.c, res/stasis/app.c,
+ res/stasis/stasis_bridge.c, include/asterisk/stasis.h,
+ include/asterisk/stasis_app.h: Stasis: Fix StasisEnd message
+ ordering 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
+
+2014-11-12 23:59 +0000 [r427762] Matthew Jordan <mjordan at digium.com>
+
+ * main/rtp_engine.c: main/rtp_engine: Fix crash when processing
+ more than one RTCP report info block 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
[... 36226 lines stripped ...]
More information about the asterisk-commits
mailing list