https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r59938 | russell | 2007-04-03 14:15:04 -0500 (Tue, 03 Apr 2007) | 4 lines
Don't attempt to report configuration errors in build_user(). oej pointed out
that for a "friend" entry, this won't work, because all user options are valid
for peers, but not the other way around.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@59939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r59623 | crichter | 2007-04-02 09:12:24 +0200 (Mo, 02 Apr 2007) | 1 line
we can now make 30 channels on a PRI (before we forgot chan 31..)
........
r59624 | crichter | 2007-04-02 09:25:54 +0200 (Mo, 02 Apr 2007) | 1 line
don't be verbose if no need
........
r59639 | crichter | 2007-04-02 14:08:12 +0200 (Mo, 02 Apr 2007) | 1 line
added option which allows us to accept incoming SETUP Messages without automatically sending Proceeding or Setup Acknowledge, this is useful with some broken switches and if you want to Release incoming calls without previously having acknowledged them. The new option is noautorespond_on_setup=yes|no default is no, so we don't break the existing behaviour
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@59774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This will cause Asterisk to hangup the call instead of keep trying whatever it
was doing. Under normal conditions, this function would *never* be called.
However, the author of this patch says an error will occur that will cause it
to get called every 100 thousand calls or so. When this does happen, it puts
the channel in a loop that eventually brings down the system. So, hangup up
the call is certainly a better alternative. (issue #8286, john)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@59341 65c4cc65-6c06-0410-ace0-fbb531ad65f3
because they get set in sip_hangup. So, there are common situations where
the variables will not be available in the dialplan at all. So, this patch
provides an alternate method for getting to this information by introducing
AUDIORTPQOS and VIDEORTPQOS dialplan functions.
(issue #9370, patch by Corydon76, with some testing by blitzrage)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@59207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* add a check for linux/mISDNdsp.h to configure.ac and update the autogenerated files: 'configure', 'autoconfig.h.in'
(the 'configure' script was not in sync with the latest configure.ac, so the diff is a bit bigger than expected).
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@59202 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r57034 | crichter | 2007-02-28 17:09:27 +0100 (Mi, 28 Feb 2007) | 1 line
fixed bugs.digium.com bugs: #9157 and bugs.beronet.com bugs: #302, #303, #304
........
r57523 | crichter | 2007-03-02 19:32:51 +0100 (Fr, 02 Mar 2007) | 1 line
fixed typo
........
r57753 | crichter | 2007-03-04 11:39:50 +0100 (So, 04 Mar 2007) | 1 line
fixed another place where the out_cause was hardcoded to 16
........
r58558 | crichter | 2007-03-09 15:43:58 +0100 (Fr, 09 Mar 2007) | 1 line
we can free channel 31 as well, since we can occupy it
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@58826 65c4cc65-6c06-0410-ace0-fbb531ad65f3
frame was not properly initialized.
- Interpolating a frame when the jitterbuffer is in use
- decrypting a frame when IAX2 encryption is on
- frames in an IAX2 trunk
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@58705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(issue #7256, tzafrir)
Also, update the configure script to make sure that we don't try to build
chan_zap if the installed version of zaptel does not include ZT_EVENT_REMOVED.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@58320 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Merged revisions 58242 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r58242 | russell | 2007-03-07 12:17:07 -0600 (Wed, 07 Mar 2007) | 7 lines
Fix a problem where the Asterisk channel name could be that of the wrong IAX2
user for a call. This is because the first step of choosing this name is to
look for an IAX2 peer that happens to have the same IP/port number that this
call is coming from and assuming that is it. However, this is not always
correct. So, I have made it change this name after authentication happens
since at that point, we have an exact match.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@58243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r58115 | murf | 2007-03-06 15:52:52 -0700 (Tue, 06 Mar 2007) | 1 line
Fix for 9220: Eyebeam cannot renew subscriptions for presence info. Reason: re-SUBSCRIBE requests don't include Accept headers, which the rfc says are optional (to put it tersely), (it uses MAY), and luckily, the sip_pvt struct has the format info stored, so we simply leave it if the format is set, and the accept header null.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@58121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r56406 | russell | 2007-02-23 14:17:56 -0600 (Fri, 23 Feb 2007) | 4 lines
Don't destroy mutexes before unregistering all of the entry points from the core.
Also, fix a potential memory leak from not destroying the locks for all of the
possible call numbers (about 32k of them).
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@56407 65c4cc65-6c06-0410-ace0-fbb531ad65f3
