extension, then consider the extension on the channel before falling back
to the default.
(closes issue #12479)
Reported by: darren1713
Patches:
exten_dial_fix_chan_iax2.c.patch uploaded by darren1713 (license 116)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114537 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These changes make sure that the reference count for sip_peer objects properly
reflects the fact that the peer is sitting in the scheduler for a scheduled
callback for qualifying peers or for expiring registrations. Without this, it
was possible for these callbacks to happen at the same time that the peer was
being destroyed. This was especially likely to happen with realtime peers, and
for people making use of the realtime prune CLI command.
(closes issue #9520)
Reported by: kryptolus
Committed patch by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@114522 65c4cc65-6c06-0410-ace0-fbb531ad65f3
during the initial INVITE, no matter if we're building the route set from
an INVITE request or response.
(closes issue #12391)
Reported by: benjaminbohlmann
Tested by: benjaminbohlmann
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113927 65c4cc65-6c06-0410-ace0-fbb531ad65f3
we should not send a BYE.
(closes issue #12392)
Reported by: fnordian
Patches:
chan_sip.patch uploaded by fnordian (license 110) with small modification from me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113681 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes a for loop (in realtime_peer) to check all the ast_variables the loop was intending to test rather than just the first one. The change exposed the problem of calling memcpy on a NULL pointer, in this case the passed in sockaddr_in struct which is now checked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #12372)
Reported by: vinsik
Tested by: tecnoxarxa
This one line change makes an if inside a for loop (in realtime_peer) check all the ast_variables the loop was intending to test rather than just the first one.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@113012 65c4cc65-6c06-0410-ace0-fbb531ad65f3
to see what would happen. It passed the compile test, and I didn't notice I had
left this change in too.
So this is a revert of a revert...sort of.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@110635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
was not for an actual bug fix per se, and so it really should not have been in 1.4 in
the first place. Plus, people who compile with DO_CRASH are more likely
to encounter a crash due to this change. While I think the usage of DO_CRASH
in ast_sched_del is a bit absurd, this sort of change is beyond the scope of 1.4
and should be done instead in a developer branch based on trunk
so that all scheduler functions are fixed at once.
I also am reverting the change to trunk and 1.6 since they also suffer from
the DO_CRASH potential.
(closes issue #12272)
Reported by: qq12345
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@110618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r110335 | russell | 2008-03-20 16:53:27 -0500 (Thu, 20 Mar 2008) | 6 lines
Fix some very broken code that was introduced in 1.2.26 as a part of the security
fix. The dnsmgr is not appropriate here. The dnsmgr takes a pointer to an address
structure that a background thread continuously updates. However, in these cases,
a stack variable was passed. That means that the dnsmgr thread would be continuously
writing to bogus memory.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@110336 65c4cc65-6c06-0410-ace0-fbb531ad65f3
when dialing a channel that does not provide progress (analog ZAP lines)
The phone does handle the double update on calls to channels that do
provide progress and wont insert duplicate items
(closes issue #12239)
Reported by: DEA
Patches:
chan_skinny-call-log.txt uploaded by DEA (license 3)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@109171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip uses the scheduler API in order to schedule retransmission of reliable
packets (such as INVITES). If a retransmission of a packet is occurring, then the
packet is removed from the scheduler and retrans_pkt is called. Meanwhile, if
a response is received from the packet as previously transmitted, then when we
ACK the response, we will remove the packet from the scheduler and free the packet.
The problem is that both the ACK function and retrans_pkt attempt to acquire the
same lock at the beginning of the function call. This means that if the ACK function
acquires the lock first, then it will free the packet which retrans_pkt is about to
read from and write to. The result is a crash.
The solution:
1. If the ACK function fails to remove the packet from the scheduler and the retransmit
id of the packet is not -1 (meaning that we have not reached the maximum number of
retransmissions) then release the lock and yield so that retrans_pkt may acquire the
lock and operate.
2. Make absolutely certain that the ACK function does not recursively lock the lock in
question. If it does, then releasing the lock will do no good, since retrans_pkt will
still be unable to acquire the lock.
(closes issue #12098)
Reported by: wegbert
(closes issue #12089)
Reported by: PTorres
Patches:
12098-putnopvutv3.patch uploaded by putnopvut (license 60)
Tested by: jvandal
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108737 65c4cc65-6c06-0410-ace0-fbb531ad65f3
has been subscribed to goes on hold. Otherwise, they just stay on like it does
when an extension is in use.
(closes issue #11263)
Reported by: russell
Patches:
notify_hold.rev1.txt uploaded by russell (license 2)
Tested by: russell
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The scheduler callback will always return 0. This means that this id
is never rescheduled, so it makes no sense to loop trying to delete
the id from the scheduler queue. If we fail to remove the item from the
queue once, it will fail every single time.
(Yes I realize that in this case, the macro would exit early because the
id is set to -1 in the callback, but it still makes no sense to use
that macro in favor of calling ast_sched_del once and being done with it)
This is the first of potentially several such fixes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@108288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
set to make sure that when we come back out of alarm, it gets reported in the log
and manager interface (after discussion with tzafrir on the -dev list)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104591 65c4cc65-6c06-0410-ace0-fbb531ad65f3
does not know what to do with these alarms. Only Asterisk 1.6 cares about it.
So, if we get an unknown alarm in chan_zap, don't generate confusing log messages
about it.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit brings in a significant set of changes to the SMDI support in Asterisk.
There were a number of bugs in the current implementation, most notably being that
it was very likely on busy systems to pop off the wrong message from the SMDI message
queue. So, this set of changes fixes the issues discovered as well as introducing
some new ways to use the SMDI support which are required to avoid the bugs with
grabbing the wrong message off of the queue.
This code introduces a new interface to SMDI, with two dialplan functions. First,
you get an SMDI message in the dialplan using SMDI_MSG_RETRIEVE() and then you access
details in the message using the SMDI_MSG() function. A side benefit of this is that
it now supports more than just chan_zap.
For example, with this implementation, you can have some FXO lines being terminated
on a SIP gateway, but the SMDI link in Asterisk.
Another issue with the current implementation is that it is quite common that the
station ID that comes in on the SMDI link is not necessarily the same as the Asterisk
voicemail box. There are now additional directives in the smdi.conf configuration
file which let you map SMDI station IDs to Asterisk voicemail boxes.
Yet another issue with the current SMDI support was related to MWI reporting over
the SMDI link. The current code could only report a MWI change when the change
was made by someone calling into voicemail. If the change was made by some other
entity (such as with IMAP storage, or with a web interface of some kind), then the
MWI change would never be sent. The SMDI module can now poll for MWI changes if
configured to do so.
This work was inspired by and primarily done for the University of Pennsylvania.
(also related to issue #9260)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
which event was received. What actually was happening was that it was reporting the number of bytes returned
from a call to read().
Thanks to Jared Smith for bringing the issue up on IRC
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@104026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
in bridge code. When that happens, we crash. Delay the RTP destruction until
the bridge is ended.
(closes issue #11960)
Reported by: norman
Patches:
20080215__bug11960__2.diff.txt uploaded by Corydon76 (license 14)
Tested by: norman
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103780 65c4cc65-6c06-0410-ace0-fbb531ad65f3
could lead to a looped list, meaning it will traverse forever.
(closes issue #11818)
Reported by: michael-fig
Patches:
11818.patch uploaded by putnopvut (license 60)
Tested by: michael-fig
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@103770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
it is supposed to specified as 8 kHz in the RTP, and RTP timestamps are supposed
to be calculated based on 8 kHz. (Apparently this is due to a bug in a spec, but
people follow it anyway, because it's the spec ...)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
or hostname was provided, which is the one part of the dial string that is
absolutely required. If it's not there, bail out.
(closes issue #11897)
Reported by sokhapkin
Patch by me
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@101693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Joshua Colp
Mark Michelson
Sean Bright
Kevin P. Fleming
Tilghman Lesher
Jason Parker
Olle Johansson
Terry Wilson
Jeff Peeler
Philippe Sultan
Michiel van Baak