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
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
Some switches may not handle the call-deflection/call-rerouting message if
the call is disconnected too soon after being sent. Asteisk was not
waiting for any reply before disconnecting the call.
* Added a 5 second delay before disconnecting the call to wait for a
potential response if the peer does not disconnect first.
(closes issue ASTERISK-19708)
Reported by: mehdi Shirazi
Patches:
jira_asterisk_19708_v1.8.patch (license #5621) patch uploaded by rmudgett
Tested by: rmudgett
........
Merged revisions 363730 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363734 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some ISDN switches occasionally fail to send a RESTART ACKNOWLEDGE in
response to a RESTART request.
* Made the second SETUP received after sending a RESTART request clear the
channel resetting state as if the peer had sent the expected RESTART
ACKNOWLEDGE before continuing to process the SETUP. The peer may not be
sending the expected RESTART ACKNOWLEDGE.
(issue ASTERISK-19608)
(issue AST-844)
(issue AST-815)
Patches:
jira_ast_815_v1.8.patch (license #5621) patch uploaded by rmudgett (modified)
........
Merged revisions 363687 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363688 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363689 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If Asterisk receives a SIP UPDATE request after a call has been terminated and
the channel has been destroyed but before the SIP dialog has been destroyed, a
condition exists where a connected line update would be attempted on a
non-existing channel. This would cause Asterisk to crash. The patch resolves
this by first ensuring that the SIP dialog has an owning channel before
attempting a connected line update. If an UPDATE request is received and no
channel is associated with the dialog, a 481 response is sent.
(closes issue ASTERISK-19770)
Reported by: Thomas Arimont
Tested by: Matt Jordan
Patches:
ASTERISK-19278-2012-04-16.diff uploaded by Matt Jordan (license 6283)
........
Merged revisions 363106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363107 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling a keypad button message event, the received digit is placed into
a fixed length buffer that acts as a queue. When a new message event is
received, the length of that buffer is not checked before placing the new digit
on the end of the queue. The situation exists where sufficient keypad button
message events would occur that would cause the buffer to be overrun. This
patch explicitly checks that there is sufficient room in the buffer before
appending a new digit.
(closes issue ASTERISK-19592)
Reported by: Russell Bryant
........
Merged revisions 363100 from http://svn.asterisk.org/svn/asterisk/branches/1.6.2
........
Merged revisions 363102 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363103 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The CHANNEL_DEADLOCK_AVOIDANCE() feature of preserving where the channel
lock was originally obtained is overkill where ast_channel_lock_both() was
inlined.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ISDN ETSI PTP and Q.SIG (And SS7 in future) have support for reporting who
was the original redirecting party of a call.
* Added support for the original redirecting party and reason to the
REDIRECTING function and the system core as well as to the stubbed
locations in sig_pri.c.
Review: https://reviewboard.asterisk.org/r/1829/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_mobile: Fixed an overrun where the cind_state buffer (an integer array
of size 16) would be overrun due to improper bounds checking. At worst, the
buffer can be overrun by a total of 48 bytes (assuming 4-byte integers),
which would still leave it within the allocated memory of struct hfp. This
would corrupt other elements in that struct but not necessarily cause any
further issues.
* app_sms: The array imsg is of size 250, while the array (ud) that the data
is copied into is of size 160. If the size of the inbound message is
greater then 160, up to 90 bytes could be overrun in ud. This would corrupt
the user data header (array udh) adjacent to ud.
* chan_unistim: A number of invalid memmoves are corrected. These would move
data (which may or may not be valid) into the ends of these buffers.
* asterisk: ast_console_toggle_loglevel does not check that the console log
level being set is less then or equal to the allowed log levels of 32.
* format_pref: In ast_codec_pref_prepend, if any occurrence of the specified
codec is not found, the value used to index into the array pref->order
would be one greater then the maximum size of the array.
* jitterbuf: If the element being placed into the jitter buffer lands in the
last available slot in the jitter history buffer, the insertion sort attempts
to move the last entry in the buffer into one slot past the maximum length
of the buffer. Note that this occurred for both the min and max jitter
history buffers.
* tdd: If a read from fsk_serial returns a character that is greater then 32,
an attempt to read past one of the statically defined arrays containing the
values that character maps to would occur.
* localtime: struct ast_time and tm are not the same size - ast_time is larger,
although it contains the elements of tm within it in the same layout. Hence,
when using memcpy to copy the contents of tm into ast_time, the size of tm
should be used, as opposed to the size of ast_time.
* extconf: this treats ast_timing's minmask array as if it had a length of 48,
when it has defined the size of the array as 24. pbx.h defines minmask as
having a size of 48.
(issue ASTERISK-19668)
Reported by: Matt Jordan
........
Merged revisions 362485 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362496 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several telcos bring the BRI PTMP layer 1 down when the line is idle.
When layer 1 goes down, Asterisk cannot make outgoing calls. Incoming
calls could fail as well because the alarm processing is handled by a
different code path than the Q.931 messages.
* Add the layer1_presence configuration option to ignore layer 1 alarms
when the telco brings layer 1 down. This option can be configured by span
while the similar DAHDI driver teignorered=1 option is system wide. This
option unlike layer2_persistence does not require libpri v1.4.13 or newer.
Related to JIRA AST-598
JIRA ABE-2845
........
Merged revisions 362428 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362429 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bind address is set to an ANY address (udpbindport=::), a warning message
is displayed stating that "Address remapping activated in sip.conf but we're
using IPv6, which doesn't need it. Please remove 'localnet' and/or 'externaddr'
settings." But if one is running dual stack, we shouldn't be told to turn those
settings off.
This patch checks if the bind address is an ANY address or not. The warning
message will now only be displayed if the bind address is NOT an ANY address and
IPv6 is being used.
Also, updated the copyright year.
(closes issue ASTERISK-19456)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
chan_sip_ipv6_message.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 362253 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362264 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In chan_agent, while handling a channel indicate, the agent channel driver
must obtain a lock on both the agent channel, as well as the channel the
agent channel is using. To do so, it attempts to lock the other channel
first, then unlock the agent channel which is locked prior to entry into
the indicate handler. If this unlock fails with a negative return value,
which can occur if the object passed to agent_indicate is an invalid ao2
object or is NULL, the return value is passed directly to strerror, which
can only accept positive integer values.
In chan_dahdi, the return value of dahdi_get_index is used to directly
index into the sub-channel array. If dahd_get_index returns a negative
value, it would use that value to index into the array, which could cause
an invalid memory access. If dahdi_get_index returns a negative number,
we now default to SUB_REAL.
(issue ASTERISK-19655)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1863/
........
Merged revisions 362204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362205 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The current Security Events Framework API only supports IPv4 when it comes to
generating security events. This patch does the following:
* Changes the Security Events Framework API to support IPV6 and updates
the components that use this API.
* Eliminates an error message that was being generated since the current
implementation was treating an IPv6 socket address as if it was IPv4.
* Some copyright dates were updated on files touched by this patch.
(closes issue ASTERISK-19447)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
security_events_ipv6v3.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1777/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the MWI processing loop, when a valid event occurs the temporary caller ID
information is deallocated. If a new DAHDI channel is successfully created,
the event is passed up to the analog_ss_thread without error and the loop
exits. If, however, the DAHDI channel is not created, then the caller ID
struct has been free'd, and the gains reset to their previous level. This
will almost certainly cause an invalid access to the free'd memory, either
in subsequent calls to callerid_free or calls to callerid_feed.
* Rework the -r361705 patch to better manage the cs and mtd allocated
resources.
* Fixed use of mwimonitoractive flag to be correct if the mwi_thread()
fails to start.
........
Merged revisions 361854 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361855 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361856 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the MWI processing loop, when a valid event occurs the temporary caller ID
information is deallocated. If a new DAHDI channel is successfully created,
the event is passed up to the analog_ss_thread without error and the loop
exits. If, however, the DAHDI channel is not created, then the caller ID
struct has been free'd, and the gains reset to their previous level. This
will almost certainly cause an invalid access to the free'd memory, either
in subsequent calls to callerid_free or calls to callerid_feed.
This patch makes it so that we only free the caller ID structure if a
DAHDI channel is successfully created, and we bump the gains back up
if we fail to make a DAHDI channel.
........
Merged revisions 361705 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 361706 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@361707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes use of connected party information in addition to caller ID in order
to populate local and remote XML elements in the dialog-info NOTIFYs.
(closes issue ASTERISK-16735)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
Patches:
local_remote_hint2.diff uploaded by Mark Michelson (license 5049)
........
Merged revisions 360862 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360863 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is just a minor code cleanup change. These uses of ao2_callback() would
never return anything since the callbacks always returned 0. However, be more
explicit that no returned results are wanted by specifying OBJ_NODATA.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Q.951 indicates that when the presentation indicator is "Number not
available due to interworking" for a number then the screening indicator
field should be "Network provided".
* Made ast_party_id_presentation() return AST_PRES_NUMBER_NOT_AVAILABLE
when the presentation is "Number not available due to interworking". This
fix makes Asterisk consistent and it also makes it consistent with earlier
branches as far as this presentation value is concerned.
* Made pri_to_ast_presentation() and ast_to_pri_presentation() conversions
handle the "Number not available due to interworking" case better in
sig_pri.c. This change is possible because the minimum required libpri
version (v1.4.11) has the necessary defines in libpri.h.
........
Merged revisions 360309 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360310 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk detects a hangup and cannot send a BYE due to a pending
INVITE, it sets the pendingbye flag and waits for the final response to that
INVITE. When the response is received, it transmits the BYE. If, however,
that INVITE request is a pending re-INVITE, it needs to first send a CANCEL
request to terminate the pending re-INVITE. In that circumstance, Asterisk
was, in some scenarios, clearing the pendingbye flag after processing the
CANCEL request and not checking for a pending BYE when receiving the final
487 response to the INVITE.
This patch ensures that if the pendingbye flag is set, it is honored
regardless of the nature of the INVITE request currently in flight.
(closes issue ASTERISK-19365)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
bugASTERISK-19365_2012_03_08.patch uploaded by mjordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1807
........
Merged revisions 360086 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360088 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added new chan_dahdi.conf colp_send option parameter to block connected
line updates per span.
(closes issue ASTERISK-17025)
Reported by: Michael Smith
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added ability to use multiple lines on phone, so for one device in configuration multiple lines can be defined, it allows to have multiple calls on one phone, callwaiting and switching between calls.
* Added ability for translation on-screen menu to multiple languages. Tested on Russian languages. Supported encodings: ISO 8859-1, ISO 8859-2, ISO 8859-4, ISO 8859-5, ISO 2022-JP. Language controlled by 'language' and on-screen menu of phone
* Other described in CHANGES file
Testing done by issue tracker users: ibercom, scsiborg, idarwin, TeknoJuce, c0rnoTa.
Tested on production system by Jonn Taylor (jonnt) using phone models: Nortel i2004, 1120E and 1140E.
(closes issue ASTERISK-16890)
Review: https://reviewboard.asterisk.org/r/1243/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For analog lines, enables Asterisk to use dialtone detection per channel
if an incoming call was hung up before it was answered. If dialtone is
detected, the call is hung up.
no: Disabled. (Default)
yes: Look for dialtone for 10000 ms after answer.
<number>: Look for dialtone for the specified number of ms after answer.
always: Look for dialtone for the entire call. Dialtone may return
if the far end hangs up first.
dialtone_detect=yes
dialtone_detect=5000
dialtone_detect=always
(closes issue ASTERISK-19316)
Reported by: Jeremy Pepper
Patch by: Jeremy Pepper
Tested by: rmudgett,Jeremy Pepper
Review: https://reviewboard.asterisk.org/r/1737/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@358344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
