[asterisk-commits] lmadsen: tag 1.4.42 r325392 - in /tags/1.4.42: .lastclean .version ChangeLog
SVN commits to the Asterisk project
asterisk-commits at lists.digium.com
Tue Jun 28 16:26:16 CDT 2011
Author: lmadsen
Date: Tue Jun 28 16:26:11 2011
New Revision: 325392
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=325392
Log:
Importing files for 1.4.42 release.
Added:
tags/1.4.42/.lastclean (with props)
tags/1.4.42/.version (with props)
tags/1.4.42/ChangeLog (with props)
Added: tags/1.4.42/.lastclean
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.42/.lastclean?view=auto&rev=325392
==============================================================================
--- tags/1.4.42/.lastclean (added)
+++ tags/1.4.42/.lastclean Tue Jun 28 16:26:11 2011
@@ -1,0 +1,1 @@
+33
Propchange: tags/1.4.42/.lastclean
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.4.42/.lastclean
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.4.42/.lastclean
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.4.42/.version
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.42/.version?view=auto&rev=325392
==============================================================================
--- tags/1.4.42/.version (added)
+++ tags/1.4.42/.version Tue Jun 28 16:26:11 2011
@@ -1,0 +1,1 @@
+1.4.42
Propchange: tags/1.4.42/.version
------------------------------------------------------------------------------
svn:eol-style = native
Propchange: tags/1.4.42/.version
------------------------------------------------------------------------------
svn:keywords = none
Propchange: tags/1.4.42/.version
------------------------------------------------------------------------------
svn:mime-type = text/plain
Added: tags/1.4.42/ChangeLog
URL: http://svnview.digium.com/svn/asterisk/tags/1.4.42/ChangeLog?view=auto&rev=325392
==============================================================================
--- tags/1.4.42/ChangeLog (added)
+++ tags/1.4.42/ChangeLog Tue Jun 28 16:26:11 2011
@@ -1,0 +1,31865 @@
+2011-06-28 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.42 Released.
+
+2011-06-28 20:03 +0000 [r325275] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Don't leak SIP username information
+
+2011-06-23 18:16 +0000 [r324627] David Vossel <dvossel at digium.com>
+
+ * res/res_features.c, channels/chan_iax2.c: Addresses AST-2011-010,
+ remote crash in IAX2 driver Thanks to twilson for identifying the
+ issue and providing the patches. AST-2011-010
+
+2011-06-15 18:06 +0000 [r323732] Terry Wilson <twilson at digium.com>
+
+ * res/res_features.c: Fix DYNAMIC_FEATURES DYNAMIC_FEATURES were
+ broken by a recent DTMF change. This patch makes sure that
+ dynamic features are also checked when deciding whether or not to
+ pass DTMF through or store it for interpreting. (closes issue
+ ASTERISK-17914) Reported by: vrban
+
+2011-06-15 15:15 +0000 [r323559] Sean Bright <sean at malleable.com>
+
+ * main/manager.c: Resolve a segfault/bus error when we try to map
+ memory that falls on a page boundary. The fix for ASTERISK-15359
+ was incorrect in that it added 1 to the length of the mmap'd
+ region. The problem with this is that reading/writing to that
+ extra byte outside of the bounds of the underlying fd causes a
+ bus error. The real issue is that we are working with both a FILE
+ * and the raw fd underneath it and not synchronizing between
+ them. The code that was removed in ASTERISK-15359 was correct,
+ but we weren't flushing the FILE * before mapping the fd. Looking
+ at the manager code in 1.4 reveals that the FILE * in 'struct
+ mansession' is never used except to create a temporary file that
+ we immediately fdopen. This means we just need to write a 0 byte
+ to the fd and everything will just work. The other branches
+ require a call to fflush() which, while not a guaranteed fix,
+ should reduce the likelihood of a crash. This all makes sense in
+ my head. (closes issue ASTERISK-16460) Reported by:
+ Ravelomanantsoa Hoby (hoby) Patches:
+ issue17747_1.4_svn_markII.patch uploaded by Sean Bright (license
+ #5060)
+
+2011-06-09 15:36 +0000 [r322646-322698] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: unlock pvt when we drop voice frames
+ received in early media when in t.38 mode
+
+ * channels/chan_sip.c: whitespace
+
+ * channels/chan_sip.c: don't drop any voice frames when checking
+ for T.38 during early media (closes issue ASTERISK-17705) Review:
+ https://reviewboard.asterisk.org/r/1186/ patch by oej reported by
+ oej
+
+2011-05-21 05:09 +0000 [r320393] Paul Belanger <pabelanger at digium.com>
+
+ * cdr/cdr_pgsql.c: Solaris compatibility fixes
+
+2011-05-20 20:38 +0000 [r320235] Richard Mudgett <rmudgett at digium.com>
+
+ * apps/app_meetme.c: The meetme CLI command completion leaves
+ conferences mutex locked. When issuing a meetme kick CLI command
+ and an invalid (non-existent) conference number is specified,
+ pressing Tab leaves the conferences mutex locked and, therefore,
+ all conferences deadlock. Add missing unlock. (closes issue
+ #19336) Reported by: zvision Patches: app_meetme.diff uploaded by
+ zvision (license 798)
+
+2011-05-20 16:38 +0000 [r320055] David Vossel <dvossel at digium.com>
+
+ * channels/chan_sip.c: chan_sip: Destroy variables on a sip_pvt
+ before copying vars from the sip_peer. (closes issue #19202)
+ Reported by: wdoekes Patches:
+ issue19202_destroy_challenged_invite_chanvars.patch uploaded by
+ wdoekes (license 717)
+
+2011-05-18 23:04 +0000 [r319527-319652] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Make sure everyone gets an unhold when a
+ transfer succeeds Some phones, like the Snom phones, send a hold
+ to the transfer target after before sending the REFER. We need to
+ make sure that we unhold the parties that are being connected
+ after the masquerade. If Local channels with the /nm option are
+ used when dialing the parties, hold music would still be playing
+ on the transfer target, even after being connected with the
+ transferee.
+
+ * apps/app_dial.c: Fix app_dial ring groups Revert part of r315643.
+ We need to remove the datastore here as well. The code in
+ bridging code will catch anything that app_dial might miss.
+ (closes issue #19311) Reported by: mspuhler Patches:
+ issue_19311_no_answer.diff uploaded by elguero (license 37)
+
+2011-05-13 01:09 +0000 [r318734] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_sip.c, res/res_features.c,
+ apps/app_directed_pickup.c: Merged revisions 318671 via svnmerge
+ from https://origsvn.digium.com/svn/asterisk/branches/1.8 * The
+ applicable fixes for v1.4 are the SIP deadlock and the in
+ progress masquerade check for multiple parties trying to pickup
+ the same call. issue18654_v1.4.patch uploaded by rmudgett
+ (license 664) * Backported to v1.6.2. issue18654_v1.6.2.patch
+ uploaded by rmudgett (license 664) ........ r318671 | alecdavis |
+ 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines Fix
+ directed group pickup feature code *8 with pickupsounds enabled
+ Since 1.6.2, the new pickupsound and pickupfailsound in
+ features.conf cause many issues. 1).
+ chan_sip:handle_request_invite() shouldn't be playing out the
+ fail/success audio, as it has 'netlock' locked. 2). dialplan
+ applications for directed_pickups shouldn't beep. 3). feature
+ code for directed pickup should beep on success/failure if
+ configured. Created a sip_pickup() thread to handle the pickup
+ and playout the audio, spawned from handle_request_invite. Moved
+ app_directed:pickup_do() to features:ast_do_pickup(). Functions
+ below, all now use the new ast_do_pickup() app_directed_pickup.c:
+ pickup_by_channel() pickup_by_exten() pickup_by_mark()
+ pickup_by_part() features.c: ast_pickup_call() (closes issue
+ #18654) Reported by: Docent Patches:
+ ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license
+ 585) Tested by: lmadsen, francesco_r, amilcar, isis242,
+ alecdavis, irroot, rymkus, loloski, rmudgett Review:
+ https://reviewboard.asterisk.org/r/1185/ ........
+
+2011-05-06 17:59 +0000 [r317719] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_sip.c: Regression after r297603 (Improve handling
+ of REGISTER requests with multiple contact headers.)
+ Uninitialized variable. (issue #18640) (closes issue #18785)
+ Reported by: pnlarsson Patches: issue18785_enegaard.patch
+ uploaded by enegaard (license 1197)
+
+2011-05-06 07:55 +0000 [r317574] Terry Wilson <twilson at digium.com>
+
+ * apps/app_queue.c: Re-fix queue round-robin This part of the
+ change for r315596 was incorrect. No bridge occurs when doing a
+ roundrobin dial and no one answers, so this code shouldn't have
+ been removed.
+
+2011-05-05 18:20 +0000 [r317211] Russell Bryant <russell at digium.com>
+
+ * channels/chan_sip.c: chan_sip: fix broken realtime peer count,
+ fix memory leak This patch addresses two bugs in chan_sip: 1) The
+ count of realtime peers and users was off. The increment checked
+ the value of the caching option, while the decrement did not. 2)
+ Add a missing regfree() for a regex. (closes issue #19108)
+ Reported by: vrban Patches: missing_regfree.patch uploaded by
+ vrban (license 756) sip_object_counter.patch uploaded by vrban
+ (license 756)
+
+2011-05-05 14:54 +0000 [r317102] Leif Madsen <lmadsen at digium.com>
+
+ * contrib/scripts/safe_asterisk: Disable console colourization
+ inside safe_asterisk checks. (closes issue #19213) Reported by:
+ lefoyer Patches:
+ issue19213_strip_color_in_safe_asterisk-svn.patch uploaded by
+ wdoekes (license 717) Tested by: wdoekes, lefoyer
+
+2011-05-04 16:08 +0000 [r316707] Sean Bright <sean at malleable.com>
+
+ * apps/app_voicemail.c: If sox fails when processing a voicemail,
+ don't delete the original file. (closes issue #18111) Reported
+ by: sysreq Patches: issue18111_trunk.patch uploaded by seanbright
+ (license 71) Tested by: seanbright
+
+2011-05-03 21:27 +0000 [r316328] David Vossel <dvossel at digium.com>
+
+ * channels/chan_local.c: Fixes chan_local crashs in local_fixup()
+ Thanks OEJ for tracking down the issue and submitting the patch.
+ (closes issue #19053) Reported by: oej Tested by: oej Review:
+ https://reviewboard.asterisk.org/r/1158/
+
+2011-05-02 18:25 +0000 [r316089] Tilghman Lesher <tilghman at meg.abyt.es>
+
+ * configure, configure.ac: Breakage from slightly before the
+ outage; would have fixed sooner but for the outage.
+
+2011-04-27 21:20 +0000 [r316006] Tilghman Lesher <tilghman at meg.abyt.es>
+
+ * configure, include/asterisk/autoconfig.h.in, configure.ac:
+ Backport the use of curl from 1.6.2 to make the 1.4 target work
+ on Bamboo.
+
+2011-04-27 20:54 +0000 [r315989] Sean Bright <sean at malleable.com>
+
+ * channels/chan_sip.c: Partial revert of r315671 which removed a
+ logging statement and not a manager event. Reported by ibercom in
+ #asterisk-bugs. (issue #16033)
+
+2011-04-27 18:57 +0000 [r315891] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: Fix our compliance with RFC 3261 section
+ 18.2.2. This change optimizes the free_via() function and removes
+ some redundant null checking. It also fixes compliance with RFC
+ 3261 section 18.2.2 by always using the port specified in the Via
+ header for routing responses (even when maddr is not set). Also
+ the htons() function is now used when setting the port.
+ Additional documentation comments have been added in various
+ places to make the logic in the code clearer. (closes issue
+ #18951) Reported by: jmls Patches:
+ issue18951_set_proper_port_from_via.patch uploaded by wdoekes
+ (license 717) (modified)
+
+2011-04-26 22:47 +0000 [r315596-315671] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Make sure unregistering a peer unlinks it
+ from the peer container Instead of mostly copying the code from
+ expire_register, just use the function that "does the right
+ thing". (closes issue #16033) Reported by: kkm Patches:
+ 016033-tilgman-fixed-refcount.diff uploaded by kkm (license 888)
+ Tested by: kkm, tilghman, twilson
+
+ * apps/app_dial.c, res/res_features.c, apps/app_queue.c: Allow
+ transfer loops without allowing forwarding loops We try to avoid
+ the situation where two phones may be forwarded to each other
+ causing an infinite loop by storing each dialed interface in a
+ channel datastore and checking the list before dialing out. This
+ works, but currently breaks situations like A calls B, A
+ transfers B to C, B transfers C to A, and A transfers C to B.
+ Since human interaction is happening here and not an automated
+ forwarding loop, it should be allowed. This patch removes the
+ dialed_interfaces datastore when a call is bridged (a suggestion
+ from the brilliant mmichelson). If a call is being bridged, it
+ should be safe to assume that we aren't stuck in a loop. Since we
+ are now handling this is the bridge code, the previous attempts
+ at handling it in app_dial and app_queue are removed. Review:
+ https://reviewboard.asterisk.org/r/1195/
+
+2011-04-26 19:18 +0000 [r315501] Tilghman Lesher <tilghman at meg.abyt.es>
+
+ * include/asterisk/select.h: Fix the bounds-checking code. The code
+ that set the bit within the select bitfield was correct, but the
+ bounds-checking code was not. The change to that line uses the
+ new _bitsize macro for clarity. Also, FD_ZERO macro did not
+ zero-out anything but the first word of the bitfield, so this
+ could have caused problems with modules using that macro with the
+ expanded bitfield. (closes issue #18773) Reported by: jamicque
+ Patches: 20110423__issue18773.diff.txt uploaded by tilghman
+ (license 14) Tested by: chris-mac
+
+2011-04-25 19:28 +0000 [r315257] Russell Bryant <russell at digium.com>
+
+ * formats/format_wav.c: Be more flexible with unknown chunks in wav
+ files. This patch makes format_wav ignore unknown chunks instead
+ of erroring out on them. (closes issue #18306) Reported by:
+ jhirsch Patches: wav_skip_unknown_blocks.diff uploaded by jhirsch
+ (license 1156)
+
+2011-04-25 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.41 Released.
+
+ * AST-2011-005, AST-2011-006
+
+ * Reverted part of r314607, as it can introduce a regression.
+ Specifically, the security check for the "system" privilege was
+ removed. If a user had the "call" privilege but not the "system" privilege,
+ they would lose the ability to execute the system app and dialplan functions
+ that run commands in a shell. This branch never used the "system" privilege
+ for that purpose and did not need to be patched.
+ (AST-2011-006)
+
+2011-02-23 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.41-rc1 Released.
+
+2011-02-21 14:57 +0000 [r308413] Matthew Nicholson <mnicholson at digium.com>
+
+ * main/udptl.c: Properly check the bounds of arrays when decoding
+ UDPTL packets. Also, remove broken support for receiving UDPTL
+ packets larger than 16k. That shouldn't ever happen anyway.
+ AST-2011-002 FAX-281
+
+2011-02-15 23:32 +0000 [r308002] Jason Parker <jparker at digium.com>
+
+ * apps/app_queue.c: Fix regression that changed behavior of queues
+ when ringing a queue member. This reverts r298596, which was to
+ fix a highly bizarre and contrived issue with a queue member that
+ called into his own queue being transferred back into his own
+ queue. I couldn't reproduce that issue in any way. I think one of
+ the other recent transfer fixes actually fixed this. (closes
+ issue #18747) Reported by: vrban
+
+2011-02-11 00:29 +0000 [r307623] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c: Reentrancy problem if outgoing call gets
+ different B channel than requested. The chan_dahdi
+ pri_fixup_principle() routine needs to protect the Asterisk
+ channel with the channel lock when it changes the technology
+ private pointer to a new private structure. * Added lock
+ protection while pri_fixup_principle() moves a call from one
+ private structure to another. * Made some pri_fixup_principle()
+ messages more meaningful. Partial backport from v1.8 -r300714.
+
+2011-02-10 22:33 +0000 [r307534] Jason Parker <jparker at digium.com>
+
+ * main/asterisk.c: Remove color when executing commands via a
+ remote console. Essentially this makes '-x' imply '-n' on
+ rasterisk. This was done in a different and incomplete way
+ previously, which I'll be reverting shortly. (issue #18776)
+ Reported by: alecdavis
+
+2011-02-08 20:05 +0000 [r306972] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Fix comparison for REFER Replaces tags with
+ pedantic=yes
+
+2011-02-08 19:40 +0000 [r306864-306965] Jeff Peeler <jpeeler at digium.com>
+
+ * apps/app_voicemail.c: fix this line again
+
+ * apps/app_voicemail.c: clean this up, sorry my brain is not really
+ working
+
+ * apps/app_voicemail.c: Backup file storing message duration is not
+ used with IMAP_STORAGE, remove code. The message duration is
+ stored in the body of the email when using IMAP_STORAGE, so
+ nothing needs to happen with the backup file. (closes issue
+ #18718) Reported by: kerframil
+
+ * apps/app_voicemail.c: make this safer and fully correct, pointed
+ out by Steve Davis
+
+2011-02-07 22:35 +0000 [r306617-306672] Terry Wilson <twilson at digium.com>
+
+ * res/res_features.c: Don't try to pickup a call in the middle of a
+ masquerade If A calls B which doesn't answer and C & D both try
+ to do a call pickup, it is possible for ast_pickup_call to answer
+ the call, then fail to masquerade one of the calls because the
+ other one is already in the process of masquerading. This patch
+ checks to see if the channel is in the process of masquerading
+ before call before selecting it for a pickup. Review:
+ https://reviewboard.asterisk.org/r/1094/
+
+ * channels/chan_sip.c: Don't allow a REFER w/replaces to replace
+ its own dialog Asterisk currently accepts a REFER with a Refer-To
+ with an embedded Replaces header that matches the dialog of the
+ REFER. This would be a situation like A calls B, A calls C, A
+ transfers B to A, which is just silly. This patch makes the
+ transfer fail instead of making Asterisk freak out and forget to
+ hang other channels up. Review:
+ https://reviewboard.asterisk.org/r/1093/
+
+2011-02-03 20:43 +0000 [r306120] Jeff Peeler <jpeeler at digium.com>
+
+ * res/res_features.c: Fix no MOH and frame queueing problem for
+ parked calls. This was a regression introduced when select was
+ changed to poll and was just a conversion error: POLLPRI detects
+ OOB data, not POLLERR. (closes issue #18637) Reported by: jvandal
+
+2011-02-03 20:36 +0000 [r306119] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_local.c: Set hangup cause in local_hangup When a
+ call involves a local channel (like SIP -> Local -> SIP), the
+ hangup cause was not being set. This resulted in SIP channels
+ sometimes getting a 503 error instead of a 486 when the far side
+ sent a busy. In Asterisk 1.8+ this also can cause issues with
+ CCSS that involve a local channel. This patch sets the
+ hangupcause for one side of the local channel to the other in
+ local_hangup for outbound calls.
+
+2011-02-03 00:02 +0000 [r305888] Richard Mudgett <rmudgett at digium.com>
+
+ * main/channel.c, channels/chan_sip.c, apps/app_sendtext.c: Minor
+ AST_FRAME_TEXT related issues. * Include the null terminator in
+ the buffer length. When the frame is queued it is copied. If the
+ null terminator is not part of the frame buffer length, the
+ receiver could see garbage appended onto it. * Add channel lock
+ protection with ast_sendtext().
+
+2011-02-01 17:00 +0000 [r305471] Jason Parker <jparker at digium.com>
+
+ * res/res_musiconhold.c: Close file descriptor for timing source
+ when a MOH class gets destroyed. (closes issue #18457) Reported
+ by: mcallist Patches: 18457-closetimer.diff uploaded by qwell
+ (license 4) 18457-closetimer_trunk.diff uploaded by qwell
+ (license 4) Tested by: qwell, loloski
+
+2011-01-31 23:45 +0000 [r305341] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c: Obtain the pri lock for PRI queue
+ counters. Need to obtain the pri lock when calling
+ pri_dump_info_str() to avoid a reentrancy problem when
+ calculating the Q.921 Q count statistic. JIRA AST-484
+
+2011-01-31 22:56 +0000 [r305129-305252] Jason Parker <jparker at digium.com>
+
+ * apps/app_dial.c, channels/chan_sip.c: Prevent a crash when
+ dialing a technology with no destination (ex: Dial(SIP/))
+ chan_iax2 and other channel drivers already had code to prevent
+ this. The attempt that app_dial was making to prevent it was not
+ correct, so I fixed that. (closes issue #18371) Reported by:
+ gbour Patches: 18371.patch uploaded by gbour (license 1162)
+
+ * res/res_musiconhold.c: Set file descriptors to -1 on creation, so
+ that we don't see weirdness later.
+
+2011-01-31 06:54 +0000 [r304952] Tilghman Lesher <tilghman at meg.abyt.es>
+
+ * apps/app_voicemail.c: Fix compilation when ODBC_STORAGE is
+ defined.
+
+2011-01-29 21:48 +0000 [r304820] Sean Bright <sean at malleable.com>
+
+ * apps/app_meetme.c: Backport MeetMe related reference leaks fixes
+ from 1.6.2/1.8/trunk. I had forgotten that MeetMe in 1.4 also
+ used astobj2, so backport the fixes where appropriate.
+
+2011-01-27 16:57 +0000 [r304460-304464] Jason Parker <jparker at digium.com>
+
+ * configure, configure.ac: Fix default prefix=/usr regression on
+ non-Linux systems. This partially reverts a change made in
+ branches/1.4/ r267759, which will cause issue #17013 to be
+ reopened. This issue was pointed out by a user on #asterisk, who
+ helpfully discovered that paths were being set incorrectly. To
+ truly understand what was wrong, one should run: svn diff --force
+ -c<this revision> configure
+
+ * configure, include/asterisk/autoconfig.h.in: Rerun bootstrap.sh
+ with no changes, so that it is more obvious what my next commit
+ changes.
+
+2011-01-26 21:00 +0000 [r304247] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: Convert from network to host byte ordering
+ before checking if an IP is a multicast address.
+
+2011-01-26 20:38 +0000 [r304242] Mark Michelson <mmichelson at digium.com>
+
+ * main/udptl.c: Get rid of unused 'verbose' field in ast_udptl
+
+2011-01-26 20:38 +0000 [r304241] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: This patch modifies chan_sip to route
+ responses to the address the request came from. It also modifies
+ chan_sip to respect the maddr parameter in the Via header.
+ ABE-2664 Review: https://reviewboard.asterisk.org/r/1059/
+
+2011-01-26 20:18 +0000 [r304159] Sean Bright <sean at malleable.com>
+
+ * configs/queues.conf.sample: Make sure the sample queues.conf is
+ properly commented.
+
+2011-01-25 23:21 +0000 [r304005] Richard Mudgett <rmudgett at digium.com>
+
+ * res/res_features.c: DTMF attended transfers sometimes fail for no
+ apparent reason. The loop in feature_request_and_dial() can exit
+ when Party C has answered without processing an
+ AST_CONTROL_ANSWER. Also sometimes an AST_CONTROL_ANSWER never
+ happens even though Party C has answered. Don't hangup Party C if
+ he is up or we receive an AST_CONTROL_ANSWER.
+
+2011-01-25 20:50 +0000 [r303906] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Guard against retransmitting BYEs
+ indefinitely In the case of an attended transfer (A calls B, A
+ atxfers to C) where A becomes unreachable before replying to
+ Asterisk's BYE, Asterisk can sometimes retransmit the BYE
+ indefinitely. This is because __sip_autodestruct tests p->refer
+ && !ast_test_flag(&p->flags[0], SIP_ALREADYGONE and will then
+ transmit a BYE. When this BYE times out, it will not ever be
+ marked as ALREADYGONE, so when __sip_autodestruct is called
+ again, we end up starting the cycle over. This patch adds a call
+ to sip_alreadygone(pkt->owner) in retrans_pkt in the case of a
+ BYE that has timed out. This should prevent Asterisk from trying
+ to transmit new BYE messages in the future. Review:
+ https://reviewboard.asterisk.org/r/1077/
+
+2011-01-25 17:36 +0000 [r303747-303765] Richard Mudgett <rmudgett at digium.com>
+
+ * channels/chan_dahdi.c: Sending out unnecessary PROCEEDING
+ messages breaks overlap dialing. Issue #16789 was a good idea.
+ Unfortunately, it breaks overlap dialing through Asterisk. There
+ is not enough information available at this point to know if
+ dialing is complete. The ast_exists_extension(),
+ ast_matchmore_extension(), and ast_canmatch_extension() calls are
+ not adequate to detect a dial through extension pattern of "_9!".
+ Workaround is to use the dialplan Proceeding() application early
+ in non-dial through extensions. * Effectively revert issue
+ #16789. * Allow outgoing overlap dialing to hear dialtone and
+ other early media. A PROGRESS "inband-information is now
+ available" message is now sent after the SETUP_ACKNOWLEDGE
+ message for non-digital calls. An AST_CONTROL_PROGRESS is now
+ generated for incoming SETUP_ACKNOWLEDGE messages for non-digital
+ calls. * Handling of the AST_CONTROL_CONGESTION in
+ chan_dahdi/sig_pri was inconsistent with the cause codes. * Added
+ better protection from sending out of sequence messages by
+ combining several flags into a single enum value representing
+ call progress level. * Added diagnostic messages for deferred
+ overlap digits handling corner cases. (closes issue #17085)
+ Reported by: shawkris (closes issue #18509) Reported by: wimpy
+ Patches: issue18509_early_media_v1.8_v3.patch uploaded by
+ rmudgett (license 664) Expanded upon
+ issue18509_early_media_v1.8_v3.patch to include analog and SS7
+ because of backporting requirements. Tested by: wimpy, rmudgett
+
+ * main/pbx.c: Backport the Proceeding application. Added in trunk
+ -r129399. Enable the workaround for issue #17085 and #18509.
+ (issue #17085) (issue #18509)
+
+2011-01-25 16:58 +0000 [r303676] Jeff Peeler <jpeeler at digium.com>
+
+ * apps/app_voicemail.c: Fix voicemail sequencing for file based
+ storage. A previous change was made to account for when the
+ number of voicemail messages exceeds the max limit to be handled
+ properly, but it caused gaps in the messages to not be properly
+ handled. This has now been resolved. In later non 1.4 branches,
+ it appears that resequencing wasn't even occurring due from what
+ appears and accidental code removal. (closes issue #18498)
+ Reported by: JJCinAZ Patches: bug18498v2.patch uploaded by
+ jpeeler (license 325) (closes issue #18486) Reported by: bluefox
+ Patches: bug18486.patch uploaded by jpeeler (license 325)
+
+2011-01-24 20:57 +0000 [r303546-303552] Russell Bryant <russell at digium.com>
+
+ * main/pbx.c, res/res_features.c: Fix a couple of mistakes in the
+ backport of this patch to 1.4.
+
+ * main/channel.c, main/pbx.c, apps/app_meetme.c,
+ res/res_features.c, include/asterisk/channel.h: Fix channel
+ redirect out of MeetMe() and other issues with channel
+ softhangup. Mantis issue #18585 reports that a channel redirect
+ out of MeetMe() stopped working properly. This issue includes a
+ patch that resolves the issue by removing a call to
+ ast_check_hangup() from app_meetme.c. I left that in my patch, as
+ it doesn't need to be there. However, the rest of the patch fixes
+ this problem with or without the change to app_meetme. The key
+ difference between what happens before and after this patch is
+ the effect of the END_OF_Q control frame. After END_OF_Q is hit
+ in ast_read(), ast_read() will return NULL. With the
+ ast_check_hangup() removed, app_meetme sees this which causes it
+ to exit as intended. Checking ast_check_hangup() caused
+ app_meetme to exit earlier in the process, and the target of the
+ redirect saw the condition where ast_read() returned NULL.
+ Removing ast_check_hangup() works around the issue in app_meetme,
+ but doesn't solve the issue if another application did the same
+ thing. There are also other edge cases where if an application
+ finishes at the same time that a redirect happens, the target of
+ the redirect will think that the channel hung up. So, I made some
+ changes in pbx.c to resolve it at a deeper level. There are
+ already places that unset the SOFTHANGUP_ASYNCGOTO flag in an
+ attempt to abort the hangup process. My patch extends this to
+ remove the END_OF_Q frame from the channel's read queue, making
+ the "abort hangup" more complete. This same technique was used in
+ every place where a softhangup flag was cleared. (closes issue
+ #18585) Reported by: oej Tested by: oej, wedhorn, russell Review:
+ https://reviewboard.asterisk.org/r/1082/
+
+2011-01-21 21:45 +0000 [r303284] Jason Parker <jparker at digium.com>
+
+ * channels/chan_dahdi.c: Reset configuration before parsing
+ users.conf. Some values configured in chan_dahdi.conf were able
+ to leak in to users.conf configuration. This was surprising
+ users, and potentially setting non-sane "defaults". ASTNOW-125
+
+2011-01-20 17:04 +0000 [r303007] Jeff Peeler <jpeeler at digium.com>
+
+ * configs/queues.conf.sample, apps/app_queue.c: Add new queue
+ strategy to preserve behavior for when queue members moved to
+ ao2. Add queue strategy called "rrordered" to mimic old behavior
+ from when queue members were stored in a linked list. ABE-2707
+
+2011-01-20 15:38 +0000 [r302916] Leif Madsen <lmadsen at digium.com>
+
+ * apps/app_dial.c: Option L() is milliseconds, not seconds. Change
+ the verbose output of option L() to say milliseconds and not
+ seconds as the value is in milliseconds. (closes issue #18264)
+ Reported by: jacco Patches: app_dial_patch.txt uploaded by
+ lmadsen (license 10) Tested by: lmadsen, jacco
+
+2011-01-19 21:21 +0000 [r302671] Richard Mudgett <rmudgett at digium.com>
+
+ * res/res_features.c: DTMF transfer plays the wrong sounds for
+ wrong number or other call failure. * Set the default for
+ features.conf.sample xferfailsound option to "beeperr" as
+ documented instead of "pbx-invalid" and corrected the use of it
+ in DTMF blind transfer (#1). * Improved DTMF blind transfer
+ handling of wrong numbers. Most of the concerns in this issue
+ were taken care of by the patch for issue 17999: Issues with DTMF
+ triggered attended transfers. (closes issue #18379) Reported by:
+ gincantalupo Tested by: rmudgett
+
+2011-01-19 21:20 +0000 [r302663] Tilghman Lesher <tilghman at meg.abyt.es>
+
+ * include/asterisk/astdb.h: Add some API documentation
+
+2011-01-18 21:35 +0000 [r302311] Matthew Nicholson <mnicholson at digium.com>
+
+ * channels/chan_sip.c: URI encode the user part of the contact
+ header. ABE-2705
+
+2011-01-18 18:04 +0000 [r302172] Richard Mudgett <rmudgett at digium.com>
+
+ * res/res_features.c: Issues with DTMF triggered attended
+ transfers. Issue #17999 1) A calls B. B answers. 2) B using DTMF
+ dial *2 (code in features.conf for attended transfer). 3) A hears
+ MOH. B dial number C 4) C ringing. A hears MOH. 5) B hangup. A
+ still hears MOH. C ringing. 6) A hangup. C still ringing until
+ "atxfernoanswertimeout" expires. For v1.4 C will ring forever
+ until C answers the dead line. (Issue #17096) Problem: When A and
+ B hangup, C is still ringing. Issue #18395 SIP call limit of B is
+ 1 1. A call B, B answered 2. B *2(atxfer) call C 3. B hangup, C
+ ringing 4. Timeout waiting for C to answer 5. Recall to B fails
+ because B has reached its call limit. Because B reached its call
+ limit, it cannot do anything until the transfer it started
+ completes. Issue #17273 Same scenario as issue 18395 but party B
+ is an FXS port. Party B cannot do anything until the transfer it
+ started completes. If B goes back off hook before C answers, B
+ hears ringback instead of the expected dialtone. ********** Note
+ for the issue #17273 and #18395 fix: DTMF attended transfer works
+ within the channel bridge. Unfortunately, when either party A or
+ B in the channel bridge hangs up, that channel is not completely
+ hung up until the transfer completes. This is a real problem
+ depending upon the channel technology involved. For chan_dahdi,
+ the channel is crippled until the hangup is complete. Either the
+ channel is not useable (analog) or the protocol disconnect
+ messages are held up (PRI/BRI/SS7) and the media is not released.
+ For chan_sip, a call limit of one is going to block that endpoint
+ from any further calls until the hangup is complete. For party A
+ this is a minor problem. The party A channel will only be in this
+ condition while party B is dialing and when party B and C are
+ conferring. The conversation between party B and C is expected to
+ be a short one. Party B is either asking a question of party C or
+ announcing party A. Also party A does not have much incentive to
+ hangup at this point. For party B this can be a major problem
+ during a blonde transfer. (A blonde transfer is our term for an
+ attended transfer that is converted into a blind transfer. :))
+ Party B could be the operator. When party B hangs up, he assumes
+ that he is out of the original call entirely. The party B channel
+ will be in this condition while party C is ringing, while
+ attempting to recall party B, and while waiting between call
+ attempts. WARNING: The ATXFER_NULL_TECH conditional is a hack to
+ fix the problem. It will replace the party B channel technology
+ with a NULL channel driver to complete hanging up the party B
+ channel technology. The consequences of this code is that the 'h'
+ extension will not be able to access any channel technology
+ specific information like SIP statistics for the call.
+ ATXFER_NULL_TECH is not defined by default. ********** (closes
+ issue #17999) Reported by: iskatel Tested by: rmudgett JIRA
+ SWP-2246 (closes issue #17096) Reported by: gelo Tested by:
+ rmudgett JIRA SWP-1192 (closes issue #18395) Reported by:
+ shihchuan Tested by: rmudgett (closes issue #17273) Reported by:
+ grecco Tested by: rmudgett Review:
+ https://reviewboard.asterisk.org/r/1047/
+
+2011-01-17 17:45 +0000 [r302087] Terry Wilson <twilson at digium.com>
+
+ * channels/chan_sip.c: Merged revisions 293493 via svnmerge from
+ https://origsvn.digium.com/svn/asterisk/branches/1.8 [^] ........
+ r293493 | twilson | 2010-11-01 09:58:00 -0500 (Mon, 01 Nov 2010)
+ | 14 lines Only offer codecs both sides support for directmedia
+ When using directmedia, Asterisk needs to limit the codecs
+ offered to just the ones that both sides recognize, otherwise
+ they may end up sending audio that the other side doesn't
+ understand. (closes issue 0017403) Reported by: one47 Patches:
+ sip_codecs_simplified4 uploaded by one47 (license 23) Tested by:
+ one47, falves11 Review: https://reviewboard.asterisk.org/r/967/
+ [^] ........ Back port a fix that should have been included
+
+2011-02-22 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.40 Released.
+
+ * Merged changes related to AST-2011-002
+
+2011-02-16 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.40-rc3 Released.
+
+ ------------------------------------------------------------------------
+ r308002 | qwell | 2011-02-15 17:32:21 -0600 (Tue, 15 Feb 2011) | 10
+ lines
+
+ Fix regression that changed behavior of queues when ringing a queue
+ member.
+
+ This reverts r298596, which was to fix a highly bizarre and contrived
+ issue with a queue member that called into his own queue being
+ transferred back into his own queue. I couldn't reproduce that issue in
+ any way. I think one of the other recent transfer fixes actually fixed
+ this.
+
+ (closes issue 0018747)
+ Reported by: vrban
+
+ ------------------------------------------------------------------------
+
+2011-01-20 Leif Madsen <lmadsen at digium.com>
+
+ * Asterisk 1.4.40-rc2 Released.
+
+ ------------------------------------------------------------------------
+ r302172 | rmudgett | 2011-01-18 12:04:37 -0600 (Tue, 18 Jan 2011) | 88
+ lines
+
+ Issues with DTMF triggered attended transfers.
+
+ Issue 0017999
+ 1) A calls B. B answers.
+ 2) B using DTMF dial *2 (code in features.conf for attended transfer).
+ 3) A hears MOH. B dial number C
+ 4) C ringing. A hears MOH.
+ 5) B hangup. A still hears MOH. C ringing.
+ 6) A hangup. C still ringing until "atxfernoanswertimeout" expires.
+ For v1.4 C will ring forever until C answers the dead line. (Issue
+ 0017096)
+
+ Problem: When A and B hangup, C is still ringing.
+
+ Issue 0018395
+ SIP call limit of B is 1
+ 1. A call B, B answered
+ 2. B *2(atxfer) call C
+ 3. B hangup, C ringing
+ 4. Timeout waiting for C to answer
+ 5. Recall to B fails because B has reached its call limit.
+
+ Because B reached its call limit, it cannot do anything until the
+ transfer
+ it started completes.
+
+ Issue 0017273
+ Same scenario as issue 18395 but party B is an FXS port. Party B
+ cannot
+ do anything until the transfer it started completes. If B goes back
+ off
+ hook before C answers, B hears ringback instead of the expected
+ dialtone.
+
+ **********
+ Note for the issue 0017273 and 0018395 fix:
+
+ DTMF attended transfer works within the channel bridge. Unfortunately,
+ when either party A or B in the channel bridge hangs up, that channel
+ is
+ not completely hung up until the transfer completes. This is a real
+ problem depending upon the channel technology involved.
+
+ For chan_dahdi, the channel is crippled until the hangup is complete.
+ Either the channel is not useable (analog) or the protocol disconnect
+ messages are held up (PRI/BRI/SS7) and the media is not released.
+
+ For chan_sip, a call limit of one is going to block that endpoint from
+ any
+ further calls until the hangup is complete.
+
+ For party A this is a minor problem. The party A channel will only be
+ in
+ this condition while party B is dialing and when party B and C are
+ conferring. The conversation between party B and C is expected to be a
+ short one. Party B is either asking a question of party C or
+ announcing
+ party A. Also party A does not have much incentive to hangup at this
+ point.
+
+ For party B this can be a major problem during a blonde transfer. (A
+ blonde transfer is our term for an attended transfer that is converted
+ into a blind transfer. :)) Party B could be the operator. When party B
+ hangs up, he assumes that he is out of the original call entirely. The
+ party B channel will be in this condition while party C is ringing,
+ while
+ attempting to recall party B, and while waiting between call attempts.
+
+ WARNING:
+ The ATXFER_NULL_TECH conditional is a hack to fix the problem. It will
+ replace the party B channel technology with a NULL channel driver to
+ complete hanging up the party B channel technology. The consequences
+ of
+ this code is that the 'h' extension will not be able to access any
+ channel
+ technology specific information like SIP statistics for the call.
+
+ ATXFER_NULL_TECH is not defined by default.
+ **********
+
+ (closes issue 0017999)
+ Reported by: iskatel
+ Tested by: rmudgett
+ JIRA SWP-2246
+
+ (closes issue 0017096)
+ Reported by: gelo
+ Tested by: rmudgett
+ JIRA SWP-1192
+
+ (closes issue 0018395)
+ Reported by: shihchuan
+ Tested by: rmudgett
+
+ (closes issue 0017273)
+ Reported by: grecco
+ Tested by: rmudgett
+
+ Review: https://reviewboard.asterisk.org/r/1047/ [^]
+
+ ------------------------------------------------------------------------
+
+2011-01-14 Leif Madsen <lmadsen at digium.com>
+
[... 31078 lines stripped ...]
More information about the asterisk-commits
mailing list