This patch changes the install to only install the hook script if
DAHDI is enabled. It also adds the script to the uninstall task, and
moves the DAHDI_UDEV_HOOK_DIR variable so that it's not between the
_MAKEOPTS variables and their comment.
This allows installs which specify a --prefix to work normally, as
long as they don't enable DAHDI.
Review: https://reviewboard.asterisk.org/r/3972/
........
Merged revisions 423281 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423283 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch was supposed to go into a team branch, but I was a bit fast on the
gun before 'svn switch' had apparently moved the target branch over.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes made during format improvements resulted in the
recording to voicemail option 'm' of the MixMonitor app
writing a zero length duration in the msgXXXX.txt file.
This change introduces a new function ast_ratestream(),
which provides the sample rate of the format associated
with the stream, and updates the app_voicemail function
for ast_app_copy_recording_to_vm to calculate the right
duration.
Review: https://reviewboard.asterisk.org/r/3996/
ASTERISK-24328 #close
........
Merged revisions 423192 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1. The number of file descriptors an ioqueue instance can handle is fixed, so we
now spawn the required number to handle the load.
2. Our transport identifiers were exceeding the range supported by pjnath.
3. The TURN client did not set up client binding causing needless bandwidth usage.
4. The code no longer updates address information on each packet.
5. STUN traffic was getting looped back to Asterisk instead of going through the
TURN server.
6. Synchronization now ensures things are completely setup or destroyed.
7. Logging now reflects the target the TURN server is sending to/receiving from
on our behalf.
ASTERISK-23577 #close
Reported by: Jay Jideliov
ASTERISK-23634 #close
Reported by: Roman Skvirsky
Review: https://reviewboard.asterisk.org/r/3982/
........
Merged revisions 423150 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423151 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423152 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423153 65c4cc65-6c06-0410-ace0-fbb531ad65f3
- adds sort=randstart (next to sort=, sort=random, sort=alpha)
- combines duplicate moh option parsing code into a single function
- adds deprecationwarnings for application=r to sort randomly
- adds deprecationwarnings for random=yes to sort randomly
- removes invisible code that was supposed to stay until 1.8
The sort=randstart works like sort=alpha, except we start at a random
position.
Review: https://reviewboard.asterisk.org/r/3991/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This module supports sending both unicast and multicast RTP
to a specified target. Multicast functionality is the same as
chan_multicast_rtp was. In the case of unicast a specific
IP address and port can be specified, along with optional RTP
engine and format in the form of:
UnicastRTP/<ip address>:<port>/<engine>/<format>
This can be useful for sending a copy of a media stream to
another application for processing.
Review: https://reviewboard.asterisk.org/r/3981/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_play_and_record_full() has a parameter called "acceptdtmf" that is a
string of acceptable DTMF digits that may be pressed by a caller to end
and accept the recording.
ARI uses this function in order to perform recording, and it provides
options for what is passed as acceptdtmf to ast_play_and_record_full().
By default, ARI passes an empty string, with the intention that no DTMF
can be used to end the recording.
The problem is that ast_play_and_record_full() attempts to be "helpful"
by setting "#" as the acceptdtmf if an empty string or NULL pointer
has been passed in. With ARI, this results in unexpected behavior
occurring if you have attempted to intercept "#" yourself in order
to perform some other manipulation of the live recording.
This change removes the "helpful" behavior by no longer accepting
"#" as a default acceptdtmf if none is specified by the caller of
ast_play_and_record_full(). This makes the ARI scenario work as
expected.
The other callers of ast_play_and_record_full() are app_voicemail
and app_minivm, and in both cases, they pass an explicit "#" to
ast_play_and_record_full() as acceptdtmf, so they are unaffected
by this change.
........
Merged revisions 422964 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422965 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It would be useful to get the current hold status of a channel.
Added CHANNEL(onhold) item that returns 1 (onhold) and 0 (not-onhold) for
the hold status of a channel.
ASTERISK-24038
Reported by: Matt Jordan
AFS-113 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3983/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On review /r/3977, it was recommended to note in the
sample configuration about the size limitation for
resource lists. However, since there was no section in
the sample configuration at all for resource list
subscriptions, I decided to make a separate commit
where I have added the necessary sample configuration
as well as the size limitation warning.
........
Merged revisions 422853 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422854 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PJSIP, unless a constant is modified at compilation time, limits
SIP requests to 4000 bytes. Full-state RLS notifications can easily
exceed this limit with moderately small lists.
This changeset allows for Asterisk to work around this size limit by
performing its own allocation of the transmission data buffer. This
way, Asterisk can allocate a buffer that exceeds the built-in maximum.
We still impose our own limit of 64000 bytes, mainly because making
allocations larger than that is a bit absurd.
ASTERISK-24181 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/3977
........
Merged revisions 422851 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a CDR is forked, a new CDR is created and appended to the CDR chain for
the Party A. The forked CDR starts life off as a clone of the last
non-finalized for the particular Party A. In the past, merely copying over
the snapshots for Party A/Party B would be sufficient. However, as the CDRs
now contain cached information from Party A - specifically application/data,
context, and extension - we need to copy that over during a fork as well.
Huzzah for unit tests catching this when the context/extension were derived
from a cached value on the CDR instead of on Party A.
........
Merged revisions 422769 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422770 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422771 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On some systems, a timeval's tv_sec/tv_usec will be unsigned lont ints, as
opposed to long ints. When the RTP engine formats these as strings, it was
previously formatting them as signed integers, which can result in some
odd negative timestamp values (particularly on 32-bit systems). This patch
formats the values as unsigned long integers.
........
Merged revisions 422766 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422767 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The context/extension in a CDR is generally considered the destination of a
call. When looking at a 2-party call CDR, users will typically be presented
with the following:
context exten channel dest_channel app data
default 1000 SIP/8675309 SIP/1000 Dial SIP/1000,,20
However, if the Dial actually takes place in a Macro, the current behaviour
in 12 will result in the following CDR:
context exten channel dest_channel app data
macro-dial s SIP/8675309 SIP/1000 Dial SIP/1000,,20
The same is true of a GoSub:
context exten channel dest_channel app data
subs dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20
This generally makes the context/exten fields less than useful.
It isn't hard to preserve these values in the CDR state machine; however, we
need to have something that informs us when a channel is executing a
subroutine. Prior to this patch, there isn't anything that does this.
This patch solves this problem by adding a new channel flag,
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a
Macro or a GoSub. The CDR engine looks for this value when updating a Party A
snapshot; if the flag is present, we don't override the context/exten on the
main CDR object. In a funny quirk, executing a hangup handler must *not* abide
by this logic, as the endbeforehexten logic assumes that the user wants to see
data that occurs in hangup logic, which includes those subroutines. Since
those execute outside of a typical Dial operation (and will typically have
their own dedicated CDR anyway), this is unlikely to cause any heartburn.
Review: https://reviewboard.asterisk.org/r/3962/
ASTERISK-24254 #close
Reported by: tm1000, Tony Lewis
Tested by: Tony Lewis
........
Merged revisions 422718 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an issue where CDRs would get stuck generating an infinite
number of CDRs, eventually crashing Asterisk (and consuming a lot of memory
along the way).
When a channel enters into a multi-party bridge, the CDR engine creates
mappings of each participant to each other participant, picking the 'A' party
as it goes. So, if we have four channels in a multi-party bridge (Alice, Bob,
Charlie, Denise), we would have something like:
Alice => Bob
Alice => Charlie
Alice => Denise
Bob => Charlie
Bob => Denise
Charlie => Denise
This works fine when participants enter the bridge a single time.
When a participant leaves a bridge, the CDRs for that channel are transitioned
to a finalized state.
The bug occurs if Bob rejoins. When the CDR engine creates mappings between the
channels, it walks through all the participants currently in the bridge, and
realizes that no one in the bridge can create a CDR with the channel (Bob).
As such it creates a new CDR for the candidate and appends it to that
candidate's chain. Unfortunately, on this particular code path, it doesn't
stop traversing the candidate's chain. Since we just added ourselves to the
chain, this causes the loop to keep going, constantly adding new CDRs.
This patch makes it so the engine bails when it creates a CDR match in this
case.
Review: https://reviewboard.asterisk.org/r/3964/
ASTERISK-24241 #close
Reported by: Deepak Singh Rawat
Tested by: Deepak Singh Rawat
ASTERISK-24208
Reported by: Frankie Chin
........
Merged revisions 422715 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422716 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* The CHANNEL() audionativeformat, videonativeformat, audioreadformat, and
audiowriteformat now need locking since the media format rework when
accessing the channel's format pointers.
* Increased the buffer size for CHANNEL() audionativeformat and
videonativeformat output strings since the allow=all can be a lengthy
list.
* Tweaked the CHANNEL() XML documentation for secure_bridge_signaling,
secure_bridge_media, and state.
* Ensured the output buffer is initialized for secure_bridge_signaling and
secure_bridge_media.
* Made use the locked_copy_string() macro instead of inlining it for trace
and checkhangup.
........
Merged revisions 422700 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds an option to the dial API that marks an outgoing dial as replacing the dialing channel for the purpose of propagating accountcode. When it is used, AST_CHANNEL_REQUESTOR_REPLACEMENT is used instead of AST_CHANNEL_REQUESTOR_BRIDGE_PEER when setting accountcodes on the involved channels with ast_channel_req_accountcodes.
Review: https://reviewboard.asterisk.org/r/3968/
........
Merged revisions 422684 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422697 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.
As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.
In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.
ASTERISK-24212 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3930
........
Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When ARI manipulates a bridge, it generally doesn't care what the mixing
technology is. Operations on a bridge initiated through ARI should perform
their action in generally the same way, regardless of the bridge's mixing
technology. While the mixing technology may determine how media flows to
channels, the actual operations on a bridge themselves should be the same.
Currently, this isn't the case with holding bridges. When a channel joins
without a role, MoH is started on that channel automatically. Subsequent bridge
operations that would stop MoH would fail (as there is no Announcer channel
playing MoH to the bridge). Starting MoH on the bridge will also create two
MoH streams: one from the MoH being played on the participant channel, and one
from the announcer channel. From the perspective of ARI users, this is
counter-intuitive - I would not expect MoH to be started for me. The mixing
technology determines how media is shared between participants, not the
application experience.
This patch does the following:
* The Stasis bridge class now inspects channels as they are going into a
bridge. If the bridge has a holding capability, and the channel has no
roles, we give it a participant role and mark the default behaviour to have
no entertainment. This allows addChannel operations to continue to set a
participant role with an entertainment option if it felt like it (or could
do it).
* The music on hold channel is now Stasis approved (tm)
Review: https://reviewboard.asterisk.org/r/3929/
ASTERISK-24264 #close
Reported by: Samuel Galarneau
Tested by: Samuel Galarneau
........
Merged revisions 422503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The UniMRCP project distributes Asterisk modules that integrate Asterisk with
UniMRCP, and other Asterisk users use the UniMRCP library as well.
Unfortunately, the UniMRCP license is Apache 2.0, which per the Free Software
Foundation, is not a compatible license with the GPLv2.
"Please note that this license is not compatible with GPL version 2, because it
has some requirements that are not in that GPL version. These include certain
patent termination and indemnification provisions. The patent termination
provision is a good thing, which is why we recommend the Apache 2.0 license for
substantial programs over other lax permissive licenses."
On the other hand, UniMRCP is a great project and we'd like to let people use
it with Asterisk.
This patch updates the LICENSE text to allow users to link Asterisk with
UniMRCP and distribute the resulting binaries.
........
Merged revisions 422293 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422294 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422295 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422296 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reporter on the issue found some issues when upgrading from version 10 to 11
on 55 hosts.
Two situations that can occur with dynamic registrations.
1. With dnsmgr disabled, if the host is not resolvable we are not trying to
resolve the host again when it is time to attempt to register again. This
results in never registering to the host.
2. With dnsmgr enabled, when the host is temporarily not resolvable the
address is set to 0.0.0.0:0 and then when the host is resolvable the port
is not being restored and stays set to 0.
This patch resolves these two issues by:
* Storing the hostname so that it can be used for resolving with DNS.
* Resolve the hostname on the next scheduled attempt to register.
* Storing the port used to reach the host so that when the hostname is
resolvable again, we can set the port again if the port is still unset after
looking up the host.
ASTERISK-23767 #close
Reported by: David Herselman
Tested by: David Herselman, Michael L. Young
Patches:
asterisk-23767-dns_reg_retry_and_set_port_11_v3.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3856/
........
Merged revisions 422274 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Users now have the ability to bind the rtpengine instance to a specific IP
address. For example, you want chan_sip (call control) on eth0 but rtp (media)
on eth1.
ASTERISK-24280 #close
Reported by: Paul Belanger
Tested by: Paul Belanger
Review: https://reviewboard.asterisk.org/r/3952/
Patches:
rtpengine.diff uploaded by Paul Belanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A misunderstanding of how the scheduler worked caused further batched notifications
beyond the first not to get scheduled. Now we reset our scheduler ID to -1 after
the batched notification is sent. This way, further notifications can be scheduled
when they arise.
........
Merged revisions 422239 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422240 65c4cc65-6c06-0410-ace0-fbb531ad65f3