|Tags||communication conferencing telephony sip|
13.17.013 Jul 2017 22:25 minor feature:
13.16.031 May 2017 15:45 minor feature:
13.15.121 May 2017 08:05 minor feature: AST-2017-004: chan_skinny: Add EOF check in skinny_session The while(1) loop in skinny_session wasn't checking for EOF so a packet that was longer than a header but still truncated. Would spin the while loop infinitely. Not only does this Permanently tie up a thread and drive a core to 100 utilization, The call of ast_log() in such a tight loop eats all available Process memory. Added poll with timeout to top of read loop. AST-2017-003: Handle zero-length body parts correctly. AST-2017-002: Ensure transaction key buffer is large enough.
13.15.013 Apr 2017 21:45 minor feature:
13.14.106 Apr 2017 00:45 minor feature: CDR: Protect from data overflow in ast_cdr_setuserfield. Ast_cdr_setuserfield wrote to a length field using strcpy. This could. Result in a buffer overrun when called from chan_sip or func_cdr. This patch Adds a maximum bytes written to the field by using ast_copy_string instead.
13.14.014 Feb 2017 16:05 minor feature:
13.13.109 Dec 2016 14:45 minor feature: Update for 13.13.1 chan_sip: Do not allow non-SP/HTAB between header key and colon. RFC says SIP headers look like: HCOLON = *( SP / HTAB ) ":" SWS SWS = LWS ; sep whitespace LWS = *WSP CRLF 1*WSP ; linear whitespace WSP = SP / HTAB ; from rfc2234. chan_sip implemented this: HCOLON = *( LOWCTL / SP ) ":" SWS LOWCTL = x00-1F ; CTL without DEL. This discrepancy meant that SIP proxies in front of Asterisk with chan_sip could pass on unknown headers with x00- x1F in them, which would be treated by Asterisk as a different (known) header. For example, the "To x01:" header would gladly be forwarded by some proxies as irrelevant, but chan_sip would treat it as the relevant "To:" header. Those relying on a SIP proxy to scrub certain headers could mistakenly get unexpected and unvalidated data fed to Asterisk. This change so chan_sip only considers SP/HTAB as valid tokens before the colon, making it agree on the headers with other speakers of SIP. res_format_attr_opus: crash when fmtp contains spaces. When an opus offer or answer was received that contained an fmtp line with spaces between the attributes the module would fail to properly parse it and crash due to recursion. This change makes the module handle the space properly and also removes the recursion requirement.
13.13.025 Nov 2016 03:05 minor feature:
13.12.212 Nov 2016 06:25 minor feature: Revert "chan_sip: lastrtprx always updated" This reverts commit 93332cb1d0eea18021ea6538237297e627d6e2fc. Unfortunately, the aforementioned commit caused a regression (incoming calls would eventually disconnect). Thus it is being removed.
13.12.103 Nov 2016 09:25 minor feature: App_voicemail: Clear voice mailbox in MailboxExists and MAILBOX_EXISTS. When executing the MailboxExists dialplan application and MAILBOX_EXISTS dialplan function the passed in temporary voice. Mailbox was not cleared, causing it to try to free garbage.
13.12.026 Oct 2016 17:05 minor feature:
13.11.211 Sep 2016 06:45 minor feature: Release summaries: Remove previous versions version: Update for 13.11.2. lastclean: Update for 13.11.2. realtime: Add database scripts for 13.11.2. res_pjsip: Only invoke unidentified endpoint logic when unidentified. The code was incorrectly invoking the unidentified logic when an endpoint had actually been identified, causing log messages to be output.
13.11.002 Sep 2016 23:25 minor feature: Release summaries: Add summaries for 13.11.0 Release summaries: Remove previous versions. version: Update for 13.11.0. lastclean: Update for 13.11.0. realtime: Add database scripts for 13.11.0. ChangeLog: Updated for 13.11.0. Release summaries: Add summaries for 13.11.0. Release summaries: Remove previous versions. version: Update for 13.11.0. lastclean: Update for 13.11.0. realtime: Add database scripts for 13.11.0.
13.10.022 Jul 2016 14:25 minor feature: Release summaries: Add summaries for 13.10.0 Release summaries: Remove previous versions. version: Update for 13.10.0. lastclean: Update for 13.10.0. realtime: Add database scripts for 13.10.0.
13.9.119 May 2016 19:45 minor feature: Release summaries: Remove previous versions version: Update for 13.9.1. lastclean: Update for 13.9.1. realtime: Add database scripts for 13.9.1. Use doubles instead of floats for conversions when comparing strings. In 13.9.0, there was an where PJSIP contacts added to an AOR would be deleted at seemingly random times. One reason this was happening was because of an operation to retrieve. The contacts whose expiration time was less than or equal to the current Time. When retrieving existing contacts, the contact's expiration time And the current time were converted from a string to a float, and those Two floats were compared. On some systems, including mine, this conversion was horribly off. For. Instance, I could regularly see the string "1463079214" get converted Into 1463079168.000000. When switching from using a float to using a Double, the conversion was as expected. Why was the conversion to float off? My best guess is that the. Conversion to float was attempting to store the entire value in the 23 Bit significand of the IEEE-754 floating point number. In particular, if You take only the 23 most significant bits of 1463079214, you get the Messed up 1463079168 that we were seeing in the conversion. It likely Was possible to get a more precise value by composing the number using an exponent, but the conversion did not work that way. With a double. You have a 52 bit significand, allowing the entire value to fit there, And thereby allowing an accurate conversion. res_sorcery_astdb: creation of retrieved objects. The contents of this commit come from a portion of commit. A01ce2b88912cd802bb045e40fe264906e55bc45 of the 13 branch. The commit referenced above's main point was to introduce some. Performance enhancements for realtime. However, mixed in with that was a For sorcery's astdb backend. The astdb was using an empty Objectset to create an object. This, combined with the floating point conversion, was what was. Contributing to contacts being deleted early.
13.9.011 May 2016 09:25 minor feature: Release summaries: Add summaries for 13.9.0 Release summaries: Remove previous versions. version: Update for 13.9.0. lastclean: Update for 13.9.0. realtime: Add database scripts for 13.9.0.
13.8.228 Apr 2016 03:25 minor feature: Release summaries: Remove previous versions version: Update for 13.8.2. lastclean: Update for 13.8.2. realtime: Add database scripts for 13.8.2. res_pjsip_registrar: 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 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 no longer occurs. 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 i
13.8.120 Apr 2016 13:25 minor feature: 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 Demode. This change registers the thread with PJProject the first time that the. Scheduler callback executes. 2016-03-08 12:12 +0000 efafbb1319 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. Rename res_pjsip_keepalive res_pjsip_transport_management. Reported by George Joseph. Due to some ignored return values, Asterisk could crash if processing an. Incoming REGISTER whose contact URI was above a certain length. Patches: 0001-res_pjsip-Validate-that-URIs-don-t-exceed-pjproject-.patch. Asterisk 13.8.0 Released. Release summaries: Add summaries for 13.8.0. Release summaries: Remove previous versions. version: Update for 13.8.0. lastclean: Update for 13.8.0. Realtime: Add database scripts for 13.8.0. Asterisk 13.8.0-rc1 Released. Release summaries: Add summaries for 13.8.0-rc1. version: Update for 13.8.0-rc1. lastclean: Update for 13.8.0-rc1. Realtime: Add database scripts for 13.8.0-rc1. Chan_pjsip: ref leak when checking direct_media_glare. The reference leak introduced in the following commit: 9444ddadf8525d1ce66a1faf1db97f9f6c265ca4. Chan_pjsip: transfers with direct media reinvite has wrong address/port. During a transfer involving direct media a race occurs between when the. Transferer channel is swapped out, initiating rtp changes/updates, and the Subsequent reinvites.
13.8.010 Apr 2016 03:26 minor feature: Asterisk 13.8.0 Released. Chan_pjsip: transfers with direct media reinvite has wrong address/port. During a transfer involving direct media a race occurs between when the. Transferer channel is swapped out, initiating rtp changes/updates, and the Subsequent reinvites. When Alice, after speaking with Charlie (Bob is on hold), connects Bob and Charlie invites are sent to each in order to establish the call between them. Bob is taken off hold and Charlie is told to have his media flow through Asterisk. However, if before those invites go out the bridge updates Bob's. And/or Charlie's rtp information with direct media data (i.e. address, port) Then the invite(s) will contain the remote data in the SDP instead of the Asterisk data. The race occurs in the native bridge glue code when updating the peer. The. Direct_media_address can get set twice before sending out the first invite During call connection. This can happen because the checking/setting of the Direct_media_address happened in one thread while the sending of the invite(s) Happened in another thread. This removes the race condition by moving the checking/setting of the. Direct_media_address to be in the same thread as the sending of the invites(s). This serializes the checking/setting and sending so they can no longer happen. Out of order.
13.7.224 Mar 2016 08:11 minor feature: 2016-02-05 14:32 +0000 0ba44bd6f3 Mark Michelson * Release summaries: Remove previous versions 2016-02-05 14:32 +0000 b750dfe202 Mark Michelson * .version: Update for 13.7.2 2016-02-05 14:32 +0000 c1b94ffe78 Mark Michelson * .lastclean: Update for 13.7.2 2016-02-05 14:32 +0000 932ed1ab5b Mark Michelson * realtime: Add database scripts for 13.7.2 2016-02-02 10:52 +0000 8de94229ba Alexei Gradinari License #5691 * res_sorcery_realtime: Fix regex regression. A regression was introduced where searching for realtime PJSIP objects by regex by starting the regex with a leading " " would cause no items to be returned. This was due to a change which attempted to drop the requirement for a leading " " to be present due to how some CLI commands formulate their regexes. However, the change, rather than simply eliminating the requirement, caused any regexes that did begin with " " to end up not returning the expected results. This change fixes the problem by inspecting the regex and formulating the realtime query differently depending on if it begins with " ". ASTERISK-25702 #close Reported by Nic Colledge Patches: realtime_retrieve_regex.patch submitted by Alexei Gradinari License #5691 Change-Id: I055df608a6e6a10732044fa737a9fe8dca602693 (cherry picked from commit 32fc784284b570a05841d95c6d9a373b4bf3a35d) 2016-02-04 16:17 +0000 a56f55d566 Mark Michelson * Check for OpenSSL defines before trying to use them. The SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2 defines did not exist prior to OpenSSL version 1.0.1. A recent commit attempts to, by default, set these options, which can cause problems on systems with older OpenSSL installations. This commit adds a configure script check for those defines and will not attempt to make use of those if they do not exist.
ManageYou can also help out here by:
← Update project
or flagging this entry for moderator attention.