https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r281294 | russell | 2010-08-09 07:14:34 -0500 (Mon, 09 Aug 2010) | 5 lines
Reorder some options in cdr.conf.sample.
Put all of the options that affect the contents of CDRs together, instead
of having the batch mode options in the middle of them.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281295 65c4cc65-6c06-0410-ace0-fbb531ad65f3
FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.
Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.
(closes issue #17318)
Reported by: armeniki
Patches:
fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The documentation for this option did not match the code. Fix that along with
some minor cleanups to the code along the way. Document a slight change in
behavior (to something that was previously undocumented) in UPGRADE.txt.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two changes here:
1. Since the externip setting can now have a port attached
to it, calling it "externip" is misleading. The option is now
documented and parsed as "externaddr." This also extends to the
"matchexterniplocally" setting. It is now documented and parsed
as "matchexternaddrlocally." The old names for the options may
still be used, but they are no longer used in the sip.conf.sample
file.
2. If no port is set for the externaddr, and UDP is the transport
to be used, then we will set the port of the externaddr to that of
the udpbindaddr. This was how things worked prior to the IPv6 merge,
so this is a regression fix.
(closes issue #17665)
Reported by: mmichelson
Patches:
17665.diff#2 uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sip.conf configuration for the channel and for devices.
The Max-Forwards header is used to prevent loops in a SIP network. Each intermediary,
like SIP proxys and SBCs, decrement this counter and detects when it reaches zero,
at which point the SIP request is nicely killed in a SIP-friendly way.
Review: https://reviewboard.asterisk.org/r/778/
Thanks to dvossel for the review and good advice.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The bridge handling code did not properly consider feature groups when setting
parameters that would affect whether or not a native bridge would be attempted.
If DYNAMIC_FEATURES only include a feature group, a native bridge would occur
that may prevent features from working.
Fix a bug in verbose output that would show the key mapping as empty if it was
using the default mapping and not a custom mapping in the feature group.
Add feature groups to the output of "features show".
Adjust the feature execution logic to match that of the logic when executing
a feature that was not configured through a feature group.
Update features.conf.sample to show that an '=' is still required if using
the default key mapping from [applicationmap].
Finally, clean up a little bit of formatting to better coform to coding
guidelines while in the area.
(closes issue #17589)
Reported by: lmadsen
Patches:
issue_17589.rev4.txt uploaded by russell (license 2)
Tested by: russell, lmadsen
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275424 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch as documented in the sample config allows one to optionally apply
white, black, or both types of filtering to manager events. The new
'eventfilter' option is set per user.
(closes issue #14861)
Reported by: fnordian
Patches:
eventfilter3.patch uploaded by fnordian (license 110),
modified by me
Review: https://reviewboard.asterisk.org/r/673/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
People expressed an interest in having access to the exact length of calls to a finer degree than seconds. See the CHANGES and UPGRADE.txt for usage also updated the sample configs to note the change.
Patch by snuffy.
(closes issue #16559)
Reported by: cianmaher
Tested by: cianmaher, snuffy
Review: https://reviewboard.asterisk.org/r/461/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add the ability to announce a call to an endpoint when there are no B
channels available. A call waiting call is a SETUP message with no B
channel selected.
Relevant specification: EN 300 056, EN 300 057, EN 300 058
For DAHDI/ISDN channels, the CHANNEL() dialplan function now supports the
"no_media_path" option.
* Returns "0" if there is a B channel associated with the call.
* Returns "1" if no B channel is associated with the call. The call is
either on hold or is a call waiting call.
If you are going to allow incoming call waiting calls then you need to use
CHANNEL(no_media_path) do determine if you must drop a call to accept the
new call.
Review: https://reviewboard.asterisk.org/r/568/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267261 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk Generic AOC Representation
- Generic AOC encode/decode routines.
(Generic AOC must be encoded to be passed on the wire in the AST_CONTROL_AOC frame)
- AST_CONTROL_AOC frame type to represent generic encoded AOC data
- Manager events for AOC-S, AOC-D, and AOC-E messages
Asterisk App Support
- app_dial AOC-S pass-through support on call setup
- app_queue AOC-S pass-through support on call setup
AOC Unit Tests
- AOC Unit Tests for encode/decode routines
- AOC Unit Test for manager event representation.
SIP AOC Support
- Pass-through of generic AOC-D and AOC-E messages to snom phones via the
snom AOC specification.
- Creation of chan_sip page3 flags for the addition of the new
'snom_aoc_enabled' sip.conf option.
IAX AOC Support
- Natively supports AOC pass-through through the use of the new
AST_CONTROL_AOC frame type
DAHDI AOC Support
- ETSI PRI full AOC Pass-through support
- 'aoc_enable' chan_dahdi.conf option for independently enabling
pass-through of AOC-S, AOC-D, AOC-E.
- 'aoce_delayhangup' option for retrieving AOC-E on disconnect.
- DAHDI A() dial string option for requesting AOC services.
example usage:
;requests AOC-S, AOC-D, and AOC-E on call setup
exten=>1111,1,Dial(DAHDI/g1/1112/A(s,d,e))
Review: https://reviewboard.asterisk.org/r/552/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267096 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added ability to send and receive ETSI Explicit Call Transfer (ECT)
messages to eliminate tromboned calls.
Note: Asterisk already supported initiating the transfer of calls to
eliminate tromboned calls to libpri so there was nothing to do for the
asterisk portion.
Review: https://reviewboard.asterisk.org/r/520/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@266926 65c4cc65-6c06-0410-ace0-fbb531ad65f3
directmediapermit/directmediadeny support to restrict which peers can do
directmedia based on ip address. In some networks not all phones are fully
routed, i.e. not all phones can ping each other. This patch adds a way to
restrict directmedia for certain peers between certain networks.
(closes issue #16645)
Reported by: raarts
Patches:
directmediapermit.patch uploaded by raarts (license 937)
Tested by: raarts
Review: https://reviewboard.asterisk.org/r/467/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264626 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Now that Asterisk modules can dynamically create and destroy logger levels
on demand, it's useful to be able to configure a logger channel (console,
file, whatever) to be able to accept log messages from *all* levels, even
levels created dynamically. This patch adds support for this, by allowing
the '*' level name to be used in logger.conf.
Review: https://reviewboard.asterisk.org/r/663/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From reviewboard:
Digium has a commercial customer who has made extensive use of the connected party and
redirecting information present in later versions of Asterisk Business Edition and which
is to be in the upcoming 1.8 release. Through their use of the feature, new problems and solutions
have come about. This patch adds several enhancements to maximize usage of the connected party
and redirecting information functionality.
First, Asterisk trunk already had connected line interception macros. These macros allow you to
manipulate connected line information before it was sent out to its target. This patch adds the
same feature except for redirecting information instead.
Second, the ast_callerid and ast_party_id structures have been enhanced to provide a "tag." This
tag can be set with func_callerid, func_connectedline, func_redirecting, and in the case of DAHDI,
mISDN, and SIP channels, can be set in a configuration file. The idea behind the callerid tag is
that it can be set to whatever value the administrator likes. Later, when running connected line
and redirecting macros, the admin can read the tag off the appropriate structure to determine what
action to take. You can think of this sort of like a channel variable, except that instead of having
the variable associated with a channel, the variable is associated with a specific identity within
Asterisk.
Third, app_dial has two new options, s and u. The s option lets a dialplan writer force a specific
caller ID tag to be placed on the outgoing channel. The u option allows the dialplan writer to force
a specific calling presentation value on the outgoing channel.
Fourth, there is a new control frame subclass called AST_CONTROL_READ_ACTION added. This was added
to correct a very specific situation. In the case of SIP semi-attended (blond) transfers, the party
being transferred would not have the opportunity to run a connected line interception macro to
possibly alter the transfer target's connected line information. The issue here was that during a
blond transfer, the SIP transfer code has no bridged channel on which to queue the connected line
update. The way this was corrected was to add this new control frame subclass. Now, we queue an
AST_CONTROL_READ_ACTION frame on the channel on which the connected line interception macro should
be run. When ast_read is called to read the frame, ast_read responds by calling a callback function
associated with the specific read action the control frame describes. In this case, the action taken
is to run the connected line interception macro on the transferee's channel.
Review: https://reviewboard.asterisk.org/r/652/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@263541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes some breakage in the test suite, that uses the contents of asterisk.conf
to discover the install layout on the system.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This simply moves the functionality from the Makefile (cleaning it up) into an external
asterisk.conf.samples file. Also updates formatting (easier to read) and grammar
changes to asterisk.conf.samples.
(closes issue #17027)
Reported by: pabelanger
Patches:
0017027.asterisk.conf.v6.patch uploaded by pabelanger (license 224)
Tested by: qwell, lmadsen, pabelanger, chappell
Review: https://reviewboard.asterisk.org/r/616/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@261124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r259270 | rmudgett | 2010-04-27 13:14:54 -0500 (Tue, 27 Apr 2010) | 14 lines
hidecalleridname parameter in chan_dahdi.conf
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: https://origsvn.digium.com/svn/asterisk/trunk@259307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Application arguments within the feature map could possibly contain a comma,
which conflicts with the syntax of the features.conf configuration file. This
patch allows the argument to be wrapped in parentheses or quoted, to allow the
application arguments to be interpreted as a single configuration parameter.
(closes issue #16646)
Reported by: pinga-fogo
Patches:
20100414__issue16646.diff.txt uploaded by tilghman (license 14)
Tested by: tilghman
Review: https://reviewboard.asterisk.org/r/547/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@257262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r257070 | mnicholson | 2010-04-13 11:46:30 -0500 (Tue, 13 Apr 2010) | 9 lines
Add an option to restore past broken behavor of the Events manager action
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: https://origsvn.digium.com/svn/asterisk/trunk@257146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
From Reviewboard:
CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date
overview of the architecture can be found in the file doc/CCSS_architecture.pdf
in the CCSS branch. Off the top of my head, the big differences between what is
implemented and what is in the document are as follows:
1. We did not end up modifying the Hangup application at all.
2. The document states that a single call completion monitor may be used across
multiple calls to the same device. This proved to not be such a good idea
when implementing protocol-specific monitors, and so we ended up using one
monitor per-device per-call.
3. There are some configuration options which were conceived after the document
was written. These are documented in the ccss.conf.sample that is on this
review request.
For some basic understanding of terminology used throughout this code, see the
ccss.tex document that is on this review.
This implements CCBS and CCNR in several flavors.
First up is a "generic" implementation, which can work over any channel technology
provided that the channel technology can accurately report device state. Call
completion is requested using the dialplan application CallCompletionRequest and can
be canceled using CallCompletionCancel. Device state subscriptions are used in order
to monitor the state of called parties.
Next, there is a SIP-specific implementation of call completion. This method uses the
methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion
using SIP signaling. There are a few things to note here:
* The agent/monitor terminology used throughout Asterisk sometimes is the reverse of
what is defined in the referenced draft.
* Implementation of the draft required support for SIP PUBLISH. I attempted to write
this in a generic-enough fashion such that if someone were to want to write PUBLISH
support for other event packages, such as dialog-state or presence, most of the effort
would be in writing callbacks specific to the event package.
* A subportion of supporting PUBLISH reception was that we had to implement a PIDF
parser. The PIDF support added is a bit minimal. I first wrote a validation
routine to ensure that the PIDF document is formatted properly. The rest of the
PIDF reading is done in-line in the call-completion-specific PUBLISH-handling
code. In other words, while there is PIDF support here, it is not in any state
where it could easily be applied to other event packages as is.
Finally, there are a variety of ISDN-related call completion protocols supported. These
were written by Richard Mudgett, and as such I can't really say much about their
implementation. There are notes in the CHANGES file that indicate the ISDN protocols
over which call completion is supported.
Review: https://reviewboard.asterisk.org/r/523
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This documentation associated wth tlsbindaddr is still useful so lets
synchronize it between trunk and 1.6.x branches.
(issue #17054)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@255066 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@255021 65c4cc65-6c06-0410-ace0-fbb531ad65f3
application is executing on a channel.
This patch addresses an issue found during working with end-users
using res_fax. If an incoming call is answered in the dialplan, or
jumps to the 'fax' extension due to reception of a CNG tone (with
faxdetect enabled), and then the remote endpoint sends a T.38
re-INVITE, it is possible for the channel's T.38 state to be
'T38_STATE_NEGOTIATING' when the application starts up. Unfortunately,
even if the application wants to use T.38, it can't respond to the
peer's negotiation request, because the AST_CONTROL_T38_PARAMETERS
control frame that chan_sip sent originally has been lost, and the
application needs the content of that frame to be able to formulate a
reply.
This patch adds a new 'request' type to AST_CONTROL_T38_PARAMETERS,
AST_T38_REQUEST_PARMS. If the application sends this request, chan_sip
will re-send the original control frame (with
AST_T38_REQUEST_NEGOTIATE as the request type), and the application
can respond as normal. If this occurs within the five second timeout
in chan_sip, the automatic cancellation of the peer reinvite will be
stopped, and the application will 'own' the negotiation process from
that point onwards.
This also improves the code path in chan_sip to allow sip_indicate(),
when called for AST_CONTROL_T38_PARAMETERS, to be able to return a
non-zero response, which should have been in place before since the
control frame *can* fail to be processed properly. It also modifies
ast_indicate() to return whatever result the channel driver returned
for this control frame, rather than converting all non-zero results
into '-1'. Finally, the new request type intentionally returns a
positive value, so that an application that sends
AST_T38_REQUEST_PARMS can know for certain whether the channel driver
accepted it and will be replying with a control frame of its own, or
whether it was ignored (if the sip_indicate()/ast_indicate() path had
properly supported failure responses before, this would not be
necessary).
This patch also modifies res_fax to take advantage of the new request.
In addition, this patch makes sip_t38_abort() actually lock the
private structure before doing its work... bad programmer, no donut.
This patch also enhances chan_sip's 'faxdetect' support to allow
triggering on T.38 re-INVITEs received as well as CNG tone detection.
Review: https://reviewboard.asterisk.org/r/556/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously only configurable globally. A unit test has also been written to
provide protection against parse failures for supported mailbox options.
(closes issue #16864)
Reported by: kobaz
Patches:
voicemail2.patch uploaded by kobaz (license 834)
Review: https://reviewboard.asterisk.org/r/555/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@254321 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@252762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@252534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
added response to roundtrip delay requests from opposite side
added roundtrip delay request sending to opposite side after answer,
added options for sending request (interval between request and
count of unreplied requests before forced call hangup)
(closes issue #16976)
Reported by: vmikhelson
Patches:
rtdr-1.6.0-2.patch uploaded by may213 (license 454)
Tested by: vmikhelson, may213
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@252277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@252089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
New config parameter "reportalarms" added in chan_dahdi.conf which supports the
following possible values:
"channels": report each channel alarms (current behavior, default for backward compatibility)
"spans": report an "SpanAlarm" event when the span of any configured channel is alarmed
"all": report channel and span alarms (aggregated behavior)
"none": do not report any alarms
(closes issue #16709)
Reported by: nahuelgreco
Patches:
chan_dahdi.c.reportalarms.patch uploaded by nahuelgreco (license 162)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@250392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@249893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This feature allows for parkinglots to be created dynamically within
the dialplan. Thanks to all who were involved with getting this patch
written and tested!
(closes issue #15135)
Reported by: IgorG
Patches:
features.dynamic_park.v3.diff uploaded by IgorG (license 20)
2009090400_dynamicpark.diff.txt uploaded by mvanbaak (license 7)
dynamic_parkinglot.diff uploaded by dvossel (license 671)
Tested by: eliel, IgorG, acunningham, mvanbaak, zktech
Review: https://reviewboard.asterisk.org/r/352/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@247248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
First off, these options weren't actually doing anything.
By the time the options were parsed, the peer and dialog
containers had already been allocated with their default
values.
Second, hash table size is something that doesn't really
make sense to change in a config file. If a user is that
interested in changing the hashtable size, he can modify
the source itself.
I have removed the parsing of the hash_peer, hash_user,
and hash_dialog options. I have removed the hash_user_size
variable altogether since it is not used at all. I also
changed hash_peer_size and hash_dialog_size to be constant,
and have changed the symbols to be in all caps as constants
typically are. I have also removed the entire section in
sip.conf.sample regarding configurable hashtable sizes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@245192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The option is global and currently the acceptable values as noted in the sample
config are accept or deny.
(closes issue #15228)
Reported by: lp0
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@235342 65c4cc65-6c06-0410-ace0-fbb531ad65f3
(closes issue #16263)
Reported by: andrew
Patches:
pagerdate.patch uploaded by andrew (license 240)
(with a slight modification by me)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@232916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously only possible per context, new option called imapfolder.
(closes issue #14298)
Reported by: jablko
Patches:
patch-200906202 uploaded by jablko (license 675)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@232700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@230881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Just updating a spelling error and some capitalization in a
documentation update that Olle added. May the Swenglish be
with you.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@229639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@227361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@226384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a configuration option to SIP peers, unsolicited_mailbox, which
configures a virtual mailbox to use for received new/old MWI information. This
virtual mailbox can then be used by any device supporting MWI.
(closes issue #13028)
Reported by: AsteriskRocks
Patches:
bug_13028_chan_sip_external_mwi_20090707.patch uploaded by cmaj (license 830)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@226060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Added handling of received HOLD/RETRIEVE messages and the optional ability
to transfer a held call on disconnect similar to an analog phone.
* Added CallRerouting/CallDeflection support for Q.SIG, ETSI PTP, ETSI PTMP.
Will reroute/deflect an outgoing call when receive the message.
Can use the DAHDISendCallreroutingFacility to send the message for the
supported switches.
* Added ability to send/receive keypad digits in the SETUP message.
Send keypad digits in SETUP message: Dial(DAHDI/g1[/K<keypad_digits>][/extension])
Access any received keypad digits in SETUP message by: ${CHANNEL(keypad_digits)}
* Added support for BRI PTMP NT mode.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the second commit for this and documents the text stream using the configured
IP address and fixes a bug in the original patch where the UDPTL stream would also
use the different IP address.
(closes issue #14729)
Reported by: _brent_
Patches:
media_address.patch uploaded by brent (license 388)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@225089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@225033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Explains new options for detecting DTMF CID on fxo lines
(issue #9096)
Reported by: fleed
Patches:
chan_dahid_sample_config.patch uploaded by sum (license 766)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Ability has been added to both manager command SIPnotify as well as console
command sip notify. Message body is stored in the "Content" variable. An
example is present in sip_notify.conf.
(closes issue #13926)
Reported by: jthurman
Patches:
sip-notify-svn189463.diff uploaded by gareth (license 208)
Tested by: gareth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@224035 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for TCP/TLS in the Contact header when using
NAT, specifically externip or externhost. The original issue was that
Asterisk sent 5060 as the port in the contact header whether TLS was
used or not. Additionally, this patch adds 2 config options to sip.conf,
specifically externtcpport and externtlsport. This allows a user to
specify different external ports for TCP and TLS other than those used
internally, this is especially useful in in a PAT/port redirection setup.
Thanks to ebroad for reporting the issue and providing the patch!
(closes issue #15880)
Reported by: ebroad
Patches:
portmap.patch uploaded by ebroad (license 878)
externtXXport_v2.patch uploaded by ebroad (license 878)
Tested by: ebroad
Review: https://reviewboard.asterisk.org/r/392/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@222398 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@222110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@221592 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@221432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@221266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
JABBER_RECEIVE (along with JabberSend) makes Asterisk interact with users over
XMPP to process calls.
SendText can be used instead of JabberSend in the context of XMPP based voice
channels (chan_gtalk and chan_jingle).
(closes issue #12569)
Reported by: eech55
Tested by: phsultan, asannucci, lmadsen, jtodd, maxgo
Review: https://reviewboard.asterisk.org/r/88/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@220457 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@216438 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@213098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@210190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@209132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@208813 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a continuation of revision 885 to LibPRI (Capture and expose the Reverse
Charging Indication IE on ISDN PRI) which added the ability to get/set Reverse
Charging Indication in LibPRI. This patch adds the ability to specify RCI on
the outbound leg of a PRI call from within Asterisk, by prefixing the dialed
number with a capital 'C' like:
...,Dial(DAHDI/g1/C4445556666)
And to read it off an inbound channel:
exten => s,1,Set(RCI=${CHANNEL(reversecharge)})
Thanks again to rmudgett for the thorough review.
(closes issue #13760)
Reported by: mrgabu
Review: https://reviewboard.asterisk.org/r/303/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Someone asked yesterday, "is there a good reason why we can't just put these
modules in Asterisk?". After a brief discussion, as long as the modules are
clearly set aside in their own directory and not enabled by default, it is
perfectly fine.
For more information about why a module goes in addons, see README-addons.txt.
chan_ooh323 does not currently compile as it is behind some trunk API updates.
However, it will not build by default, so it should be okay for now.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This might seem like a legitimate comment that merely needed semicolon
prefixes, but in reality, the adaptive layer is designed to allow arbitrary
CDR variables, without needing the use of a userfield to store multiple items.
It's therefore not only invalid syntax but also goes against the intent of the
adaptive method.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@204069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original patch for this was written by Brett Bryant, and I split it out into
it's own module.
(closes issue #12876)
Reported by: bbryant
Patches:
06162008_cdr_custom_syslog.diff uploaded by bbryant (license 36)
05212009_cdr_syslog.patch uploaded by seanbright (license 71)
Tested by: seanbright
Review: https://reviewboard.asterisk.org/r/297/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203846 65c4cc65-6c06-0410-ace0-fbb531ad65f3
CEL is the new system for logging channel events. This was inspired after
facing many problems trying to represent what is possible to happen to a call
in Asterisk using CDR records. For more information on CEL, see the built in
HTML or PDF documentation generated from the files in doc/tex/.
Many thanks to Steve Murphy (murf) and Brian Degenhardt (bmd) for their hard
work developing this code. Also, thanks to Matt Nicholson (mnicholson) and
Sean Bright (seanbright) for their assistance in the final push to get this
code ready for Asterisk trunk.
Review: https://reviewboard.asterisk.org/r/239/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@203638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Also change the preferred configuration option from 'hostname' (which was
misleading because it didn't actually treat the value as a hostname) to
'connection' and added some verbage explaining that the user would need to
refer to their freetds.conf file for those settings. 'hostname' was kept
as a backwards compatible configuration parameter.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@202887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip has an option to save the sysname on rtupdate. This patch copies that same logic to chan_iax.
(closes issue #14837)
Reported by: barthpbx
Patches:
iax2-rtsavesysname.patch uploaded by barthpbx (license 744)
rt_iax.diff uploaded by dvossel (license 671)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@201534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code was there because of the AgentCallbackLogin() application.
->loginchan[] member was only used by AgentCallbackLogin().
Agent where dumped to astdb if they where logged in using AgentCallbacklogin()
so they are not being dumper anymore.
Review: https://reviewboard.asterisk.org/r/267/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@198217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit add Calendaring support to Asterisk for iCalendar, CalDAV, and MS
Exchange calendars. Exchange support has only been tested on Exchange Server 2k3
and does not support forms-based authentication at this time (patches *very*
welcome). Exchange support is also currently missing the ability to return a
list of a meting's attendees (again, patches are very, very welcome).
Features include:
Querying a calendar for events over a specific time range
Checking a calendar's busy status via the dialplan
Writing calendar events via the dialplan (CalDAV and Exchange only)
Handling calendar event notifications through the dialplan
(closes issue #14771)
Tested by: lmadsen, twilson, Shivaprakash
Review: https://reviewboard.asterisk.org/r/58
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197738 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Let's try that again, this time removing trailing whitespace and not leading
whitespace. I can't believe no one noticed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@197535 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/trunk@196416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP purists may want to look the other way...
When COLP/CONP support for SIP was committed, there was a condition under
which Asterisk may transmit a SIP UPDATE in order to communicate the change
in connected line information. The issue here is that while we could send a
SIP UPDATE message, we were not prepared to receive such an UPDATE and would
always responde with a 501 when we received an UPDATE.
The situation was a bit rough. We really want to be able to receive UPDATEs
having to do with connected line changes, but the amount of effort involved
in properly supporting RFC 3311 was staggering. This commit represents a
compromise.
First, it was decided that it is important to only send a SIP UPDATE to
an endpoint that is able to handle one. So, now we have added parsing of
the Allow header into SIP. We store the allowed methods on SIP peers so
that when we communicate with them, we already will know what we can and
cannot send to them. We will parse the peer's allowed methods when he registers
with us. If the peer is not the type to register with us, but the qualify option
is enabled, then we will use the response to the OPTIONS request we send
the peer to determine the peer's allowed methods. When the peer's registration
expires, or when qualify deems the peer to be unreachable, we clear the allowed
methods from the peer.
For an actual call, we will copy the peer's allowed methods to the sip_pvt
representing the call leg. If we are communicating with an endpoint which is
not a peer, then we will just parse the Allow header from the first message
we receive during the call and store the information in the sip_pvt.
If, during communication with a peer, we receive a 501 response, then we will
make sure to save the fact that we cannot use that method when communicating
with that peer.
Now, with all that infrastructure in place, the only actual place we use this
information currently is when attempting to send a connected line change using
an UPDATE request. If we cannot send the change immediately using an UPDATE,
we will set the SIP_NEEDREINVITE flag so that we can send a REINVITE as soon
as it is allowed.
The second part of the changes here is for Asterisk to accept UPDATE requests
that have connected line changes. Since we are not fully supporting RFC 3311,
Asterisk will NOT place the UPDATE method in Allow headers it sends. Instead,
if you are communicating with what you know to be another Asterisk box, you may
set the rpid_update parameter in sip.conf so that we will send UPDATEs to that
Asterisk box. When we send a connected line update, we set a custom header
called "X-Asterisk-rpid-update."
On the receiving end, if Asterisk receives an UPDATE that does not have the
"X-Asterisk-rpid-update" header present, then Asterisk will respond with a 501
since media-changing UPDATEs are not supported. We should never get such
UPDATEs, since as was stated earlier, Asterisk does not put UPDATE in its Allow
header. If the custom header is present in the received UPDATE, though, then we
will check the incoming request for connected line updates and queue the update
on the channel where the change occurred.
ABE-1840
ABE-1822
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Up to now, cdr_custom would only accept a single filename/format from
cdr_custom.conf. This change allows you to specify multiple filename
& format directives.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@195165 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Select what to do with outgoing COLP information on this port.
0 - Send out COLP information unaltered. (default)
1 - Force COLP to restricted on all outgoing COLP information.
2 - Do not send COLP information.
outgoing_colp=0
Also fixed sending the EctInform message so it always has the
required redirectionNumber parameter when the status is active.
JIRA ABE-1853
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@194479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Terry Wilson
David Vossel
Leif Madsen
Paul Belanger
Tilghman Lesher
Alec L Davis
Mark Michelson
Olle Johansson
TransNexus OSP Development
Jeff Peeler
Matthew Nicholson
Richard Mudgett
Tzafrir Cohen
Bradley Latus
Kevin P. Fleming
Alexandr Anikin
Jared Smith
Joshua Colp
Jason Parker
Doug Bailey
Matthias Nick
Philippe Sultan
Michiel van Baak
Sean Bright
Ryan Brindley
Moises Silva
Eliel C. Sardanons
Gavin Henry