https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r314628 | mnicholson | 2011-04-21 13:24:05 -0500 (Thu, 21 Apr 2011) | 27 lines
Merged revisions 314620 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r314620 | mnicholson | 2011-04-21 13:22:19 -0500 (Thu, 21 Apr 2011) | 20 lines
Merged revisions 314607 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r314607 | mnicholson | 2011-04-21 13:19:21 -0500 (Thu, 21 Apr 2011) | 14 lines
Added limits to the number of unauthenticated sessions TCP based protocols are allowed to have open simultaneously. Also added timeouts for unauthenticated sessions where it made sense to do so.
Unrelated, the manager interface now properly checks if the user has the "system" privilege before executing shell commands via the Originate action.
AST-2011-005
AST-2011-006
(closes issue #18787)
Reported by: kobaz
(related to issue #18996)
Reported by: tzafrir
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "controlling user number" is always the number of the voice mail box
which is identical with the subscriber number itself. This number which
is listed in the ISDN phone MWI menu cannot be called back to contact the
voice mail box. The controlling user number should be made configurable.
JIRA ABE-2738
JIRA SWP-2846
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add Asterisk Device State information and callbacks to the Call Completion
Supplemental Services for generic agents.
There are currently not many devices that have native support for CCSS.
Even as the devices become available there may be other reasons why one
may choose to not take advantage of the native abilities and stick with
the generic implementation. The generic implementation is quite capable
and could be greatly enhanced by adding device state capabilities. A
phone could then subscribe to the device state with a BLF key in
conjunction with Asterisk hints.
The advantages of the device state information would allow a single button
to: request CCSS, cancel a CCSS request, and display the current state of
a CCSS request.
For example, you may have a single button that when not lit, there is no
active CCSS request. When you press that button, the dialplan can query
the DEVICE_STATE() associated with that caller to determine whether they
should be calling CallCompletionRequest() or CallCompletionCancel(). If
there is currently a pending request, then the dialplan would cancel it.
This also has the advantage of showing the true state of a request, which
is an asynchronous call, even when CallCompletionRequest() thinks it was
successful. The actual request could ultimately fail. Once lit, further
feedback can be provided to the caller about the current state of their
request since it will be updated by the CCSS State Machine as appropriate.
The DEVICE_STATE mapping is configurable since the BLF being used on a
given phone type may vary. The idea is to allow some level of
customization as to the phone's behavior.
As an example, you may want the BLF key to go solid once you have
requested a callback. You may then want the LED to blink (typically
ringing) when either the callback is in process, which is a visual
indication that the incoming call is the desired callback. You may want
it to blink when the callee is ready but you are busy, giving you a visual
indication that the target is available as you may want to get off the
line so that the callback can be successful.
Device state information is sent back via the ast_devstate_prov_add()
callback for any generic CCSS device as it traverses through the state
machine. You simply provide a map between CC_STATE values and the
corresponding AST_DEVICE state values.
You could then generate hints against these states similar to what is
possible today with Custom Devstates or MeetMe states. For example, you
may have an extension 3000 that is currently associated with device
SIP/3000. You could then create a feature code for that extension that
may look something like:
exten => *823000,hint,ccss:sip/3000
You would then subscribe a BLF button to *823000 which would point to the
dialplan that handled CCSS requests/cancels using the available
DEVICE_STATE() information about ccss:sip/3000 to make the decision about
what to do.
(closes issue #18788)
Reported by: p_lindheimer
Patches:
ccss.trunk.18788.patch uploaded by p lindheimer (license 558)
Modified with final reviewboard comments.
Tested by: p_lindheimer, loloski
Review: https://reviewboard.asterisk.org/r/1105/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adding the setvar option with variable substitution on the value allows things
like setting the outbound caller id name to the summary of a calendar event,
etc. Values could be chained together as they are appended in order to do some
scripting if necessary.
Review: https://reviewboard.asterisk.org/r/1134/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The display ie handling can be controlled independently in the send and
receive directions with the following options:
* Block display text data.
* Use display text in SETUP/CONNECT messages for name.
* Use display text for COLP name updates (FACILITY/NOTIFY as appropriate).
* Pass arbitrary display text during a call. Sent in INFORMATION
messages. Received from any message that the display text was not used as
a name.
If the display options are not set then the options default to legacy
behavior.
The arbitrary display text is exchanged between bridged channels using the
AST_FRAME_TEXT frame type.
To send display text from the dialplan use the SendText() application when
the arbitrary display text option is enabled.
JIRA SWP-2688
JIRA ABE-2693
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r305247 | qwell | 2011-01-31 16:25:23 -0600 (Mon, 31 Jan 2011) | 7 lines
Add alternative name for config option.
The SIP sample configuration had "tlscadir" as the option name, but chan_sip
used the more correct "tlscapath". Now both are accepted.
Discovered (sort of) by a user on IRC in #asterisk
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@305248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303009 | jpeeler | 2011-01-20 11:10:32 -0600 (Thu, 20 Jan 2011) | 21 lines
Merged revisions 303008 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303008 | jpeeler | 2011-01-20 11:07:44 -0600 (Thu, 20 Jan 2011) | 14 lines
Merged revisions 303007 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303007 | jpeeler | 2011-01-20 11:04:08 -0600 (Thu, 20 Jan 2011) | 8 lines
Add new queue strategy to preserve behavior for when queue members moved to ao2.
Add queue strategy called "rrordered" to mimic old behavior from when queue
members were stored in a linked list.
ABE-2707
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the moh_signaling option to specify what to do when the channel's
bridged peer puts the ISDN channel on and off of hold.
Implemented as a FSM to control libpri ISDN signaling when the bridged
peer places the channel on and off of hold with the AST_CONTROL_HOLD and
AST_CONTROL_UNHOLD control frames.
JIRA SWP-2687
JIRA ABE-2691
Review: https://reviewboard.asterisk.org/r/1063/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292787 | lmadsen | 2010-10-22 16:28:43 -0500 (Fri, 22 Oct 2010) | 21 lines
Merged revisions 292786 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r292786 | lmadsen | 2010-10-22 16:16:12 -0500 (Fri, 22 Oct 2010) | 13 lines
Update the LDIF file for LDAP.
The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
would cause problems and ERROR messages when registering.
Additional documention has been added based on feedback in the issue I'm closing.
(closes issue #13861)
Reported by: scramatte
Patches:
ldap-update.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, jcovert, suretec, rgenthner
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292050 | tzafrir | 2010-10-16 12:47:00 +0200 (ש', 16 אוק 2010) | 22 lines
Merged revisions 292049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r292049 | tzafrir | 2010-10-16 12:03:04 +0200 (ש', 16 אוק 2010) | 15 lines
Base directory for MOH should be ASTDATADIR
If the directive 'directory' is relative, make it relative to the
datadir, rather than to the varlibdir. In the sample configuration
it is relative ('moh').
This has no effect unless you have actively set the datadir explicitly
(at build time or at run time).
(closes issue #16906)
Patches:
moh_datadir uploaded by tzafrir (license 46)
Review: https://reviewboard.asterisk.org/r/974/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291192 | dvossel | 2010-10-11 16:38:39 -0500 (Mon, 11 Oct 2010) | 19 lines
Gtalk enhancements and general code cleanup.
This patch includes several chan_gtalk enhancements.
Two new gtalk.conf options have been added, externip
and stunadd. Setting externip allows us to
manually specify what the external IP address is
outside of a NAT environment. Setting the stunaddr
option to a valid stun server allows for that external
ip to be retrieved via a STUN server automatically. This
external IP is then advertised during call setup as
a possible candidate.
I have also attempted to clean up chan_gtalk's code
so it meets our coding guidelines. During this cleanup
I noticed several things that need to be done in the
code and made a TODO section at the top of the file.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286931 | jpeeler | 2010-09-15 14:22:15 -0500 (Wed, 15 Sep 2010) | 16 lines
Add parking extension for non-default parking lots.
This is a new feature that allows for parking to custom parking lots to be
accessed directly, rather than with channel variables or by changing the
default parking lot. The extension is set with the parkext option just as the
default parking lot is done. Also, the manager action has been updated to
optionally allow a specified parking lot.
(closes issue #14882)
Reported by: vmikhnevych
Patches:
patch_14882.txt uploaded by mnick (license 874)
modified by me
Review: https://reviewboard.asterisk.org/r/884/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r285006 | dvossel | 2010-09-03 17:21:50 -0500 (Fri, 03 Sep 2010) | 9 lines
Disables auth_options_request option by default.
The auth_options_request option was created to do authentication
on OPTIONS request just like INVITES are done. Since it has been
noted that some endpoints use OPTIONS requests as a way of qualifying
a peer and that a 401 authentication response could result in
interoperability issues, this option has been disabled by default.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284950 | dvossel | 2010-09-03 12:29:02 -0500 (Fri, 03 Sep 2010) | 14 lines
authenticate OPTIONS requests just like we would an INVITE
OPTIONS requests should be treated the same as an INVITE
This includes authentication. This patch adds the ability for
incoming out of dialog OPTION requests to be authenticated
before providing a response indicating whether an extension
is available or not. The authentication routine works the
exact same way as it does for incoming INVITEs. This means
that if a peer has 'insecure=invite' in their peer definition,
the same will be true for the processing of the OPTIONS request.
Review: https://reviewboard.asterisk.org/r/881/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r283173 | russell | 2010-08-23 06:58:34 -0500 (Mon, 23 Aug 2010) | 5 lines
Expand cel_custom.conf.sample.
Include the usage of CSV_QUOTE() to ensure data has valid CSV formatting. Also list
the special CEL variables that are available for use in the mapping.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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