diff --git a/ChangeLog b/ChangeLog index 31a0986dc8..67f756b139 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,337 @@ +2016-05-03 12:55 +0000 Asterisk Development Team + + * asterisk certified/13.8-cert1-rc2 Released. + +2016-05-03 07:54 +0000 [cadb5c4e64] Joshua Colp + + * Release summaries: Remove previous versions + +2016-05-03 07:54 +0000 [d4d5548ef8] Joshua Colp + + * .version: Update for certified/13.8-cert1-rc2 + +2016-05-03 07:54 +0000 [a5bc40ae51] Joshua Colp + + * .lastclean: Update for certified/13.8-cert1-rc2 + +2016-05-03 07:54 +0000 [2b6df52c66] Joshua Colp + + * realtime: Add database scripts for certified/13.8-cert1-rc2 + +2016-04-15 11:59 +0000 [c4426f1035] Alexei Gradinari + + * res_pjsip: disable multi domain to improve realtime performace + + This patch added new global pjsip option 'disable_multi_domain'. + Disabling Multi Domain can improve Realtime performance by reducing + number of database requests. + + ASTERISK-25930 #close + + Change-Id: I2e7160f3aae68475d52742107949a799aa2c7dc7 + +2016-04-26 05:48 +0000 [c69e0f1813] Joshua Colp + + * app_queue: Fix crash when unloading module. + + When unloading the app_queue module the members in each queue are + destroyed and as part of this they are removed from the pending + members container. Unfortunately a crash would occur as the container + was destroyed before the members were removed. + + This change tweaks ordering so the container destruction occurs + after the members are destroyed. + + ASTERISK-16115 + + Change-Id: I48c728668c55aee3d05b751a5d450fb57e87f44b + +2016-04-21 14:23 +0000 [eebe8b3dd3] Kevin Harwell + + * app_queue: queue members can receive multiple calls + + It was possible for a queue member that is a member of at least 2 or more + queues to receive mulitiple calls at the same time. This happened because + of a race between when a member was being rung and when the device state + notified the other queue(s) member object of the state change. + + This patch makes it so when a queue member is being rung it gets added to + a global pool of queue members. If that same member is tried again, e.g. + from another queue, and it is found to already exist in the pending member + container then it will not ring that member. + + ASTERISK-16115 #close + + Change-Id: I546dd474776d158c2b6be44205353dee5bac7e48 + +2016-04-22 17:53 +0000 [5cbd4b9799] gtjoseph + + * res_agi: Prevent run_agi from eating frames it shouldn't + + The run_agi function is eating control frames when it shouldn't be. This is + causing issues when an AGI is run from CONNECTED_LINE_SEND_SUB in a blond + transfer. + + Alice calls Bob. Bob attended transfers to Charlie but hangs up before Charlie + answers. + + Alice gets the COLP UPDATE indicating Charlie but Charlie never gets an UPDATE + and is left thinking he's connected to Bob. + + In this case, when CONNECTED_LINE_SEND_SUB runs on Alice's channel and it calls + an AGI, the extra eaten frames prevent CONNECTED_LINE_SEND_SUB from running on + Charlie's channel. + + The fix was to accumulate deferrable frames in the "forever" loop instead of + dropping them, and re-queue them just before running the actual agi command + or exiting. + + ASTERISK-25951 #close + + Change-Id: I0f4bbfd72fc1126c2aaba41da3233a33d0433645 + +2016-04-15 14:36 +0000 [bc51227ef8] Richard Mudgett + + * res_stasis: Handle re-enter stasis bridge with swap channel. + + We lose the fact that there is a swap channel if there is one. We + currently wind up rejoining the stasis bridge as a normal join after the + swap channel has already been kicked from the bridge. + + This patch preserves the swap channel so the AMI/ARI events can note that + the channel joining the bridge is swapping with another channel. Another + benefit to swaqpping in one operation is if there are any channels that + get lonely (MOH, bridge playback, and bridge record channels). The lonely + channels won't leave before the joining channel has a chance to come back + in under stasis if the swap channel is the only reason the lonely channels + are staying in the bridge. + + ASTERISK-25947 #close + Reported by: Richard Mudgett + + ASTERISK-24649 + Reported by: John Bigelow + + ASTERISK-24782 + Reported by: John Bigelow + + Change-Id: If37ea508831d1fed6dbfac2f191c638fc0a850ee + +2016-04-19 16:58 +0000 [8dd79720e6] Richard Mudgett + + * bridge: Hold off more than one imparting channel at a time. + + An earlier patch blocked the ast_bridge_impart() call until the channel + either entered the target bridge or it failed. Unfortuantely, if the + target bridge is stasis and the imprted channel is not a stasis channel, + stasis bounces the channel out of the bridge to come back into the bridge + as a proper stasis channel. When the channel is bounced out, that + released the block on ast_bridge_impart() to continue. If the impart was + a result of a transfer, then it became a race to see if the swap channel + would get hung up before the imparted channel could come back into the + stasis bridge. If the imparted channel won then everything is fine. If + the swap channel gets hung up first then the transfer will fail because + the swap channel is leaving the bridge. + + * Allow a chain of ast_bridge_impart()'s to happen before any are + unblocked to prevent the race condition described above. When the channel + finally joins the bridge or completely fails to join the bridge then the + ast_bridge_impart() instances are unblocked. + + ASTERISK-25947 + Reported by: Richard Mudgett + + ASTERISK-24649 + Reported by: John Bigelow + + ASTERISK-24782 + Reported by: John Bigelow + + Change-Id: I8fef369171f295f580024ab4971e95c799d0dde1 + +2016-04-19 17:52 +0000 [2a2e754d15] gtjoseph + + * res_pjsip_callerid: Clear out display name if id->name is not valid + + When create_new_id_hdr creates a new RPID or PAI header, it starts by cloning + the From header, then it overwrites the display name and uri from the channel's + connected.id. If the connected.id.name wasn't valid, create_new_id_hdr was + leaving the display name from the From header in the new RPID or PAI header. + On an attended transfer where the originator had a caller id number set but not + a display name, the re-INVITE to the final transferee had the number of the + originator but the display name of the transferer. + + Added a check to clear out the display name in the new header if + connected.id.name was invalid. + + ASTERISK-25942 #close + + Change-Id: I60b4bf7a7ece9b7425eba74151c0b4969cd2738b + +2016-04-19 13:02 +0000 [188ce34aff] Joshua Colp + + * app_talkdetect: Make the module core supported. + + This module is used as part of testsuite tests to confirm + stuff works. I'm accordingly marking it as core as it is + required by those tests. + + Change-Id: I558e7af7679b22b8ed641d7dd37ee4ca35b11e88 + +2016-04-19 13:00 +0000 [da80f40014] Joshua Colp + + * app_talkdetect: Enable for testsuite tests. + + Change-Id: I9acf2e2210f7a15cdd2c63c4c8dcb92de6b47d43 + +2016-04-18 12:12 +0000 [9f3ecf0a8d] Mark Michelson + + * 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 + +2016-04-18 17:00 +0000 [39b4742db1] Mark Michelson + + * 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 + +2016-04-18 13:41 +0000 [4caa57f6b3] Joshua Colp + + * 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 + +2016-04-14 13:49 +0000 [0b35582bbb] Mark Michelson + + * transport management: Register thread with PJProject. + + The scheduler thread that kills idle TCP connections was not registering + with PJProject properly and causing assertions if PJProject was built in + debug mode. + + This change registers the thread with PJProject the first time that the + scheduler callback executes. + + AST-2016-005 + + Change-Id: I5f7a37e2c80726a99afe9dc2a4a69bdedf661283 + +2016-03-08 12:12 +0000 [9f8b803a29] Mark Michelson + + * res_pjsip_transport_management: Kill idle TCP connections. + + "Idle" here means that someone connects to us and does not send a SIP + request. PJProject will not automatically time out such connections, so + it's up to Asterisk to do it instead. + + When we receive an incoming TCP connection, we will start a timer + (equivalent to transaction timer D) waiting to receive an incoming + request. If we do not receive a request in that timeframe, then we will + shut down the TCP connection. + + ASTERISK-25796 #close + Reported by George Joseph + + AST-2016-005 + + Change-Id: I7b0d303e5d140d0ccaf2f7af562071e3d1130ac6 + +2016-03-08 10:52 +0000 [a35d3eb73b] Mark Michelson + + * Rename res_pjsip_keepalive res_pjsip_transport_management + + ASTERISK-25796 + Reported by George Joseph + + AST-2016-005 + + Change-Id: Id322a05f927392293570599730050bc677d99433 + +2016-04-14 07:15 +0000 [3de37dee68] Mark Michelson + + * AST-2016-004: Fix crash on REGISTER with long URI. + + Due to some ignored return values, Asterisk could crash if processing an + incoming REGISTER whose contact URI was above a certain length. + + ASTERISK-25707 #close + Reported by George Joseph + + Patches: + 0001-res_pjsip-Validate-that-URIs-don-t-exceed-pjproject-.patch + + AST-2016-004 + + Change-Id: I0ed3898fe7ab10121b76c8c79046692de3a1be55 + +2016-03-23 08:59 +0000 [e378c18815] gtjoseph + + * pjproject-bundled: Cleanups for reported issues + + PortAudio should no longer be required + PJSIP_MAX_PKT_LEN is now 6000 + Older autoconf issue fixed. (CentOS 6) + + Change-Id: I463fa9586cbe7c6b3b603289f535bd8e361611dd + (cherry picked from commit d963a3374991c64594cf196e90a5c74964c8ba7c) + 2016-04-06 16:01 +0000 Asterisk Development Team * asterisk certified/13.8-cert1-rc1 Released.