ChangeLog: Updated for 13.8.2

ChangeLog

@@ -1,3 +1,100 @@
+2016-04-20 10:46 +0000  Asterisk Development Team <asteriskteam@digium.com>
+
+	* asterisk 13.8.2 Released.
+
+2016-04-20 05:45 +0000 [26d67ce885]  Joshua Colp <jcolp@digium.com>
+
+	* Release summaries: Remove previous versions
+
+2016-04-20 05:45 +0000 [d9909232ed]  Joshua Colp <jcolp@digium.com>
+
+	* .version: Update for 13.8.2
+
+2016-04-20 05:45 +0000 [fc57bb9b15]  Joshua Colp <jcolp@digium.com>
+
+	* .lastclean: Update for 13.8.2
+
+2016-04-20 05:45 +0000 [ac04474f38]  Joshua Colp <jcolp@digium.com>
+
+	* realtime: Add database scripts for 13.8.2
+
+2016-04-18 17:00 +0000 [91a3e1184f]  Mark Michelson <mmichelson@digium.com>
+
+	* res_pjsip_registrar: Fix bad memory-ness with user_agent.
+
+	  Recent changes to the PJSIP registrar resulted in tests failing due to
+	  missing AOR_CONTACT_ADDED test events. The reason for this was that the
+	  user_agent string had junk values in it, resulting in being unable to
+	  generate the event.
+
+	  I'm going to be honest here, I have no idea why this was happening. Here
+	  are the steps needed for the user_agent variable to get messed up:
+	  * REGISTER is received
+	  * First contact in the REGISTER results in a contact being removed
+	  * Second contact in the REGISTER results in a contact being added
+	  * The contact, AOR, expiration, and user agent all have to be passed as
+	    format parameters to the creation of a string. Any subset of those
+	    parameters would not be enough to cause the problem.
+
+	  Looking into what was happening, the thing that struck me as odd was
+	  that the user_agent variable was meant to be set to the value of the
+	  User-Agent SIP header in the incoming REGISTER. However, when removing a
+	  contact, the user_agent variable would be set (via ast_strdupa inside a
+	  loop) to the stored contact's user_agent. This means that the
+	  user_agent's value would be incorrect when attempting to process further
+	  contacts in the incoming REGISTER.
+
+	  The fix here is to use a different variable for the stored user agent
+	  when removing a contact. Correcting the behavior to be correct also
+	  means the memory usage is less weird, and the issue no longer occurs.
+
+	  ASTERISK-25929 #close
+	  Reported by Joshua Colp
+
+	  Change-Id: I7cd24c86a38dec69ebcc94150614bc25f46b8c08
+	  (cherry picked from commit f436b9ab111f1ff57c6dd3970051f123b42c1103)
+
+2016-04-18 13:41 +0000 [70e25ced60]  Joshua Colp <jcolp@digium.com>
+
+	* res_pjsip_transport_management: Allow unload to occur.
+
+	  At shutdown it is possible for modules to be unloaded that wouldn't
+	  normally be unloaded. This allows the environment to be cleaned up.
+
+	  The res_pjsip_transport_management module did not have the unload
+	  logic in it to clean itself up causing the res_pjsip module to not
+	  get unloaded. As a result the res_pjsip monitor thread kept going
+	  processing traffic and timers when it shouldn't.
+
+	  Change-Id: Ic8cadee131e3b2c436a81d3ae8bb5775999ae00a
+	  (cherry picked from commit 49bfdc9ac029e0ef17cd8e85d8d7b7731387a34e)
+
+2016-04-18 12:12 +0000 [856931edc2]  Mark Michelson <mmichelson@digium.com>
+
+	* PJSIP: Remove PJSIP parsing functions from uri length validation.
+
+	  The PJSIP parsing functions provide a nice concise way to check the
+	  length of a hostname in a SIP URI. The problem is that in order to use
+	  those parsing functions, it's required to use them from a thread that
+	  has registered with PJLib.
+
+	  On startup, when parsing AOR configuration, the permanent URI handler
+	  may not be run from a PJLib-registered thread. Specifically, this could
+	  happen when Asterisk was started in daemon mode rather than
+	  console-mode. If PJProject were compiled with assertions enabled, then
+	  this would cause Asterisk to crash on startup.
+
+	  The solution presented here is to do our own parsing of the contact URI
+	  in order to ensure that the hostname in the URI is not too long. The
+	  parsing does not attempt to perform a full SIP URI parse/validation,
+	  since the hostname in the URI is what is important.
+
+	  ASTERISK-25928 #close
+	  Reported by Joshua Colp
+
+	  Change-Id: Ic3d6c20ff3502507c17244a8b7e2ca761dc7fb60
+	  (cherry picked from commit efae187217750e322cd6167705a33f888b631427)
+
 2016-04-14 20:26 +0000  Asterisk Development Team <asteriskteam@digium.com>
 
 	* asterisk 13.8.1 Released.