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
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91192 | russell | 2007-12-05 11:31:42 -0600 (Wed, 05 Dec 2007) | 10 lines
Make the lock in the threadstorage debugging code untracked to avoid a deadlock
on thread destruction.
(closes issue #11207)
Reported by: ys
Patches:
threadstorage.c.diff uploaded by ys (license 281)
Also fixes an open bug report: (closes issue #11446)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91197 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91070 | russell | 2007-12-04 18:35:31 -0600 (Tue, 04 Dec 2007) | 11 lines
Fix some crashes in chan_iax2 that were reported as happening on Mac systems.
It turns out that the problem was the Mac version of the ast_atomic_fetchadd_int()
function. The Mac atomic add function returns the _new_ value, while this function
is supposed to return the old value. So, the crashes happened on unreferencing
objects. If the reference count was decreased to 1, ao2_ref() thought that it
had been decreased to zero, and called the destructor. However, there was still
an outstanding reference around.
(closes issue #11176)
(closes issue #11289)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91114 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r91074 | russell | 2007-12-04 18:48:47 -0600 (Tue, 04 Dec 2007) | 4 lines
When DEBUG_THREADS is enabled, we only have the details about who is holding
a lock that we are waiting on for a mutex, not rwlocks. This should fix the
problem where people have reported "core show locks" crashing sometimes.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91077 f38db490-d61c-443f-a65b-d21fe96a405b
........
r91032 | russell | 2007-12-04 17:46:40 -0600 (Tue, 04 Dec 2007) | 5 lines
Modify file.h to maintain API compatibility with earlier versions. If a recent
compiler is being used, then a warning will show up for any modules still using
the old name "private" instead of "_private".
(patch suggested by paravoid)
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91033 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90967 | russell | 2007-12-04 13:57:39 -0600 (Tue, 04 Dec 2007) | 7 lines
Make some changes to some additions I made recently for doing channel autoservice
when looking up extensions. This code was added to handle the case where a
dialplan switch was in use that could block for a long time. However, the way
that I added it, it did this for all extension lookups. However, lookups in the
in-memory tree of extensions should _not_ take long enough to matter. So, move
the autoservice stuff to be only around executing a switch.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@91011 f38db490-d61c-443f-a65b-d21fe96a405b
This introduces two new options for zapata.conf: mwimonitor and mwimonitornotify.
The mwimonitor option enables MWI monitoring. When the MWI state on a line changes,
then the script specified by mwimonitornotify will be executed for custom handling
of the state change, similar to the externnotify option of voicemail.conf.
Also, when the MWI state on an FXO line changes, an internal Asterisk event is
generated to indicate the new state of the associated mailbox. That may, any
module that cares about MWI information will get notified and can handle it
just as if app_voicemail had sent this notification.
(BE-253, original patch from markster, with some minor modifications by me to
add comments, documentation, and internal event support)
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@90949 f38db490-d61c-443f-a65b-d21fe96a405b
does not modify the contents of the "mailbox" string. In other words, I'm changing
the imap_retrieve_file function to take a const char* as the third argument so that I
don't need to cast const char*'s as char*'s to suppress compiler warnings.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@90930 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r90735 | mmichelson | 2007-12-03 17:12:17 -0600 (Mon, 03 Dec 2007) | 22 lines
A big one...
This is the merge of the forward-loop branch. The main change here is that call-forwards can no longer loop.
This is accomplished by creating a datastore on the calling channel which has a linked list of all devices
dialed. If a forward happens, then the local channel which is created inherits the datastore. If, through this
progression of forwards and datastore inheritance, a device is attempted to be dialed a second time, it will simply
be skipped and a warning message will be printed to the CLI. After the dialing has been completed, the datastore
is detached from the channel and destroyed.
This change also introduces some side effects to the code which I shall enumerate here:
1. Datastore inheritance has been backported from trunk into 1.4
2. A large chunk of code has been removed from app_dial. This chunk is the section of code
which handles the call forward case after the channel has been requested but before it has
been called. This was removed because call-forwarding still works fine without it, it makes the
code less error-prone should it need changing, and it made this set of changes much less painful
to just have the forwarding handled in one place in each module.
3. Two new files, global_datastores.h and .c have been added. These are necessary since the datastore
which is attached to the channel may be created and attached in either app_dial or app_queue, so they
need a common place to find the datastore info. This approach was taken in case similar datastores are
needed in the future, there will be a common place to add them.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@90873 f38db490-d61c-443f-a65b-d21fe96a405b