Age | Commit message (Collapse) | Author |
|
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
|
|
If faxing fails at a very early stage, then it is possible for
us to pass a NULL t30 state pointer to spandsp, which spandsp
is none too pleased with.
This patch ensures that we pass the correct pointer to spandsp
in the situation where we have not yet set our local t30 state
pointer.
ASTERISK-24301 #close
Reported by Matt Jordan
Patches:
ASTERISK-24301-fax.diff Uploaded by Mark Michelson (License #5049)
........
Merged revisions 423360 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423365 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423372 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423380 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
|
|
When no transport is associated to an endpoint, the AMI output for
PJSIPShowEndpoint indicates an error instead of silently ignoring the
missing transport.
This patch causes the error to appear only if a transport was specified
on the endpoint and the transport doesn't exist. It also fixes an issue
with counting the objects that were actually found.
ASTERISK-24161 #close
ASTERISK-24331 #close
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3998/
........
Merged revisions 423282 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423284 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423285 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
|
|
If you call ast_category_insert with a match category that doesn't exist, the
list traverse runs out of 'next' categories and you get a SEGV. This patch
adds check for the end-of-list condition and changes the signature to return
an int for success/failure indication instead of a void.
The only consumer of this function is manager and it was also changed to use
the return value.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3993/
........
Merged revisions 423276 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 423277 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423278 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423279 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423280 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 423253 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423254 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423255 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423256 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
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
r423209 | file | 2014-09-16 17:35:34 -0300 (Tue, 16 Sep 2014) | 8 lines
res_rtp_asterisk: Fix building when pjproject is not used.
........
Merged revisions 423207 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423208 from http://svn.asterisk.org/svn/asterisk/branches/12
........
r423212 | file | 2014-09-16 18:03:59 -0300 (Tue, 16 Sep 2014) | 10 lines
res_rtp_asterisk: Fix 100% CPU usage due to timer heap thread spinning.
Side note: I need a vacation.
........
Merged revisions 423210 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423211 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423209,423212 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423213 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
|
|
........
Merged revisions 423172 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423173 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423174 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
|
|
Reported by: Zogot (on IRC)
Patches:
tmp.diff uploaded by Zogot, cleaned up by me.
........
Merged revisions 423128 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423129 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423130 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Document it in sip.conf.
ASTERISK-24249 #close
Reported by: Avinash Mohod
Review: https://reviewboard.asterisk.org/r/3926/
........
Merged revisions 423066 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 423067 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 423068 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423069 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423070 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
|
|
Also has could affect with anything that goes through ast_destroy_realtime.
If a CLI user used the command 'realtime destroy <family>' with only a single
column/value pair, Asterisk would crash when trying to create a variable list
from a NULL value.
ASTERISK-24231 #close
Reported by: Niklas Larsson
Review: https://reviewboard.asterisk.org/r/3985/
........
Merged revisions 422984 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422985 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422991 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
|
|
ast_config_text_file_save() currently truncates include files as they
are processed. If a subsequent include file or the main config file has
a permissions error that prevents writing, earlier include files are left
truncated resulting in a frantic search for backups.
This patch causes ast_config_text_file_save to check for write access
on all files before it truncates any of them.
Will be applied 1.8 > trunk.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3986/
........
Merged revisions 422900 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422903 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422904 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422905 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The errors generated when validating 'auth' settings are missing a space which
makes the messages a little confusing.
........
Merged revisions 422899 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422901 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422902 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Modifying Makefile and sounds.xml to include new core 1.4.26 and extra 1.4.15
sound prompt releases, plus the new Japanese core sound prompts contributed
by QLOOG.
ASTERISK-23324
Reported by: Kevin McCoy
Tested by: Rusty Newton
........
Merged revisions 422789 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422790 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422791 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422883 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
channel.
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
|
|
........
Merged revisions 422855 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422856 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
|
|
resource list
https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
According to the off-nominal plan, if evenlist support is not specified in a
SUBSCRIBE's supported header(s), that subscription should be rejected with an
error.
ASTERISK-23871
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3960/diff/#index_header
........
Merged revisions 422836 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422837 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
|
|
not media stream.
........
Merged revisions 422746 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422747 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422748 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
|
|
NULL call IDs were meant to appear as '(none)' but instead were showing
the contents of an uninitialized character buffer.
ASTERISK-24223
Review: https://reviewboard.asterisk.org/r/3979/
........
Merged revisions 422664 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422665 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* In ast_state_chan2dev() use ARRAY_LEN() instead of a sentinel value in
chan2dev[].
* Fix some comments in chan_iax2.c.
........
Merged revisions 422661 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422663 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This corrects a situation where menuselect can incorrectly enable a
module by default that has defaultenabled set to "no" and has
failed/non-selected dependencies. The bug is due to an inverted test
when checking for whether the given module should be set to enabled by
default on load.
Review: https://reviewboard.asterisk.org/r/3975/
Reported by: John Bigelow
........
Merged revisions 422646 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422647 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Review: https://reviewboard.asterisk.org/r/3969/
........
Merged revisions 422584 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422625 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422626 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422631 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422632 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The code for changing the Contact header wrongly assumed that the Contact
would always contain a URI. This is incorrect.
ASTERISK-24271
Reported by: Dafi Ni
........
Merged revisions 422557 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422558 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
media has been negotiated.
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
|
|
Internal channels don't have CDRs. Querying the CDR engine for their variables
will make it cranky.
........
Merged revisions 422506 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422507 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422524 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 ConfbridgeList event doesn't include how long the user has been a
member of the conference. This patch adds Duration (seconds) which
is based on user->chan->answertime.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3955/
........
Merged revisions 422444 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422445 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A WaitEvent issued via an http session isn't respecting eventfilters defined
for the user. I just added a match_filter to the predicate that controls
astman_append.
Tested by: George Joseph
Review: https://reviewboard.asterisk.org/r/3958/
........
Merged revisions 422439 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422440 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422441 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422442 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds a manpage for the smsq utility. Note that this is one of
the patches the Debian distro applies for the Asterisk project, as per
ASTERISK-24191.
Review: https://reviewboard.asterisk.org/r/3895/
ASTERISK-24171 #close
Reported by: Jeremy Laine
patches:
smsq.8 uploaded by Jeremy Laine (License 6561)
........
Merged revisions 422376 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422377 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422378 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422379 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds a manpage for the aelparse utility. Note that this is one of
the patches the Debian distro applies for the Asterisk project, as per
ASTERISK-24191.
Review: https://reviewboard.asterisk.org/r/3896/
ASTERISK-24171 #close
Reported by: Jeremy Laine
patches:
aelparse.8 uploaded by Jeremy Laine (License 6561)
........
Merged revisions 422371 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 422372 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422373 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422374 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422375 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
message was being triggered on configuration reload.
This patch changes that case to just return instead.
Review: https://reviewboard.asterisk.org/r/3953/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422358 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
|