https://origsvn.digium.com/svn/asterisk/trunk
........
r255021 | lmadsen | 2010-03-26 14:07:38 -0500 (Fri, 26 Mar 2010) | 8 lines
Update confusing documentation for tlsbindaddr.
Update some confusing documentation for the tlsbindaddr
option in sip.conf.sample. Point at a link instead which
has better documentation.
(closes issue #17054)
Reported by: klaus3000
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@255023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r252762 | lmadsen | 2010-03-16 13:48:22 -0500 (Tue, 16 Mar 2010) | 15 lines
Merged revisions 252761 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r252761 | lmadsen | 2010-03-16 13:46:20 -0500 (Tue, 16 Mar 2010) | 7 lines
Additional extensions.ael global variable fixes.
Fixing up a couple more overlapping global variable namespaces shared with
extensions.conf.sample. Also noticed a few of the lines that were commented
out didn't have the closing semi-colon so I added that as well.
(issue #17035)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252763 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r252534 | lmadsen | 2010-03-15 15:52:32 -0500 (Mon, 15 Mar 2010) | 15 lines
Merged revisions 252533 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r252533 | lmadsen | 2010-03-15 15:48:56 -0500 (Mon, 15 Mar 2010) | 7 lines
Update extensions.ael file to not overlap extensions.conf.
Updated the extensions.ael file so the global variables don't overlap
those that we have in extensions.conf (sample files). This way unexpected
things won't happed hopefully if both pbx_ael and res_config are loaded.
(closes issue #17035)
Reported by: pprindeville
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r252089 | twilson | 2010-03-12 16:04:51 -0600 (Fri, 12 Mar 2010) | 20 lines
Only change the RTP ssrc when we see that it has changed
This change basically reverts the change reviewed in
https://reviewboard.asterisk.org/r/374/ and instead limits the
updating of the RTP synchronization source to only those times when we
detect that the other side of the conversation has changed the ssrc.
The problem is that SRCUPDATE control frames are sent many times where
we don't want a new ssrc, including whenever Asterisk has to send DTMF
in a normal bridge. This is also not the first time that this mistake
has been made. The initial implementation of the ast_rtp_new_source
function also changed the ssrc--and then it was removed because of
this same issue. Then, we put it back in again to fix a different
issue. This patch attempts to only change the ssrc when we see that
the other side of the conversation has changed the ssrc.
It also renames some functions to make their purpose more clear.
Review: https://reviewboard.asterisk.org/r/540/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@252137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r249893 | dvossel | 2010-03-02 13:08:38 -0600 (Tue, 02 Mar 2010) | 11 lines
fixes adaptive jitterbuffer configuration
When configuring the adaptive jitterbuffer, the target_extra
value not only could not be set from the configuration, but was
not even being set to its proper default. This value is required
in order for the adaptive jitterbuffer to work correctly. To resolve
this a config option has been added to expose this value to the conf
files, and a default value is provided when no config specific value
is present.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@249895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r230881 | file | 2009-11-23 09:45:45 -0600 (Mon, 23 Nov 2009) | 7 lines
Change fax detection in chan_sip so it behaves as one would expect.
Internally the way T.38 is negotiated has changed and the option no longer
reflects a behavior that is valid. It will now look for a CNG tone on
received calls and if present send the call to the 'fax' extension. It is
then up to the application or channel to request the switch over to T.38.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@230884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r227361 | lmadsen | 2009-11-03 13:25:18 -0600 (Tue, 03 Nov 2009) | 11 lines
Additional fixes to the extensions.conf.sample file.
Update the extensions.conf.sample [stdexten] context so that we use the
variable instead of requiring it to be passed explicitly. Also updated uses of
the [stdexten] context throughout.
(closes issue #15858)
Reported by: pprindeville
Patches:
stdexten-context-update.txt uploaded by lmadsen (license 10)
Tested by: pprindeville
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@227364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r226384 | lmadsen | 2009-10-28 15:11:07 -0500 (Wed, 28 Oct 2009) | 17 lines
Merged revisions 226382 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r226382 | lmadsen | 2009-10-28 15:06:13 -0500 (Wed, 28 Oct 2009) | 9 lines
Update documentation in sip.conf.sample.
Update the documentation in sip.conf.sample in order to make it more clear
that directmedia/canreinvite do not cause Asterisk to ignore reINVITEs. It
is only used to stop Asterisk from generating a reINVITE, but does not stop
it from accepting them if necessary.
(closes issue #15644)
Reported by: lmadsen
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@226385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r225033 | dvossel | 2009-10-21 09:39:10 -0500 (Wed, 21 Oct 2009) | 27 lines
Merged revisions 225032 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r225032 | dvossel | 2009-10-21 09:37:04 -0500 (Wed, 21 Oct 2009) | 20 lines
IAX/SIP shrinkcallerid option
The shrinking of caller id removes '(', ' ', ')', non-trailing '.',
and '-' from the string. This means values such as 555.5555 and
test-test result in 555555 and testtest. There are instances,
such as Skype integration, where a specific value is passed via
caller id that must be preserved unmodified. This patch makes
the shrinking of caller id optional in chan_sip and chan_iax in
order to support such cases. By default this option is on to
preserve previous expected behavior.
(closes issue #15940)
Reported by: dimas
Patches:
v2-15940.patch uploaded by dimas (license 88)
15940_shrinkcallerid_trunk.c uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/408/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@225035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r222110 | kpfleming | 2009-10-05 14:45:00 -0500 (Mon, 05 Oct 2009) | 25 lines
Allow non-compliant T.38 endpoints to be supportable via configuration option.
Many T.38 endpoints incorrectly send the maximum IFP frame size they can accept
as the T38FaxMaxDatagram value in their SDP, when in fact this value is
supposed to be the maximum UDPTL payload size (datagram size) they can accept.
If the value they supply is small enough (a commonly supplied value is '72'),
T.38 UDPTL transmissions will likely fail completely because the UDPTL packets
will not have enough room for a primary IFP frame and the redundancy used for
error correction. If this occurs, the Asterisk UDPTL stack will emit log messages
warning that data loss may occur, and that the value may need to be overridden.
This patch extends the 't38pt_udptl' configuration option in sip.conf to allow
the administrator to override the value supplied by the remote endpoint and
supply a value that allows T.38 FAX transmissions to be successful with that
endpoint. In addition, in any SIP call where the override takes effect, a debug
message will be printed to that effect. This patch also removes the
T38FaxMaxDatagram configuration option from udptl.conf.sample, since it has not
actually had any effect for a number of releases.
In addition, this patch cleans up the T.38 documentation in sip.conf.sample
(which incorrectly documented that T.38 support was passthrough only).
(issue #15586)
Reported by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@222113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r221592 | kpfleming | 2009-10-01 11:16:09 -0500 (Thu, 01 Oct 2009) | 12 lines
Remove ability to control T.38 FAX error correction from udptl.conf.
chan_sip has had the ability to control T.38 FAX error correction mode on a per-peer
(or global) basis for a couple of releases now, which is where it should have been
all along. This patch removes the ability to configure it in udptl.conf, but issues
a warning if the user tries to do, telling them to look at sip.conf.sample for how
to configure it now. For any SIP peers that are T.38 enabled in sip.conf, there is
already a default for FEC error correction even if the user does not specify any mode,
so this change will not turn off error correction by default, it will have the same
default value that has been in the udptl.conf sample file.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221432 | mnicholson | 2009-09-30 15:40:20 -0500 (Wed, 30 Sep 2009) | 17 lines
Merged revisions 221360 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221360 | mnicholson | 2009-09-30 14:36:06 -0500 (Wed, 30 Sep 2009) | 10 lines
Fix SRV lookup and Request-URI generation in chan_sip.
This patch adds a new field "portinuri" to the sip dialog struct and the sip peer struct. That field is used during RURI generation to determine if the port should be included in the RURI. It is also used in some places to determine if an SRV lookup should occur.
(closes issue #14418)
Reported by: klaus3000
Tested by: klaus3000, mnicholson
Review: https://reviewboard.asterisk.org/r/369/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r221266 | twilson | 2009-09-30 12:52:30 -0500 (Wed, 30 Sep 2009) | 32 lines
Merged revisions 221086 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r221086 | twilson | 2009-09-30 09:49:11 -0500 (Wed, 30 Sep 2009) | 25 lines
Change the SSRC by default when our media stream changes
Be default, change SSRC when doing an audio stream changes Asterisk doesn't
honor marker bit when reinvited to already-bridged RTP streams,resulting in
far-end stack discarding packets with "old" timestamps that areactually part of
a new stream. This patch sends AST_CONTROL_SRCUPDATE whenever there is a
reinvite, unless the 'constantssrc' is set to true in sip.conf.
The original issue reported to Digium support detailed the following situation:
ITSP <-> Asterisk 1.4.26.2 <-> SIP-based Application Server Call comes in
fromITSP, Asterisk dials the app server which sends a re-invite back
toAsterisk--not to negotiate to send media directly to the ITSP, but to
indicatethat it's changing the stream it's sending to Asterisk. The app
servergenerates a new SSRC, sequence numbers, timestamps, and sets the marker
bit on the new stream. Asterisk passes through the teimstamp of the new stream,
butdoes not reset the SSRC, sequence numbers, or set the marker bit.
When the timestamp on the new stream is older than the timestamp on the
originalstream, the ITSP (which doesn't know there has been any change) discards
the newframes because it thinks they are too old. This patch addresses this by
changing the SSRC on a stream update unless constantssrc=true is set in
sip.conf.
Review: https://reviewboard.asterisk.org/r/374/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@221304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r216438 | oej | 2009-09-04 16:02:34 +0200 (Fre, 04 Sep 2009) | 35 lines
Merged revisions 216430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r216430 | oej | 2009-09-04 15:45:48 +0200 (Fre, 04 Sep 2009) | 27 lines
Make apps send PROGRESS control frame for early media and fix too early media issue in SIP
The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI
links *before* any call progress. The SIP channel receives these frames and by default
signals 183 Session progress and starts sending media. This will cause phones to
play silence and ignore the later 180 ringing message. A bad user experience.
The fix is twofold:
- We discovered that asterisk apps that support early media ("noanswer") did not send
any PROGRESS frame to indicate early media. Fixed.
- We introduce a setting in chan_sip so that users can disable any relay of media frames
before the outbound channel actually indicates any sort of call progress.
In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions
of Asterisk, this will be enabled. We don't assume that it will change your Asterisk
phone experience - only for the better.
We encourage third-party application developers to make sure that if they have applications
that wants to send early media, add a PROGRESS control frame transmission to make sure that
all channel drivers actually will start sending early media. This has not been the default
in Asterisk previous to this patch, so if you got inspiration from our code, you need to
update accordingly. Sorry for the trouble and thanks for your support.
This code has been running for a few months in a large scale installation (over 250
servers with PRI and/or BRI links to old PBX systems).
That's no proof that this is an excellent patch, but, well, it's tested :-)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@216647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r213098 | tilghman | 2009-08-19 16:05:17 -0500 (Wed, 19 Aug 2009) | 9 lines
Better parsing for the "register" line
Allows characters that are otherwise used as delimiters to be used within
certain fields (like the secret).
(closes issue #15008, closes issue #15672)
Reported by: tilghman
Patches:
20090818__issue15008.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen, tilghman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@213117 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r212857 | tilghman | 2009-08-18 14:25:09 -0500 (Tue, 18 Aug 2009) | 4 lines
Make the default extconfig.conf match entries with the sample res_mysql.conf.
This eliminates a future source of possible confusion with the configuration of
1.6.1 and higher.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@212866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r210190 | kpfleming | 2009-08-03 15:48:48 -0500 (Mon, 03 Aug 2009) | 11 lines
Rename 'canreinvite' option to 'directmedia', with backwards compatibility.
It is clear from multiple mailing list, forum, wiki and other sorts of posts
that users don't really understand the effects that the 'canreinvite' config
option actually has, and that in some cases they think that setting it to 'no'
will actually cause various other features (T.38, MOH, etc.) to not work properly,
when in fact this is not the case. This patch changes the proper name of the
option to what it should have been from the beginning ('directmedia'), but
preserves backwards compatibility for existing configurations.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@210191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r209132 | mmichelson | 2009-07-27 12:50:04 -0500 (Mon, 27 Jul 2009) | 24 lines
Merged revisions 209131 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r209131 | mmichelson | 2009-07-27 12:44:06 -0500 (Mon, 27 Jul 2009) | 18 lines
Allow for UDPTL to use only even-numbered ports if desired.
There are some VoIP providers out there that will not accept SDP
offers with odd numbered UDPTL ports. While it is my personal opinion
that these VoIP providers are misinterpreting RFC 2327, it really is
not a big deal to play along with their silly little games. Of course,
since restricting UDPTL ports to only even numbers reduces the range
of available ports by half, so the option to use only even port numbers
is off by default. A user can enable the behavior by setting
use_even_ports=yes in udptl.conf.
(closes issue #15182)
Reported by: CGMChris
Patches:
15182.patch uploaded by mmichelson (license 60)
Tested by: CGMChris
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@209135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r208813 | mvanbaak | 2009-07-25 14:03:25 +0200 (Sat, 25 Jul 2009) | 10 lines
add default alias reload to run module reload.
Requiring 'module reload' to reload everything, including
core etc makes russell very unhappy.
The default configuration already loads the 'friendly' aliases template.
Added 'reload=module reload' to that template.
Also removed the comment in main/cli.c that reload should come back.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@208816 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200477 | moy | 2009-06-14 01:13:48 -0500 (Sun, 14 Jun 2009) | 3 lines
added openr2 to menuselect-deps.in, recent commit in menuselect made me realize this was never done but was working anyways
also added support for skip category request feature of openr2 and updated chan_dahdi.conf.sample
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196416 | dvossel | 2009-05-22 16:09:45 -0500 (Fri, 22 May 2009) | 19 lines
SIP set outbound transport type from Registration
In sip.conf the transport option allows for the configuration of what transport types (udp, tcp, and tls) a peer will accept, but only the first type listed was used for outbound connections. This patch changes this. Now the default transport type is only used until the peer registers. When registration takes place the transport type is parsed out of the Contact header. If the Contact header's transport type is equal to one that the peer supports, the peer's default transport type for outbound connections is set to match the Contact header's type. If the Contact header's transport type is not present, then the peer's default transport type is set to match the one the peer registered with. When a peer unregisters or the registration expires, the default transport type for that peer is reset.
(closes issue #12282)
Reported by: rjain
Patches:
reg_patch_1.diff uploaded by dvossel (license 671)
Tested by: dvossel
(closes issue #14727)
Reported by: pj
Patches:
reg_patch_3.diff uploaded by dvossel (license 671)
Tested by: pj, dvossel
Review: https://reviewboard.asterisk.org/r/249/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r193194 | kpfleming | 2009-05-08 09:06:15 -0500 (Fri, 08 May 2009) | 13 lines
Merged revisions 193193 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193193 | kpfleming | 2009-05-08 09:03:28 -0500 (Fri, 08 May 2009) | 7 lines
Make absolute paths for logger channels work properly
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r191955 | kpfleming | 2009-05-04 11:57:36 +0200 (Mon, 04 May 2009) | 8 lines
Ensure that by default only one console channel driver is loaded
This configuration file was changed to ensure that only one console channel driver
(chan_oss) is loaded by default, but the change would only work if chan_console
was not built. Now it will work as expected; if chan_alsa or chan_console are built
and installed, they will not be loaded unless explicity requested.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@191958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces official support for R2 signaling in chan_dahdi. The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.
Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, México and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Perú, and probably others.
To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.
The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.
I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message. These are the names that I
could find in the mantis issue.
(closes issue #12509)
Reported by: moy
Patches:
chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen
Review: http://reviewboard.digium.com/r/40/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180380 | mmichelson | 2009-03-05 12:58:48 -0600 (Thu, 05 Mar 2009) | 25 lines
Fix broken mailbox parsing when searchcontexts option is enabled.
When using the searchcontexts option in voicemail.conf, the code
made the assumption that all mailbox names defined were unique across
all contexts. However, the code did nothing to actually enforce this
assumption, nor did it do anything to alert a user that he may have
created an ambiguity in his voicemail.conf file by defining the same
mailbox name in multiple contexts.
With this change, we now will issue a nice long warning if searchcontexts
is on and we encounter the same mailbox name in multiple contexts and ignore
any duplicates after the first box. Whether searchcontexts is enabled or not,
if we come across a duplicate mailbox in the same context, then we will issue
a warning and ignore the duplicated mailbox. I have also added a small note
to voicemail.conf.sample in the explanation for searchcontexts explaining
that you cannot define the same mailbox in multiple contexts if you have
enabled the option.
(closes issue #14599)
Reported by: lmadsen
Patches:
14599.patch uploaded by mmichelson (license 60) (with slight modification)
Tested by: lmadsen
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the subscription context for a call pickup subscription differs
from the context of the call pickup target, there's not an easy way
to divine what context should be used for the pickup. The way to work
around this is to use PICKUPMARK as the context for the pickup.
This has been documented in the sip.conf.sample file
(ABE-1708)
closes issue #14567
submitted by: alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180155 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r180006 | mmichelson | 2009-03-03 16:48:18 -0600 (Tue, 03 Mar 2009) | 17 lines
Clarify some documentation of queues.conf.sample
It had always been possible to explicitly specify a "blank"
value for a sound file in queues.conf and have no sound played
back. The problem with this is that it would result in some ugly
CLI warnings from file.c.
This commit introduces a check when playing a file in app_queue
to see if the name of the file is zero-length and return early if
that is the case. Also, the ability to specify the blank sound
files in queues.conf is now mentioned more clearly in queues.conf.sample
(closes issue #14227)
Reported by: caspy
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@180007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
In this case, it's just a matter of reducing the default timeouts from 2000
to 1000 msec, as the max def feature digit timeout is no longer halved.
........
r178956 | murf | 2009-02-26 14:27:32 -0700 (Thu, 26 Feb 2009) | 18 lines
This change moves the default feature digit timeout to 1000 ms from the previous default of 500.
As per bug 14515, a dev discussion arrived at a "mediated concensus"
of a default feature digit timeout of 1.0 sec. Some voted for 1300;
ctooley thought 1500 for distracted phone users in phone booths;
kpfleming put his foot down at 1.0 sec.
Users who found the previous default max delay of 250 msec perfect,
are welcome to override the new default. Notice that I said that
250 msec was the default; wait a minute, you might say, the config
file said it was 500 msec!; well, because of the bug fix for 14515,
we found that 500 msec was actually enforcing a max of 250. The bug
fix would restore 500 msec, but we felt even that was a bit tight
for most users... 2000 msec was pushed earlier by mmichelson, so
that reduces to 1000 msec after the bug fix. Enjoy!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@178986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch includes a number of changes to the indications API. The primary
motivation for this work was to improve stability. The object management
in this API was significantly flawed, and a number of trivial situations could
cause crashes.
The changes included are:
1) Remove the module res_indications. This included the critical functionality
that actually loaded the indications configuration. I have seen many people
have Asterisk problems because they accidentally did not have an
indications.conf present and loaded. Now, this code is in the core,
and Asterisk will fail to start without indications configuration.
There was one part of res_indications, the dialplan applications, which did
belong in a module, and have been moved to a new module, app_playtones.
2) Object management has been significantly changed. Tone zones are now
managed using astobj2, and it is no longer possible to crash Asterisk by
issuing a reload that destroys tone zones while they are in use.
3) The API documentation has been filled out.
4) The API has been updated to follow our naming conventions.
5) Various bits of code throughout the tree have been updated to account
for the API update.
6) Configuration parsing has been mostly re-written.
7) "Code cleanup"
The code is from svn/asterisk/team/russell/indications/.
Review: http://reviewboard.digium.com/r/149/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@176627 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Turns key rotation back on by default. Added bit into encryption IE to indicate whether or not key rotation is supported or not. If it is not supported then it is not enabled, which insures backwards compatibility. This eliminates the need for the keyrotate option in iax.conf, so it has been removed.
Review: http://reviewboard.digium.com/r/159/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the 'faxdetect' configuration option is used, one may also want to use
the 'faxbuffers' configuration option in chan_dahdi.conf. This option will
dynamically use the configured 'faxbuffers' buffer policy on a channel for
the life of the call following the detection of fax tones. The faxbuffers
buffer policy will be reverted during call teardown.
An example use of 'faxbuffers' is below. This example would switch to using
6 buffers with a full buffer policy.
faxbuffers=>6,full
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175411 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds forceencryption=yes as an iax.conf option. When force encryption is enabled, no unencrypted connections are allowed. This insures all connections are encrypted. This is a new feature, so CHANGES and iax.conf.sample are updated as well.
(closes issue #13285)
Reported by: sgofferj
Tested by: russell
Review: http://reviewboard.digium.com/r/150/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@175344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is very similar to the DAHDI immediate=yes option. When the phone is picked up, instead of giving a dialtone it connects directly to the "s" extension. Changes where implemented in chan_iax2.c to directly connect to the "s" extension in the appropriate context when this option is enabled. Examples explaining its use are added to iax2.conf.sample. CHANGES has been updated as well.
(closes issue #14266)
Reported by: jcovert
Patches:
chan_iax2.c.patch-trunk uploaded by jcovert (license 551)
iax.conf.sample.patch uploaded by jcovert (license 551)
Tested by: jcovert, dvossel
Review: http://reviewboard.digium.com/r/143/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@174046 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In trunk, the only necessary change pointed out was that the call
to ChanIsAvail uses an option that has been removed.
For the 1.6.1 branch, however, it appears that the sample file is
badly in need of updating since there are |'s used all over the place
there. My tentative plan is just to copy trunk's sample config file
to those branches since the info there is most up-to-date and should
be correct for use in 1.6.1
Thanks to macli in #asterisk-dev for bringing this up
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@173776 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r172517 | twilson | 2009-01-30 11:47:41 -0600 (Fri, 30 Jan 2009) | 37 lines
Fix feature inheritance with builtin features
When using builtin features like parking and transfers, the AST_FEATURE_* flags
would not be set correctly for all instances when either performing a builtin
attended transfer, or parking a call and getting the timeout callback. Also,
there was no way on a per-call basis to specify what features someone should
have on picking up a parked call (since that doesn't involve the Dial() command).
There was a global option for setting whether or not all users who pickup a
parked call should have AST_FEATURE_REDIRECT set, but nothing for DISCONNECT,
AUTOMON, or PARKCALL.
This patch:
1) adds the BRIDGE_FEATURES dialplan variable which can be set either in the
dialplan or with setvar in channels that support it. This variable can be set
to any combination of 't', 'k', 'w', and 'h' (case insensitive matching of the
equivalent dial options), to set what features should be activated on this
channel. The patch moves the setting of the features datastores into the
bridging code instead of app_dial to help facilitate this.
2) adds global options parkedcallparking, parkedcallhangup, and
parkedcallrecording to be similar to the parkedcalltransfers option for
globally setting features.
3) has builtin_atxfer call builtin_parkcall if being transfered to the parking
extension since tracking everything through multiple masquerades, etc. is
difficult and error-prone
4) attempts to fix all cases of return calls from parking and completed builtin
transfers not having the correct permissions
(closes issue #14274)
Reported by: aragon
Patches:
fix_feature_inheritence.diff.txt uploaded by otherwiseguy (license 396)
Tested by: aragon, otherwiseguy
Review http://reviewboard.digium.com/r/138/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added doxygen comments to the major dahdi structures.
* Fixed PRI and SS7 using an incorrect string value if the extension
delimiter is not present in the Dial() function.
* Fixed SS7 not checking if the dialed extension is at least as long
as the stripmsd option.
* Fixed PRI not handling unknown TON/NPI prefix letters correctly.
* Fixed some uninitialized string variables on FXS ports.
configs/chan_dahdi.conf.sample
* Updated some documentation.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@172400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This prevents the situation when MWI messages are added to caller ID spills causing the channel to be hung up
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@169153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this commit, a register => line in sip.conf may contain a port number in the
"user" section of the line. Please see CHANGES and sip.conf.sample for more
details regarding this.
(closes issue #14198)
Reported by: Nick_Lewis
Patches:
chan_sip.c-domainport2.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@168575 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update the queues.conf.sample documentation to mention that you need to preload chan_local.so as well if you plan on using Local channels for queue members, and you're preloading pbx_config.so.
(closes issue #14179)
Reported by: CrashHD
Tested by: CrashHD
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@167477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
enabled (either globally or for a specific peer), chan_sip will treat any SDP
data it receives as new data and update the media stream accordingly. By
default, Asterisk will only modify the media stream if the SDP session version
received is different from the current SDP session version. This option is
required to interoperate with devices that have non-standard SDP session
version implementations (observed by toc on the bug tracker with Microsoft OCS
which always uses 0 as the session version).
http://reviewboard.digium.com/r/94/
(closes issue #13958)
Reported by: toc
Tested by: toc
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@165180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Leif Madsen
Tilghman Lesher
Terry Wilson
David Vossel
Tzafrir Cohen
Jared Smith
Joshua Colp
Jason Parker
Kevin P. Fleming
Matthew Nicholson
Matthias Nick
Olle Johansson
Mark Michelson
Michiel van Baak
Jeff Peeler
Russell Bryant
Moises Silva
Gavin Henry
Sean Bright
Richard Mudgett
Steve Murphy
Dwayne M. Hubbard
Doug Bailey