Age | Commit message (Collapse) | Author |
|
Let's say you have a template T with variable VAR1 = ON and you have a
context C(T) that doesn't specify VAR1. If you read C, the effective value
of VAR1 is ON. Now you change T VAR1 to OFF and call
ast_config_text_file_save. The current behavior is that the file gets
re-written with T/VAR1=OFF but C/VAR1=ON is added. Personally, I think this
is a bug. It's preserving the effective state of C even though I didn't
specify C/VAR1 in th first place. I believe the behavior should be that if
I didn't specify C/VAR1 originally, then the effective value of C/VAR1 should
continue to follow the inherited state. Now, if I DID explicitly specify
C/VAR1, the it should be preserved even if the template changes.
Even though I think the existing behavior is a bug, it's been that way forever
so I'm not changing it. Instead, I've created ast_config_text_file_save2()
that takes a bitmask of flags, one of which is to preserve the effective context
(the current behavior). The original ast_config_text_file_save calls *2 with
the preserve flag. If you want the new behavior, call *2 directly without a
flag.
I've also updated Manager UpdateConfig with a new parameter
'PreserveEffectiveContext' whose default is 'yes'. If you want the new behavior
with UpdateConfig, set 'PreserveEffectiveContext: no'.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4297/
........
Merged revisions 430295 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 430274 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430275 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
contrib/ast-db-manage: Correct down_revision path for user_eq_phone
When the user_eq_phone patch was backported to 13, it referenced the downward
revision that the PJSIP optimistic encryption option also references. This
creates a multi-path upgrade Exception when generating the SQL files.
This patch corrects this in the 13 branch. Note that trunk, which already
contained both of these features, is unaffected by this problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When res_pjsip loads and an endpoint auto-subscribes a mailbox for mwi,
if a contact hasn't registered yet, res_pjsip_mwi spits out a warning.
This is a perfectly normal situation though and doesn't require something
as serious as a warning. It's also self correcting. The device will start
getting mwi as soon as it registers.
This patch changes the warning to a notice.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4314/
........
Merged revisions 430227 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430228 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Change the "Locally bridged"/"Remotely bridged" messages from dbg/2 to verb/4.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4300/
........
Merged revisions 430225 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430226 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The current behavior of 'pjsip send unregister' is to send the unregister
(REGISTER with 0 exp) but let the next scheduled register proceed normally.
I don't think that's a good idea. If you unregister, it should stay
unregistered until you decide to start registrations again. So this patch
just adds a cancel_registration call to the current unregister_task to
cancel the timer.
Of course, now you need a way to start registration again so I've added
a 'pjsip send register' command that unregisters and cancels any existing
registration (the same as send unregister), then sends an immediate
registration and starts the timer back up again.
Both changes also ripple to AMI. There's a new PJSIPRegister command.
There's no harm in calling either command repeatedly. They don't care
about the actual state.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4301/
........
Merged revisions 430223 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430224 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
For some reason I was using a hash container instead of a list to gather the
contacts for 'pjsip list/show contacts' so even though I had a sort function,
the output wasn't sorted. This patch just changes the hash container to a
list container and the contacts now appear sorted in the CLI.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4305/
........
Merged revisions 430221 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A blond transfer to a failed destination, when followed
by a recall attempt, lead to a leak of the reference to
the destination channel. In addition to correcting the
regression on the previous attempt (r429826) this fixes
the leak and two additional reference leaks on failures
of bridge_import.
ASTERISK-24513 #close
Review: https://reviewboard.asterisk.org/r/4302/
........
Merged revisions 430199 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 430200 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 430181 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The PJSIP_AOR dialplan function allows inspection of configured AORs including
what contacts are currently bound to them.
The PJSIP_CONTACT dialplan function allows inspection of contacts in existence.
These can include both externally added (by way of registration) or permanent
ones.
ASTERISK-24341
Reported by: xrobau
Review: https://reviewboard.asterisk.org/r/4308/
........
Merged revisions 430179 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r428708 additional codecs were added including
a payload type of 128 which is outside of nominal
range of 0-127. This change moves changes 128 to
96 to avoid causing a pjsip assertion when making
a call to an endpoint configured with allow=all.
ASTERISK-24367 #close
Review: https://reviewboard.asterisk.org/r/4286/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This updates the documentation for the 'method' configuration option to
be more verbose about the behaviors of values 'unspecified' and
'default'. They do exactly the same thing which is to select the
default as defined by PJSIP which is currently TLSv1.
Review: https://reviewboard.asterisk.org/r/4264/
........
Merged revisions 430145 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430146 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Updated the queues.conf.sample file to explicitly state which channel queue
variables are propagated to.
ASTERISK-24267
Reported by: Mitch Claborn
........
Merged revisions 430126 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 430127 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
We only need to hold the context_merge_lock once. Locking it twice will make
many other parts of Asterisk very sad.
ASTERISK-24641 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If you remove an endpoint/aor from pjsip.conf then do a core reload,
qualifies will continue even though the object are gone. This happens
because nothing clears out the qualify tasks.
This patch unschedules all existing qualify tasks before scheduling
new ones on reload.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4290/
........
Merged revisions 430064 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430067 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds a trailing slash to the category for this test.
No more warning.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4295/
........
Merged revisions 430059 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
After the initial DTMF atxfer call attempt to the transfer target fails to
answer during a blonde transfer, the recall callback channels do not get
setup with information from the initial transferrer channel. As a result,
the recall callback to the transferrer does not have callid, channel
variables, datastores, accountcode, peeraccount, COLP, and CLID setup. A
similar situation happens with the recall callback to the transfer target
but it is less visible. The recall callback to the transfer target does
not have callid, channel variables, datastores, accountcode, peeraccount,
and COLP setup.
* Added missing information to the recall callback channels before
initiating the call. callid, channel variables, datastores, accountcode,
peeraccount, COLP, and CLID
* Set callid of the transferrer channel on the DTMF atxfer controller
thread attended_transfer_monitor_thread().
* Added missing channel unlocks and props unref to off nominal paths in
attended_transfer_properties_alloc().
ASTERISK-23841 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4259/
........
Merged revisions 430034 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The QUEUESTART log entry has historically acted like a fully booted event
for the queue_log file. When the QUEUESTART entry was posted to the log
was broken by the change made by ASTERISK-15863.
* Made post the QUEUESTART queue_log entry when Asterisk fully boots.
This restores the intent of that log entry and happens after realtime has
had a chance to load.
AST-1444 #close
Reported by: Denis Martinez
Review: https://reviewboard.asterisk.org/r/4282/
........
Merged revisions 430009 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 430010 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Given the following scenario:
* Three SIP phones (A, B, C), all communicating via a proxy with Asterisk
* A call is established between A and B. B performs a SIP attended transfer of
A to C. B sets the call on hold (A is hearing MOH) and dials the extension of
C. While phone C is ringing, B transfers the call (that is, what we typically
call a 'blond transfer').
* When the transfer completes, A hears the ringing of phone C, while B is idle.
In the SIP messaging for the above scenario, a REFER request is sent to
transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an
UPDATE request to phone C to update party information. This update is sent
directly to phone C, not through the intervening proxy. This has the unfortunate
side effect of providing route information, which is then set on the sip_pvt
structure for C. If someone (e.g. B) is trying to get the call back (through a
directed pickup), Asterisk will send a CANCEL request to C. However, since we
have now updated the route set, the CANCEL request will be sent directly to C
and not through the proxy. The phone ignores this CANCEL according to RFC3261
(Section 9.1).
This patch updates reqprep such that the route is not updated if an UPDATE
request is being sent while the INVITE state is INV_PROCEEDING or
INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent
to the correct location.
Review: https://reviewboard.asterisk.org/r/4279
ASTERISK-24628 #close
Reported by: Karsten Wemheuer
patches:
issue.patch uploaded by Karsten Wemheuer (License 5930)
........
Merged revisions 429982 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429983 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds the ability for channel drivers to supply presence information
in a similar manner to device state. The patch does not provide any channel
driver implementations, but it does provide the core infrastructure necessary
for channel drivers to provide such information.
The core handles multiple providers of presence state information. Ordering
of presence state is as follows:
INVALID < NOT_SET < AVAILABLE < UNAVAILABLE < CHAT < AWAY < XA < DND
Each provider can trump the previous if it provides a presence state that
supercedes a previous one.
Review: https://reviewboard.asterisk.org/r/4050
ASTERISK-24363 #close
Reported by: Gareth Palmer
patches:
chan_presencestate-428146.patch uploaded by Gareth Palmer (License 5169)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429967 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Summaries can't contain XML nodes, as they are defined to contain only text
data.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429952 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch adds the ability to pass options and a command to MixMontor when
recording a conference using ConfBridge.
New options are -
* record_options: Options to MixMontor, eg: m(), W() etc.
* record_command: The command to execute when recording is over.
* record_file_timestamp: Append the start time to the file name.
These options can also be used with the CONFBRIDGE function, e.g.,
Set(CONFBRIDGE(bridge,record_command)=/path/to/command ^{MIXMONITOR_FILENAME}))
Review: https://reviewboard.asterisk.org/r/4023
ASTERISK-24351 #close
Reported by: Gareth Palmer
patches:
record_command-428838.patch uploaded by Gareth Palmer (License 5169)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Reloading wasn't working correctly because on a reload, the sorcery apply
handler was never being called for unchanged users. So, instead of using
an apply handler, I'm now iterating over all users. Works much more reliably.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4288/
........
Merged revisions 429914 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
startup.
The named ACL code incorrectly destroyed the config options information if loading
of the configuration file failed at startup. This would result in reloading
also failing even if a valid configuration file was put in place.
ASTERISK-23733 #close
Reported by: Richard Kenner
........
Merged revisions 429893 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429894 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This won't fix the reported issue but it is an incorrect use of sizeof.
ASTERISK-24566
Reported by: Badalian Vyacheslav
........
Merged revisions 429867 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429868 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429870 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When the configuration section scheme of chan_dahdi.conf is used (keyword
dahdichan instead of channel) all setvar= options are completely ignored.
No variable defined this way appears in the created DAHDI channels.
* Move the clearing of setvar values to after the deferred processing of
dahdichan.
AST-1378 #close
Reported by: Guenther Kelleter
Patch by: Guenther Kelleter
........
Merged revisions 429825 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429829 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
After a blond transfer (start attended and hang up)
to a destination that also hangs up without answer,
the Local;1 channel was leaked and would show up on
core show channels. This was happening because the
attended state blond_nonfinal_enter() resetting the
props->transfer_target to null while releasing it's
own reference, which would later prevent props from
releasing another reference during destruction. The
change made here is simply to not assign the target
to NULL.
ASTERISK-24513 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4262/
........
Merged revisions 429826 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429827 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
ASTERISK-24337 #close
Reported by: Rusty Newton
........
Merged revisions 429804 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429805 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429806 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
........
Merged revisions 429784 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
A native rtp bridge was being chosen (it shouldn't have been) when using two
pjsip channels with incompatible DTMF modes. This patch sets the rtp instance
property, AST_RTP_PROPERTY_DTMF, for the appropriate DTMF mode(s) for pjsip.
It was not being set before, meaning all DTMF modes for pjsip were being treated
as compatible, thus native bridging would be chosen as the bridge type when it
shouldn't have been.
ASTERISK-24459 #close
Reported by: Yaniv Simhi
Review: https://reviewboard.asterisk.org/r/4265/
........
Merged revisions 429763 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, Asterisk would always respond to 401 responses to
registration attempts by trying to provide a registration with authentication
credentials. Even if subsequent attempts were rejected with 401 responses,
Asterisk would continue this behavior. If authentication credentials were
incorrect, this could continue forever.
With this patch, we keep track of whether we have attempted authentication
on an outbound registration attempt. If we already have, we don not try
again until the next attempt. This prevents the infinite loop scenario.
Review: https://reviewboard.asterisk.org/r/4273
........
Merged revisions 429761 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429762 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The AST_FLAG_BRIDGE_DUAL_REDIRECT_WAIT flag was created to prevent bridges from
prematurely acting on orphaned channels in bridges. The problem with the AMI
redirect action was that it was setting this flag on channels based on the presence
of a PBX, not whether the channel was in a bridge. Whether a channel has a PBX
is irrelevant, so the condition has been altered to check if the channel is in a
bridge.
ASTERISK-24536 #close
Reported by Niklas Larsson
Review: https://reviewboard.asterisk.org/r/4268
........
Merged revisions 429741 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this patch, we were using the PJSIP dialog's secure flag
to determine if a secure transport was being used. Unfortunately,
the dialog's secure flag was only set if a SIPS URI were in use,
as required by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested
in is not dialog security, but transport security. This code change
switches to a model where we use the dialog's target URI to determine
what transport would be used to communicate, and then check if that
transport is secure.
AST-1450 #close
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/4277
........
Merged revisions 429739 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If certain pjsip modules aren't loaded, the wizard causes a SEGV
when it unloads. Added a check for the presense of the object
type wizard before trying to clean it up.
Tested-by: George Joseph
........
Merged revisions 429719 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429720 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The module now applies the FILEUNCHANGED flag when both reloaded is
specified AND there's no last_config for the object type.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4276/
........
Merged revisions 429699 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Fix test breakage caused by not checking for res_pjsip before
calling ast_sip_get_sorcery.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4269/
........
Merged revisions 429653 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429654 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
........
Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429633 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If a remote endpoint reinvites to T.38 immediately the state machine
will go into a peer reinvite state. If a T.38 capable application
(such as ReceiveFax) queries it will receive this state. Normally
the application will then indicate so that the channel driver will
queue up the T.38 offer previously received. Once it receives this
offer the application will act normally and negotiate.
The res_pjsip_t38 module incorrectly partially squashed this indication.
This would cause the application to think the request had failed when
in reality it had actually worked.
This change makes it so that no T.38 control frames (or indications)
are squashed.
........
Merged revisions 429612 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
res_pjsip_config_wizard
------------------
* This is a new module that adds streamlined configuration capability for
chan_pjsip. It's targetted at users who have lots of basic configuration
scenarios like 'phone' or 'agent' or 'trunk'. Additional information
can be found in the sample configuration file at
config/samples/pjsip_wizard.conf.sample.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4190/
........
Merged revisions 429592 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429593 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this change, recreating persistent subscriptions would
create the subscription but would not activate it. This led to subscriptions
being listed in the "NULL" state by diagnostics and not sending NOTIFYs
when expected.
Review: https://reviewboard.asterisk.org/r/4261
........
Merged revisions 429571 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429573 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
No functionality change. Just move the definition of ast_module_reload
from _private.h to module.h so it can be public.
Also removed the include of _private.h from manager.c since ast_module_load
was the only reason for including it.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4251/
........
Merged revisions 429542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch started with David Lee's patch at
https://reviewboard.asterisk.org/r/2826/ and includes a regression fix
introduced by the ASTERISK-22455 patch.
The initialization of a mutex's lock tracking structure was not protected
in a critical section. This is fine for any mutex that is explicitly
initialized, but a static mutex may have its lock tracking double
initialized if multiple threads attempt the first lock simultaneously.
* Added a global mutex to properly serialize initialization of the lock
tracking structure. The painful global lock can be mitigated by adding a
double checked lock flag as discussed on the original review request.
* Defer lock tracking initialization until first use.
* Don't be "helpful" and initialize an uninitialized lock when
DEBUG_THREADS is enabled. Debug code is not supposed to fix or change
normal code behavior. We don't need a lock initialization race that would
force a re-setup of lock tracking. Lock tracking already handles
initialization on first use.
* Properly handle allocation failures of the lock tracking structure.
* No need to initialize tracking data in __ast_pthread_mutex_destroy()
just to turn around and destroy it.
The regression introduced by ASTERISK-22455 is the result of manipulating
a pthread_mutex_t struct outside of the pthread library code. The
pthread_mutex_t struct seems to have a global linked list pointer member
that can get changed by other threads. Therefore, saving and restoring
the contents of a pthread_mutex_t struct is a bad thing.
Thanks to Thomas Airmont for finding this obscure regression.
* Don't overwrite the struct ast_lock_track.reentr_mutex member to restore
tracking data in __ast_cond_wait() and __ast_cond_timedwait(). The
pthread_mutex_t struct must be treated as a read-only opaque variable.
Miscellaneous other items fixed by this patch:
* Match ast_suspend_lock_info() with ast_restore_lock_info() in
__ast_cond_timedwait().
* Made some uninitialized lock sanity checks return EINVAL and try a
DO_THREAD_CRASH.
* Fix bad canlog initialization expressions.
ASTERISK-24614 #close
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/4247/
Review: https://reviewboard.asterisk.org/r/2826/
........
Merged revisions 429539 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The Verbose message displayed when a file is played back via 'stream file'
was formatted differently than other playbacks:
* It didn't include the channel name
* It didn't include the channel language
It does, however, include the playback offset as well as any escape digits.
That information was kept; however, this patch updates the formatting to more
closely match the Verbose messages displayed when a file is played back by
'control stream file', Playback, ControlPlayback, or any other file playback
operation.
........
Merged revisions 429519 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When shutting down Asterisk the codecs are cleaned up. As a result anything
attempting to get a codec based on ID or details will find that no codec
exists. This currently occurs when determining the sample count of a frame.
This code did not take this situation into account.
This change fixes this by getting the codec directly from the format and
eliminates the lookup. This is both faster and also provides a guarantee
that the codec will exist and will be valid.
ASTERISK-24604 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4260/
........
Merged revisions 429497 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When direct media is enabled and a pjsip channel is answered a race would occur
between the handling of the answer and bridge setup. Sometimes the media
negotiation would take place after the native bridge was setup. This resulted
in a NULL media address, which in turn resulted in Asterisk using its address
as the remote media address when sending a reinvite. This patch makes the
chan_pjsip answer handler synchronous thus alleviating the race condition (the
bridge won't start setting things up until after it returns).
ASTERISK-24563 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4257/
........
Merged revisions 429477 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
res_pjsip_outbound_publish was missing the CHECK_PJSIP_MODULE_LOADED()
call in load_module, and would crash with a segfault if res_pjsip
declined to load.
Review: https://reviewboard.asterisk.org/r/4258/
........
Merged revisions 429457 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This allows use of the 'inactive' stream direction identifier to be
used for hold where 'sendonly' is normally used. Some Seimens phones
use 'inactive' and this change allows music on hold to operate
properly.
Review: https://reviewboard.asterisk.org/r/4252/
Reported by: Steve Pitts
........
Merged revisions 429432 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429433 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429434 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This adds a log message notifying the user that a stale configuration
is in place upon reload when a config object fails to load. This
situation can end up causing confusion when the object failed to load
but exists from a previous config load especially when the old config
is significantly different from the new config.
Review: https://reviewboard.asterisk.org/r/4250/
Reported by: Thomas Thompson
........
Merged revisions 429429 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429430 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|