of DESTDIR and INSTALL_PATH - many thanks to Tzafrir Cohen and
Simon Perreault for extremely useful feedback:
1. comment out the [directories] section the created asterisk.conf ;
you can set the correct defaults at build time using INSTALL_PATH,
so the repetition here is redundant and often wrong.
(The next step now is move asterisk.conf outside the Makefile to
asterisk.conf.sample, because there is little if anything here
that needs to be constructed at build/install time).
2. use DESTDIR?=$(INSTALL_PATH) so you only need to specify a path
once if the two coincide. This should have no ill side effects,
because if you don't specify DESTDIR, you really need
INSTALL_PATH="" to set the correct defaults, and if you specify
DESTDIR the value is not overridden.
The second part required moving the 'export DESTDIR' right after
the assignment to prevent DESTDIR getting set by the export
(this is documented in the Makefile).o hopefully avoid the mistake)$
With this change you can now do something like this from your source tree:
make INSTALL_PATH=/some/place install samples
and then
main/asterisk -vdc
which will pick up the correct config files and libraries from
/some/place - i.e. great for developers!
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@92002 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91830 | russell | 2007-12-07 15:24:33 -0600 (Fri, 07 Dec 2007) | 5 lines
Make the lock protecting each thread's list of locks it currently holds
recursive. I think that this will fix the situation where some people have
said that "core show locks" locks up the CLI.
(related to issue #11080)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91831 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91828 | russell | 2007-12-07 15:17:24 -0600 (Fri, 07 Dec 2007) | 6 lines
Fix another bug in the DEBUG_THREADS code. The ast_mutex_init() function had
the mutex attribute object marked as static. This means that multiple threads
initializing locks at the same time could step on each other and end up with
improperly initialized locks.
(found when tracking down locking issues related to issue #11080)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91829 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91826 | russell | 2007-12-07 15:11:08 -0600 (Fri, 07 Dec 2007) | 6 lines
I love fixing lock related errors in the lock debugging code. That's about as
ironic as it gets in Asterisk programming land. Anyway, I spotted this bug while
trying to track down why systems are locking up and acting weird in issue #11080.
The mutex attribute object was marked as static in this function when it should
not have been.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91827 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91783 | russell | 2007-12-07 10:38:48 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add channel locking around datastore operations that expect the channel
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Remove the dialed variable as it isn't needed.
* Restructure some code for clarity and coding guidelines stuff
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91784 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91780 | russell | 2007-12-07 10:25:25 -0600 (Fri, 07 Dec 2007) | 7 lines
* Add channel locking around datastore operations that expect the channel
to be locked.
* Document why we don't record Local channels in the dialed interfaces list.
* Handle memory allocation failure.
* Remove the dialed variable, as it wasn't actually needed.
* Tweak some formatting to conform to coding guidelines.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91781 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91777 | russell | 2007-12-07 10:08:35 -0600 (Fri, 07 Dec 2007) | 6 lines
* Add a bit more of a verbose comment as to why a hangup frame needs to be
queued up if autoservice gets a NULL return from ast_read().
* Make the process of queueing the hangup frame more efficient by putting the
frame where it is going to end up and avoiding some locking and extra memory
allocations and freeing.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91778 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91737 | mmichelson | 2007-12-07 09:39:58 -0600 (Fri, 07 Dec 2007) | 7 lines
Hangups that happen during autoservice were not processed appropriately. This is
because a hangup actually causes a NULL frame to be received, not a hangup frame.
Queueing a hangup if we receive a NULL frame during autoservice corrects this problem
(closes issue #11467, reported by jmls, patched by me)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91738 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91677 | russell | 2007-12-06 20:38:40 -0600 (Thu, 06 Dec 2007) | 4 lines
Allow dialing local channels from Queue() and Dial() again. There was a slight
flaw in the code to prevent call forwards from looping that caused this problem.
(related to issue #11486)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91678 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91675 | russell | 2007-12-06 20:19:45 -0600 (Thu, 06 Dec 2007) | 7 lines
Fix in an issue in the call forwarding handling code that was causing crashes
on every call into a queue. I'm not entirely sure about the logic in this part
of the code, so I want to look at it some more tomorrow. However, this makes
it safe and keeps it from crashing.
(closes issue #11486, reported by adamg, patched by me)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91676 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91637 | tilghman | 2007-12-06 18:52:17 -0600 (Thu, 06 Dec 2007) | 5 lines
At the end of a call, when we're reporting, RTCP may already be partially torn down, so check for NULL dereference
Reported by: blitzrage
Patch by: tilghman
(Closes issue #11450)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91638 f38db490-d61c-443f-a65b-d21fe96a405b
........
r91501 | russell | 2007-12-06 13:11:35 -0600 (Thu, 06 Dec 2007) | 5 lines
Add a new module flag to indicate that a build sum is present. Modules built
against older Asterisk 1.4 headers will now load properly with just a warning
indicating that they are old and may cause problems.
(patch by paravoid)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91502 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91450 | file | 2007-12-06 12:49:42 -0400 (Thu, 06 Dec 2007) | 6 lines
Fix various in the udptl implementation. It could return empty modem frames, have an incorrect sequence number on packets, and display the wrong sequence number in the debug messages.
(closes issue #11228)
Reported by: Cache
Patches:
udptl-4.patch uploaded by dimas (license 88)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91458 f38db490-d61c-443f-a65b-d21fe96a405b
- Now use Response: success
- New header "Ping: pong" :-)
- The Events action
- Now use Response: Success
- The new status is reported as "Events: On" or "Events: Off"
- Report if manager is enabled in the reload event
Small cleanups...
From moremanager
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91420 f38db490-d61c-443f-a65b-d21fe96a405b
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate and Newchannel events
- these have changed headers
"State" -> ChannelStateDesc Text based channel state
-> ChannelState Numeric channel state
- The events does not send "<unknown>" for unknown caller IDs just an empty field
- Newstate event
- Now has "CalleridNum" for numeric caller id, like Newchannel
- The event does not send "<unknown>" for unknown caller IDs just an empty field
- Link and Unlink events
- The "Link" and "Unlink" bridge events in channel.c are now renamed to "Bridge"
- The link state is in the bridgestate: header as "Link" or "Unlink"
- For channel.c bridges, "Bridgetype: core" is added. This opens up for
bridge events in rtp.c and channel drivers
- The "Rename" manager event has a renamed header, to use the same
terminology for the current channel as other events
- Oldname -> Channel
(Moremanager)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91409 f38db490-d61c-443f-a65b-d21fe96a405b
Maybe belongs in the new cdr category?
---moremanager---
Event: NewAccountCode
Modules: cdr.c
Purpose: To report a change in account code for a live channel
Example:
Event: NewAccountCode
Privilege: call,all
Channel: SIP/olle-01844600
Uniqueid: 1177530895.2
AccountCode: Stinas account 1234848484
OldAccountCode: Olles Account 12345
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91408 f38db490-d61c-443f-a65b-d21fe96a405b
- Event Dial has new headers, to comply with other events
- Source -> Channel Channel name (caller)
- SrcUniqueID -> UniqueID Uniqueid
(new) -> Dialstring Dialstring in app data
(moremanager)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91407 f38db490-d61c-443f-a65b-d21fe96a405b
Action ZapShowChannels
Header changes
- Channel: -> ZapChannel
For active channels, the Channel: and Uniqueid: headers are added
You can now add a "ZapChannel: " argument to zapshowchannels actions
to only get information about one channel.
From the moremanager branch
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91386 f38db490-d61c-443f-a65b-d21fe96a405b
Thanks, eliel, for writing the original patch. Modified by me to follow
other manager events and the new "moremanager" style.
(closes issue #11478)
Reported by: eliel
Patches:
manager.c.patch uploaded by eliel (license 64)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91347 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91273 | mmichelson | 2007-12-05 16:35:52 -0600 (Wed, 05 Dec 2007) | 11 lines
The 'G' option for Dial() did not properly handle the case where only a label was
provided. This was due to the fact that the answering channel did not have an extension
set, so ast_parseable_goto would fail. This fix eliminates the call to ast_parseable_goto
on the answering channel since it is a wasteful call. The answering channel and the calling
channel are both directed to the same extension and context, just different priorities, so
we can just copy the values from the calling channel to the answering channel and increment
the answering channel's priority.
(closes issue #11382, reported by jon, patch by me with correction by jon)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91291 f38db490-d61c-443f-a65b-d21fe96a405b
rizzo