........
r188901 | mmichelson | 2009-04-17 08:29:33 -0500 (Fri, 17 Apr 2009) | 28 lines
Several fixes to the extenpatternmatchnew logic.
1. Differentiate between literal characters in an extension
and characters that should be treated as a pattern match. Prior to
these fixes, an extension such as NNN would be treated as a pattern,
rather than a literal string of N's.
2. Fixed the logic used when matching an extension with a bracketed
expression, such as 2[5-7]6.
3. Removed all areas of code that were executed when NOT_NOW was
#defined. The code in these areas had the potential to crash, for
one thing, and the actual intent of these blocks seemed counterproductive.
4. Fixed many many coding guidelines problems I encountered while looking
through the corresponding code.
5. Added failure cases and warning messages for when duplicate extensions
are encountered.
6. Miscellaneous fixes to incorrect or redundant statements.
(closes issue #14615)
Reported by: steinwej
Tested by: mmichelson
Review: http://reviewboard.digium.com/r/194/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r188647 | dvossel | 2009-04-15 17:10:04 -0500 (Wed, 15 Apr 2009) | 18 lines
Merged revisions 188646 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r188646 | dvossel | 2009-04-15 17:08:40 -0500 (Wed, 15 Apr 2009) | 12 lines
National prefix inserted even when caller ID not available
When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank.
(closes issue #13207)
Reported by: shawkris
Patches:
national_prefix.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/220/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r188544 | mmichelson | 2009-04-15 10:24:50 -0500 (Wed, 15 Apr 2009) | 9 lines
Make the cancellation of the dial timeout on a call forward optional.
This introduces the 'z' option to app_dial. With it set, a call forward
will cancel any timeout originally set for this instance of the Dial
application.
AST-207
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r188342 | jpeeler | 2009-04-14 10:54:16 -0500 (Tue, 14 Apr 2009) | 33 lines
Add service maintenance message support
This is the companion commit to libpri r732. Service messages are now supported
for switch types 4ess/5ess. A new option service_message_support has been added
to chan_dahdi.conf and is noted in the sample config file. The service message
support is turned off by default. The current implementation relies on AstDB
to keep track of channel state, which allows the statuses to be preserved
across Asterisk restarts. Below is a description of the storage format.
The state and reason for the service state are in the form <state>:<reason>,
where:
<state> ::= { 'O' } // 'O' – Out Of Service
<reason> ::= { '0' | '1' | '2' | '3' }, where:
'0' – No reason (backwards compatibility)
'1' – NEAR END
'2' – FAR END
'3' – both NEAR and FAR END
The new CLI commands to handle channel service state are:
pri service disable channel <chan>
pri service enable channel <chan>
Many people contributed to the development of this functionality. Because I
entered at the very end I do not know the exact history. Special thanks to
all who moved the bug forward one way or another:
cmaj, PCadach, markster, mattf, drmac, MikeJ, serge-v, murf, kanelbullar, Seb7,
tilghman, lmadsen, and especially dhubbard (he answered lots of my questions
and did a large portion of the work)
(closes issue #3450)
Reported by: cmaj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188247 | file | 2009-04-14 10:14:21 -0300 (Tue, 14 Apr 2009) | 7 lines
Fix a bug with the change I made yesterday to outbound proxy support.
Per discussion with oej on IRC we need the actual IP address, not the
outbound proxy IP address, in the sa field. This change matches the already
existing code for all other uses of the outbound proxy setting.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188067 | file | 2009-04-13 13:28:06 -0300 (Mon, 13 Apr 2009) | 10 lines
Fix a bug where using an outbound proxy would cause the local address to be 127.0.0.1.
Copy the outbound proxy IP address into the SIP dialog structure as the IP address we will
be sending to. This has to be done because the logic that determines what local IP address to use
in the SIP messages is not aware of an outbound proxy being in place. It only knows what IP address
we are sending to.
(closes issue #12006)
Reported by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188032 | mmichelson | 2009-04-13 09:17:56 -0500 (Mon, 13 Apr 2009) | 6 lines
Set all queue variables on both the caller and member channels.
This allows for the variables to be accessed if a member macro is run.
Thanks to Grigoriy Puzankin for bringing this up on the -dev list.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@188037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r187906 | jpeeler | 2009-04-10 15:26:46 -0500 (Fri, 10 Apr 2009) | 12 lines
Fix module embedding for chan_h323.
Include libchanh323.a in the modules.link file so that all the symbols can be
resolved at link time.
(closes issue #11966)
Reported by: dome
Patches:
issue_11966.patch uploaded by kpfleming (license 421)
Tested by: jpeeler
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r187636 | kpfleming | 2009-04-10 10:11:16 -0500 (Fri, 10 Apr 2009) | 3 lines
revert addition of LOG_SECURITY log channel; after further discussion, a much better solution will be used
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r187560 | mmichelson | 2009-04-09 16:06:26 -0500 (Thu, 09 Apr 2009) | 11 lines
Add a new option, mwi_from, to sip.conf.
This allows for you to change the From header for outgoing MWI
NOTIFY requests. Prior to this, the best you could do was to
set a callerid in the general section of sip.conf. The problem
was that this was used for all outbound requests, not just
MWI NOTIFY requests.
AST-201
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187561 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A note to all of you. Don't block revisions in a branch if you actually
meant to merge them. Two very old revisions somehow didn't get merged into
1.6.0 and this change was dependent on those two old revisions. What should have
taken 2 minutes has now wasted about 30 minutes of my time :(
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187555 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r141810 | mmichelson | 2008-09-08 16:18:49 -0500 (Mon, 08 Sep 2008) | 22 lines
Merged revisions 141809 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r141809 | mmichelson | 2008-09-08 16:10:10 -0500 (Mon, 08 Sep 2008) | 14 lines
Fix pedantic mode of chan_sip to only check the
remote tag of an endpoint once a dialog has
been confirmed. Up until that point, it is possible
and legal for the far-end to send provisional
responses with a different To: tag each time. With
this patch applied, these provisional messages
will not cause a matching problem.
(closes issue #11536)
Reported by: ibc
Patches:
11536v2.patch uploaded by putnopvut (license 60)
........
................
r141868 | mmichelson | 2008-09-08 17:14:40 -0500 (Mon, 08 Sep 2008) | 4 lines
Um, apparently I didn't actually finish merging before committing.
Bad bad bad
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187554 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r187491 | jpeeler | 2009-04-09 14:10:02 -0500 (Thu, 09 Apr 2009) | 15 lines
Add ability for dialplan execution to continue when caller hangs up.
The F option to app_dial has been modified to accept no parameters and perform
the above functionality. I don't see anywhere else that is doing function
overloading, but this really is the best place for this operation because:
- It makes it close to the 'g' option in the argument list which provides
similar functionality.
- The existing code to support the current F option provides a very
convienient location to add this new feature.
(closes issue #12381)
Reported by: michael-fig
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r187421 | mmichelson | 2009-04-09 12:30:39 -0500 (Thu, 09 Apr 2009) | 21 lines
Fix a crash in res_musiconhold when using cached realtime moh.
The moh_register function links an mohclass and then immediately
unrefs the class since the container now has a reference. The problem
with using realtime music on hold is that the class is allocated,
registered, and started in one fell swoop. The refcounting logic
resulted in the count being off by one. The same problem did not
happen when using a static config because the allocation and registration
of an mohclass is a separate operation from starting moh. This also did
not affect non-cached realtime moh because the classes are not registered
at all.
I also have modified res_musiconhold to use the _t_ variants of the ao2_
functions so that more info can be gleaned when attempting to trace the
refcounts. I found this to be incredibly helpful for debugging this issue
and there's no good reason to remove it.
(closes issue #14661)
Reported by: sum
........
r187424 | mmichelson | 2009-04-09 12:34:39 -0500 (Thu, 09 Apr 2009) | 3 lines
Use safe macro practices even though they really aren't necessary.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r187269 | kpfleming | 2009-04-08 22:44:27 -0400 (Wed, 08 Apr 2009) | 5 lines
add a dedicated log channel for modules to be able report security-related events, so that they can be fed into external processes for analysis and possible mitigation efforts
(inspired by this evening's Toronto Asterisk Users Group meeting and previous dicussions amongst various community members)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187270 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r187211 | jpeeler | 2009-04-08 16:00:39 -0500 (Wed, 08 Apr 2009) | 20 lines
Add timer for features so that backup bridge config can go away
The biggest change done here was elimination of the backup_config for use with
features. Previously, the bridging code upon detecting a feature would set the
start time of the bridge to the start time of the feature. Then after the
feature had either expired or timed out the start time would be reset to the
true bridge start time from the backup_config. Now, the time differences are
calculated with respect to the newly added feature_start_time timeval instead.
There should be no behavior changes from the previous functionality aside from
the bridge timing being unaffected by either valid or partial feature matches.
Previously the timing would be increased by the length of time configured for
featuredigittimeout, which was probably never noticed.
(closes issue #14503)
Reported by: KNK
Tested by: jpeeler
Review: http://reviewboard.digium.com/r/179/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r187046 | mmichelson | 2009-04-08 11:52:20 -0500 (Wed, 08 Apr 2009) | 16 lines
Merged revisions 187045 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r187045 | mmichelson | 2009-04-08 11:52:03 -0500 (Wed, 08 Apr 2009) | 10 lines
Fix a small logical error when loading moh classes.
We were unconditionally incrementing the number of mohclasses
registered. However, we should actually only increment if the
call to moh_register was successful.
While this probably has never caused problems, I noticed it
and decided to fix it anyway.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@187047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Thanks to thehar for reporting this for me. I noticed this at about 1:00am last night and just wanted to go to bed.
(closes issue #14853)
Reported by: thehar
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@186990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186985 | mmichelson | 2009-04-08 10:27:41 -0500 (Wed, 08 Apr 2009) | 30 lines
Merged revisions 186984 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186984 | mmichelson | 2009-04-08 10:26:46 -0500 (Wed, 08 Apr 2009) | 24 lines
Make a couple of changes with regards to a new message printed in ast_read().
"ast_read() called with no recorded file descriptor" is a new message added
after a bug was discovered. Unfortunately, it seems there are a bunch of places
that potentially make such calls to ast_read() and trigger this error message
to be displayed. This commit does two things to help to make this message appear
less.
First, the message has been downgraded to a debug level message if dev mode is
not enabled. The message means a lot more to developers than it does to end users,
and so developers should take an effort to be sure to call ast_read only when
a channel is ready to be read from. However, since this doesn't actually cause an
error in operation and is not something a user can easily fix, we should not spam
their console with these messages.
Second, the message has been moved to after the check for any pending masquerades.
ast_read() being called with no recorded file descriptor should not interfere with
a masquerade taking place.
This could be seen as a simple way of resolving issue #14723. However, I still want
to try to clear out the existing ways of triggering this message, since I feel that
would be a better resolution for the issue.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@186986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186833 | mmichelson | 2009-04-07 18:50:56 -0500 (Tue, 07 Apr 2009) | 15 lines
Merged revisions 186832 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186832 | mmichelson | 2009-04-07 18:49:49 -0500 (Tue, 07 Apr 2009) | 8 lines
Set the AST_FEATURE_WARNING_ACTIVE flag when a p2p bridge returns AST_BRIDGE_RETRY.
Without this flag set, warning sounds will not be properly played to either party
of the bridge.
(closes issue #14845)
Reported by: adomjan
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@186834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r186620 | mmichelson | 2009-04-06 11:06:25 -0500 (Mon, 06 Apr 2009) | 3 lines
Silly svn. These files didn't get merged over in the merge of the issue8824 branch.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.0@186621 65c4cc65-6c06-0410-ace0-fbb531ad65f3
