From: Mark Michelson Date: Wed, 22 Jun 2016 21:15:11 +0000 (-0500) Subject: ChangeLog: Updated for certified/13.8-cert1-rc3 X-Git-Tag: certified/13.8-cert1-rc3^0 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=f282a88ee4b50a03848555604392314f1b00b6d4;p=thirdparty%2Fasterisk.git ChangeLog: Updated for certified/13.8-cert1-rc3 --- diff --git a/ChangeLog b/ChangeLog index 67f756b139..87c1567468 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,517 @@ +2016-06-22 21:15 +0000 Asterisk Development Team + + * asterisk certified/13.8-cert1-rc3 Released. + +2016-06-22 16:14 +0000 [4df81def29] Mark Michelson + + * Release summaries: Remove previous versions + +2016-06-22 16:14 +0000 [286d58affc] Mark Michelson + + * .version: Update for certified/13.8-cert1-rc3 + +2016-06-22 16:14 +0000 [8b7fe94df7] Mark Michelson + + * .lastclean: Update for certified/13.8-cert1-rc3 + +2016-06-22 16:14 +0000 [0449fd2e1e] Mark Michelson + + * realtime: Add database scripts for certified/13.8-cert1-rc3 + +2016-06-09 09:20 +0000 [a6610fbe2f] gtjoseph + + * build: Fix ast_sockaddr initialization to be more portable + + A change to glibc 2.22 changed the order of the sockadddr_storage + members which caused the places where we do an initialization of + ast_sockaddr with '{ { 0, 0, } }' to fail compilation. Those + initializers (which we shouldn't have been using anyway) have been + replaced with memsets. + + Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4 + +2016-06-12 11:19 +0000 [102d88e791] gtjoseph + + * res_pjsip_pubsub: Address SEGV when attempting to terminate a subscription + + Occasionally under load we'll attempt to send a final NOTIFY on a + subscription that's already been terminated and a SEGV will occur + down in pjproject's evsub_destroy function. This is a result of a + race condition between all the paths that can generate a notify + and/or destroy the underlying pjproject evsub object: + + * The client can send a SUBSCRIBE with Expires: 0. + * The client can send a SUBSCRIBE/refresh. + * The subscription timer can expire. + * An extension state can change. + * An MWI event can be generated. + * The pjproject transaction timer (timer_b) can expire. + + Normally when our pubsub_on_evsub_state is called with a terminate, + we push a task to the serializer and return at which point the dialog + is unlocked. This is usually not a problem because the task runs + immediately and locks the dialog again. When the system is heavily + loaded though, there may be a delay between the unlock and relock + during which another event may occur such as the subscription timer + or timer_b expiring, an extension state change, etc. These may also + cause a terminate to be processed and if so, we could cause pjproject + to try to destroy the evsub structure twice. There's no way for us to + tell that the evsub was already destroyed and the evsub's group lock + can't tolerate this and SEGVs. + + The remedy is twofold. + + * A patch has been submitted to Teluu and added to the bundled + pjproject which adds add/decrement operations on evsub's group lock. + + * In res_pjsip_pubsub: + * configure.ac and pjproject-bundled's configure.m4 were updated + to check for the new evsub group lock APIs. + * We now add a reference to the evsub group lock when we create + the subscription and remove the reference when we clean up the + subscription. This prevents evsub from being destroyed before + we're done with it. + * A state has been added to the subscription tree structure so + termination progress can be tracked through the asyncronous tasks. + * The pubsub_on_evsub_state callback has been split so it's not doing + double duty. It now only handles the final cleanup of the + subscription tree. pubsub_on_rx_refresh now handles both client + refreshes and client terminates. It was always being called for + both anyway. + * The serialized_on_server_timeout task was removed since + serialized_pubsub_on_rx_refresh was almost identical. + * Missing state checks and ao2_cleanups were added. + * Some debug levels were adjusted to make seeing only off-nominal + things at level 1 and nominal or progress things at level 2+. + + ASTERISK-26099 #close + Reported-by: Ross Beer. + + Change-Id: I779d11802cf672a51392e62a74a1216596075ba1 + +2016-06-13 13:33 +0000 [d9ab222edc] Richard Mudgett + + * res_rtp_multicast.c: Fix warning message typo. + + Change-Id: Ic9928208b9957e09866abe3d9649030942ec52b3 + +2016-06-10 12:35 +0000 [39329a9e66] Richard Mudgett + + * chan_rtp: Backport changes from master. + + * Deprecate chan_multicast_rtp. + + Change-Id: Ib5a45e58c75ee8abd0b4f9575379b5321feb853e + +2016-06-10 16:13 +0000 [6d45341963] Richard Mudgett + + * chan_rtp.c: Copy file from chan_multicast_rtp.c + + Change-Id: I1119b53f2152ab1cbec74b5be7ea44844dbda8ef + +2016-06-03 22:44 +0000 [0322479ff7] Richard Mudgett + + * res_pjsip_registrar.c: Eliminate rx REGISTER request race condition. + + This patch fixes a race condition processing received REGISTER requests + and their retransmissions caused by REGISTER requests being processed by + two threads. The "sip_transaction Unable to register REGISTER transaction + (key exists)" message is a notable symptom of this issue. + + This issue was more likely to happen before the pjsip/distributor + serializers were created. Instead of steps one and two below placing the + REGISTER messages into the same pjsip/distributor they were placed in + random pjsip/default serializers. + + 1) REGISTER requests come in and get placed on the pjsip/distributor + serializer. + + 2) Before the first request is processed a retransmission comes in and is + placed on the same pjsip/distributor serializer. + + 3) The first request goes up the pjsip stack and is then shunted off to + the pjsip/aor/ serializer. + + 4) Before the first request is completed processing in the pjsip/aor/ + serializer, the second request goes up the pjsip stack and is also shunted + off to the pjsip/aor/ serializer. + + 5) The first request completes processing and sends out its response. + + 6) The second request completes processing and tries to send out its + response but pjlib complains that the REGISTER transaction key already + exists. + + 7) Sadness ensues. + + * The race is eliminated by removing the pjsip/aor/ serializer and + continuing the processing in the pjsip/distributor serializer. Now any + retransmissions queued in the pjsip/distributor serializer will be + processed after the first message is completely processed. + + ASTERISK-26088 #close + Reported by: Richard Mudgett + + Change-Id: I842d714346088bf717ea27437f1dd85bff0bab5a + +2016-06-03 11:35 +0000 [942fa0c95b] Richard Mudgett + + * stasis: Add setting subscription congestion levels. + + Stasis subscriptions and message routers create taskprocessors to process + the event messages. API calls are needed to be able to set the congestion + levels of these taskprocessors for selected subscriptions and message + routers. + + * Updated CDR, CEL, and manager's stasis subscription congestion levels + based upon stress testing. Increased the congestion levels to reduce the + potential for bursty call setup/teardown activity from triggering the + taskprocessor overload alert. CDRs in particular need an extra high + congestion level because they can take awhile to process the stasis + messages. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: Id0a716394b4eee746dd158acc63d703902450244 + +2016-06-02 18:19 +0000 [b046fa1907] Richard Mudgett + + * sorcery: Add setting object type congestion levels. + + Sorcery creates taskprocessors for object types to process object observer + callbacks. An API call is needed to be able to set the congestion levels + of these taskprocessors for selected object types. + + * Updated PJSIP's contact and contact_status sorcery object type observer + default congestion levels based upon stress testing. Increased the + congestion levels to reduce the potential for bursty register/unregister + and subscribe/unsubscribe activity from triggering the taskprocessor + overload alert. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I4542e83b556f0714009bfeff89505c801f1218c6 + +2016-06-02 16:08 +0000 [237f9ef7af] Richard Mudgett + + * taskprocessors: Implement high/low water mark alerts. + + When taskprocessors get backed up, there is a good chance that we are + being overloaded and need to defer adding new work to the system. + + * Implemented a high/low water alert mechanism for modules to check if the + system is being overloaded and take appropriate action. When a + taskprocessor is created it has default congestion levels set. A + taskprocessor can later have those congestion levels altered for specific + needs if stress testing shows that the taskprocessor is a symptom of + overloading or needs to handle bursty activity without triggering an + overload alert. + + * Add CLI "core show taskprocessor" low/high water columns. + + * Fixed __allocate_taskprocessor() to not use RAII_VAR(). RAII_VAR() was + never a good thing to use when creating a taskprocessor because of the + nature of how its references needed to be cleaned up on a partial + creation. + + * Made res_pjsip's distributor check if the taskprocessor overload alert + is active before placing a message representing brand new work onto a + distributor serializer. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I182f1be603529cd665958661c4c05ff9901825fa + +2016-05-27 17:31 +0000 [ff70f04a37] Richard Mudgett + + * res_pjsip_session: Use distributor serializer for incoming calls. + + We must continue using the serializer that the original INVITE came in on + for the dialog. There may be retransmissions already enqueued in the + original serializer that can result in reentrancy and message sequencing + problems. + + Outgoing call legs create the pjsip/outsess/ serializers for + their dialogs. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I24d7948749c582b8045d5389ba3f6588508adbbc + +2016-05-27 16:28 +0000 [4b26c9ead8] Richard Mudgett + + * res_pjsip_pubsub.c: Recreate subscriptions using distributor serializer. + + * Resolves potential reentrancy problems if system restarted in the middle + of subscription message transactions. + + * Fixes memory leak recreating persistent subscriptions when the + subscription resource tree could not be created. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I71e34d7ae8ed35a694f1030e820e2548c48697be + +2016-05-27 12:50 +0000 [a137d1822e] Richard Mudgett + + * res_pjsip_pubsub.c: Use distributor serializer for incoming subscriptions. + + We must continue using the serializer that the original SUBSCRIBE came in + on for the dialog. There may be retransmissions already enqueued in the + original serializer that can result in reentrancy and message sequencing + problems. The "sip_transaction Unable to register SUBSCRIBE transaction + (key exists)" message is a notable symptom of this issue. + + Outgoing subscriptions still create the pjsip/pubsub/ + serializers for their dialogs. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I18b00bb74a56747b2c8c29543a82440b110bf0b0 + +2016-05-26 17:35 +0000 [9a7a5aec18] Richard Mudgett + + * pjsip_distributor.c: Consistently pick a serializer for messages. + + Incoming messages that are not part of a dialog or a recognized response + to one of our requests need to be sent to a consistent serializer. Under + load we may be queueing retransmissions before we can process the original + message. We don't need to throw these messages onto random serializers + and cause reentrancy and message sequencing problems. + + * Created a pool of pjsip/distributor serializers that get picked by + hashing the call-id and remote tag strings of the received messages. + + * Made ast_sip_destroy_distributor() destroy items in the reverse order of + creation. + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I2ce769389fc060d9f379977f559026fbcb632407 + +2016-06-02 12:51 +0000 [f2a76c4292] Richard Mudgett + + * pjsip_distributor.c: Ignore messages until fully booted. + + We should not be processing any incoming messages until we are fully + booted. We may not have dialplan or other needed configuration loaded + yet. + + ASTERISK-26089 #close + Reported by: Scott Griepentrog + + ASTERISK-26088 + Reported by: Richard Mudgett + + Change-Id: I584aefb4f34b885a8927e1f13a2c64babd606264 + +2016-04-01 13:30 +0000 [51e45e5ca5] gtjoseph + + * res_pjsip contact: Lock expiration/addition of contacts + + Contact expiration can occur in several places: res_pjsip_registrar, + res_pjsip_registrar_expire, and automatically when anyone calls + ast_sip_location_retrieve_aor_contact. At the same time, res_pjsip_registrar + may also be attempting to renew or add a contact. Since none of this was locked + it was possible for one thread to be renewing a contact and another thread to + expire it immediately because it was working off of stale data. This was the + casue of intermittent registration/inbound/nominal/multiple_contacts test + failures. + + Now, the new named lock functionality is used to lock the aor during contact + expire and add operations and res_pjsip_registrar_expire now checks the + expiration with the lock held before deleting the contact. + + ASTERISK-25885 #close + Reported-by: Josh Colp + + Change-Id: I83d413c46a47796f3ab052ca3b349f21cca47059 + +2016-03-31 20:04 +0000 [880d502141] gtjoseph + + * lock: Add named lock capability + + Locking some objects like sorcery objects can be tricky because the underlying + ao2 object may not be the same for all callers. For instance, two threads that + call ast_sorcery_retrieve_by_id on the same aor name might actually get 2 + different ao2 objects if the underlying wizard had to rehydrate the aor from a + database. Locking one ao2 object doesn't have any effect on the other even if + those objects had locks in the first place. + + Named locks allow access control by keyspace and key strings. Now an "aor" + named "1000" can be locked and any other thread attempting to lock "aor" "1000" + will wait regardless of whether the underlying ao2 object is the same or not. + Mutex and rwlocks are supported. + + This capability will initially be used to lock an aor when multiple threads may + be attempting to prune expired contacts from it. + + Change-Id: If258c0b7f92b02d07243ce70e535821a1ea7fb45 + +2016-06-02 12:04 +0000 [a81feefde9] Joshua Colp + + * res_odbc: Implement a connection pool. + + Testing has shown that our usage of UnixODBC is problematic + due to bugs within UnixODBC itself as well as the heavy weight + cost of connecting and disconnecting database connections, even + when pooling is enabled. + + For users of UnixODBC 2.3.1 and earlier crashes would occur due + to insufficient protection of the disconnect operation. This was + fixed in UnixODBC 2.3.2 and above. + + For users of UnixODBC 2.3.3 and higher a slow-down would occur + under heavy database use due to repeated connection establishment. + A regression is present where on each connection the database + configuration is cached again, with the cache growing out of + control. + + The connection pool implementation present in this change helps + to mitigate these issues by reducing how much we connect and + disconnect database connections. We also solve the issue of + crashes under UnixODBC 2.3.1 by defaulting the maximum number of + connections to 1, returning us to the previous working behavior. + For users who may have a fixed version the maximum concurrent + connection limit can be increased helping with performance. + + The connection pool works by keeping a list of active connections. + If the connection limit has not been reached a new connection is + established. If the connection limit has been reached then the + request waits until a connection becomes available before + continuing. + + ASTERISK-26074 #close + ASTERISK-26054 #close + + Change-Id: I6774bf4bac49a0b30242c76a09c403d2e856ecff + +2016-05-30 10:58 +0000 [aab8bc5d31] gtjoseph + + * pjproject_bundled: Move to pjproject 2.5 + + Although all the patches we had against 2.4.5 were applied by Teluu, + a new bug was introduced preventing re-use of tcp and tls transports + This patch removes all the previous patches against 2.4.5, updates + the version to 2.5, and adds a new patch to correct the transport + re-use problem. + + Change-Id: I0dc6c438c3910f7887418a5832ca186aea23d068 + (cherry picked from commit e8abfdcdc5ce4d32d1fe281e75b13fd652f9e5f7) + +2016-05-18 07:54 +0000 [b9a28ccbd4] gtjoseph + + * udptl: Don't eat sequence numbers until OK is received + + Scenario: + Local fax -> Asterisk w/ firewall -> Provider -> Remote fax + + * Local fax starts rtp call to remote fax + * Remote fax starts t38 call back to local fax. + * Local fax sends t38 no-signal to Asterisk before sending an OK. + * udptl processes the frame and increments the expected sequence number. + * chan_sip drops the frame because the call isn't up so nothing goes out + the external interface to open the port for incoming packets. + * Local fax sends OK and Asterisk sends OK to the remote fax. + * Remote fax sends t38 packets which are dropped by the firewall. + * Local fax re-sends t38 no-signal with the same sequence number. + * udptl drops the frame because it thinks it's a dup. + * Still no outgoing packets to open the firewall. + * t38 negotiation fails. + + The patch drops frames t38 received before udptl sequence processing + when the call hasn't been answered yet. The second no-signal frame + is then seen as new and is relayed out the external interface which + opens the port and allows negotiation to continue. + + ASTERISK-26034 #close + + Change-Id: I11744b39748bd2ecbbe8ea84cdb4f3c5943c5af9 + +2016-05-17 11:14 +0000 [f85c77a9e1] gtjoseph + + * chan_sip: Prevent extra Session-Expires headers from being added + + When chan_sip does a re-INVITE to refresh a session and authentication + is required, the INVITE with the Authorization header containes a + second Session-Expires header without the ";refersher=" parameter. + This is causing some proxies to return a 400. Also, when Asterisk is + the uas and the refresher, it is including the Session-Expires and + Min-SE headers in OPTIONS messages which is not allowed per RFC4028. + + This patch (based on the reporter's) Checks to see if a Session-Expires + header is already in the message before adding another one. It also + checks that the method is INVITE or UPDATE. + + ASTERISK-26030 #close + + Change-Id: I58a7b07bab5a3177748d8a7034fb8ad8e11ce1d9 + +2016-05-07 14:39 +0000 [8bf050b853] gtjoseph + + * config_transport: Tell pjproject to allow all SSL/TLS protocols + + The default tls settings for pjproject only allow TLS 1, TLS 1.1 and TLS 1.2. + SSL is not allowed. So, even if you specify "sslv3" for a transport method, + it's silently ignored and one of the TLS protocols is used. This was a new + behavior of pjsip_tls_setting_default() in 2.4 (when tls.proto was added) that + we never caught. + + Now we need to set tls.proto = 0 after we call pjsip_tls_setting_default(). + This tells pjproject to set the socket protocol to match the method. + + ASTERISK-26004 #close + + Change-Id: Icfb55c1ebe921298dedb4b1a1d3bdc3ca41dd078 + +2016-05-05 11:37 +0000 [4fc2c98369] Kevin Harwell + + * res_pjsip_authenticator_digest: Don't use source port in nonce verification + + From the issue reporter: + "res_pjsip_outbound_authenticator_digest builds a nonce that is a hash of + the timestamp, the source address, the source port, a server UUID that is + calculated at startup, and the authentication realm. + + Rather than caching nonces that we create, we instead attempt to re-calculate + the nonce when receiving an incoming request with authentication. We then + compare the re-calculated nonce to the incoming nonce, and if they don't match, + then authentication has failed early. + + The problem is that it is possible, especially when using TCP, to receive two + requests from the same endpoint but have differing source ports for those + requests. Asterisk itself commonly will use different source ports for + outbound TCP requests." + + This patch removes the source port dependency when building the nonce. + + ASTERISK-25978 #close + + Change-Id: I871b5f4adce102df1c4988066283095ec509dffe + +2016-05-05 05:07 +0000 [4e7791d483] Joshua Colp + + * file: Ensure nativeformats remains valid for lifetime of use. + + It is possible for the nativeformats of a channel to change + throughout its lifetime. As a result a user of it needs to either + ensure the channel is locked when accessing the formats or keep + a reference to the nativeformats themselves. + + This change fixes the file playback support so it keeps a + reference to the nativeformats when accessing things. + + ASTERISK-25998 #close + + Change-Id: Ie45b65475e1481ddf05b874ee48f63e39fff8915 + 2016-05-03 12:55 +0000 Asterisk Development Team * asterisk certified/13.8-cert1-rc2 Released.