[svn-commits] lmadsen: tag 1.4.42 r325392 - in /tags/1.4.42: .lastclean .version ChangeLog

SVN commits to the Digium repositories svn-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 svn-commits mailing list