This uses the calling channel's caller ID and connected line information
to populate the remote and local identities in the dialog-info NOTIFY when
an extension is ringing.
There is a bit of an oddity here, and that is that we seed the remote target
with the To header of the outbound call rather than the from header. This
is because it was reported that seeding with the from header caused hints
to be broken with certain SNOM devices. A comment has been added to the code
to explain this.
(closes issue ASTERISK-16735)
reported by Maciej Krajewski
patches:
local_remote_hint2.diff uploaded by Mark Michelson (license #5049)
16735_tweak1.diff uploaded by Mark Michelson (license #5049)
Tested by Niccolo Belli
........
Merged revisions 365574 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365575 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The VoiceMail d([c]) option is documented to accept digits for a new extension
in context <c>, if played during the greeting. This option works fine if the
extension being redirected to has an extension with the same initial digit in
the channel's current context. If that digit did not happen to exist in some
extension, a dialplan match would fail and the user would not be redirected.
This patch fixes it such that if the <c> option is used, the extensions are
matched in that context as opposed to the caller's original context.
(closes issue ASTERISK-18243)
Reported by: mjordan
Tested by: mjordan
Review: https://reviewboard.asterisk.org/r/1892
........
Merged revisions 365474 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365475 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the changes here are trivial NULL checks. There are a couple
optimizations to remove the need to check for NULL and outboundproxy parsing
in chan_sip.c was rewritten to avoid use of strtok. Additionally, a bug was
found and fixed with the parsing of outboundproxy when "outboundproxy=," was
set.
(Closes issue ASTERISK-19654)
........
Merged revisions 365398 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365399 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made chan_local.c:check_bridge() check the return value of
ast_channel_masquerade(). In long chains of local channels, the
masquerade occasionally fails to get setup because there is another
masquerade already setup on an adjacent local channel in the chain.
* Made the outgoing local channel (the ;2 channel) flush one voice or
video frame per optimization attempt.
* Made sure that the outgoing local channel also does not have any frames
in its queue before the masquerade.
* Made do the masquerade immediately to minimize the chance that the
outgoing channel queue does not get any new frames added and thus
unconditionally flushed.
* Made block indication -1 (Stop tones) event when the local channel is
going to optimize itself out. When the call is answered, a chain of local
channels pass down a -1 indication for each bridge. This blizzard of -1
events really slows down the optimization process.
(closes issue ASTERISK-16711)
Reported by: Alec Davis
Tested by: rmudgett, Alec Davis
Review: https://reviewboard.asterisk.org/r/1894/
........
Merged revisions 365313 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365320 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These three all are in RTP code that attempts to print the number of sequence number cycles
in an RTCP RR report. The code was masking out the upper 16 bits and then shifting the number
right by 16 bits. This led to an all zero result in all cases. The fix is to do the shift without
the bit masking.
(issue ASTERISK-19649)
........
Merged revisions 365298 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365299 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The security events framework API was changed in Asterisk 10 but the unit tests
were not updated at the same time.
This patch does the following:
* Adds two more security events that were added to the API
* Add challenge, received_challenge and received_hash in the inval_password
security event unit test
(Closes issue ASTERISK-19760)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
issue-asterisk-19760-trunk.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1897/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r365006 | twilson | 2012-05-02 10:49:03 -0500 (Wed, 02 May 2012) | 12 lines
Fix a CEL LINKEDID_END race and local channel linkedids
This patch has the ;2 channel inherit the linkedid of the ;1 channel and fixes
the race condition by no longer scanning the channel list for "other" channels
with the same linkedid. Instead, cel.c has an ao2 container of linkedid strings
and uses the refcount of the string as a counter of how many channels with the
linkedid exist. Not only does this eliminate the race condition, but it also
allows us to look up the linkedid by the hashed key instead of traversing the
entire channel list.
Review: https://reviewboard.asterisk.org/r/1895/
........
r365068 | twilson | 2012-05-02 12:02:39 -0500 (Wed, 02 May 2012) | 11 lines
Don't leak a ref if out of memory and can't link the linkedid
If the ao2_link fails, we are most likely out of memory and bad things
are going to happen. Before those bad things happen, make sure to clean
up the linkedid references.
This patch also adds a comment explaining why linkedid can't be passed
to both local channel allocations and combines two ao2_ref calls into 1.
Review: https://reviewboard.asterisk.org/r/1895/
........
Merged revisions 365006,365068 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365083 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
Update security events unit tests
The security events framework API was changed in Asterisk 10 but the unit tests
were not updated at the same time.
This patch does the following:
* Adds two more security events that were added to the API
* Add challenge, received_challenge and received_hash in the inval_password
security event unit test
(issue ASTERISK-19760)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
issue-asterisk-19760-branch10.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1877/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365016 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In audiohook_read_frame_both, anytime samples are obtained from the read/write
factories a debug statement is logged stating that samples were not obtained
from the factories. This statement used to only occur if option_debug was
turned on and no samples were obtained; in some refactoring when the
option_debug statement was removed, the "else" clause was removed as well.
This patch makes it so that those debug log statements only occur if the
condition leading up to them actually happened.
........
Merged revisions 364965 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364966 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reason I'm removing this is that Coverity reported a STRAY_SEMICOLON
issue here. Since the function has been unused for so long, I just elected
to remove it altogether.
(closes issue ASTERISK-19660)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As it turned out, this wasn't a huge deal. We were calling
ast_app_parse_options() for a set of options of which none
took arguments. The proper thing to do for this case is to
pass NULL for the "args" parameter here. We were instead passing
a seemingly-randomly chosen char * from the function. While this
would never get written to, you can rest assured things would
have gotten bad had new options (which took arguments) been added
to func_volume.
(closes issue ASTERISK-19656)
........
Merged revisions 364899 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364900 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 360862 was intended to improve identities sent in dialog-info
NOTIFY requests. Some users reported that hint became broken once this
was done. It's not clear exactly what part of the patch has caused this
regression, but broken hints are bad.
For now, this revision is being reverted so that the next releases of
Asterisk do not have bad behavior in them. The original reported issue
will have to be fixed differently in the next version of Asterisk.
(issue ASTERISK-16735)
........
Merged revisions 364706 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364707 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The configuration option to specify a custom sound_leader_has_left file for a
conference bridge was not being parsed. This patch fixes it so that a custom
sound file will now be used.
(closes issue ASTERISK-19771)
Reported by: Pawel Kuzak
Tested by: Pawel Kuzak, Michael L. Young
Patches: leaderhasleft_sound.dpatch uploaded by Pawel Kuzak (license 6380)
Review: https://reviewboard.asterisk.org/r/1884/
........
Merged revisions 364536 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If enabled using the keepalive option in sip.conf a small packet will be sent
at a regular interval to keep the NAT mapping open. This is lightweight as the
remote side does not need to parse and handle a SIP message.
(closes issue AST-783)
Review: https://reviewboard.asterisk.org/r/1756/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
md5.c: In function ‘MD5Final’:
md5.c:154:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
md5.c:155:2: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
There is an md5 unit test and it still passes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364462 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The warnings were about argv[0] being used uninitialized, which is correct.
Just remove setting username to this value, since username is set again before
it actually gets used.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add two new dialplan functions: FEATURE() and FEATUREMAP(). FEATURE()
lets you set some of the configuration options from the [general] section
of features.conf on a per-channel basis. FEATUREMAP() lets you customize
the key sequence used to activate built-in features, such as blindxfer,
and automon. See the built-in documentation for details.
Review: https://reviewboard.asterisk.org/r/1871/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r364365 | twilson | 2012-04-27 17:31:01 -0500 (Fri, 27 Apr 2012) | 11 lines
Fix ast_parse_arg numeric type range checking and add tests
ast_parse_arg wasn't checking for strto* parse errors or limiting
the results by the actual range of the numeric types. This patch fixes
that and adds unit tests as well.
Review: https://reviewboard.asterisk.org/r/1879/
........
Merged revisions 364340 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
r364369 | twilson | 2012-04-27 17:33:10 -0500 (Fri, 27 Apr 2012) | 2 lines
Add missing test_config.c
........
Merged revisions 364365,364369 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364397 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The method ast_tvdiff_ms attempts to calculate the difference, in milliseconds,
between two timeval structs, and return the difference in a 64-bit integer.
Unfortunately, it assumes that the long tv_sec/tv_usec members in the timeval
struct are large enough to hold the calculated values before it returns. On
64-bit machines, this might be the case, as a long may be 64-bits. On 32-bit
machines, however, a long may be less (32-bits), in which case, the calculation
can overflow.
This overflow caused significant problems in MixMonitor, which uses the method
to determine if an audio factory, which has not presented audio to an audiohook,
is merely late in providing said audio or will never provide audio. In an
overflow situation, the audiohook would incorrectly determine that an audio
factory that will never provide audio is merely late instead. This led to
situations where a MixMonitor never recorded any audio. Note that this happened
most frequently when that MixMonitor was started by the ConfBridge application
itself, or when the MixMonitor was attached to a Local channel.
(issue ASTERISK-19497)
Reported by: Ben Klang
Tested by: Ben Klang
Patches:
32-bit-time-overflow-10-2012-04-26.diff (license #6283) by mjordan
(closes issue ASTERISK-19727)
Reported by: Mark Murawski
Tested by: Michael L. Young
Patches:
32-bit-time-overflow-2012-04-27.diff (license #6283) by mjordan)
(closes issue ASTERISK-19471)
Reported by: feyfre
Tested by: feyfre
(issue ASTERISK-19426)
Reported by: Johan Wilfer
Review: https://reviewboard.asterisk.org/r/1889/
........
Merged revisions 364277 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364285 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unref the SIP pvt stored in the refer structure as soon as it is no longer
needed so that the pvt and associated file descriptors can be freed sooner.
This change makes a reference decrement unnecessary in code that handles SIP
BYE/Also transfers which should not touch the reference anyway.
(Closes issue ASTERISK-19579)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
........
Merged revisions 364258 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364259 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog. This can occur, for example, when
certain phones request a SIP hold.
Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored. This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.
(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Review: https://reviewboard.asteriskorg/r/1885/
........
Merged revisions 364203 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364204 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When party B does an attended transfer of party A to party C, the
attending bridge between party B and C should not be running an h exten
when the bridge ends. Running an h exten now sets a softhangup flag to
ensure that an AGI will run in dead AGI mode.
* Set the AST_FLAG_BRIDGE_HANGUP_DONT on the party B channel for the
attending bridge between party B and C.
(closes issue AST-870)
(closes issue ASTERISK-19717)
Reported by: Mario
(closes issue ASTERISK-19633)
Reported by: Andrey Solovyev
Patches:
jira_asterisk_19633_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett, Andrey Solovyev, Mario
........
Merged revisions 364060 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364065 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reference held for SIP blind transfers using the Replaces header in an
INVITE was never freed on success and also failed to be freed in some error
conditions. This caused a file descriptor leak since the RTP structures in use
at the time of the transfer were never freed. This reference leak and another
relating to subscriptions in the same code path have now been corrected.
(closes issue ASTERISK-19579)
........
Merged revisions 363986 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363987 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363988 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Richard Mudgett
Mark Michelson
Matthew Jordan
Kinsey Moore
Michael L. Young
Sean Bright
Alexandr Anikin
Terry Wilson
Jason Parker
Jonathan Rose
Mark Murawki
Joshua Colp
Russell Bryant
Stefan Schmidt
Olle Johansson