| Age | Commit message (Collapse) | Author |
|---|
|
This adds support for parsing timelen values from config files. This
includes support for all flags which apply to PARSE_INT32. Support for
this parser is added to ACO via the OPT_TIMELEN_T option type.
Fixes an issue where extra characters provided to ast_app_parse_timelen
were ignored, they now cause an error.
Testing is included.
ASTERISK-27117 #close
Change-Id: I6b333feca7e3f83b4ef5bf2636fc0fd613742554
|
|
This has not worked for some time and is no longer actively maintained.
Change-Id: I5110b0db69c152761b58fa025cb0a53b0e544d99
|
|
ASTERISK-26846 #close
Change-Id: I541a1602ff55ab73684e9f8002edb9e0e745d639
|
|
This commit adds support for RFC 5761: Multiplexing RTP Data and Control
Packets on a Single Port. Specifically, it enables the feature when
using chan_pjsip.
A new option, "rtcp_mux" has been added to endpoint configuration in
pjsip.conf. If set, then Asterisk will attempt to use rtcp-mux with
whatever it communicates with. Asterisk follows the rules set forth in
RFC 5761 with regards to falling back to standard RTCP behavior if the
far end does not indicate support for rtcp-mux.
The lion's share of the changes in this commit are in
res_rtp_asterisk.c. This is because it was pretty much hard wired to
have an RTP and an RTCP transport. The strategy used here is that when
rtcp-mux is enabled, the current RTCP transport and its trappings (such
as DTLS SSL session) are freed, and the RTCP session instead just
mooches off the RTP session. This leads to a lot of specialized if
statements throughout.
ASTERISK-26732 #close
Reported by Dan Jenkins
Change-Id: If46a93ba1282418d2803e3fd7869374da8b77ab5
|
|
Blind transfers to a recognized parking extension need to use the parker's
channel variable values to create the dynamic parking lot. This is
because there is always only one parker while the parkee may actually be a
multi-party bridge. A multi-party bridge can never supply the needed
channel variables to create the dynamic parking lot. In the multi-party
bridge blind transfer scenario, the parker's CHANNEL(parkinglot) value and
channel variables are inherited by the local channel used to park the
bridge.
* In park_common_setup(), make use the parker instead of the parkee to
supply the dynamic parking lot channel variable values. In all but one
case, the parkee is the same as the parker. However, in the recognized
parking extension blind transfer scenario for a two party bridge they are
different channels. For consistency, we need to use the parker channel.
* In park_local_transfer(), pass the CHANNEL(parkinglot) value to the
local channel when blind transferring a multi-party bridge to a recognized
parking extension.
* When a local channel starts a call, the Local;2 side needs to inherit
the CHANNEL(parkinglot) value from Local;1.
The DTMF one-touch parking case wasn't even trying to create dynamic
parking lots before it aborted the attempt.
* In parking_park_call(), add missing code to create a dynamic parking
lot.
A DTMF bridge hook is documented as returning -1 to remove the hook.
Though the hook caller is really coded to accept non-zero. See the
ast_bridge_hook_callback typedef.
* In feature_park_call(), don't remove the DTMF one-touch parking hook
because of an error.
ASTERISK-24605 #close
Reported by: Philip Correia
Patches:
call_park.patch (license #6672) patch uploaded by Philip Correia
Change-Id: I221d3a8fcc181877a1158d17004474d35d8016c9
|
|
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
|
|
Asterisk by default will create a single database connection and share
it among all threads that attempt to access the database. In previous
versions of Asterisk, this was tolerable, because the most used channel
driver, chan_sip, mostly accessed the database from a single thread.
With PJSIP, however, many threads may be attempting to perform database
operations, and there is the potential for many more database accesses,
meaning the concurrency is a horrible bottleneck if only one connection
is shared.
Asterisk has a connection pooling facility built into it, but the
implementation has flaws. For one, there is a strict limit on the number
of simultaneous connections that could be made to the database. Anything
beyond the maximum would result in a failed operation. Attempting to
predict what the maximum should be is nearly impossible even for someone
intimately familiar with Asterisk's threading model. In addition, use of
transactions in the dialplan can cause some severe bugs if connection
pooling is enabled.
This commit seeks to fix the concurrency problem by removing all
connection management code from Asterisk and leaving that to the
underlying unixODBC code instead. Now, Asterisk does not share a single
connection, nor does it try to maintain a connection pool. Instead, all
Asterisk ever does is request a connection from unixODBC and allow
unixODBC to either allocate those connections or retrieve them from a
pool.
Doing this has a bit of a ripple effect. For one, since connections are
not long-lived objects, several of the safeguards that previously
existed have been removed. We don't have to worry about trying to use a
connection that has gone stale. In every case, when we request a
connection, it has just been made and we don't need to perform any
sanity checks to be sure it's still active.
Another major player affected by this change is transactions.
Transactions and their respective connections were so tightly coupled
that it was almost pornographic. This code change moves
transaction-related code to its own file separate from the core ODBC
functionality. This way, the core of ODBC does not even have to know
that transactions exist.
In making this large change, I had to look at a lot of code and
understand it. When making this change, I discovered several places
where the behavior is definitely not ideal, but it seemed outside the
scope of this change to be fixing it. Instead, any place where I saw
some sort of room for improvement has had a XXX comment added explaining
what could be altered to improve it.
Change-Id: I37a84def5ea4ddf93868ce8105f39de078297fbf
|
|
Since res_pjsip now depends on res_pjproject, this is now mentioned
in UPGRADE.txt and the basic-pbx modules.conf has been updated.
Change-Id: I42826597d5e10f08e518208860c44c96e52f1b2d
|
|
Change-Id: I510991c60d28d171f47c4b58bba4947f7fc71b13
|
|
Due to backwards compatible changes, the ARI version should be bumped to
1.8.0 prior to the release of 13.5.0. Note that a previous patch already
bumped the version of AMI for this release.
Change-Id: I419033bfbbc0d3533a29ccb32b2981f39e0883e7
|
|
* The AMI version is bumped to 2.8.0.
ASTERISK-25189 #close
Reported by: John Hardin
Change-Id: I2b1778c3fdc1dca0ed55db4e3a639eddfb16c2ac
|
|
This patch updates the version of ARI to 1.7.0 to reflect the backwards
compatible changes that will be introduced in 13.4.0.
Change-Id: I6c36e6144da426412f25828a868e4df916bff60a
|
|
This patch adds a new option to cdr.conf, 'newcdrcolumns', that will handle CDR
columns added in Asterisk 1.8. The columns are:
* peeraccount
* linkedid
* sequence
When enabled, the columns in the database entry will be populated with the data
from the CDR.
ASTERISK-24976 #close
Change-Id: I51a57063f4ae5e194a9d933a8df45dc8a4534f0b
|
|
Some telco switches occasionally ignore ISDN RESTART requests. The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request. If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco. The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.
chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code. Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards. I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.
* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.
ASTERISK-25034 #close
Reported by: Richard Mudgett
Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
|
|
Add new column to INSERT new columns added in cdr 1.8 version. The columns are:
* peeraccount
* linkedid
* sequence
This feature is configurable in cdr_odbc.conf using a new configuration
option, 'newcdrcolumns'.
ASTERISK-24976 #close
Change-Id: Ibe0c7540a88305c6012786f438a0813ad8b19127
|
|
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file.
As a result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Alter the "core show file version" CLI command such that it always
reports the version of Asterisk. The file version is no longer
available.
* main/manager: The Version key now always reports the Asterisk version.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action.
- Modification of the "core show file version" CLI command.
Change-Id: Ia932d3c64cd18a14a3c894109baa657ec0a85d28
|
|
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds a new session supplement that handles in-dialog OPTIONS
requests. Said OPTIONS requests are sent a 200 OK, as an endpoint lookup
for the OPTIONS request would already have been done by the time the
session supplement receives the inbound request.
ASTERISK-24862 #close
Reported by: yaron nahum
patches:
res_pjsip_dlg_options.c submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The distinctive ring feature interferes with detecting Caller ID and
appears to have been broken for years. What happens is if you have a
ring-ring cadence as used in the UK you get too many DAHDI events for the
distinctive ring pattern array and Caller ID detection is aborted. I
think when Zapata/DAHDI added the ring begin event it broke distinctive
ring. More events happen than before and the code does no filtering of
which event times are recorded in the pattern array.
* Made distinctive ring only record the ringt count when the ring ends
instead of on just any DAHDI event. Distinctive ring can be ring,
ring-ring, ring-ring-ring, or different ring durations for the up to three
rings.
* Fixed the distinctive ring detection enable (chan_dahdi.conf option
usedistinctiveringdetection) to be per port instead of somewhat per port
and somewhat global. This has been broken since v1.8.
* Fixed using the default distinctive ring context when the detected
pattern does not match any configured dringX patterns. The default
context did not get set when the previous call was a matched distinctive
ring pattern and the current call is not matched. This has been broken
since v1.8.
* Made distinctive ring have no effect on Caller ID detection when it is
disabled. Caller ID detection just monitors for 10 seconds before giving
up.
* Fixed leak of struct callerid_state memory when a polarity reversal
during Caller ID detection causes the incoming call to be aborted.
DAHDI-1143
AST-1545
ASTERISK-24825 #close
Reported by: Richard Mudgett
ASTERISK-17588
Reported by: Daniel Flounders
Review: https://reviewboard.asterisk.org/r/4444/
........
Merged revisions 432530 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432534 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
across a bridge.
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@430434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
mode.
For the featdmf signaling mode the incoming MF Caller-ID information is
formatted as follows: *${CALLERID(ani2)}${CALLERID(ani)}#*${EXTEN}#
Rather than discarding the ani2 digits, populate the CALLERID(ani2) value
with what is received instead.
AST-1368 #close
Reported by: Denis Martinez
Patches:
extract_ani2_for_featdmf_v11.patch (license #5621) patch uploaded by Richard Mudgett
........
Merged revisions 429783 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
AMI/ARI are getting a few enhancements in the next release of Asterisk 13. Per
semantic versioning, that warrants a bump in the minor version number, as it
reflects a backwards compatible change. Hence, this commit.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@429091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@428687 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a packet exceeds the MTU, pjproject will switch from UDP to TCP. In
some circumstances (on some networks), this can cause some issues with
messages not getting sent to the correct destination - and can also cause
connections to get dropped due to quirks in pjproject deciding to
terminate TCP connections with no messages.
While fixing the routing/messaging issues is important, having a
configuration option in Asterisk that tells pjproject to not switch over
to TCP would be useful. That way, if some glitch is discovered on some
other network/site, we can at least disable the behavior until a fix is
put into place.
AFS-197 #close
Review: https://reviewboard.asterisk.org/r/4137/
........
Merged revisions 427129 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@427130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 422255 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@422256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When issuing a POST /channels/{channel_id}/play on a channel that is not
yet answered, ARI is supposed to:
* Queue up an AST_CONTROL_PROGRESS on the channel
* Start up the playback of the media
Instead, we sneak an answer on the channel right before starting playing media.
This is due to ARI's usage of control_streamfile. This function implicitly
answers the channel (and doesn't give ARI the option to stop it). The answering
of the channel here is probably unnecessary:
* app_voicemail, by far the biggest consumer of this function, always answers
the channels anyway
* control stream file (in res_agi) and ControlPlayback probably shouldn't be
implicitly answering the channel. Answering should not be tied directly to
playing back media.
As it turns out, the answering of the channel here is pretty old:
356042 twilson if (ast_channel_state(chan) != AST_STATE_UP) {
3087 anthm res = ast_answer(chan);
180259 tilghman }
(As in, ancient?)
Note that others ran into this problem and commented about it on various
mailing lists.
Review: https://reviewboard.asterisk.org/r/3907/
ASTERISK-24229 #close
Reported by: Matt Jordan
........
Merged revisions 421695 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@421696 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch gives the optional ability to keep queue rules in RealTime. It is
important to note that with this patch:
(a) Queue rules in RealTime are only examined on module load/reload
(b) Queue rules are loaded both from the queuerules.conf file as well as the
RealTime backend
To inform app_queue to examine RealTime for queue rules, a new setting has been
added to queuerules.conf's general section "realtime_rules". RealTime queue
rules will only be used when this setting is set to "yes".
The schema for the database table supports a rule_name, time, min_penalty, and
max_penalty columns. min_penalty and max_penalty can be relative, if a '-' or
'+' literal is provided. Otherwise, the penalties are treated as constants.
For example:
rule_name, time, min_penalty, max_penalty
'default', '10', '20', '30'
'test2', '20', '30', '55'
'test2', '25', '-11', '+1111'
'test2', '400', '112', '333'
'test3', '0', '4564', '46546'
'test_rule', '40', '15', '50'
which would result in :
Rule: default
- After 10 seconds, adjust QUEUE_MAX_PENALTY to 30 and adjust
QUEUE_MIN_PENALTY to 20
Rule: test2
- After 20 seconds, adjust QUEUE_MAX_PENALTY to 55 and adjust
QUEUE_MIN_PENALTY to 30
- After 25 seconds, adjust QUEUE_MAX_PENALTY by 1111 and adjust
QUEUE_MIN_PENALTY by -11
- After 400 seconds, adjust QUEUE_MAX_PENALTY to 333 and adjust
QUEUE_MIN_PENALTY to 112
Rule: test3
- After 0 seconds, adjust QUEUE_MAX_PENALTY to 46546 and adjust
QUEUE_MIN_PENALTY to 4564
Rule: test_rule
- After 40 seconds, adjust QUEUE_MAX_PENALTY to 50 and adjust
QUEUE_MIN_PENALTY to 15
If you use RealTime, the queue rules will be always reloaded on a module
reload, even if the underlying file did not change. With the option disabled,
the rules will only be reloaded if the file was modified.
Review: https://reviewboard.asterisk.org/r/3607/
ASTERISK-23823 #close
Reported by: Michael K
patches:
app_queue.c_realtime_trunk.patch uploaded by Michael K (License 6621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420624 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420607 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@420496 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call. It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.
SIP/100 -> Local;1/Local;2 -> SIP/200
Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.
Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options. Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.
Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support. The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode. The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.
With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work. Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:
SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100
If a channel already has an accountcode it can only change by the
following explicit user actions:
1) A channel originate method that can specify an accountcode to use.
2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial. e.g., Dial and
FollowMe. The exception to this propagation method is Queue. Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.
3) Dialplan using CHANNEL(accountcode).
4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.
If a channel does not have an accountcode it can get one from the
following places:
1) The channel driver's configuration at channel creation.
2) Explicit user action as already indicated.
3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.
You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications. Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.
Accountcode and peeraccount values propagate to an outgoing channel before
dialing. Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge. The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.
* Made peeraccount functional by changing accountcode propagation as
described above.
* Fixed CEL extracting the wrong ie value for the peeraccount. This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.
* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.
AFS-65 #close
Review: https://reviewboard.asterisk.org/r/3601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This moves all samples configs from configs/ to configs/samples. This allows
for additional sets of sample configuration files to be added in the future.
Review: https://reviewboard.asterisk.org/r/3804/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
progressinband=never in sip.conf is easily defeated if an onward trunk sends a
progress indication of its own. This is almost certain to happen if the onward
trunk is ISDN or IAX as these technologies send a progress indication even if
early media is not required. This progress message is passed to the caller,
and causes the "never" option to be rather badly named.
This patch changes the behaviour of this setting in the following ways:
1) In sip_write(), do not pass the media unless we have either progressed
beyond INV_EARLY_MEDIA, or we are in INV_EARLY_MEDIA state, and early
media is both set-up and wanted. This helps resolve double-ringing on some
buggy handsets.
2) In sip_indicate(), if we see AST_CONTROL_PROGRESS, but
SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to avoid implicitly
enabling early media. Avoid sending double ring indications.
NOTE: the meaning of the SIP_PROGRESS_SENT flag changes slightly in this patch
to also encapsulate the fact that a channel has *sent or received* a 183
Progress indication. This makes the updated code in sip_write() much more
simple.
Review: https://reviewboard.asterisk.org/r/3700
ASTERISK-23972 #close
Reported by: Steve Davies
patches:
inband_never_present_early_media2 uploaded by Steve Davies (License 5012)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The commit that added libxml2 support didn't fully check for the libxml2
development script in the Asterisk configure file. As a result, Asterisk could
be configured, then fail on menuselect. This patch fixes it so that Asterisk
should detect the libxml2 dependency failure first.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418850 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This is the final patch in adding menuselect to Asterisk.
- The first patch (r418832) added menuselect along with mxml
- The second patch (r418833) removed mxml from menuselect
This patch adds support for libxml2 to menuselect, and makes libxml2 a
required library for Asterisk.
Note that the libxml2 portion of this patch was written by Sean Bright,
and was made available on a team branch:
http://svn.digium.com/svn/menuselect/team/seanbright/libxml2/
Review: https://reviewboard.asterisk.org/r/3773/
ASTERISK-20703 #close
patches:
some_mysterious_team_branch uploaded by seanbright (License 5060)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When the PresenceState action is executed, the nominal path fails to include
the ActionID in the successful response. This patch adds a call to
astman_start_ack, which guarantees that an ActionID (if provided) will be
sent back to the AMI client.
Unlike the Asterisk 11 and 12 patches, this patch also deprecates the
duplicate Message key in the response to the action, replacing it with the
key 'PresenceMessage'.
Review: https://reviewboard.asterisk.org/r/3776/
ASTERISK-23985 #close
........
Merged revisions 418713 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 418714 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.
Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.
The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.
For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.
And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.
To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.
Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.
We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.
It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.
And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.
Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.
This patch removes:
* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge
It removes the following applications/functions:
* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO
It removes the colon delimiter from the SIPPEER function.
Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
Review: https://reviewboard.asterisk.org/r/3698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.
Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP. It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed. This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.
NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.
The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.
This commit is a merge of the two patches indicated below.
ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
pri-4.diff (license #6302) patch uploaded by Pavel Troller
jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett
Review: https://reviewboard.asterisk.org/r/3633/
........
Merged revisions 417956 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417957 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417958 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Persistent HTTP connection support is needed due to the increased usage of
the Asterisk core HTTP transport and the frequency at which REST API calls
are going to be issued.
* Add http.conf session_keep_alive option to enable persistent
connections.
* Parse and discard optional chunked body extension information and
trailing request headers.
* Increased the maximum application/json and
application/x-www-form-urlencoded body size allowed to 4k. The previous
1k was kind of small.
* Removed a couple inlined versions of ast_http_manid_from_vars() by
calling the function. manager.c:generic_http_callback() and
res_http_post.c:http_post_callback()
* Add missing va_end() in ast_ari_response_error().
* Eliminated unnecessary RAII_VAR() use in http.c:auth_create().
ASTERISK-23552 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3691/
........
Merged revisions 417880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* SS7 support now requires libss7 v2.0 or later. The new libss7 is not
backwards compatible.
* Added SS7 support for connected line and redirecting.
* Most SS7 CLI commands are reworked as well as new SS7 commands added.
See online CLI help.
* Added several SS7 config option parameters described in
chan_dahdi.conf.sample.
* ISUP timer support reworked and now requires explicit configuration.
See ss7.timers.sample.
Special thanks to Kaloyan Kovachev for his support and persistence in
getting the original patch by adomjan updated and ready for release.
SS7-27 #close
Reported by: adomjan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
MixMonitor AMI commands StartMixMonitor and StopMixMonitor lacked class
authorization. StopMixMonitor now requires that the manager user either have
the call or system class authorization. StartMixMonitor is a slightly larger
issue since it can execute shell commands if the right arguments are passed
into it, and we consider this a permission escalation. A security release
will be issued for problem this shortly.
ASTERISK-23609 #close
Reported by: Corey Farrell
........
Merged revisions 415825 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415832 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
From now on, make install will overwrite safe_asterisk with the
latest version. You need to move any local modifications to files
inside /etc/asterisk/startup.d, if you have any.
See also commits r394939 and r397938.
ASTERISK-21965 #close
Patches:
safe_asterisk.patch uploaded by jkister (License 6232, modified by me)
........
Merged revisions 415748 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415749 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Replaced a stray echo that should've been a message call in
safe_asterisk. This replaces a conditional log message by a slightly
different message. Please update your log parsing scripts.
* Made the $NOTIFY mail Subject more verbose by adding the machine name
and exitstatus.
(Note that a 'make install' still won't overwrite your old safe_asterisk
if it exists. See ASTERISK-21965.)
ASTERISK-23492 #close
........
Merged revisions 415521 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415522 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 415523 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 414345 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 414346 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 414347 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Per rfc3892, the Referred-By header in a REFER must be copied into the
referenced request (IE. The outgoing INVITE to the transfer target).
* Automatically put the Referred-By header in the outgoing INVITE message
if the SIPREFERREDBYHDR channel variable is defined with a value.
* Made chan_sip.c:get_refer_info() set SIPREFERREDBYHDR for inheritance so
chan_pjsip has a better chance to interoperate.
* Fixed refer_blind_callback() and refer_incoming_refer_request() to not
modify the data in the pointer returned by pjsip_msg_find_hdr_by_name().
It seems wrong to modify that data since the calling routine doesn't own
the buffer.
ASTERISK-23501 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3514/
........
Merged revisions 413210 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
1) Added the unistim.conf variable dtmf_duration which can select the DTMF playback duration from 0ms to 150ms (0 is off and is the new default)
2) Enabled the transmission of month names, which are sent with the date and changed the dateformat variable to accept the values 0-3 as per the UNISTIM standard (2 & 3 match the previous 1 & 2 formats).
3) Enabled the "Mute" packet so muting microphone works as expected and microphone muted for all calls while LED light on
4) Changed Duree to Timer on i2004 display
(closes issue ASTERISK-23592)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
Every run will now blow away the previous run (as large ref files
sometimes caused issues). We now also no longer open/close the file
on each write, instead relying on fflush to make sure data gets written
to the file (in case the ao2 call being performed is about to cause a
crash)
(3) It goes with a comma delineated format for the ref debug file. This
makes parsing much easier. This also now includes the thread ID of the
thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
contrib/scripts folder.
(5) The old refcounter implementation in utils/ has been removed.
Review: https://reviewboard.asterisk.org/r/3377/
........
Merged revisions 412114 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412115 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 412153 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
