........
r152990 | russell | 2008-10-30 15:46:17 -0500 (Thu, 30 Oct 2008) | 3 lines
Add a todo for a new timing API implementation that would work for Linux systems
as of kernel 2.6.25 and glibc 2.8
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r152887 | russell | 2008-10-30 14:28:06 -0500 (Thu, 30 Oct 2008) | 7 lines
Fix a bug in AST_SCHED_REPLACE_UNREF(). The reference count of the object
_must_ be increased before creating the scheduler entry. Otherwise, you
create a race condition where the reference count may hit zero and the
object can disappear out from under you. This could also would have
incorrectly decreased the reference count in the case that the scheduler
add failed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r152879 | mmichelson | 2008-10-30 14:23:16 -0500 (Thu, 30 Oct 2008) | 7 lines
I just noticed this construct and thought it was
silly to have a bunch of case statements with duplicated
code in each case. Instead, just use the built-in fallthrough
capability of case statements and reduce the code to
a single instance
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r152877 | russell | 2008-10-30 14:21:53 -0500 (Thu, 30 Oct 2008) | 9 lines
Modify the documentation of the sip_registry struct
- Remove a comment that says that the monitor thread is the only one that
ever touches these objects. This is no longer the case with TCP. Also,
I would eventually like to get the scheduler in its own thread, so this
is just a poor assumption to make.
- Note that reference counting of these objects with respect to scheduler
entries is not complete. There are some leaked references when deleting
scheduler entries.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152878 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r152807 | mmichelson | 2008-10-30 11:38:19 -0500 (Thu, 30 Oct 2008) | 6 lines
After seeing another problem in #asterisk stemming from
the low default value of featuredigittimeout, I decided it
was high time to change it. I have changed the default to
2000 ms based on a suggestion from Leif Madsen.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r152646 | mmichelson | 2008-10-29 15:53:53 -0500 (Wed, 29 Oct 2008) | 9 lines
If there was no named defined in a voicemail.conf mailbox
entry, then app_directory would crash when attempting to
read that entry from the file. We now check for the NULL
or empty string properly so that there will be no crash.
(closes issue #13804)
Reported by: bluecrow76
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152605 | murf | 2008-10-28 23:47:13 -0600 (Tue, 28 Oct 2008) | 22 lines
Merged revisions 152538 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152538 | murf | 2008-10-28 23:19:04 -0600 (Tue, 28 Oct 2008) | 14 lines
A little documentation cross-ref between features and
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152536 | murf | 2008-10-28 23:01:00 -0600 (Tue, 28 Oct 2008) | 57 lines
Merged revisions 152535 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152535 | murf | 2008-10-28 22:36:32 -0600 (Tue, 28 Oct 2008) | 46 lines
The magic trick to avoid this crash is not to
try to find the channel by name in the list,
which is slow and resource consuming, but rather
to pay attention to the result codes from the
ast_bridge_call, to which I added the
AST_PBX_NO_HANGUP_PEER_PARKED value, which
now are returned when a channel is parked.
Why? because CDR's aren't generated via parking,
so nothing is needed, but if a transfer occurred,
there are critical things I need.
If you get AST_PBX_KEEPALIVE,
then don't touch the channel pointer.
If you get AST_PBX_NO_HANGUP_PEER, or
AST_PBX_NO_HANGUP_PEER_PARKED, then don't
touch the peer pointer.
Updated the several places where the results
from a bridge were not being properly obeyed,
and fixed some code I had introduced so that
the results of the bridge were not overridden
(in trunk).
All the places that previously tested for
AST_PBX_NO_HANGUP_PEER now have to check for
both AST_PBX_NO_HANGUP_PEER and AST_PBX_NO_HANGUP_PEER_PARKED.
I tested this against the 4 common parking
scenarios:
1. A calls B; B answers; A parks B; B hangs up while A is getting the parking
slot announcement, immediately after being put on hold.
2. A calls B; B answers; A parks B; B hangs up after A has been hung up, but
before the park times out.
3. A calls B; B answers; B parks A; A hangs up while B is getting the parking slot announcement, immediately after being put on hold.
4. A calls B; B answers; B parks A; A hangs up after B has been hung up, but before the park times out.
No crash.
I also ran the scenarios above against valgrind, and accesses looked good.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152369 | tilghman | 2008-10-28 12:07:39 -0500 (Tue, 28 Oct 2008) | 15 lines
Merged revisions 152368 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152368 | tilghman | 2008-10-28 12:04:56 -0500 (Tue, 28 Oct 2008) | 8 lines
Reset all DIAL variables back to blank, in case Dial is called multiple times
per call (which could otherwise lead to inconsistent status reports).
(closes issue #13216)
Reported by: ruddy
Patches:
20081014__bug13216.diff.txt uploaded by Corydon76 (license 14)
Tested by: ruddy
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r152174 | tilghman | 2008-10-27 11:44:55 -0500 (Mon, 27 Oct 2008) | 2 lines
Set ARGC in subroutines with the number of arguments passed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152175 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r152060 | seanbright | 2008-10-26 16:25:08 -0400 (Sun, 26 Oct 2008) | 15 lines
Merged revisions 152059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r152059 | seanbright | 2008-10-26 16:23:36 -0400 (Sun, 26 Oct 2008) | 7 lines
Since passing \0 as the second argument to strchr is valid (and will
match the trailing \0 of a string) we need to check that first, otherwise
we end up with incorrect results. Fix suggested by reporter.
(closes issue #13787)
Reported by: meitinger
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@152068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r151906 | russell | 2008-10-25 06:02:11 -0500 (Sat, 25 Oct 2008) | 16 lines
Merged revisions 151905 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151905 | russell | 2008-10-25 05:59:02 -0500 (Sat, 25 Oct 2008) | 8 lines
Move AMI initialization to occur after loading modules. This prevents a
deadlock when someone tries to initiate a module reload from the AMI just
as Asterisk is starting.
(closes issue #13778)
Reported by: hotsblanc
Fix suggested by hotsblanc
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151600 | mmichelson | 2008-10-22 15:05:14 -0500 (Wed, 22 Oct 2008) | 10 lines
Change some logical ands to bitwise ands and add
messages alerting that a channel is being ignored
if the PROC_DAHDI_NOCHAN option is set in process_dahdi.
(closes issue #13759)
Reported by: smurfix
Patches:
dahdi.patch uploaded by smurfix (license 547)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r151554 | russell | 2008-10-22 12:44:05 -0500 (Wed, 22 Oct 2008) | 2 lines
Fix this check to use the proper variable (the result from get_in_brackets)
........
r151555 | russell | 2008-10-22 12:45:05 -0500 (Wed, 22 Oct 2008) | 2 lines
Print out the right var in the log message
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151464 | mmichelson | 2008-10-21 18:54:41 -0500 (Tue, 21 Oct 2008) | 11 lines
Make the sip_standard_port function more granular by allowing separate
type and port arguments. This is necessary because when building our From
and Contact headers, we need to be absolutely sure that we are placing our
source port there and not the peer's source port.
(closes issue #12761)
Reported by: asbestoshead
Patches:
patch-chan-sip-contact-port.txt uploaded by asbestoshead (license 455)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151513 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151428 | mmichelson | 2008-10-21 18:27:45 -0500 (Tue, 21 Oct 2008) | 14 lines
If a peer uses any transport other than UDP, then MWI will
fail for that peer since sip_alloc will allocate a sip_pvt with
a default transport of UDP. This change resets the socket type
immediately after allocating the sip_pvt in sip_send_mwi_from_peer,
so that the proceeding call to create_addr_from_peer does not fail
right away. The socket data from the peer is properly copied to
the sip_pvt in create_addr_from_peer.
(closes issue #13710)
Reported by: andrew53
Patches:
sip_notify_use_tcp.patch uploaded by andrew53 (license 519)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151420 | mmichelson | 2008-10-21 18:08:56 -0500 (Tue, 21 Oct 2008) | 10 lines
When attempting to resolve hostnames, we need to be sure
to remove any parameters from the string so that name
resolution succeeds.
(closes issue #13727)
Reported by: fnordian
Patches:
resolvewithouturiparameter.patch uploaded by fnordian (license 110)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151421 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151371 | tilghman | 2008-10-21 10:20:50 -0500 (Tue, 21 Oct 2008) | 5 lines
Default file modes should always be full read and write, to allow the system
administrator to make the decision of what permissions will actually be given,
through the use of the process umask.
(Closes issue# 13751)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151372 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r151242 | kpfleming | 2008-10-20 07:59:04 +0300 (Mon, 20 Oct 2008) | 9 lines
Merged revisions 151240 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151240 | kpfleming | 2008-10-20 07:45:56 +0300 (Mon, 20 Oct 2008) | 3 lines
break up acinclude.m4 into individual files, which will make it easier to maintain, easier to add new macros (less patching) and will ease maintenance of these macros across Asterisk branches
........
................
r151243 | kpfleming | 2008-10-20 08:00:56 +0300 (Mon, 20 Oct 2008) | 9 lines
Merged revisions 151241 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r151241 | kpfleming | 2008-10-20 07:57:33 +0300 (Mon, 20 Oct 2008) | 2 lines
rename this macro to properly reflect what it does
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151245 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r151101 | kpfleming | 2008-10-19 22:11:28 +0300 (Sun, 19 Oct 2008) | 13 lines
cleaup of the TCP/TLS socket API:
1) rename 'struct server_args' to 'struct ast_tcptls_session_args', to follow coding guidelines
2) make ast_make_file_from_fd() static and rename it to something that indicates what it really is for (again coding guidelines)
3) rename address variables inside 'struct ast_tcptls_session_args' to be more descriptive (dare i say it... coding guidelines)
4) change ast_tcptls_client_start() to use the new 'remote_address' field of the session args for the destination of the connection, and use the 'local_address' field to bind() the socket to the proper source address, if one is supplied
5) in chan_sip, ensure that we pass in the PP address we are bound to when creating outbound (client) connections, so that our connections will appear from the correct address
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@151135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r150817 | bweschke | 2008-10-17 22:18:33 -0400 (Fri, 17 Oct 2008) | 8 lines
Using the GetVar handler in AMI is potentially dangerous (insta-crash [tm]) when you use a dialplan function that requires a channel and then you don't provide one or provide an invalid one in the Channel: parameter. We'll handle this situation exactly the same way it was handled in pbx.c back on r61766.
We'll create a bogus channel for the function call and destroy it when we're done. If we have trouble allocating the bogus channel then we're not going to try executing the function call at all and run the risk of crashing.
(closes issue #13715)
reported by: makoto
patch by: bweschke
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r150729 | qwell | 2008-10-17 16:35:23 -0500 (Fri, 17 Oct 2008) | 1 line
Merge codec_consistency branch. This should make sample usage much happier.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150730 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r150307 | mmichelson | 2008-10-16 19:13:35 -0500 (Thu, 16 Oct 2008) | 14 lines
After a long discussion on #asterisk-bugs, it seems kind of
odd that a channel would be named after the originating port.
For endpoints that always include ":5060" as part
of the From: header, it will mean that you have a ton of
channels with names like "SIP/5060-3ea38a8b."
I am boldly moving forward with this change in trunk, but I'm
not touching other branches with this one since this definitely
would qualify as a behavior change. If there is a problem with
this commit, and I haven't seen the obvious reason why you'd want
to name the channel after the port from which the call originated,
then please feel free to revert this
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r150309 | jpeeler | 2008-10-16 19:14:19 -0500 (Thu, 16 Oct 2008) | 3 lines
Initialize character arrays as they are not guaranteed to be set.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r150305 | mmichelson | 2008-10-16 18:41:16 -0500 (Thu, 16 Oct 2008) | 14 lines
Merged revisions 150304 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r150304 | mmichelson | 2008-10-16 18:40:54 -0500 (Thu, 16 Oct 2008) | 6 lines
Reverting changes from commits 150298 and 150301 since
I was mistakenly under the assumption that dialplan functions
*always* required that a channel be present. I need to go
home earlier, I think :)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.1@150306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
