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
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
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
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
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
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
Given the scenario where a PJSIP channel is in a native RTP bridge with direct
media and the channel is then hung up the code will currently re-INVITE the channel
back to Asterisk and send a BYE at the same time. Many SIP implementations dislike
this greatly.
This change makes it so that if a re-INVITE transaction is in progress the BYE
is queued to occur after the completion of the transaction (be it through normal
means or a timeout).
Review: https://reviewboard.asterisk.org/r/4248/
........
Merged revisions 429409 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In the past the SDP negotiation within res_pjsip_session was made more tolerant of
certain situations. The only case where SDP negotiation will fail is when a major
error occurs during negotiation. Receiving an already declined media stream is
not considered a major error.
When producing the local SDP the logic took this into account so on the initial INVITE
the declined media stream did not cause an SDP negotiation failure. Unfortunately
the logic for handling media streams with a handler did not mirror this logic and
considered an already declined media stream an error and thus failed the SDP
negotiation.
This change makes the logic between both situations match so only under major
errors will the SDP negotiation fail.
ASTERISK-24607 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4254/
........
Merged revisions 429407 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using a non-default sorcery wizard (in this instance realtime) for outbound
publishes Asterisk will crash after a stack overflow occurs due to the code
infinitely recursing. The fix entails removing the outbound publish state
dependency from the outbound publish sorcery object and instead keeping an in
memory container that can be used to lookup the state when needed.
ASTERISK-24514 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4178/
........
Merged revisions 429175 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
AMI/ARI are getting a few enhancements in the next release of Asterisk 13. Per
semantic versioning, that warrants a bump in the minor version number, as it
reflects a backwards compatible change. Hence, this commit.
........
Merged revisions 429091 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429092 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reviewboard description does a fine job of summarizing this, so here it is:
A reporter discovered that Asterisk would crash when attempting to retransmit
a reinvite that had previously received a 491 response. The crash occurred
because a pjsip_tx_data structure was being saved for reuse, but its reference
count was not being increased. The result was that the pjsip_tx_data was being
freed before we were actually done with it. When we attempted to re-use the
structure when re-sending the reinvite, Asterisk would crash.
The fix implemented here is not to try holding onto the pjsip_tx_data at all.
Instead, when we reschedule sending the reinvite, we create a brand new
pjsip_tx_data and send that instead. Because of this change, there is no need
for an ast_sip_session_delayed_request structure to have a pjsip_tx_data on
it any more. So any code referencing its use has been removed.
When this initial fix was introduced, I encountered a second crash when
processing a subsequent 200 OK on a rescheduled reinvite. The reason was
that when rescheduling the reinvite, we gave the wrong location for a
response callback. This has been fixed in this patch as well.
ASTERISK-24556 #close
Reported by Abhay Gupta
Review: https://reviewboard.asterisk.org/r/4233
........
Merged revisions 429089 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects several bugs that currently exist in the stasis
application code.
* After a masquerade, the resulting channels have channel topics that
do not match their uniqueids
** Masquerades now swap channel topics appropriately
* StasisStart and StasisEnd messages are leaked to observer
applications due to being published on channel topics
** StasisStart and StasisEnd publishing is now properly restricted
to controlling apps via app topics
* Race conditions exist where StasisStart and StasisEnd messages due to
a masquerade may be received out of order due to being published on
different topics
** These messages are now published directly on the app topic so this
is now a non-issue
* StasisEnds are sometimes missing when sent due to masquerades and
bridge swaps into and out of Stasis()
** This was due to StasisEnd processing adjusting message-sent flags
after Stasis() had already exited and Stasis() had been re-entered
** This was corrected by adjusting these flags prior to sending the
message while the initial Stasis() application was still shutting
down
Review: https://reviewboard.asterisk.org/r/4213/
ASTERISK-24537 #close
Reported by: Matt DiMeo
........
Merged revisions 429061 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429062 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When repeatedly starting/stopping a Monitor on a channel, the accumulated
in/out sample counts are never reset to 0. This can cause inadvertent jumps
in the recordings, as the code in the channel core will determine incorrectly
that a jump in the recorded file position should occur. Setting the sample
counts to 0 simply reflects the initial state a Monitor should be in when it
is started, as this is the initial count that would be on the channels at that
time.
ASTERISK-24573 #close
Reported by: Nuno Borges
patches:
24573.patch uploaded by Nuno Borges (License 6116)
........
Merged revisions 429031 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429032 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429033 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429034 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matthew Jordan
George Joseph
Joshua Colp
Richard Mudgett
Scott Griepentrog
Kevin Harwell
Mark Michelson
Walter Doekes
David M. Lee
Kinsey Moore