Callerid checksum-ing was being handled incorrectly here. When the checksum is
calculated to be 0x00, it will perform 0x100-0x00 which results in 0x100. This
value will then fail the otherwise correct callerid message.
This patch changes the logic to simply add the calculated checksum to the
transmitted 2's compliment checksum.
Review: https://reviewboard.asterisk.org/r/3356/
(closes issue ASTERISK-23488)
........
Merged revisions 410710 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The syncing thread sleeps for a second before waiting to be
told to attempt to sync again. If a signal were sent during this
sleeping period, we would end up having to wait until the next
sync signal occurred in order to sync up the astdb.
This code rearrangement also ensures that any pending transactions
will be synced prior to Asterisk shutting down.
Patches: db_sync.patch by John Hardin (License #6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410556 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When MOH is playing to a user in a conference and the user is kicked or
hangs up from the conference then the AMI MusicOnHoldStop events didn't
happen. (Asterisk v11 AMI event: MusicOnHold, state:Stop)
(closes issue ASTERISK-23311)
Reported by: Benjamin Keith Ford
Review: https://reviewboard.asterisk.org/r/3306/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending a HTTP request that is handled by Asterisk with a large number of
Cookie headers could overflow the stack.
Another vulnerability along similar lines is any HTTP request with a
ridiculous number of headers in the request could exhaust system memory.
(closes issue ASTERISK-23340)
Reported by: Lucas Molas, researcher at Programa STIC, Fundacion; and Dr. Manuel Sadosky, Buenos Aires, Argentina
........
Merged revisions 410380 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to avoid creation of the channel and
consumption of associated file descriptors altogether if the inbound
request is going to be rejected anyway.
(closes issue ASTERISK-23373)
Reported by: Corey Farrell
Patches:
chan_sip-earlier-st-1.8.patch uploaded by Corey Farrell (license 5909)
chan_sip-earlier-st-11.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 410308 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a static realtime peer with qualify=yes is loaded, Asterisk will fail to
send an OPTIONS request due to the lastms being equal to 0. This results in
the peer being unable to receive calls from Asterisk because the status is
permanently UNKNOWN.
This patch allows an OPTIONS request to be sent during module load by
ignoring the lastms value on startup only.
Review: https://reviewboard.asterisk.org/r/3294/
(closes issue ASTERISK-17523)
Reported by: Maciej Krajewski
Tested by: wushumasters
patches:
realtime_fix_11.7.0.txt uploaded by Trevor Peirce (license 6112)
........
Merged revisions 410105 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I observed a crash in res_musiconhold on an Asterisk 11 system using realtime
MOH. Investigation of the backtrace showed a corrupt mohclass, implying that
it got destroyed before the code expected it to. I went looking for reference
counting errors that could have caused this crash and this patch this result.
It contains 2 changes.
1) Remove a usless block of code that was impossible to reach. There was even
a comment indicating that it was impossible to reach. The conditional includes
"!ast_test_flag(global_flags, MOH_CACHERTCLASSES)" and it's inside of an if
block with the opposite check "ast_test_flag(global_flags,
MOH_CACHERTCLASSES)". There's no good reason to keep it around.
2) A similar block to #1 contained a reference counting error. It stores
state->class in the local variable mohclass without increasing its reference
count. The reference count on mohclass is decremented at the end of the
function. This block of code probably very rarely runs, which would help
explain why this system was working fine for many months before experiencing a
crash.
Review: https://reviewboard.asterisk.org/r/3282/
........
Merged revisions 410043 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@410044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When acting as a T.38 fax gateway, res_fax_spandsp would at times cause a crash
in libspandsp. This would occur when, during fax tone detection, a ulaw/alaw
frame would be passed to modem_connect_tones_rx. That particular routine
expects the data to be in slin format. This patch looks at the frame type and,
if the data is ulaw/alaw, converts the format to slin before passing it to
modem_connect_tones_rx.
Review: https://reviewboard.asterisk.org/r/3296
(closes issue ASTERISK-20149)
Reported by: Alexandr Gordeev
Tested by: Michal Rybarik
patches:
spandsp_g711decode.diff uploaded by Michal Rybarik (license 6578)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409990 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The test of the result of the stat() call was inverted such that its
output was only used if the call failed. This inverts the test so that
the output of stat() is used correctly. This was causing full reloads
on unchanged files.
(closes issue ASTERISK-23383)
Reported by: David Woolley
........
Merged revisions 409916 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When nanosecond time resolution was added for identifying config file
changes, it didn't cover all of the myriad of ways that one might obtain
nanosecond time resolution off of struct stat.
Rather than complicate the #if even further figuring out one system from
the next, this patch directly tests for the three struct members I know
about today, and #ifdef's accordingly.
Review: https://reviewboard.asterisk.org/r/3273/
........
Merged revisions 409833 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- Fixed too early RTP setup with phone, that cause no ringback tone on caller side
- Handle call transfer cancel only in STATE_CALL case (related to ASTERISK-23073)
(Reported by: Németh Tamás, niurkin sil)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409761 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Several fixes for the WebSockets implementation in res/res_http_websocket.c
* Flush the websocket session FILE* as fwrite() may not actually guarantee sending
the data to the network. If we do not flush, it seems that buffering on the SSL
socket for outbound messages causes issues
* Refactored ast_websocket_read to take into account that SSL file descriptors
may be ready to read via fread() but poll() will not actually say so because
the data was already read from the network buffers and is now in the libc buffers
(closes issue ASTERISK-23099)
(closes issue ASTERISK-21930)
Review: https://reviewboard.asterisk.org/r/3248/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Upon failure of an INVITE transaction meant to initiate a remote native
bridge, rtp_engine.c would not clean up non-reference-counted bridge
instance pointers leaving a dangling pointer which was being used to
perform a local native bridge after the other channel had hung up. This
lead to dereferencing into freed memory and plenty of AO2 errors. This
change allows the remote native bridge loop to clean up properly when
the bridge fails.
(closes issue ASTERISK-23310)
Reported by: Jeremy Laine
........
Merged revisions 409521 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for QueueMemberPaused was causing documentation
generation to fail because the documentation for that AMI event was in
the wrong location. This moves that documentation the correct location
and adds a missing parameter.
(closes issue SWDAT-261)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix crash in ast_channel_hangupcause_set() because p->owner not checked
before calling. Regression introduced by the fix for ASTERISK-22621.
(closes issue ASTERISK-23135)
Reported by: OK
(issue ASTERISK-23323)
Reported by: Walter Doekes
........
Merged revisions 409156 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, local candidate lists including SRFLX would fail to start
properly when building ICE candidate check lists. This patch fixes that problem
by making sure that each SRFLX candidate is associated with the proper
base address so that the check list can create matches properly.
This patch was written by jcolp. The issue will be left open to await testing
by the issue participants.
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409129 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This memset complained in dev mod on my Ubuntu box. The memset is both
unnecessary and dangerous. At this point, m hasn't been initialized
yet, so the memset will write off to whatever address happens to be
on the stack at the time.
........
Merged revisions 409077 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Change minrate from 2400 to 4800 on config reload in response to changes from
ASTERISK-22790 only. Any config with minrate of 2400 that would fail before
r405693 will still fail.
Comment out many settings in res_fax.conf.sample. The defaults are set in
res_fax.c, so setting the same value in sample config does nothing but make
the sample config more fragile.
(closes issue ASTERISK-23231)
Reported by: David Brillert
Review: https://reviewboard.asterisk.org/r/3261/
........
Merged revisions 409052 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When two RTP channels are in a remote bridge, the remote bridging loop in
rtp_engine will periodically check to see if the two channels can still be
bridged. One of the many things it checks is whether or not the codecs have
changed on the channel. If the codec has changed, it will break out of the
loop to re-determine which type of bridge is appropriate.
In order to perform this check, the ast_rtp_glue virtual table's get_codec
callback is called for each channel. The callback implementations assume
that the channel tech private is valid when called; as such, there has
always been some code in place to check whether or not the channel pvt is
NULL before calling. However, this check is insufficient.
The channels are unlocked during the remote bridging loop. It is possible
for a channel to get masqueraded between the check for the pvt being NULL and
the actual call to get_codec. When this occurs, the callback is called with a
ZOMBIE channel, which now has a NULL pvt. Crash.
While this has always been possible in Asterisk 1.8, it is much more likely to
occur in Asterisk 11 and later versions due to the timing changes that occur
when getting the codec from a channel. Note that this is much more likely to be
reproduced on slow, boggy hardware running Asterisk 11 - but fairly rarely
otherwise.
Also Note: This crash was also caught by the various SIP blind transfer tests,
in addition to the bug report Alec filed.
Review: https://reviewboard.asterisk.org/r/3247/
(closes issue ASTERISK-21737)
Reported by: Alec Davis
Tested by: Alec Davis
........
Merged revisions 409001 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@409002 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the 'v' option is specified to ForkCDR application, AST_CDR_FLAG_KEEP_VARS
flag is set only for the first CDR in the chain. So ForkCDR works fine with this
option only once. After the second and further calls to ForkCDR, CDR variables
get cleared on all CDRs besides the first one and moved to the newly forked CDR.
It always sets the KEEP_VARS flag on the first CDR in the chain, instead of the
most recent CDR which is used as a base to fork a new CDR.
This patch sets KEEP_VARS flag on the most recent CDR on the stack (the CDR used
for forking).
(closes issue ASTERISK-23260)
Reported by: zvision
Patches:
app_forkcdr.diff uploaded by zvision (license 5755)
........
Merged revisions 408747 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk didn't support the dynamic payload change in rtp mapping in the 200
OK response.
Scenario:
Asterisk sends the INVITE proposing alaw and telephone-event, it proposes
rtpmap:101 for telephone-event. Peer responds with 2xx, it answers with
alaw and telephone-event also, but it proposes a different rtpmap number
(rtpmap:103) for telephone-event.
Expected Behaviour:
Asterisk should honour the rtpmapping in the response and send DTMF packets
using 103 as payload type for DTMF.
Actual Behaviour: Asterisk sends DTMF packets using payload type 101.
With this patch asterisk now supports changes that can occur in the rtp mapping
in the response.
(closes issue ASTERISK-23279)
Reported by: NITESH BANSAL
Review: https://reviewboard.asterisk.org/r/3225/
Patches:
dynamic_payload_change.patch uploaded by nbansal (license 6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408729 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.
Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.
The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.
Credit to Olle Johansson for pointing me in the right direction on this issue.
(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
........
Merged revisions 408642 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the "x" option (specify a DTMF digit to exit the application), it is
not obvious in the documentation that this only works when spying on a channel.
If a channel being used to spy on other channels is waiting to connect to a
channel or is no longer attached to a channel, the DTMF is ignored.
As noted on the issue tracker, since there are workarounds available and this is
a rarely used option we are opting for a documentation change here.
(closes issue ASTERISK-22661)
Reported by: Chris Hillman
Patches:
asterisk-22661-doc-clarify-chan_spy.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2990/
........
Merged revisions 408536 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Repeatedly modifying config files and reloading too fast sometimes fails
to reload the configuration because the cached modification timestamp has
one second resolution.
* Added file size and nanosecond resolution fields to the cached config
file modification timestamp information. Now if the file size changes or
the file system supports nanosecond resolution the modified file has a
better chance of being detected for reload.
* Added a missing unlock in an off-nominal code path.
(closes issue AST-1303)
Review: https://reviewboard.asterisk.org/r/3235/
........
Merged revisions 408387 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@408388 65c4cc65-6c06-0410-ace0-fbb531ad65f3
