| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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: http://svn.digium.com/svn/asterisk/trunk@210190 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
(closes issue #15071)
Reported by: ughnz
Patches:
optional-sms1.diff uploaded by mnicholson (license 96)
Tested by: ughnz, mnicholson
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@209993 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@209674 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@209132 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@208813 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@207095 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206872 | dvossel | 2009-07-16 16:33:19 -0500 (Thu, 16 Jul 2009) | 6 lines
error in iax.conf related IP-based access control
(closes issue #15518)
Reported by: pkempgen
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@206873 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@206603 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@204749 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204654 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
.sample).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204440 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204428 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204423 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204422 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204419 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@204413 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204217 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@204119 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@204069 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@203846 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
configurable values for finer control.
(closes issue #8855)
Reported by: mikma
Tested by: klaus3000, file
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@203735 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
application and channel.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@203699 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@203638 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
GR-303.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@203402 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@202887 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@201534 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the new skip category feature unless supported
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@200799 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
realize this was never done but was working anyways
also added support for skip category request feature of openr2 and updated chan_dahdi.conf.sample
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@200477 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
should be specified.
(closes issue #14367)
Reported by: Nick_Lewis
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@198791 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@198217 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@198186 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197824 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197777 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@197738 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
Let's try that again, this time removing trailing whitespace and not leading
whitespace. I can't believe no one noticed.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197535 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197528 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197406 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197189 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
the sample configuration files.
(closes issue #15207)
Reported by: seandarcy
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@197089 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@196416 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
functionality (allowing multiple mappings).
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@195949 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@195589 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@195165 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194764 | russell | 2009-05-15 13:43:18 -0500 (Fri, 15 May 2009) | 2 lines
Fix some spelling fail.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@194765 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
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: http://svn.digium.com/svn/asterisk/trunk@194479 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193193 | kpfleming | 2009-05-08 09:03:28 -0500 (Fri, 08 May 2009) | 7 lines
Make absolute paths for logger channels work properly
(Note: This is not a new feature, it was previously undocumented and broken.)
The Asterisk logger has a feature to support absolute pathnames for logger channels, but the code implementing the feature was broken. This has been fixed, and the absolute path feature is now documented in the sample logger.conf.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@193194 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
This configuration file was changed to ensure that only one console channel driver
(chan_oss) is loaded by default, but the change would only work if chan_console
was not built. Now it will work as expected; if chan_alsa or chan_console are built
and installed, they will not be loaded unless explicity requested.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191955 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
In discussions today at the Europe Asterisk Developer Meet-Up, we determined that
the event_log was used in only 9 places in the entire tree, and really was not needed
at all. The users have been converted to use LOG_NOTICE, or the messages have been
removed since other messages were already in place that provided the same information.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191785 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191418 f38db490-d61c-443f-a65b-d21fe96a405b
|
|
chan_sip allows for outbound TLS connections, but does not allow the user to specify what protocol to use (default was SSLv2, and still is if this new option is not specified). This patch lets the user pick the SSL/TLS client method for outbound connections in sip.
(closes issue #14770)
Reported by: TheOldSaint
(closes issue #14768)
Reported by: TheOldSaint
Review: http://reviewboard.digium.com/r/240/
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@191177 f38db490-d61c-443f-a65b-d21fe96a405b
|
