| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
(closes issue #17359)
Reported by: alecdavis
Patches:
bug17359.diff.txt uploaded by alecdavis (license 585)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@264056 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Issue #7321 implements a new chan_dahdi configuration option. However, a
change mentioned in the issue was never implemented. This is the change
that will allow the feature to work.
I added a note to chan_dahdi.conf.sample about the feature.
(closes issue #17143)
Reported by: djensen99
Patches:
diff.txt uploaded by djensen99 (license NA) (One line change)
Tested by: djensen99
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@259270 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Before r238915, certain values for the EventMask parameter of the Events action would result in no response being returned. This patch adds an option to restore that broken behavior. Also while fixing this bug I discovered that passing an empty EventMasks parameter would also result in no response being returned, this has been fixed as well while being preserved when the broken behavior is requested.
(closes issue #17023)
Reported by: nblasgen
Review: https://reviewboard.asterisk.org/r/602/
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@257070 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #17021)
Reported by: kovzol
Tested by: lmadsen, kovzol, davidw, ebroad
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@255503 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Add the french snipset to say.conf.
(Closes issue #15799)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@253018 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@252761 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@252533 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@252532 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@252531 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@252175 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16267)
Reported by: elsto
Patches:
cdr.conf.sample.patch.txt uploaded by lmadsen (license 10)
Tested by: davidw, elsto
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@250043 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
risk.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@245944 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
patch by jsmith, after discussion with jtodd
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@235181 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #16223)
Reported by: bklang
Patches:
clarify-iax-requirecalltoken.patch uploaded by bklang (license 919)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@233279 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
a workaround for it that does not change existing behavior.
(closes issue #14426)
Reported by: macli
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@229965 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@226382 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@225032 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@221360 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15471)
Reported by: dkerr
Patches:
csv_quote_14.txt uploaded by mnick (license )
Tested by: mnick
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@221157 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@221086 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15583)
Reported by: pkempgen
Patches:
20090726__issue15583.diff.txt uploaded by tilghman (license 14)
20090726__issue15583-1.4-4.diff.txt uploaded by pkempgen (license 169)
Tested by: pkempgen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@219023 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@216430 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #12912)
Reported by: rathaus
Tested by: tilghman, russell, dvossel, dbrooks
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@216000 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
dialplan.
(closes issue #15755)
Reported by: trendboy
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@213493 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@209131 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Previously overlap dialing could only be turned on or off for both incoming and
outgoing calls. New parameters incoming, outgoing, and both have been added to
allow further control. There is no change in default behavior with these new
options and allows in band DTMF to be accepted in one direction if required.
(closes issue #14471)
Reported by: eboscani
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@207092 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15518)
Reported by: pkempgen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@206872 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@194764 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(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: http://svn.digium.com/svn/asterisk/branches/1.4@193193 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #11678)
Reported by: jamessan
Patches:
20090330__bug11678.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman, lmadsen
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186415 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Changed a capital K to a lowercase k.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186174 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r186056 | tilghman | 2009-04-02 12:02:18 -0500 (Thu, 02 Apr 2009) | 2 lines
Fix for AST-2009-003
........
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@186059 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@185121 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
After several issues raised on the Asterisk bugtracker against
the 1.4 branch were determined to be fixable with the state interface
change available in the 1.6.X series, it finally came time to just
suck it up and backport the change.
For a detailed explanation of what this change entails, the original
trunk commit for this feature may be found here:
http://svn.digium.com/view/asterisk?view=revision&revision=97203
In addition, the details for the use of this change to fix the problems
stated in issue #12970 may be found in the review request I made for
this change. It is linked below.
(closes issue #12970)
Reported by: edugs15
Review: http://reviewboard.digium.com/r/116
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@184980 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(Related to issue #14731)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@183913 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@180380 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@180006 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@178956 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14540)
Reported by: jtodd
Patch by: jtodd, with additional notes by tilghman (license 14)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@178445 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
dialplan configuration files.
(closes issue #14388)
Reported by: macli
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@173070 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
* Added doxygen comments to the major dahdi structures.
* Fixed PRI using an incorrect string value if the extension
delimiter is not present in the Dial() function.
* Fixed some uninitialized string variables on FXS ports.
configs/chan_dahdi.conf.sample
* Updated some documentation.
These changes are already in trunk -r172400
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@172962 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Since this option actually already existed in 1.6.0+, use the same name so as
not to confuse people when they upgrade
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@172639 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/branches/1.4@172517 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the dialplan for newbies.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@171837 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170836 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #14319)
Reported by: klaus3000
Patches:
patch_idlecheck_res_odbc.conf.sample.txt uploaded by klaus3000 (license 65)
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@170719 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168721 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@168480 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
context. The truth is that you can only set this in the general section
or per mailbox. Thus I am updating the sample config file to be more
accurate.
Thanks to sasargen on IRC for bringing up this issue.
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@155011 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
dial and queue... I wasted some time (stupidly) trying
to get the one-touch parking stuff working, because it
didn't occur to me that I had to also have the corresponding
options in the dial command! Duh! (In all this time, I never
set this up before!)
So, to keep some poor fool from suffering the same fate,
I made the features.conf.sample file mention the corresponding
opts in dial/queue; and the docs for dial/app specifically
mention the corresponding decls in the feature.conf file.
I hope this doesn't spoil some vast, eternal plan...
git-svn-id: http://svn.digium.com/svn/asterisk/branches/1.4@152538 f38db490-d61c-443f-a65b-d21fe96a405b
|
