(closes issue #17215)
 Reported by: vazir
 Patches: 
       20100518__issue17215.diff.txt uploaded by tilghman (license 14)
 Tested by: tilghman


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272260 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272259 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r272255 | pabelanger | 2010-06-23 16:57:01 -0400 (Wed, 23 Jun 2010) | 12 lines
  
  First caller into a dynamic conference now enter pin once.
  
  If MeetMe is configured to use dynamic conference
  numbers, then the first caller (which creates the
  conference) had to enter the PIN number twice.
  
  (closes issue #15878)
  Reported by: shawkris
  Patches:
        issue15878.patch uploaded by pabelanger (license 224)
  Tested by: pabelanger
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272257 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272256 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #16991)
Reported by: pprindeville
Patches: 
      with_netsnmp.patch.txt uploaded by twilson (license 396)
Tested by: twilson

Review: https://reviewboard.asterisk.org/r/739/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272254 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17520)
Reported by: kobaz
Patches:
      manager.patch uploaded by kobaz (license 834)
Tested by: lmadsen


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272252 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17548)
Reported by: cjacobsen
Patches:
      say.conf.sample.diff uploaded by cjacobsen (license 1029)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272243 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This command lets you request a "/n" local channel
optimize itself out of the way anyway.

Review: https://reviewboard.asterisk.org/r/732/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272218 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272150 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r272147 | tilghman | 2010-06-23 13:40:28 -0500 (Wed, 23 Jun 2010) | 5 lines
  
  Backport part of revision 136715 to fix callerid in voicemail text files (IMAP only).
  
  (closes issue #16945)
   Reported by: mneuhauser
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272148 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272146 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17144)
 Reported by: nahuelgreco
 Patches: 
       20100513__issue17144__trunk.diff.txt uploaded by tilghman (license 14)
 Tested by: tilghman


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272145 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Even if there are no stations or trunks defined, we need to start the sla
thread to make sure we get the reload event. Also, when doing a reload we need
to remove the existing trunks and stations or they end up hanging around.

(closes issue #16818)
Reported by: mbonin
Patches: 
      sla_reload.patch uploaded by twilson (license 396)
Tested by: twilson


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272109 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.

The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.

The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272090 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This small changes prevents destroy_all_channels() from accessing a lock on an
unused dahdi_pri struct, resolving a ton of ERRORs that get spewed out when
shutting Asterisk down gracefully.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272052 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17440)
Reported by: kobaz


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272014 65c4cc65-6c06-0410-ace0-fbb531ad65f3

RFC 3261 section 9 states that a CANCEL has no effect on a
request to a UAS that has already given a final response.  This
patch checks to make sure there is a pending invite before
allowing a CANCEL request to be processed, otherwise it responds
to the CANCEL with a "481 Call/Transaction Does Not Exist".

Review: https://reviewboard.asterisk.org/r/697/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271977 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This fixes a ref count leak in event filters and checks for
a filter container allocation failure during session creation.



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271905 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271902 | mnicholson | 2010-06-22 12:31:57 -0500 (Tue, 22 Jun 2010) | 8 lines
  
  Decrease the module ref count in sip_hangup when SIP_DEFER_BYE_ON_TRANSFER is set.  This is necessary to keep the ref count correct.
  
  (closes issue #16815)
  Reported by: rain
  Patches:
        chan_sip-unref-fix.diff uploaded by rain (license 327) (modified)
  Tested by: rain
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271903 65c4cc65-6c06-0410-ace0-fbb531ad65f3

This patch as documented in the sample config allows one to optionally apply
white, black, or both types of filtering to manager events. The new
'eventfilter' option is set per user.

(closes issue #14861)
Reported by: fnordian
Patches: 
      eventfilter3.patch uploaded by fnordian (license 110),
      modified by me

Review: https://reviewboard.asterisk.org/r/673/


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271868 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Don't Finalize() if Initialize() did not succeed.  This resulted in an error
about trying to Finalize() an invalid handle.

Also trim some trailing whitespace while in the area.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271867 65c4cc65-6c06-0410-ace0-fbb531ad65f3

Using this method makes it so res_fax doesn't have to be rebuilt on every
svn update.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271833 65c4cc65-6c06-0410-ace0-fbb531ad65f3

If both the transferer and transferee of a attended transfer hangup before
the new channel picks up, the new channel should be hung up as well as it
has no endpoint to talk to.  This mirrors the expected behavior used in 1.4. 

(closes issue #17444)
Reported by: corruptor



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271831 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271764 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271761 | mnicholson | 2010-06-22 09:49:36 -0500 (Tue, 22 Jun 2010) | 9 lines
  
  Allow users to specify a port for dundi peers.
  
  (closes issue #17056)
  Reported by: klaus3000
  Patches:
        dundi-peerport-patch-trunk.txt uploaded by klaus3000 (license 65)
  Tested by: klaus3000
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271762 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
  
  Modify chan_sip's packet generation api to automatically calculate the Content-Length.  This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated.  This change was made to ensure that the Content-Length is always correct.
  
  (closes issue #17326)
  Reported by: kenner
  Tested by: mnicholson, kenner
  
  Review: https://reviewboard.asterisk.org/r/693/
........


This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271690 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271657 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17534)
Reported by: fabled
Patches:
      speex-wb-sample.diff uploaded by fabled (license 448)


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271625 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271552 | jpeeler | 2010-06-21 15:37:47 -0500 (Mon, 21 Jun 2010) | 7 lines
  
  Do not use sizeof to calculate size of a heap allocated character array.
  
  Change left out from 271399.
  
  (closes issue #16053)
  Reported by: diLLec
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271554 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17437)
Reported by: klaus3000
Patches:
      sip_crash uploaded by dvossel (license 671)
Tested by: klaus3000



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271553 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271551 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #16869)
 Reported by: chappell
 Patches: 
       app_say_counted-20100317.c uploaded by chappell (license 8)
 Tested by: chappell


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271520 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271399 | jpeeler | 2010-06-18 14:28:24 -0500 (Fri, 18 Jun 2010) | 11 lines
  
  Fix crash when parsing some heavily nested statements in AEL on reload.
  
  Due to the recursion used when compiling AEL in gen_prios, all the stack space 
  was being consumed when parsing some AEL that contained nesting 13 levels deep.
  Changing a few large buffers to be heap allocated fixed the crash, although I
  did not test how many more levels can now be safely used.
  
  (closes issue #16053)
  Reported by: diLLec
  Tested by: jpeeler
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271483 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271341 65c4cc65-6c06-0410-ace0-fbb531ad65f3

https://origsvn.digium.com/svn/asterisk/branches/1.4

........
  r271335 | jpeeler | 2010-06-18 13:33:17 -0500 (Fri, 18 Jun 2010) | 13 lines
  
  Eliminate deadlock potential in dahdi_fixup().
  
  (This is a backport of 269307, committed to trunk by rmudgett.)
  
  Calling dahdi_indicate() when the channel private lock is already
  held can cause a deadlock if the PRI lock is needed because
  dahdi_indicate() will also get the channel private lock.  The pri_grab()
  function assumes that the channel private lock is held once to avoid
  deadlock.
  
  (closes issue #17261)
  Reported by: aragon
........


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271336 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271300 65c4cc65-6c06-0410-ace0-fbb531ad65f3

According to RFC 3261 section 17.2.2, which describes non-INVITE server
transaction, when a dialog enters the Completed state it must destroy
the dialog after Timer J (T1*64) fires.  For a BYE transaction Asterisk
terminates the dialog immediately during sip_hangup() when it should be
waiting T1*64 ms.  This results in some odd behavior.  For instance if
Asterisk receives a BYE and transmits a 200ok in response, if the endpoint
never receives the 200ok it will retransmit the BYE to which Asterisk
responds with a "481 Call leg/transaction does not exist" because the
dialog is already gone.

To resolve this I made a function called sip_scheddestroy_final().  This
differs slightly from sip_schedestroy() in that it enables a flag that
will prevent the destruction from ever being rescheduled or canceled
afterwards.  It also prevents the pvt's needdestroy flag from being set
which triggers the destruction of the dialog within the do_monitor thread().
By using this function we are guaranteed destruction will not occur
until the scheduled time.  This allows Asterisk to respond to any possible
retransmits for a dialog after we process the initial BYE request for T1*64 ms.

Other changes: I removed two instances where sip_cancel_destroy is used
right before calling sip_scheddestroy.  sip_scheddestroy always calls
sip_cancel_destroy before scheduling the new destruction so it is completely
unnecessary.

Review: https://reviewboard.asterisk.org/r/694/



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #16153)
Reported by: kfister
Patches:
      16153-1.6.2.0-rc5.patch uploaded by kfister (license 912)
      slin16.sip.patch.1 uploaded by malcolmd (license 924)
Tested by: kfister, malcolmd


git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271261 65c4cc65-6c06-0410-ace0-fbb531ad65f3

(closes issue #17501)
Reported by: fabled
Patches:
      asterisk-trunk-speex-wideband-v2.patch uploaded by fabled (license 448)
Tested by: malcolmd, fabled, dvossel



git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271231 65c4cc65-6c06-0410-ace0-fbb531ad65f3

git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271192 65c4cc65-6c06-0410-ace0-fbb531ad65f3