(closes issue #13334)
Reported by: srt
Patches:
      13334_missing_event_header_in_core_show_channel.diff uploaded by srt (license 378)


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

Reloading the config and having no changes still initialized some settings to 0. Initialize settings after doing all of the cfg checks.

(closes issue #13942)
Reported by: davidw
Patches: 
      cdr_diff.txt uploaded by otherwiseguy (license 396)
Tested by: davidw


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

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

........
r158306 | mmichelson | 2008-11-21 09:24:19 -0600 (Fri, 21 Nov 2008) | 5 lines

This change had somehow gotten reverted due to a
completely unrelated commit. Thanks to Theo Belder
on the Asterisk-dev list for pointing this out.


........


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

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

for this sscanf statement. Thanks Richard!



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

on 32-bit systems, so we need to use %llu instead. Of course
%llu is 128-bits on 64-bit systems, so we have to cast to
unsigned long long. No harm, but it's sure annoying.



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

from an int to a uint64_t. This prevents potential comparison
problems from happening if the version string exceeds
INT_MAX. This was an apparent problem for one user who could
not properly place a call on hold since the version in the
SDP of the re-INVITE to place the call on hold greatly 
exceeded INT_MAX.

This also aligns with RFC 2327 better since it recommends
using an NTP timestamp for the version (which is a 
64-bit number).


(closes issue #13531)
Reported by: sgofferj
Patches:
      13531.patch uploaded by putnopvut (license 60)
Tested by: sgofferj



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

a comma.  This was causing problems with switch statements with empty expressions.

(closes issue #13901)
Reported by: smurfix
Patches:
      20081118_bug13901.diff uploaded by seanbright (license 71)
Tested by: seanbright
Reviewed by: murf


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

https://origsvn.digium.com/svn/asterisk/trunk

........
r158072 | twilson | 2008-11-20 11:48:58 -0600 (Thu, 20 Nov 2008) | 2 lines

Begin on a crusade to end trailing whitespace!

........


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

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

........
r158071 | mmichelson | 2008-11-20 11:48:42 -0600 (Thu, 20 Nov 2008) | 16 lines

We don't handle 4XX responses to BYE well. According to
section 15 of RFC 3261, we should terminate a dialog if we
receive a 481 or 408 in response to our BYE. Since I am aware
of at least one phone manufacturer who may sometimes send a 
404 as well, I am being liberal and saying that any 4XX response
to a BYE should result in a terminated dialog.


(closes issue #12994)
Reported by: pabelanger
Patches:
      12994.patch uploaded by putnopvut (license 60)

Closes AST-129


........


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

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

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

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

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

........
r158053 | mmichelson | 2008-11-20 11:33:06 -0600 (Thu, 20 Nov 2008) | 12 lines

Make sure to set the hangup cause on the calling channel in the case
that ast_call() fails. For incoming SIP channels, this was causing
us to send a 603 instead of a 486 when the call-limit was reached on
the destination channel.

(closes issue #13867)
Reported by: still_nsk
Patches:
      13867.diff uploaded by putnopvut (license 60)
Tested by: blitzrage


........


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

Reported by: snyfer

This handles the case for a zero length file to attempt to be streamed. Instead of failing from not playing any data, go ahead and return success as ast_streamfile should consider playing nothing a success when there is nothing to play.



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

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

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

........
  r157859 | kpfleming | 2008-11-19 15:34:47 -0600 (Wed, 19 Nov 2008) | 7 lines
  
  the gcc optimizer frequently finds broken code (use of uninitalized variables, unreachable code, etc.), which is good. however, developers usually compile with the optimizer turned off, because if they need to debug the resulting code, optimized code makes that process very difficult. this means that we get code changes committed that weren't adequately checked over for these sorts of problems.
  
  with this build system change, if (and only if) --enable-dev-mode was used and DONT_OPTIMIZE is turned on, when a source file is compiled it will actually be preprocessed (into a .i or .ii file), then compiled once with optimization (with the result sent to /dev/null) and again without optimization (but only if the first compile succeeded, of course).
  
  while making these changes, i did some cleanup work in Makefile.rules to move commonly-used combinations of flag variables into their own variables, to make the file easier to read and maintain
........


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

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

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

'queue remove member'



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

res_timing_timerfd



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

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

as an unsigned long long on a 64-bit machine.

Reported by kpfleming on IRC



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

querying realtime from the dialplan a little more consistent and easy to use.
The original REALTIME function is preserved, for those who are already
accustomed to that interface.
(closes issue #13651)
 Reported by: Corydon76
 Patches: 
       20081119__bug13651__2.diff.txt uploaded by Corydon76 (license 14)
 Tested by: blitzrage, Corydon76


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

This provides a new timing interface. In order to use it,
you must be running a Linux with a kernel version of
2.6.25 or newer and glibc 2.8 or newer.

This timing interface is a good alternative if a timing
source is necessary (e.g. for IAX trunking) but DAHDI is
otherwise unnecessary for the system.

For now, this commit contains the actual work done in the
res_timing_timerfd branch. There are no notices in the README
or CHANGES files yet, but they will be added in my next commit.

The timing API of Asterisk also needs to have a bit of work done
with regards to choosing which timing interface to use. This commit
makes the choice a build-time decision, by only allowing one of
the timer interfaces to be chosen in menuselect. It would be preferable
if the choice could be made at run-time, however. The preferred timing
interface could be loaded and tested, and if it does not work, choice
number two may be used instead. That sort of thing. That is beyond
the scope of work in this branch though.



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

Fix checking for CONFIG_STATUS_FILEINVALID so that modules don't crash upon trying to parse an invalid config


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

(closes issue #13473)
 Reported by: genie
 Patches: 
       20080916__bug13473.diff.txt uploaded by Corydon76 (license 14)


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

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

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

make some corrections to the ast_agi_register_multiple(), ast_agi_unregister_multiple() and ast_agi_fdprintf() API calls to be consistent with API guidelines

also, move UPGRADE.txt to UPGRADE-1.6.txt and make the new UPGRADE.txt contain information about upgrading between Asterisk 1.6 releases



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

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

in 1.6.1 (as compared to 1.6.0 and versions of 1.4), this change also
deprecates the use of Asterisk with FreeBSD 4, given the central use of va_copy
in core functions.  va_copy() is C99, anyway, and we already require C99 for
other purposes, so this isn't really a big change anyway.  This change also
simplifies some of the core ast_str_* functions.


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

else Asterisk will crash when attempting to dereference the NULL
pointer

(closes issue #13858)
Reported by: eliel
Patches:
      astmm.c.patch uploaded by eliel (license 64)



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

configure instead of the icky loop I was doing before).

(closes issue #13842)
Reported by: snuffy
Patches:
      bug13842_20081106.diff uploaded by snuffy (license 35)
      13842.diff uploaded by seanbright (license 71)
Tested by: snuffy


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

is unloaded and then Asterisk is stopped. The problem was that
we are not unregistering the ast_moh_destroy function at exit.

(closes issue #13761)
Reported by: eliel
Patches:
      res_musiconhold.c.patch uploaded by eliel (license 64)



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

target of the Makefile.

(closes issue #13875)
Reported by: pabelanger
Patches:
      Makefile.155928 uploaded by pabelanger (license 224)



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

is in use so that the message is deleted from both
local and IMAP storage.

(closes issue #13642)
Reported by: jaroth
Patches:
      deleteyes.patch uploaded by jaroth (license 50)




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

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

........
r157503 | mmichelson | 2008-11-18 16:47:57 -0600 (Tue, 18 Nov 2008) | 13 lines

Add some missing invite state changes necessary in the sip_write
function. Not setting the invite state correctly on the call was
resulting in the Record application leaving empty files. I also
have updated the doxygen comment next to the declaration of the
INV_EARLY_MEDIA constant to reflect that we also use this state
when we *send* a 18X response to an INVITE.

(closes issue #13878)
Reported by: nahuelgreco
Patches:
      sip-early-media-recording-1.4.22.patch uploaded by nahuelgreco (license 162)
	  Tested by: putnopvut

........


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

changed from using a global lock in update_call_counter to
using the locks within the sip_pvt and sip_peer structures
instead.



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