The new option 'preferchannelclass' is added to musiconhold.conf. If yes
(the default) the CHANNEL(musicclass) is preferred when choosing the
hold music. If it is no, the class suggested by the application that
calls the MoH (e.g. the Queue() app) gets preferred (new behaviour).
This way you set a different hold-music from the Queue-music by setting
both the CHANNEL(musicclass) and the queue-context musicclass.
ASTERISK-24276 #close
Reported by: Kristian Høgh
Patches:
app_override_channel_moh.patch uploaded by Kristian Høgh (License #6639)
Review: https://reviewboard.asterisk.org/r/4010/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The crash on the issues is a result of an invalid transport configuration
change when asterisk is restarted. The attempt to send the qualify
request fails and we cleaned up. However, the callback is also called
which results in a double unref of the objects involved.
* Put a wrapper around pjsip_endpt_send_request() to detect when the
passed in callback is called because of an error so callers can know to
not cleanup.
* Made send_request_cb() able to handle repeated challenges (Up to 10).
* Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding
it. The sched entry will no longer self stop and must be externally
stopped.
* Added REF_DEBUG description tags to struct sched_data in
pjsip_options.c.
* Fix some off-nominal ref leaks in schedule_qualify(),
qualify_and_schedule().
* Reordered pjsip_options.c module start/stop code to cleanup better on
error.
ASTERISK-24295 #close
Reported by: Rogger Padilla
Review: https://reviewboard.asterisk.org/r/3954/
........
Merged revisions 423866 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423867 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this commit, CDR and CEL tests were expected to trigger
FRACKs (i.e. assertions) due to the fact that the channels they
create have no formats on them. Some code was independently added
recently that attempts to prevent FRACKs from occurring by failing
early when attempting to set up translation paths if one or both
channels support no formats. Unfortunately, this attempt to be helpful
made the CDR and CEL tests go from simply FRACKing to outright
failing and in some cases, failing so badly as to crash Asterisk.
This commit seeks to correct past mistakes by adding the ulaw format
to channels created by the CDR and CEL unit tests. This makes setting
up translation paths succeed, eliminates previously-seen FRACKs, and
ultimately causes the unit tests to succeed again.
Review: https://reviewboard.asterisk.org/r/4014
........
Merged revisions 423783 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r423414 (13) / r423415 (trunk), an API call that determines if a format
capability structure is empty was added. This returns true if the format
capability structure is completely empty or "none". A check for this was added
in channel.c's set_format call. Unfortunately, when this check was true, it
returned from the function while still holding the channel lock. This caused
the CDR unit tests - which have a tendency to create channels with no formats -
to deadlock. Whoops.
This patch unlocks the channel on the off-nominal path.
........
Merged revisions 423641 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to the release of Swagger 1.2, the attribute 'extends' was being
promoted as a possible way to show that a particular object extends an existing
object. Instead, the Swagger specification went with the 'subTypes' attribute
in the base object. This patch removes the unsupported attribute; the object
that the offending objects proposed to extend already lists them in its
'subTypes' attribute.
ASTERISK-24300 #close
Reported by: Bradley Watkins
........
Merged revisions 423620 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423621 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When unloading the module did not unregister the CLI commands causing a crash upon
load when they were registered again.
When reloading the module the return value from the config options framework was not
checked to determine if an error occurred or not. This caused a message to be output
saying the module did not exist when reloading if no changes were present.
AST-1433 #close
AST-1434 #close
........
Merged revisions 423579 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423580 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423581 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Outgoing PJSIP calls can result in non-negotiated formats listed in the
channel's native formats if video formats are listed in the endpoint's
configuration. The resulting call could then use a non-negotiated format
resulting in one way audio.
* Simplified the update of session->req_caps in set_caps(). Why do
something in five steps when only one is needed?
AFS-162 #close
Review: https://reviewboard.asterisk.org/r/4000/
........
Merged revisions 423561 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change gives framehooks a reverse-direction masquerade callback in
addition to chan_fixup_cb similar to the callback added to datastores
to handle the same situation. The new callback provides the same
parameters as the fixup callback, but is called on the new channel's
framehooks before moving framehooks from the old channel to the new
channel. This gives the framehooks an oppurtunity to decide whether
they should remain on the new channel or be removed.
This new callback is used to prevent the PJSIP T.38 framehook from
remaining on a masqueraded channel if the new channel is not also a
PJSIP channel. This was causing a crash when a local channel was
masqueraded into a PJSIP channel and the framehook was executed on the
local channel since the channel's tech private data was not structured
as expected.
Review: https://reviewboard.asterisk.org/r/4001/
........
Merged revisions 423503 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423504 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423505 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This function acts like strsep with three exceptions...
* The separator is a single character instead of a string.
* Separators inside quotes are treated literally instead of like separators.
* You can elect to have leading and trailing whitespace and quotes
stripped from the result and have '\' sequences unescaped.
Like strsep, ast_strsep maintains no internal state and you can call it
recursively using different separators on the same storage.
Also like strsep, for consistent results, consecutive separators are not
collapsed so you may get an empty string as a valid result.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3989/
........
Merged revisions 423476 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423478 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423480 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Empty here means that there are no formats in the format_cap structure
or the only format in it is the "none" format.
I've added calls to check the emptiness of a format_cap in a few places
in order to short-circuit operations that would otherwise be pointless
as well as to prevent some assertions from being triggered in cases
where channels with no formats are used.
........
Merged revisions 423414 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423415 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_pjsip_pubsub has two separate checks that it makes when a SUBSCRIBE
arrives.
* It checks that there is a subscription handler for the Event
* It checks that there are body generators for the types in the Accept header
The problem is, there's nothing that ensures that these two things will
actually mesh with each other. For instance, Asterisk will accept a subscription
to MWI that accepts pidf+xml bodies. That doesn't make sense.
With this commit, we add some type information to the mix. Subscription
handlers state they generate data of type X, and body generators state
that they consume data of type X. This way, Asterisk doesn't end up in
some hilariously mismatched situation like the one in the previous paragraph.
ASTERISK-24136 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/3877
Review: https://reviewboard.asterisk.org/r/3878
........
Merged revisions 423344 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423348 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
