https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r315503 | tilghman | 2011-04-26 14:32:50 -0500 (Tue, 26 Apr 2011) | 28 lines
Merged revisions 315502 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315502 | tilghman | 2011-04-26 14:22:52 -0500 (Tue, 26 Apr 2011) | 21 lines
Merged revisions 315501 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315501 | tilghman | 2011-04-26 14:18:46 -0500 (Tue, 26 Apr 2011) | 14 lines
Fix the bounds-checking code.
The code that set the bit within the select bitfield was correct, but the
bounds-checking code was not. The change to that line uses the new _bitsize
macro for clarity. Also, FD_ZERO macro did not zero-out anything but the
first word of the bitfield, so this could have caused problems with modules
using that macro with the expanded bitfield.
(closes issue #18773)
Reported by: jamicque
Patches:
20110423__issue18773.diff.txt uploaded by tilghman (license 14)
Tested by: chris-mac
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "controlling user number" is always the number of the voice mail box
which is identical with the subscriber number itself. This number which
is listed in the ISDN phone MWI menu cannot be called back to contact the
voice mail box. The controlling user number should be made configurable.
JIRA ABE-2738
JIRA SWP-2846
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r314017 | dvossel | 2011-04-18 08:41:06 -0500 (Mon, 18 Apr 2011) | 17 lines
sip codec negotiation of dynamic rtp payloads error fix
This patch fixes how chan_sip handles dynamic rtp payload types
it does not understand. At the moment if a dynamic payload's mime
type does not match one we understand, the payload does not get
removed from our payload table. As a result of this, the payload
is set to whatever dynamic codec we use internally for that payload
number on outgoing INVITES. This is incorrect.
This patch fixes this by properly checking the rtpmap set function's
return code to make sure it was found. The function can return both
-1 and -2 depending on the source of the mismatch. We were just
checking -1 explicitly.
Review: https://reviewboard.asterisk.org/r/1169/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In chan_dahdi.conf, the user can now use length 4 patterns in addition to the usual length 2 patterns. The s
ntax remains the same and the method used to track the pattern history will only change when using the length
4 patterns.
(closes issue SWP-3250)
Code:
jrose
rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309808 | tilghman | 2011-03-06 18:54:42 -0600 (Sun, 06 Mar 2011) | 14 lines
Merged revisions 309251 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309251 | tilghman | 2011-03-01 19:06:02 -0600 (Tue, 01 Mar 2011) | 7 lines
Revert previous 2 commits, and instead conditionally redefine the same macro used in flex 2.5.35 that clashed with our workaround.
Not surprisingly, the workaround was exactly the same code as was provided by
the Flex maintainers, albeit in two different places, in different macros.
This should fix the FreeBSD builds, which have an older version of Flex.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding the setvar option with variable substitution on the value allows things
like setting the outbound caller id name to the summary of a calendar event,
etc. Values could be chained together as they are appended in order to do some
scripting if necessary.
Review: https://reviewboard.asterisk.org/r/1134/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309035 | tilghman | 2011-02-28 05:10:28 -0600 (Mon, 28 Feb 2011) | 15 lines
Merged revisions 309033-309034 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309033 | tilghman | 2011-02-28 04:43:12 -0600 (Mon, 28 Feb 2011) | 4 lines
A later version of flex already includes the fwrite workaround code, which if used twice causes a compilation error.
Detect whether Flex will compile without the workaround; if so, suppress our workaround code.
........
r309034 | tilghman | 2011-02-28 05:07:52 -0600 (Mon, 28 Feb 2011) | 2 lines
Clarify meaning, removing double negative (stupid!)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309036 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines
No response sent for SIP CC subscribe/resubscribe request.
Asterisk does not send a response if we try to subscribe for call
completion after we have received a 180 Ringing. You can only subscribe
for call completion when the call has been cleared.
When we receive the 180 Ringing, for this call, its call-completion state
is 'CC_AVAILABLE'. If we then send a subscribe message to Asterisk, it
trys to change the call-completion state to 'CC_CALLER_REQUESTED'.
Because this is an invalid state change, it just ignores the message. The
only state Asterisk will accept our subscribe message is in the
'CC_CALLER_OFFERED' state.
Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears
the call by sending a CANCEL.
Asterisk should always send a response. Even if its a negative one.
The fix is to allow for the CCSS core to notify a CC agent that a failure
has occurred when CC is requested. The "ack" callback is replaced with a
"respond" callback. The "respond" callback has a parameter indicating
either a successful response or a specific type of failure that may need
to be communicated to the requester.
(closes issue #18336)
Reported by: GeorgeKonopacki
Tested by: mmichelson, rmudgett
JIRA SWP-2633
(closes issue #18337)
Reported by: GeorgeKonopacki
Tested by: mmichelson
JIRA SWP-2634
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The nativeformats field was being overwritten when it should have been
appended too. This caused some format capabilities to be lost briefly and
some log warnings to be output.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The display ie handling can be controlled independently in the send and
receive directions with the following options:
* Block display text data.
* Use display text in SETUP/CONNECT messages for name.
* Use display text for COLP name updates (FACILITY/NOTIFY as appropriate).
* Pass arbitrary display text during a call. Sent in INFORMATION
messages. Received from any message that the display text was not used as
a name.
If the display options are not set then the options default to legacy
behavior.
The arbitrary display text is exchanged between bridged channels using the
AST_FRAME_TEXT frame type.
To send display text from the dialplan use the SendText() application when
the arbitrary display text option is enabled.
JIRA SWP-2688
JIRA ABE-2693
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r304950 | tilghman | 2011-01-31 00:41:36 -0600 (Mon, 31 Jan 2011) | 18 lines
Change mutex tracking so that it only consumes memory in the core mutex object when it's actually being used.
This reduces the overall size of a mutex which was 3016 bytes before this back
down to 216 bytes (this is on 64-bit Linux with a glibc-implemented mutex).
The exactness of the numbers here may vary slightly based upon how mutexes are
implemented on a platform, but the long and short of it is that prior to this
commit, chan_iax2 held down 98MB of memory on a 64-bit system for nothing more
than a table of 32767 locks. After this commit, the same table occupies a mere
7MB of memory.
(closes issue #18194)
Reported by: job
Patches:
20110124__issue18194.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/1066
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303549 | russell | 2011-01-24 14:51:37 -0600 (Mon, 24 Jan 2011) | 45 lines
Merged revisions 303548 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303548 | russell | 2011-01-24 14:49:53 -0600 (Mon, 24 Jan 2011) | 38 lines
Merged revisions 303546 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303546 | russell | 2011-01-24 14:32:21 -0600 (Mon, 24 Jan 2011) | 31 lines
Fix channel redirect out of MeetMe() and other issues with channel softhangup.
Mantis issue #18585 reports that a channel redirect out of MeetMe() stopped
working properly. This issue includes a patch that resolves the issue by
removing a call to ast_check_hangup() from app_meetme.c. I left that in my
patch, as it doesn't need to be there. However, the rest of the patch fixes
this problem with or without the change to app_meetme.
The key difference between what happens before and after this patch is the
effect of the END_OF_Q control frame. After END_OF_Q is hit in ast_read(),
ast_read() will return NULL. With the ast_check_hangup() removed, app_meetme
sees this which causes it to exit as intended. Checking ast_check_hangup()
caused app_meetme to exit earlier in the process, and the target of the
redirect saw the condition where ast_read() returned NULL.
Removing ast_check_hangup() works around the issue in app_meetme, but doesn't
solve the issue if another application did the same thing. There are also
other edge cases where if an application finishes at the same time that a
redirect happens, the target of the redirect will think that the channel hung
up. So, I made some changes in pbx.c to resolve it at a deeper level. There
are already places that unset the SOFTHANGUP_ASYNCGOTO flag in an attempt to
abort the hangup process. My patch extends this to remove the END_OF_Q frame
from the channel's read queue, making the "abort hangup" more complete. This
same technique was used in every place where a softhangup flag was cleared.
(closes issue #18585)
Reported by: oej
Tested by: oej, wedhorn, russell
Review: https://reviewboard.asterisk.org/r/1082/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For each component, the set of valid BNF expansions defines exactly
which characters may appear unescaped. All other characters MUST be
escaped.
This patch modifies ast_uri_encode() to encode strings in line with this recommendation. This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261. The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.
The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.
The unit tests for these functions have also been updated.
ABE-2705
Review: https://reviewboard.asterisk.org/r/1081/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, I had added the ast_sched_thread stuff that was a generic scheduler
thread implementation. However, if you used it, it required using different
functions for modifying scheduler contents. This patch reworks how this is
done and just allows you to optionally start a thread on the original scheduler
context structure that has always been there. This makes it trivial to switch
to the generic scheduler thread implementation without having to touch any of
the other code that adds or removes scheduler entries.
In passing, I made some naming tweaks to add ast_ prefixes where they were not
there before.
Review: https://reviewboard.asterisk.org/r/1007/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r298960 | tilghman | 2010-12-17 17:52:04 -0600 (Fri, 17 Dec 2010) | 20 lines
Merged revisions 298957 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r298957 | tilghman | 2010-12-17 17:30:55 -0600 (Fri, 17 Dec 2010) | 13 lines
Merged revisions 298905 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r298905 | tilghman | 2010-12-17 15:40:56 -0600 (Fri, 17 Dec 2010) | 6 lines
Let Asterisk find better backtrace information with libbfd.
The menuselect option BETTER_BACKTRACES, if enabled, will use libbfd to search
for better symbol information within both the Asterisk binary, as well as
loaded modules, to assist when using inline backtraces to track down problems.
Review: https://reviewboard.asterisk.org/r/1055/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298961 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Already had the pthread ID which is not the same. The most obvious enhancement
is in the "core show threads" output. As stated in the utils header, if the
platform isn't supported -1 is reported (instead of the process ID previously).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r297157 | mnicholson | 2010-12-01 13:47:33 -0600 (Wed, 01 Dec 2010) | 2 lines
Changed some NOTICE and WARNING messages to DEBUG messages.
........
r297486 | mnicholson | 2010-12-02 15:30:47 -0600 (Thu, 02 Dec 2010) | 6 lines
Add support for reserving a fax session before answering the channel.
Note: this change breaks ABI compatibility.
FAX-217
........
r297495 | mnicholson | 2010-12-03 09:21:52 -0600 (Fri, 03 Dec 2010) | 4 lines
Print a DEBUG message instead of a WARNING message when the selected fax tech does not support reserving sessions.
Answer the channel before quering it for t.38 support. This is necessary for the query to work properly over local channels.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
by splitting up devices from hints into an own ao2_container the callback to
get these devices for statechange handling is faster.
with this changes the length of a device used in a hint isnt longer restricted
to 80 characters.
Tests showed that calling handle_statechange is 40 times faster if no hints
are used and 25 times faster if there are any hints.
(closes issue #17928)
Reported by: mdu113
Tested by: schmidts
Review: https://reviewboard.asterisk.org/r/1003/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296752 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296534 | tilghman | 2010-11-29 01:28:44 -0600 (Mon, 29 Nov 2010) | 20 lines
Merged revisions 296533 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r296533 | tilghman | 2010-11-29 01:27:09 -0600 (Mon, 29 Nov 2010) | 13 lines
I love standards. There are so many to choose from. Except when there isn't one.
Linux and *BSD disagree on the elements within the ucred structure. Detect
which one is in use on the system.
(closes issue #18384)
Reported by: bjm
Patches:
cred-diffs uploaded by bjm (license 473)
20101127__issue18384__1.6.2.diff.txt uploaded by tilghman (license 14)
20101127__issue18384__1.8.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman, bjm
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r295866 | rmudgett | 2010-11-22 13:36:10 -0600 (Mon, 22 Nov 2010) | 60 lines
Merged revisions 295843 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r295843 | rmudgett | 2010-11-22 13:28:23 -0600 (Mon, 22 Nov 2010) | 53 lines
Merged revisions 295790 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r295790 | rmudgett | 2010-11-22 12:46:26 -0600 (Mon, 22 Nov 2010) | 46 lines
The channel redirect function (CLI or AMI) hangs up the call instead of redirecting the call.
To recreate the problem:
1) Party A calls Party B
2) Invoke CLI "channel redirect" command to redirect channel call leg
associated with A.
3) All associated channels are hung up.
Note that if the CLI command were done on the channel call leg associated
with B it works.
This regression was a result of the fix for issue #16946
(https://reviewboard.asterisk.org/r/740/).
The regression affects all features that use an async goto to execute the
dialplan because of an external event: Channel redirect, AMI redirect, SIP
REFER, and FAX detection.
The struct ast_channel._softhangup code is a mess. The variable is used
for several purposes that do not necessarily result in the call being hung
up. I have added doxygen comments to describe how the various _softhangup
bits are used. I have corrected all the places where the variable was
tested in a non-bit oriented manner.
The primary fix is the new AST_CONTROL_END_OF_Q frame. It acts as a weak
hangup request so the soft hangup requests that do not normally result in
a hangup do not hangup.
JIRA SWP-2470
JIRA SWP-2489
(closes issue #18171)
Reported by: SantaFox
(closes issue #18185)
Reported by: kwemheuer
(closes issue #18211)
Reported by: zahir_koradia
(closes issue #18230)
Reported by: vmarrone
(closes issue #18299)
Reported by: mbrevda
(closes issue #18322)
Reported by: nerbos
Review: https://reviewboard.asterisk.org/r/1013/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r295711 | russell | 2010-11-19 18:50:00 -0600 (Fri, 19 Nov 2010) | 36 lines
Merged revisions 295710 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r295710 | russell | 2010-11-19 18:45:51 -0600 (Fri, 19 Nov 2010) | 29 lines
Fix cache of device state changes for multiple servers.
This patch addresses a regression where device states across multiple servers
were not being processing completely correctly. The code works to determine
the overall state by looking at the last known state of a device on each
server. However, there was a regression due to some invasive rewrites of how
the cache works that led to the cache only storing the last device state change
for a device, regardless of which server it was on.
The code is set up to cache device state change events by ensuring that each
event in the cache has a unique device name + entity ID (server ID). The code
that was responsible for comparing raw information elements (which EID is)
always returned a match due to a memcmp() with a length of 0.
There isn't much code to fix the actual bug. This patch also introduces a new
CLI command that was very useful for debugging this problem. The command
allows you to dump the contents of the event cache.
(closes issue #18284)
Reported by: klaus3000
Patches:
issue18284.rev1.txt uploaded by russell (license 2)
Tested by: russell, klaus3000
(closes issue #18280)
Reported by: klaus3000
Review: https://reviewboard.asterisk.org/r/1012/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
Analog lines do not transfer CONNECTED LINE or execute the interception macros.
Add connected line update for sig_analog transfers and simplify the
corresponding sig_pri and chan_misdn transfer code.
Note that if you create a three-way call in sig_analog before transferring
the call, the distinction of the caller/callee interception macros make
little sense. The interception macro writer needs to be prepared for
either caller/callee macro to be executed. The current implementation
swaps which caller/callee interception macro is executed after a three-way
call is created.
Review: https://reviewboard.asterisk.org/r/996/
JIRA ABE-2589
JIRA SWP-2372
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294278 | jpeeler | 2010-11-08 15:59:45 -0600 (Mon, 08 Nov 2010) | 23 lines
Merged revisions 294277 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r294277 | jpeeler | 2010-11-08 15:58:13 -0600 (Mon, 08 Nov 2010) | 16 lines
Fix playback failure when using IAX with the timerfd module.
To fix this issue the alert pipe will now be used when the timerfd module is
in use. There appeared to be a race that was not solved by adding locking in the
timerfd module, but needed to be there anyway. The race was between the timer
being put in non-continuous mode in ast_read on the channel thread and the IAX
frame scheduler queuing a frame which would enable continuous mode before the
non-continuous mode event was read. This race for now is simply avoided.
(closes issue #18110)
Reported by: tpanton
Tested by: tpanton
I put tested by tpanton because it was tested on his hardware. Thanks for the
remote access to debug this issue!
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293803 | twilson | 2010-11-03 11:05:14 -0700 (Wed, 03 Nov 2010) | 25 lines
Avoid valgrind warnings for ast_rtp_instance_get_xxx_address
The documentation for ast_rtp_instance_get_(local/remote)_address stated that
they returned 0 for success and -1 on failure. Instead, they returned 0 if the
address structure passed in was already equivalent to the address instance
local/remote address or 1 otherwise. 90% of the calls to these functions
completely ignored the return address and passed in an uninitialized struct,
which would make valgrind complain even though the operation was technically
safe.
This patch fixes the documentation and converts the get_xxx_address functions
to void since all they really do is copy the address and cannot fail.
Additionally two new functions
(ast_rtp_instance_get_and_cmp_(local/remote)_address) are created for the 3
times where the return value was actually checked. The
get_and_cmp_local_address function is currently unused, but exists for the sake
of symmetry.
The only functional change as a result of this change is that we will not do an
ast_sockaddr_cmp() on (mostly uninitialized) addresses before doing the
ast_sockaddr_copy() in the get_*_address functions. So, even though it is an
API change, it shouldn't have a noticeable change in behavior.
Review: https://reviewboard.asterisk.org/r/995/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291758 | pabelanger | 2010-10-14 11:15:12 -0400 (Thu, 14 Oct 2010) | 11 lines
Add the ability for ast_find_ourip to return IPv4, IPv6 or both.
While testing chan_gtalk I noticed jabber was using my IPv6 address
and not IPv4. When using bindaddr=0.0.0.0 it is possible for ast_find_ourip()
to return both IPv6 and IPv4 results. Adding a family parameter gives you
the ablility to choose.
Since jabber/gtalk/h323 do not support IPv6, we should only return IPv4 results.
Review: https://reviewboard.asterisk.org/r/973/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291192 | dvossel | 2010-10-11 16:38:39 -0500 (Mon, 11 Oct 2010) | 19 lines
Gtalk enhancements and general code cleanup.
This patch includes several chan_gtalk enhancements.
Two new gtalk.conf options have been added, externip
and stunadd. Setting externip allows us to
manually specify what the external IP address is
outside of a NAT environment. Setting the stunaddr
option to a valid stun server allows for that external
ip to be retrieved via a STUN server automatically. This
external IP is then advertised during call setup as
a possible candidate.
I have also attempted to clean up chan_gtalk's code
so it meets our coding guidelines. During this cleanup
I noticed several things that need to be done in the
code and made a TODO section at the top of the file.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines
Merged revisions 289798 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines
Merged revisions 289797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
The scenario here is with a non P2P early media session. The reported time
length of DTMF presses are coming up short when sending to the remote side.
Currently the event duration is a running total that is incremented when sending
continuation packets. These continuation packets are only triggered upon
incoming media from the remote side, which means that the running total probably
is not going to end up matching the actual length of time Asterisk received
DTMF. This patch changes the end event duration to be lengthened if it is
detected that the end event is going to come up short.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287647 | dvossel | 2010-09-20 17:09:16 -0500 (Mon, 20 Sep 2010) | 21 lines
Addition of the FrameHook API (AKA AwesomeHooks)
So far all our tools for viewing and manipulating media streams
within Asterisk have been entirely focused on audio. That made
sense then, but is not scalable now. The FrameHook API lets us
tap into and manipulate _ANY_ type of media or signaling passed
on a channel present today or in the future. This tool is a step
in the direction of expanding Asterisk's boundaries and will help
generate some rather interesting applications in the future.
In addition to the FrameHook API, a simple dialplan function
exercising the api has been included as well. This function
is called FRAME_TRACE(). FRAME_TRACE() allows for the internal
ast_frames read and written to a channel to be output. Filters
can be placed on this function to debug only certain types of frames.
This function could be thought of as an internal way of doing
ast_frame packet captures.
Review: https://reviewboard.asterisk.org/r/925/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287648 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286931 | jpeeler | 2010-09-15 14:22:15 -0500 (Wed, 15 Sep 2010) | 16 lines
Add parking extension for non-default parking lots.
This is a new feature that allows for parking to custom parking lots to be
accessed directly, rather than with channel variables or by changing the
default parking lot. The extension is set with the parkext option just as the
default parking lot is done. Also, the manager action has been updated to
optionally allow a specified parking lot.
(closes issue #14882)
Reported by: vmikhnevych
Patches:
patch_14882.txt uploaded by mnick (license 874)
modified by me
Review: https://reviewboard.asterisk.org/r/884/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r285962 | tilghman | 2010-09-10 00:32:18 -0500 (Fri, 10 Sep 2010) | 13 lines
Merged revisions 285961 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r285961 | tilghman | 2010-09-10 00:31:31 -0500 (Fri, 10 Sep 2010) | 6 lines
Another fix for Mac OS X.
While trying to fix this the "right" way, I wandered into dependency hell. Two
hours later, I backed out, and just removed the offending code. ast_inline_api
only goes one level deep and then it breaks. Ouch.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r285931 | tilghman | 2010-09-09 20:25:50 -0500 (Thu, 09 Sep 2010) | 21 lines
Merged revisions 285930 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r285930 | tilghman | 2010-09-09 20:16:32 -0500 (Thu, 09 Sep 2010) | 14 lines
Merged revisions 285889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r285889 | tilghman | 2010-09-09 19:13:45 -0500 (Thu, 09 Sep 2010) | 7 lines
Fix Mac OS X build.
This also fixes a rather grievous calculation error for the offset of
ast_fdset, which was masked on Linux and FreeBSD, because these platforms
check the first 256 FDs regardless of the bitmask setting (due to backwards
compatibility).
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines
Fix SRTP for changing SSRC and multiple a=crypto SDP lines
Adding code to Asterisk that changed the SSRC during bridges and masquerades
broke SRTP functionality. Also broken was handling the situation where an
incoming INVITE had more than one crypto offer. This patch caches the SRTP
policies the we use so that we can change the ssrc and inform libsrtp of the
new streams. It also uses the first acceptable a=crypto line from the incoming
INVITE.
(closes issue #17563)
Reported by: Alexcr
Patches:
srtp.diff uploaded by twilson (license 396)
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/878/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r283230 | russell | 2010-08-23 08:23:12 -0500 (Mon, 23 Aug 2010) | 7 lines
Make the AST_CEL_AMA enum match up with the AST_CDR_ ama flag values.
Really, having 2 enums for this is silly and error prone, demonstrated by
the crash that I hit because there was an assumption in the code that the
values in each matched up. However, this is a quick fix to get them to
match up so it will work.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282098 | rmudgett | 2010-08-12 17:06:06 -0500 (Thu, 12 Aug 2010) | 7 lines
Separate call completion config parameter allocation and default initialization.
If you ever have a need to reset the call completion config parameters
to defaults, now you can.
And no Virginia, C++ idioms do not always work in C.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282099 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282047 | dvossel | 2010-08-12 15:15:41 -0500 (Thu, 12 Aug 2010) | 35 lines
improved translation paths for wideband codecs
The problem I'm addressing is that Asterisk's current
method of building the least cost translation paths
between codecs does not take into account sample rate.
For instance, it was possible for siren14 (a 32khz codec),
to contain the a translation path to siren7 (a 16khz
audio codec) that goes through slin at 8khz. In this
case Asterisk takes a 32khz codec, down samples it to
8khz and then up samples it to 16khz which is terrible
regardless if it is computationally less expensive. This
patch now builds translation paths that give priority to
maintaining the best possible sample rate before taking
into consideration computational cost. This patch also
adds cli commands to expose what translation paths are
actually being used.
Changes:
1. Translation paths will never contain a step that changes
the sample rate unless absolutely necessary.
2. When choosing the best codec to make two channels compatible.
Shared codecs with the highest sample rate are given priority.
3. A new cli command to show all translation paths available
for a specific codec 'core show translation paths [codec name]'
has been added.
4. 'core show translation' which displays the translation
matrix now includes the new higher bit audio codecs in the table.
5. 'core show channel [channel name]' now displays the
translation paths if translation is used.
(closes issue #16841)
Reported by: dvossel
Review: https://reviewboard.asterisk.org/r/842/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r279949 | dvossel | 2010-07-27 15:57:00 -0500 (Tue, 27 Jul 2010) | 31 lines
Merged revisions 279946 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r279946 | dvossel | 2010-07-27 15:54:32 -0500 (Tue, 27 Jul 2010) | 24 lines
Merged revisions 279945 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r279945 | dvossel | 2010-07-27 15:33:40 -0500 (Tue, 27 Jul 2010) | 19 lines
remove empty audiohook write list on channel
If a channel has an audiohook write list created on it, that
list stays on the channel until the channel is destroyed. There
is no reason to keep that list on the channel if it becomes empty.
If it is empty that just means we are doing needless translating
for every ast_read and ast_write. This patch removes the audiohook
list from the channel once it is detected to be empty on either a
read or write. If a audiohook is added back to the channel after
this list is destroyed, the list just gets recreated as if it never
existed to begin with.
(closes issue #17630)
Reported by: manvirr
Review: https://reviewboard.asterisk.org/r/799/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279504 | mmichelson | 2010-07-26 11:04:09 -0500 (Mon, 26 Jul 2010) | 14 lines
Allow for systems without locale support to be usable.
A recent change to SIP URI comparison code added a locale-specific
string comparison to the mix, and certain systems do not support
such functions. This fix allows for those systems to still use
Asterisk 1.8
(closes issue #17697)
Reported by: pprindeville
Patches:
asterisk-trunk-bugid17697.patch uploaded by pprindeville (license 347)
Tested by: mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277568 | tilghman | 2010-07-16 16:54:29 -0500 (Fri, 16 Jul 2010) | 8 lines
Since we split values at the semicolon, we should store values with a semicolon as an encoded value.
(closes issue #17369)
Reported by: gkservice
Patches:
20100625__issue17369.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271399 | jpeeler | 2010-06-18 14:28:24 -0500 (Fri, 18 Jun 2010) | 11 lines
Fix crash when parsing some heavily nested statements in AEL on reload.
Due to the recursion used when compiling AEL in gen_prios, all the stack space
was being consumed when parsing some AEL that contained nesting 13 levels deep.
Changing a few large buffers to be heap allocated fixed the crash, although I
did not test how many more levels can now be safely used.
(closes issue #16053)
Reported by: diLLec
Tested by: jpeeler
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This way the libraries can be found even if they are in
non-standard locations.
(closes issue #16155)
Reported by: jcollie
Patches:
0008-change-configure.ac-to-look-for-pkg-config-gmime-2.0.patch uploaded by jcollie (license 412)
Tested by: jsmith, tilghman, pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270042 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind pointed out that attempting to get an IE value from an event that has
no IEs produces an invalid memory read past the end of the event. Thanks to
mmichelson for pointing the problem out to me and then testing the fix.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This changes the sample slinear frame data to contain non-zero data so that
translation calculations for speex works when preprocessing and VAD is turned
on. The encoder expects samples to be returned, but when attempted with the
mentioned two options and silent sample frames everything was discarded.
(closes issue #17240)
Reported by: seandarcy
Review: https://reviewboard.asterisk.org/r/682/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses a modified version of pabelanger's patch that checks for NTLM support
instead, which was added in 0.29.0 which is what is required for
res_calendar_ews.
(closes issue #17391)
Reported by: loloski
Patches:
issue17391.patch.v2 uploaded by pabelanger (license 224)
Tested by: twilson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This ensures cross-platform compatibility, even among Linux distributions,
which don't always put headers in the same place.
(closes issue #17391)
Reported by: loloski
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r265089 | mmichelson | 2010-05-21 15:59:14 -0500 (Fri, 21 May 2010) | 8 lines
Don't hang up on a queue caller if the file we attempt to play does not exist.
This also fixes a documentation mistake in file.h that made my original attempt
to correct this problem not work correctly.
(closes issue #17061)
Reported by: RoadKill
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@265090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264996 | mmichelson | 2010-05-21 11:28:34 -0500 (Fri, 21 May 2010) | 32 lines
Allow ast_safe_sleep to defer specific frames until after the sleep has concluded.
From reviewboard
Background:
A Digium customer discovered a somewhat odd bug. The setup is that parties A
and B are bridged, and party A places party B on hold. While party B is
listening to hold music, he mashes a bunch of DTMF. Party A takes party
B off hold while this is happening, but party B continues to hear hold
music. I could reproduce this about 1 in 5 times.
The issue:
When DTMF features are enabled and a user presses keys, the channel that
the DTMF is streamed to is placed in an ast_safe_sleep for 100 ms, the
duration of the emulated tone. If an AST_CONTROL_UNHOLD frame is read
from the channel during the sleep, the frame is dropped. Thus the
unhold indication is never made to the channel that was originally placed
on hold.
The fix:
Originally, I discussed with Kevin possible ways of fixing the specific
problem reported. However, we determined that the same type of problem
could happen in other situations where ast_safe_sleep() is used. Using
autoservice as a model, I modified ast_safe_sleep_conditional() to
defer specific frame types so they can be re-queued once the sleep has
finished. I made a common function for determining if a frame should
be deferred so that there are not two identical switch blocks to
maintain.
Review: https://reviewboard.asterisk.org/r/674/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r264248 | tilghman | 2010-05-19 12:41:29 -0500 (Wed, 19 May 2010) | 17 lines
Internal timing is now on by default, if you're using DAHDI 2.3 or above.
The reason for ensuring DAHDI 2.3 or above is that this version ensures that
a timer is always available, whereas in previous versions, it was possible
for DAHDI to be loaded, but have no drivers to actually generate timing. If
internal_timing was turned on in this circumstance, a complete lack of audio
would result. This is the reason why internal_timing was not on by default.
However, now that DAHDI ensures the availability of a timer, there is no
reason for this setting to be off (and in fact, it solves a great many initial
user problems).
(closes issue #15932)
Reported by: dimas
Patches:
20100519__issue15932.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This will save a considerable amount of CPU on the BSDs, including Mac OS X,
as it eliminates several places in the code that we previously used a busy
loop. Additionally, this adds a res_timing interface, using kqueue timers.
Review: https://reviewboard.asterisk.org/r/543/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Clean up chan_sip.c to use new AST_CLI functions
(closes issue #17287)
Reported by: pabelanger
Patches:
issue17287.patch uploaded by pabelanger (license 224)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision -r1489 of the libpri 1.4 branch corrected a deviation from Q.931
Section 5.3.2. However, this resulted in an unexpected behaviour change
to the upper layer (Asterisk).
This change uses pri_hangup_fix_enable() to follow Q.931 Section 5.3.2
call hangup better if the version of libpri supports it.
(issue #17104)
Reported by: shawkris
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@262569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We nicely detect the right flags on each system for building Asterisk with
pthreads, then ignore it for every other build option that requires us to
build with pthreads. This caused some items to return a false negative.
Also cleanup some minor naming issues that caused "library library" redundancy
in the output.
(closes issue #17303)
Reported by: stuarth
Patches:
20100507__issue17303.diff.txt uploaded by tilghman (license 14)
Tested by: stuarth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We have some functions inside the AstData API to get the tree
in XML form, but it is not required at the moment to compile
asterisk and we can disable that part of the API if we don't have
libxml2 support.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r260049 | dvossel | 2010-04-29 10:31:02 -0500 (Thu, 29 Apr 2010) | 14 lines
Fixes crash in audiohook_write_list
The middle_frame in the audiohook_write_list function was
being freed if a audiohook manipulator returned a failure.
This is incorrect logic. This patch resolves this and
adds detailed descriptions of how this function should work
and why manipulator failures must be ignored.
(closes issue #17052)
Reported by: dvossel
Tested by: dvossel
(closes issue #16196)
Reported by: atis
Review: https://reviewboard.asterisk.org/r/623/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@260050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The fax session initilization code for T.38 faxes has been rewritten. T.38 session initialization was removed from generic_fax_exec, and split into two different code paths for receive and send. Also the 'z' option (to send a T.38 reinvite if we do not receive one) was added to sendfax.
In the output of 'fax show sessions', the 'Type' column has been renamed to 'Tech' and replaced with a new 'Tech' column that will report 'G.711' or 'T.38'.
Control of ECM defaults has been added to res_fax
A 'fax show settings' CLI command has been added.
Support of the new AST_T38_REQUEST_PARMS control method request to handle channels that have already received a T.38 reinvite before the FAX application is start has been added.
Support for the 'fax show settings' command has been added to res_fax_spandsp and handling of the ECM flag has been slightly altered.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
"Bad Things" would happen if Asterisk was compiled with DEBUG_THREADS, but a
loaded module was not (or vice versa). This also immensely simplifies the
lock code, since there are no longer 2 separate versions of them.
Review: https://reviewboard.asterisk.org/r/508/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This module implements an abstraction for retrieving and exporting
asterisk data.
Developed by:
Brett Bryant <brettbryant@gmail.com>
Eliel C. Sardanons (LU1ALY) <eliels@gmail.com>
For the Google Summer of code 2009 Project.
Documentation can be found in doxygen format and inside the
header include/asterisk/data.h
Review: https://reviewboard.asterisk.org/r/275/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes add the ability to run 'make asterisk.txt' just like the existing
'make asterisk.pdf' commands to generate a text document from the TeX files we
have in the doc/tex/ directory. I've also updated a few of the .tex files because
they weren't properly escaping certain characters so they would show up as Unicode
characters (like [U+021C]). Made changes to the configure scripts so it would
detect the catdvi program which is required to convert the .dvi file generated
by latex.
I've also added a few lines to the build_tools/prep_tarball script so that the
text documentation gets generated and added to future tarballs of Asterisk
releases.
(closes issue #17220)
Reported by: lmadsen
Patches:
asterisk.txt.patch uploaded by lmadsen (license 10)
asterisk.txt.patch-v4 uploaded by pabelanger (license 224)
Tested by: lmadsen, pabelanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added a new manager command to mute/unmute MixMonitor audio on a channel.
Added a new feature to audiohooks so that you can mute either read / write
(or both) types of frames - this allows for MixMonitor to mute either side
of the conversation without affecting the conversation itself.
(closes issue #16740)
Reported by: jmls
Review: https://reviewboard.asterisk.org/r/487/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@258190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Review Board:
There are two interrelated changes here.
First, there is the introduction of func_srv. This adds two new read-only
dialplan functions, SRVQUERY and SRVRESULT. They work very similarly to the
ENUMQUERY and ENUMRESULT functions, except that this allows one to query SRV
records instead. In order to facilitate this work, I added a couple of new API
calls to srv.h. ast_srv_get_record_count tells the number of records returned
by an SRV lookup. This number is calculated at the time of the SRV lookup.
ast_srv_get_nth_record allows one to get a numbered SRV record.
Second, there is the modification to chan_sip that allows one to specify a
hostname or IP address (along with a port) to send an outgoing INVITE to when
dialing a SIP peer. This goes hand-in-hand with func_srv. You can query SRV
records and then use the host and port from the results to dial via a specific
host instead of what is configured in sip.conf.
Review: https://reviewboard.asterisk.org/r/608
SWP-1200
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_channel structure had a field used for linking a channel into a
linked list, but now that ast_channel structures are ao2 objects, this is
no longer needed, and could be harmful as ao2 objects really shouldn't
ever be placed into linked lists (since those lists don't assist with
reference count management on the objects).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
users expect them to work.
'core set debug' and 'core set verbose' can optionally change the
level for a specific filename; however, this is actually for a
specific source file name, not the module that source file is included
in. With examples like chan_sip, chan_iax2, chan_misdn and others
consisting of multiple source files, this will not lead to the
behavior that users expect. If they want to set the debug level for
chan_sip, they want it set for all of chan_sip, and not to have to
also set it for reqresp_parser and other files that comprise the
chan_sip module.
This patch changes this functionality to be module-name based instead
of file-name based.
To make this work, some Makefile modifications were required to ensure
that the AST_MODULE definition is present in each object file produced
for each module as well.
Review: https://reviewboard.asterisk.org/r/574/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@253917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The mis-placement of the latest entry meant that when it was set, it was writing
one index past the end of the properties array in the ast_rtp_instance (which
happened to be the local_address field).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250871 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Only chan_dahdi set a value in cdrflags. Everyone else just copied it
around the system. Noone cared about any value it may have contained.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. The documentation for ast_str_set and ast_str_append state that
the max_len parameter may be -1 in order to limit the size of the
ast_str to its current allocated size. The problem was that the max_len
parameter in all cases was a size_t, which is unsigned. Thus a -1 was
interpreted as UINT_MAX instead of -1. Changing the max_len parameter
to be ssize_t fixed this issue.
2. Once issue 1 was fixed, there was an off-by-one error in the case
where we attempted to write a string larger than the current allotted
size to a string when -1 was passed as the max_len parameter. When trying
to write more than the allotted size, the ast_str's __AST_STR_USED was
set to 1 higher than it should have been. Thanks to Tilghman for quickly
spotting the offending line of code.
Oh, and the unit test that I referenced in the top line of this commit
will be added to reviewboard shortly. Sit tight...
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This module includes a single test so far that creates events using two
different methods and does some verification on the result to make sure
the correct data can be retrieved from the event that was created.
One bug was found in the event API while developing this test, which makes
me happy. :-)
Review: https://reviewboard.asterisk.org/r/495/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Detect all platforms that don't like that, either, and ensure that when documentation is
missing, we pass a non-NULL pointer when outputting the corresponding documentation.
(closes issue #16689)
Reported by: bklang
Patches:
20100209__issue16689__with_tests.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/497/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@246030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) It occurred to me that the difference in usage between the error ast_str and
the ast_test_update_status() usage has turned out to be a bit ambiguous in
practice. In a lot of cases, the same message was being sent to both.
In other cases, it was only sent to one or the other. My opinion now is that
in every case, I think it makes sense to do both; we should output it to the
CLI as well as save it off for logging purposes.
This change results in most of the changes in this diff, since it required
changes to all existing unit tests. It also allowed for some simplifications
of unit test API implementation code.
2) Update ast_test_status_update() to include the file, function, and line
number for the code providing the update.
3) There are some formatting tweaks here and there. Hopefully they aren't too
distracting for code review purposes. Reviewboard's diff viewer seems to do a
pretty good job of pointing out when something is a whitespace change.
4) I moved the md5_test and sha1_test into the test_utils module. It seemed
like a better approach since these tests are so tiny.
5) I changed the number of nodes used in heap_test_2 from 1 million to
100 thousand. The only reason for this was to reduce the time it took
for this test to run.
6) Remove an unused function prototype that was at the bottom of utils.h.
7) Simplify test_insert() using the LIST_INSERT_SORTALPHA() macro. The one
minor difference in behavior is that it no longer checks for a test registered
with the same name.
8) Expand the code in test_alloc() to provide specific error messages for each
failure case, to clearly inform developers if they forget to set the name,
summary, description, etc.
9) Tweak the output of the "test show registered" CLI command. I swapped the
name and category to have the category first. It seemed more natural since
that is the sort key.
10) Don't output the status ast_str in the "test show results" CLI command.
This is going to tend to be pretty verbose, so just leave that for the
detailed test logs (test generate results).
Review: https://reviewboard.asterisk.org/r/493/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. URI Encoding
This patch changes ast_uri_encode()'s behavior when doreserved is enabled.
Previously when doreserved was enabled only a small set of reserved
characters were encoded. This set was comprised primarily of the reserved
characters defined in RFC3261 section 25.1, but contained other characters as
well. Rather than only escaping the reserved set, doreserved now escapes
all characters not within the unreserved set as defined by RFC 3261 and
RFC 2396. Also, the 'doreserved' variable has been renamed to 'do_special_char'
in attempts to avoid confusion.
When doreserve is not enabled, the previous logic of only encoding the
characters <= 0X1F and > 0X7f remains, except for the '%' character, which
must always be encoded as it signifies a HEX escaped character during the decode
process.
2. URI Decoding: Break up URI before decode.
In chan_sip.c ast_uri_decode is called on the entire URI instead of it's
individual parts after it is parsed. This is not good as ast_uri_decode
can introduce special characters back into the URI which can mess up parsing.
This patch resolves this by not decoding a URI until parsing is completely
done. There are many instances where we check to see if pedantic checking
is enabled before we decode a URI. In these cases a new macro,
SIP_PEDANTIC_DECODE, is used on the individual parsed segments of the URI
rather than constantly putting if (pedantic) { decode() } checks everywhere
in the code. In the areas where ast_uri_decode is not dependent upon
pedantic checking this macro is not used, but decoding is still moved to
each individual part of the URI. The only behavior that should change from
this patch is the time at which decoding occurs.
Since I had to look over every place URI parsing occurs to create this
patch, I found several places where we use duplicate code for parsing.
To consolidate the code, those areas have updated to use the parse_uri()
function where possible.
3. SIP display-name decoding according to RFC3261 section 25.
To properly decode the display-name portion of a FROM header, chan_sip's
get_calleridname() function required a complete re-write. More information
about this change can be found in the comments at the beginning of this function.
4. Unit Tests.
Unit tests for ast_uri_encode, ast_uri_decode, and get_calleridname() have been
written. This involved the addition of the test_utils.c file for testing the
utils api.
(closes issue #16299)
Reported by: wdoekes
Patches:
astsvn-16299-get_calleridname.diff uploaded by wdoekes (license 717)
get_calleridname_rewrite.diff uploaded by dvossel (license 671)
Tested by: wdoekes, dvossel, Nick_Lewis
Review: https://reviewboard.asterisk.org/r/469/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@243200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch removes code that was duplicated from pbx.c to manager.c
in order to prevent API change in released versions of Asterisk.
There are propably also other places that would benefit from reading the
return code and react if a function returns error codes on writing a value into it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@242919 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r242520 | tilghman | 2010-01-24 00:33:01 -0600 (Sun, 24 Jan 2010) | 8 lines
Only rebuild bison and flex source files on demand, if bison and flex are detected by the configure script.
Changed after discussion on the -dev list about possible unnecessary build
failures, due to checkouts/untars causing these special source files to
possibly be newer than their resulting C files. This should additionally
ensure that nobody need learn about extra Makefile arguments to ensure the
proper files get rebuilt when changes are made to these special source files.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@242521 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the limit was set past MAX_INT upon answering, the call was immediately
hung up due to overflow from the return of ast_tvdiff_ms (in ast_check_hangup).
The time calculation functions ast_tvdiff_sec and ast_tvdiff_ms have been
changed to return an int64_t to prevent overflow. Also the reporter suggested
adding a message indicating the reason for the call hanging up. Given that the
new limit is so much higher, the message (which would only really be useful in
the overflow scenario) has been made a debug message only.
(closes issue #16006)
Reported by: viraptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@241143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Specifically, by setting TESTTIME() to a particular date and time, you
can test whether a dialplan correctly branches as was intended. This was
developed after recent questions on the -users list on how to test their
holiday dialplan logic.
(closes issue #16464)
Reported by: tilghman
Patches:
20100112__issue16464.diff.txt uploaded by tilghman (license 14)
Review: https://reviewboard.asterisk.org/r/458/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@239957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During the process of removing an audiohook from one channel
and attaching it to another the audiohook's status is updated
to DONE and then back to whatever it was previously. Typically
updating the status after setting it to DONE is not a good idea
because DONE can trigger unrecoverable audiohook destruction
events... because of this a conditional check was added to
audiohook_update_status to explicitly prevent the audiohook
from ever changing after being set to DONE. It was this check
that prevented audiohook inherit from work properly though.
Now ast_audiohook_move_by_source is treated as a special exception,
as the audiohook must be returned to its previous status after
attaching it to the new channel. This is only a safe operation
because the audiohook's lock is held the entire time, otherwise
this could cause trouble.
(closes issue #16522)
Reported by: corruptor
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The ast_test_status_update() function is defined in test.h.
When TEST_FRAMEWORK is not enabled a macro is defined as a no-op
place holder for this function. The macro did not contain
the correct number of arguments. This caused a compile error.
Much thanks to wdoekes for reporting the issue and supplying the
patch!
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@238091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r237405 | tilghman | 2010-01-04 12:19:00 -0600 (Mon, 04 Jan 2010) | 16 lines
Add a flag to disable the Background behavior, for AGI users.
This is in a section of code that relates to two other issues, namely
issue #14011 and issue #14940), one of which was the behavior of
Background when called with a context argument that matched the current
context. This fix broke FreePBX, however, in a post-Dial situation.
Needless to say, this is an extremely difficult collision of several
different issues. While the use of an exception flag is ugly, fixing all
of the issues linked is rather difficult (although if someone would like
to propose a better solution, we're happy to entertain that suggestion).
(closes issue #16434)
Reported by: rickead2000
Patches:
20091217__issue16434.diff.txt uploaded by tilghman (license 14)
20091222__issue16434__1.6.1.diff.txt uploaded by tilghman (license 14)
Tested by: rickead2000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@237406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r236585 | seanbright | 2009-12-28 10:12:08 -0500 (Mon, 28 Dec 2009) | 7 lines
Try a test compile to see if PTHREAD_ONCE_INIT requires extra braces.
There was conditional code (based on build platform) to optioinally wrap
PTHREAD_ONCE_INIT in braces that was removed since it is fixed in newer versions
of Solaris/OpenSolaris, but I am still running into it on Solaris 10 x86 so add
a configure-time check for it.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@236613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Unit Test Framework is a new API that manages registration and
execution of unit tests in Asterisk with the purpose of verifying the
operation of C functions. The Framework consists of a single test
manager accompanied by a list of registered test functions defined
within the code. A test is defined, registered, and unregistered
from the framework using a set of macros which allow the test code
to only be compiled within asterisk when the TEST_FRAMEWORK flag is
enabled in menuselect. This allows the test code to exist in the
same file as the C functions it intends to verify. Registered tests
may be viewed and executed via a set of new CLI commands. CLI commands
are also present for generating and exporting test results into xml
and txt formats.
For more information and use cases please refer to the documentation
provided at the beginning of the test.h file.
Review: https://reviewboard.asterisk.org/r/447/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@236027 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r235635 | jpeeler | 2009-12-18 16:29:51 -0600 (Fri, 18 Dec 2009) | 48 lines
Correct CDR dispositions for BUSY/FAILED
This patch is simple in that it reorders the disposition defines so that the fix
for issue 12946 works properly (the default CDR disposition was changed to
AST_CDR_NOANSWER). Also, the AST_CDR_FLAG_ORIGINATED flag was set in ast_call to
ensure all CDR records are written.
The side effects of CDR changes are scary, so I'm documenting the test cases
performed to attempt to catch any regressions. The following tests were all
performed using 1.4 rev 195881 vs head (235571) + patch:
A calls B
C calls B (busy)
Hangup C
Hangup A
(Both SIP and features)
A calls B
A blind transfers to C
Hangup C
(Both SIP and features)
A calls B
A attended transfers to C
Hangup C
A calls B
A attended transfers to C (SIP)
C blind transfers to A (features)
Hangup A
All of the test scenario CDRs matched.
The following tests were performed just with the patch to ensure proper operation
(with unanswered=yes):
exten =>s,1,Answer
exten =>s,n,ResetCDR(w)
exten =>s,n,ResetCDR(w)
exten =>s,1,ResetCDR(w)
exten =>s,n,ResetCDR(w)
(closes issue #16180)
Reported by: aatef
Patches:
bug16180.patch uploaded by jpeeler (license 325)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235660 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The option is global and currently the acceptable values as noted in the sample
config are accept or deny.
(closes issue #15228)
Reported by: lp0
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Classes are now tracked past removal from the core container, and module
removal is actively prevented until all references are freed.
* A hanging reference stored in the channel has been removed. This could have
caused a mismatch and the music state not properly cleared, if two or more
reloads occurred between MOH being stopped and MOH being restarted.
* In certain circumstances, duplicate classes were possible.
* A race existed at reload time between a process being killed and the thread
responsible for reading from the related pipe respawning that process.
* Several reference counts have also been corrected. At least one could have
caused deleted classes to stick around forever, consuming resources. This
originally manifested as MOH external processes that were not killed at
reload time.
(closes issue #16279, closes issue #16207)
Reported by: parisioa, dcabot
Patches:
20091202__issue16279__2.diff.txt uploaded by tilghman (license 14)
Tested by: parisioa, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@232660 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the process of swapping ULAW to a place in the extended codec space, we
found several unhandled cases, where a 32-bit integer was still being used to
handle a codec field. Most of these have been fixed with this commit, although
there is at least one case (codec_dahdi) which depends upon outside headers to
be altered before a conversion can be made.
(Fixes AST-278, SWP-459)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Allow users of UDPTL stack to associate a character-string tag with a UDPTL
session, so that log/error/debug messages generated by the UDPTL stack can
be 'connected' to the endpoint that caused them to be generated.
2) Improve comments (and process) of calculating the far end's maximum IFP size
when redundancy mode is in use for error correction.
3) When an IFP larger than the calculated 'far max IFP' size is presented for
writing, truncate it rather than putting in the buffer and allowing the buffer
to overflow; this will cause the ends to retrain to a lower bit rate that
produces IFPs of an appropriate size if possible, and if not possible, the
FAX transfer will fail completely. In these cases, it is due to the one endpoint
supplying a T38FaxMaxDatagram value that is improperly calculated and is
too low to be of use; we have configuration options available to override
this behavior.
4) Eliminate use of T38FaxMaxDatagram value in udptl.conf; it is no longer
needed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@231692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Add REPLACE function, which searches a given variable for a set of
characters and replaces each with a given character.
* Add PASSTHRU function, which passes a literal string back, like a NoOp for
functions. Intent is to be able to specify a literal string to another
function that takes a variable name as an argument.
* Let the array manipulation functions work with dialplan functions, in
addition to variables. This allows the array manipulation functions to
modify ASTDB and ODBC backends, assuming the func_odbc configuration has
both read and write functions.
(closes issue #15223)
Reported by: ajohnson
Patches:
20091112__issue15223.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@230994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch, originally submitted by jozza, enables custom modules to send actions to AMI
and receive messages from AMI via a hook interface. Included is a simple test module to
illustrate the interface.
(closes issue #14635)
Reported by: jozza
Review: https://reviewboard.asterisk.org/r/412/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@227448 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a side project I've been poking at this week. The intent is to discuss
Asterisk architecture in a top down fashion to help new developers understand how
Asterisk is put together. There is a ton of stuff to write about, so this will
just continue to evolve over time.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added handling of received HOLD/RETRIEVE messages and the optional ability
to transfer a held call on disconnect similar to an analog phone.
* Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP.
Will reroute/deflect an outgoing call when receive the message.
Can use the DAHDISendCallreroutingFacility to send the message for the
supported switches.
* Added ability to send/receive keypad digits in the SETUP message.
Send keypad digits in SETUP message: Dial(DAHDI/g1[/K<keypad_digits>][/extension])
Access any received keypad digits in SETUP message by: ${CHANNEL(keypad_digits)}
* Added support for BRI PTMP NT mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added documentation on how to create a local git repository from
SVN. This documentation was added via doxygen.
(closes issue #15814)
Reported by: tzafrir
Patches:
git-asterisk-howto uploaded by tzafrir (license 46)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225483 65c4cc65-6c06-0410-ace0-fbb531ad65f3
What this patch fixes
1.Moves sip TCP/TLS connection setup into the TCP helper thread:
Connection setup takes awhile and before this it was being
done while holding the monitor lock.
2.Moves TCP/TLS writing to the TCP helper thread: Through the
use of a packet queue and an alert pipe, the TCP helper thread
can now be woken up to write data as well as read data.
3.Locking error: sip_xmit returned an XMIT_ERROR without giving
up the tcptls_session lock. This lock has been completely removed
from sip_xmit and placed in the new sip_tcptls_write() function.
4.Memory leak: When creating a tcptls_client the tls_cfg was alloced
but never freed unless the tcptls_session failed to start. Now the
session_args for a sip client are an ao2 object which frees the
tls_cfg on destruction.
5.Pointer to stack variable: During sip_prepare_socket the creation
of a client's ast_tcptls_session_args was done on the stack and
stored as a pointer in the newly created tcptls_session. Depending
on the events that followed, there was a slight possibility that
pointer could have been accessed after the stack returned. Given
the new changes, it is always accessed after the stack returns
which is why I found it.
Notable code changes
1.I broke tcptls.c's ast_tcptls_client_start() function into two
functions. One for creating and allocating the new tcptls_session,
and a separate one for starting and handling the new connection.
This allowed me to create the tcptls_session, launch the helper
thread, and then establish the connection within the helper thread.
2.Writes to a tcptls_session are now done within the helper thread.
This is done by using an alert pipe to wake up the thread if new
data needs to be sent. The thread's sip_threadinfo object contains
the alert pipe as well as the packet queue.
3.Since the threadinfo object contains the alert pipe, it must now be
accessed outside of the helper thread for every write (queuing of a
packet). For easy lookup, I moved the threadinfo objects from a
linked list to an ao2_container.
(closes issue #13136)
Reported by: pabelanger
Tested by: dvossel, whys
(closes issue #15894)
Reported by: dvossel
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/380/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225445 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Telecom Specs in NZ suggests that SUB ADDRESS is always on, so doing
"desk to desk" between offices each with an asterisk box over the ISDN
should then be possible, without a whole load of DDI numbers required.
(closes issue #15604)
Reported by: alecdavis
Patches:
asterisk_subaddr_trunk.diff11.txt uploaded by alecdavis (license 585)
Some minor modificatons were made.
Tested by: alecdavis, rmudgett
Review: https://reviewboard.asterisk.org/r/405/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225357 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch finishes the implementation of OBJ_MULTIPLE in astobj2 (the
case where multiple results need to be returned; OBJ_NODATA mode
already was supported). In addition, it converts ast_channel_iterators
(only the targeted versions, not the ones that iterate over all
channels) to use this method.
During this work, I removed the 'ao2_flags' arguments to the
ast_channel_iterator constructor functions; there were no uses of that
argument yet, there is only one possible flag to pass, and it made the
iterators less 'opaque'. If at some point in the future someone really
needs an ast_channel_iterator that does not lock the container, we can
provide constructor(s) for that purpose.
Review: https://reviewboard.asterisk.org/r/379/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225244 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Two examples of its use are included, and the usage could be expanded in some
cases into certain configuration options where time periods are specified.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224225 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This isn't the best way to do this, but it is the easiest. There are some
limitations that are going to need to be addressed at some point with reloads
and when I (or someone else) work on that, then the API can be updated to
handle passing the private config data that the calendar tech modules need in
a better way as well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@223016 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222878 | russell | 2009-10-08 14:45:47 -0500 (Thu, 08 Oct 2009) | 44 lines
Make filestream frame handling safer by isolating frames before returning them.
This patch is related to a number of issues on the bug tracker that show
crashes related to freeing frames that came from a filestream. A number of
fixes have been made over time while trying to figure out these problems, but
there re still people seeing the crash. (Note that some of these bug reports
include information about other problems. I am specifically addressing
the filestream frame crash here.)
I'm still not clear on what the exact problem is. However, what is _very_
clear is that we have seen quite a few problems over time related to unexpected
behavior when we try to use embedded frames as an optimization. In some cases,
this optimization doesn't really provide much due to improvements made in other
areas.
In this case, the patch modifies filestream handling such that the embedded frame
will not be returned. ast_frisolate() is used to ensure that we end up with a
completely mallocd frame. In reality, though, we will not actually have to malloc
every time. For filestreams, the frame will almost always be allocated and freed
in the same thread. That means that the thread local frame cache will be used.
So, going this route doesn't hurt.
With this patch in place, some people have reported success in not seeing the
crash anymore.
(SWP-150)
(AST-208)
(ABE-1834)
(issue #15609)
Reported by: aragon
Patches:
filestream_frisolate-1.4.diff2.txt uploaded by russell (license 2)
Tested by: aragon, russell
(closes issue #15817)
Reported by: zerohalo
Tested by: zerohalo
(closes issue #15845)
Reported by: marhbere
Review: https://reviewboard.asterisk.org/r/386/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channels are stored in an ao2_container. When accessing an item within
an ao2_container the proper locking order is to first lock the container,
and then the items within it.
In ast_do_masquerade both the clone and original channel must be locked
for the entire duration of the function. The problem with this is that
it attemptes to unlink and link these channels back into the ao2_container
when one of the channel's name changes. This is invalid locking order as
the process of unlinking and linking will lock the ao2_container while
the channels are locked!!! Now, both the channels in do_masquerade are
unlinked from the ao2_container and then locked for the entire function.
At the end of the function both channels are unlocked and linked back
into the container with their new names as hash values.
This new method of requiring all channels and tech pvts to be unlocked
before ast_do_masquerade() or ast_change_name() required several
changes throughout the code base.
(closes issue #15911)
Reported by: russell
Patches:
masq_deadlock_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel, atis
(closes issue #15618)
Reported by: lmsteffan
Patches:
deadlock_local_attended_transfers_trunk.diff uploaded by dvossel (license 671)
Tested by: lmsteffan, dvossel
Review: https://reviewboard.asterisk.org/r/387/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r222152 | kpfleming | 2009-10-05 20:16:36 -0500 (Mon, 05 Oct 2009) | 20 lines
Fix ao2_iterator API to hold references to containers being iterated.
See Mantis issue for details of what prompted this change.
Additional notes:
This patch changes the ao2_iterator API in two ways: F_AO2I_DONTLOCK
has become an enum instead of a macro, with a name that fits our
naming policy; also, it is now necessary to call
ao2_iterator_destroy() on any iterator that has been
created. Currently this only releases the reference to the container
being iterated, but in the future this could also release other
resources used by the iterator, if the iterator implementation changes
to use additional resources.
(closes issue #15987)
Reported by: kpfleming
Review: https://reviewboard.asterisk.org/r/383/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@221266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
JABBER_RECEIVE (along with JabberSend) makes Asterisk interact with users over
XMPP to process calls.
SendText can be used instead of JabberSend in the context of XMPP based voice
channels (chan_gtalk and chan_jingle).
(closes issue #12569)
Reported by: eech55
Tested by: phsultan, asannucci, lmadsen, jtodd, maxgo
Review: https://reviewboard.asterisk.org/r/88/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the functionality here is gained simply by setting the feature flag
on the bridge config. However, the dial limit functionality has been moved from
app_dial to the features code and has been made public so both app_dial and
the bridge app can use it.
(closes issue #13165)
Reported by: tim_ringenbach
Patches:
app_bridge_options_r138998.diff uploaded by tim ringenbach (license 540),
modified by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit adds the doxygen changes that I've made to describe the Mantis
work flow documentation for the open source issue tracker. This should make
it easier to determine the flow of issues through the issue tracker, and what
those statuses mean.
(closes issue #15902)
Reported by: lmadsen
Patches:
mantisworkflow.h uploaded by lmadsen (license 10)
Review: https://reviewboard.asterisk.org/r/367/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r219136 | mnicholson | 2009-09-17 09:58:39 -0500 (Thu, 17 Sep 2009) | 10 lines
Prevent a potential race condition and crash when hanging up a channel by removing the channel from the channel list before begining channel tear down.
This fix may potentially cause problems with CDR backends that access the channel a CDR is associated with via the channel list. This fix makes the channel unavabile at the time when the CDR backend is invoked. This has been documented in include/asterisk/cdr.h.
(closes issue #15316)
Reported by: vmarrone
Tested by: mnicholson
Review: https://reviewboard.asterisk.org/r/362/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@219139 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent change to the configure script that allows the user to specify
CFLAGS and/or LDFLAGS to the script had the unfortunate side effect of
letting autoconf's default CFLAGS (-g -O2) feed in to the rest of the build
system, thereby overriding the DONT_OPTIMIZE setting in menuselect. That
problem is now corrected.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@217074 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added detection of DTMF tone energy levels on FXO channels in chan_dahdi
monitoring loop so DTMF CID can be detected without the need of a polarity
change precursor.
(closes issue #9096)
Reported by: fleed
Patches:
9096-chan_dahdi-trunk.diff uploaded by dbailey (license 819)
Tested by: cyberplant, sum, maturs
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@216094 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This did not function in the way that was intended, causing more compatibility
issues than it solved. It is best, therefore, that it be simply removed.
(Discussed with kpfleming; agreement to remove was reached.)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@215800 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One note on defining _POSIX_C_SOURCE: while this feature test macro
works to require certain behaviors on Linux, it works differently on *BSD
platforms to REMOVE certain API calls that are not in the POSIX specification,
such as vasprintf(3). Thus, defining it while depending upon vasprintf (and
other extensions to the POSIX standard) to be defined is a recipe to ensure
that Asterisk is only buildable on Linux.
Hence, this define which was meant to INCREASE portability, effectively
ensures the opposite.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214863 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cross-compilation environments want to provide 'defaults' for compiler and
linker options, and frequently do this by specifying CFLAGS and LDFLAGS in the
environment or as command-line arguments to the configure script. This patch
modifies the configure script and Makefile to preserve these settings and
ensure they are used in the build process.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@214696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It's not clear that we actually require XOPEN_VERSION to be 600 or greater
at this time, so skip the check for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Based on a post on the gcc-help mailing list and some subsequent reading,
we can increase our portability to various platforms by directly defining
the POSIX and X/OPEN API feature sets we wish to have available. This patch
does that, and also includes a double-check to ensure that the system
we are compiling on can actually provide the requested feature sets.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@212463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch makes some small changes to handle watchdog timeouts in a better way,
and also uses a 'cleaner' method of including the spandsp header files.
(closes issue #14769)
Reported by: andrew
Patches:
app_fax-20090406.diff uploaded by andrew (license 240)
v1-14769.patch uploaded by dimas (license 88)
Tested by: freh, deti, caspy, dimas, sgimeno, Dovid
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@210777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The udptl-updates branch that was merged yesterday failed to properly send back
T.38 SDP responses with the correct error correction mode, if the incoming SDP
from the other end caused us to change error correction modes. This patch
corrects that situation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208548 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Over the past couple of months, a number of issues with Asterisk
negotiating (and successfully completing) T.38 sessions with various
endpoints have been found. This patch attempts to address many of
them, primarily focused around ensuring that the endpoints'
MaxDatagram size is honored, and in addition by ensuring that T.38
session parameter negotiation is performed correctly according to the
ITU T.38 Recommendation.
The major changes here are:
1) T.38 applications in Asterisk (app_fax) only generate/receive IFP
packets, they do not ever work with UDPTL packets. As a result of
this, they cannot be allowed to generate packets that would overflow
the other endpoints' MaxDatagram size after the UDPTL stack adds any
error correction information. With this patch, the application is told
the maximum *IFP* size it can generate, based on a calculation using
the far end MaxDatagram size and the active error correction mode on
the T.38 session. The same is true for sending *our* MaxDatagram size
to the remote endpoint; it is computed from the value that the
application says it can accept (for a single IFP packet) combined with
the active error correction mode.
2) All treatment of T.38 session parameters as 'capabilities' in
chan_sip has been removed; these parameters are not at all like
audio/video stream capabilities. There are strict rules to follow for
computing an answer to a T.38 offer, and chan_sip now follows those
rules, using the desired parameters from the application (or channel)
that wants to accept the T.38 negotiation.
3) chan_sip now stores and forwards ast_control_t38_parameters
structures for tracking 'our' and 'their' T.38 session parameters;
this greatly simplifies negotiation, especially for pass-through
calls.
4) Since T.38 negotiation without specifying parameters or receiving
the final negotiated parameters is not very worthwhile, the
AST_CONTROL_T38 control frame has been removed. A note has been added
to UPGRADE.txt about this removal, since any out-of-tree applications
that use it will no longer function properly until they are upgraded
to use AST_CONTROL_T38_PARAMETERS.
Review: https://reviewboard.asterisk.org/r/310/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@208464 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces the security events API. This API is to be used by
Asterisk components to report events that have security implications.
A simple example is when a connection is made but fails authentication. These
events can be used by external tools manipulate firewall rules or something
similar after detecting unusual activity based on security events.
Inside of Asterisk, the events go through the ast_event API. This means that
they have a binary encoding, and it is easy to write code to subscribe to these
events and do something with them.
One module is provided that is a subscriber to these events - res_security_log.
This module turns security events into a parseable text format and sends them
to the "security" logger level. Using logger.conf, these log entries may be
sent to a file, or to syslog.
One service, AMI, has been fully updated for reporting security events.
AMI was chosen as it was a fairly straight forward service to convert.
The next target will be chan_sip. That will be more complicated and will
be done as its own project as the next phase of security events work.
For more information on the security events framework, see the documentation
generated from doc/tex/. "make asterisk.pdf"
Review: https://reviewboard.asterisk.org/r/273/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@206021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).
This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.
(closes issue #14849)
Reported by: afosorio
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@205696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Tilghman Lesher
David Vossel
Richard Mudgett
Leif Madsen
Jonathan Rose
Terry Wilson
Paul Belanger
Matthew Nicholson
Russell Bryant
Jeff Peeler
Stefan Schmidt
Jason Parker
Jan Kalab
Olle Johansson
Mark Michelson
Eliel C. Sardanons
Julian Lyndon-Smith
Kevin P. Fleming
Sean Bright
David Brooks
Philippe Sultan
Michiel van Baak
Doug Bailey
Joshua Colp