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
