| Age | Commit message (Collapse) | Author |
|---|
|
Since 'core stop now' and 'core restart now' do not stop modules,
it is unsafe for most of the core to run cleanups. Originally all
cleanups used ast_register_atexit, and were only changed when it
was shown to be unsafe. ast_register_atexit is now used only when
absolutely required to prevent corruption and close child processes.
Exceptions that need to use ast_register_atexit:
* CDR: Flush records.
* res_musiconhold: Kill external applications.
* AstDB: Close the DB.
* canary_exit: Kill canary process.
ASTERISK-24142 #close
Reported by: David Brillert
ASTERISK-24683 #close
Reported by: Peter Katzmann
ASTERISK-24805 #close
Reported by: Badalian Vyacheslav
ASTERISK-24881 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4500/
Review: https://reviewboard.asterisk.org/r/4501/
........
Merged revisions 433495 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433497 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Fixed a couple of frame leaks that were found during testing.
ASTERISK-24828 #close
Reported by: John Hardin
Review: https://reviewboard.asterisk.org/r/4445/
........
Merged revisions 432362 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432363 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 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
|
|
The AMI event is called NewConnectedLine and the ARI event is called
ChannelConnectedLine.
ASTERISK-24554 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/4231
........
Merged revisions 429064 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429084 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
|
|
command.
The static buffer for codecs when invoking the "core show channeltype" CLI command
did not have enough room for all codecs. This has been extended so it does.
ASTERISK-24542 #close
Reported by: snuffy
patches:
channeltype-tech.diff submitted by snuffy (license 5024)
Review: https://reviewboard.asterisk.org/r/4204/
........
Merged revisions 428632 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428633 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There should be AMI VarSet events when channel variables are inherited by
an outgoing channel. Also local;2 should generate VarSet events when it
gets all of its channel variables from channel local;1.
ASTERISK-24415 #close
Reported by: Richard Mudgett
Patches:
jira_asterisk_24415_v12.patch (license #5621) patch uploaded by Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4074/
........
Merged revisions 425782 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425783 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 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
|
|
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
|
|
On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.
* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite. AFS-63 was effectively reintroduced because of the media
formats work. res_pjsip_sdp_rtp.c:set_caps()
* Improved the unexpected frame format WARNING message to include more
information.
* Added protective locking while altering formats on a channel. Reworked
set_format() to simplify and protect the formats under manipulation.
* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())
AFS-137 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3906/
........
Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
r420934 introduced some failures in the test suite. Upon investigating, it was
discovered that differences in the way we were evaluating whether a channel was in
the process of leaving a bridge were causing some reinvites not to occur (mostly
reinvites back to Asterisk when ending a call). This patch fixes that behavioral
change.
ASTERISK-24027 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3910/
........
Merged revisions 421186 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421187 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Use ao2_replace() instead of ao2_cleanup(); ao2_bump().
ao2_replace() has the advantange of not altering the ref count if the
replaced pointer is the same.
Review: https://reviewboard.asterisk.org/r/3904/
........
Merged revisions 420992 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420993 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
If a manager or CLI user attached a mixmonitor to a call running a dynamic
bridge feature while in a bridge, the feature would be interrupted and the
channel would be forcibly kicked out of the bridge (usually ending the call
during a simple 1 to 1 call). This would also occur during any similar action
that could set the unbridge soft hangup flag, so the fix for this was to
remove unbridge from the soft hangup flags and make it a separate thing all
together.
ASTERISK-24027 #close
Reported by: mjordan
Review: https://reviewboard.asterisk.org/r/3900/
........
Merged revisions 420934 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 420940 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This fixes a class of issues where Stasis applications were not made
aware that their channels were being manipulated or replaced by
external entitiessuch as transfers, AMI commands, or dialplan
applications such as Bridge(). Inconsistent information such as
StasisEnd events with unknown channels as a result of masquerades has
also been corrected. To accomplish these fixes, several new fields
were added to blind and attended transfer messages as well as
StasisStart and BridgeAttendedTransfer Stasis events.
ASTERISK-23941 #close
Review: https://reviewboard.asterisk.org/r/3865/
Review: https://reviewboard.asterisk.org/r/3857/
Review: https://reviewboard.asterisk.org/r/3852/
Review: https://reviewboard.asterisk.org/r/3816/
Review: https://reviewboard.asterisk.org/r/3731/
Review: https://reviewboard.asterisk.org/r/3729/
Review: https://reviewboard.asterisk.org/r/3728/
........
Merged revisions 420325 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This introduces stasis.conf and a mechanism to prevent certain message
types from being published. Internally, this works by preventing the
chosen message types from being created which ensures that those
message types can never be published. This patch also adjusts message
publishers such that message payloads are not created if the related
message type is not available.
ASTERISK-23943 #close
Review: https://reviewboard.asterisk.org/r/3823/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420124 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Audit of v1.8 usage of ast_channel_datastore_remove() for datastore memory
leaks.
* Fixed leaks in app_speech_utils and func_frame_trace.
* Fixed app_speech_utils not locking the channel when accessing the
channel datastore list.
Review: https://reviewboard.asterisk.org/r/3859/
Audit of v11 usage of ast_channel_datastore_remove() for datastore memory
leaks.
* Fixed leak in func_jitterbuffer. (Was not in v12)
Review: https://reviewboard.asterisk.org/r/3860/
Audit of v12 usage of ast_channel_datastore_remove() for datastore memory
leaks.
* Fixed leaks in abstract_jb.
* Fixed leak in ast_channel_unsuppress(). Used by ARI mute control and
res_mutestream.
* Fixed ref leak in ast_channel_suppress(). Used by ARI mute control and
res_mutestream.
Review: https://reviewboard.asterisk.org/r/3861/
........
Merged revisions 419684 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 419685 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 419686 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The previous behavior was to simply set the accountcode of an outgoing
channel to the accountcode of the channel initiating the call. It was
done this way a long time ago to allow the accountcode set on the SIP/100
channel to be propagated to a local channel so the dialplan execution on
the Local;2 channel would have the SIP/100 accountcode available.
SIP/100 -> Local;1/Local;2 -> SIP/200
Propagating the SIP/100 accountcode to the local channels is very useful.
Without any dialplan manipulation, all channels in this call would have
the same accountcode.
Using dialplan, you can set a different accountcode on the SIP/200 channel
either by setting the accountcode on the Local;2 channel or by the Dial
application's b(pre-dial), M(macro) or U(gosub) options, or by the
FollowMe application's b(pre-dial) option, or by the Queue application's
macro or gosub options. Before Asterisk v12, the altered accountcode on
SIP/200 will remain until the local channels optimize out and the
accountcode would change to the SIP/100 accountcode.
Asterisk v1.8 attempted to add peeraccount support but ultimately had to
punt on the support. The peeraccount support was rendered useless because
of how the CDR code needed to unconditionally force the caller's
accountcode onto the peer channel's accountcode. The CEL events were thus
intentionally made to always use the channel's accountcode as the
peeraccount value.
With the arrival of Asterisk v12, the situation has improved somewhat so
peeraccount support can be made to work. Using the indicated example, the
the accountcode values become as follows when the peeraccount is set on
SIP/100 before calling SIP/200:
SIP/100 ---> Local;1 ---- Local;2 ---> SIP/200
acct: 100 \/ acct: 200 \/ acct: 100 \/ acct: 200
peer: 200 /\ peer: 100 /\ peer: 200 /\ peer: 100
If a channel already has an accountcode it can only change by the
following explicit user actions:
1) A channel originate method that can specify an accountcode to use.
2) The calling channel propagating its non-empty peeraccount or its
non-empty accountcode if the peeraccount was empty to the outgoing
channel's accountcode before initiating the dial. e.g., Dial and
FollowMe. The exception to this propagation method is Queue. Queue will
only propagate peeraccounts this way only if the outgoing channel does not
have an accountcode.
3) Dialplan using CHANNEL(accountcode).
4) Dialplan using CHANNEL(peeraccount) on the other end of a local
channel pair.
If a channel does not have an accountcode it can get one from the
following places:
1) The channel driver's configuration at channel creation.
2) Explicit user action as already indicated.
3) Entering a basic or stasis-mixing bridge from a peer channel's
peeraccount value.
You can specify the accountcode for an outgoing channel by setting the
CHANNEL(peeraccount) before using the Dial, FollowMe, and Queue
applications. Queue adds the wrinkle that it will not overwrite an
existing accountcode on the outgoing channel with the calling channels
values.
Accountcode and peeraccount values propagate to an outgoing channel before
dialing. Accountcodes also propagate when channels enter or leave a basic
or stasis-mixing bridge. The peeraccount value only makes sense for
mixing bridges with two channels; it is meaningless otherwise.
* Made peeraccount functional by changing accountcode propagation as
described above.
* Fixed CEL extracting the wrong ie value for the peeraccount. This was
done intentionally in Asterisk v1.8 when that version had to punt on
peeraccount.
* Fixed a few places dealing with accountcodes that were reading from
channels without the lock held.
AFS-65 #close
Review: https://reviewboard.asterisk.org/r/3601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419520 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In the old times media formats were represented using a bit field. This was
fast but had a few limitations.
1. Asterisk was limited in how many formats it could handle.
2. Formats, being a bit field, could not include any attribute information.
A format was strictly its type, e.g., "this is ulaw".
This was changed in Asterisk 10 (see
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal for
notes on that work) which led to the creation of the ast_format structure.
This structure allowed Asterisk to handle attributes and bundle information
with a format.
Additionally, ast_format_cap was created to act as a container for multiple
formats that, together, formed the capability of some entity. Another
mechanism was added to allow logic to be registered which performed format
attribute negotiation. Everywhere throughout the codebase Asterisk was
changed to use this strategy.
Unfortunately, in software, there is no free lunch. These new capabilities
came at a cost.
Performance analysis and profiling showed that we spend an inordinate
amount of time comparing, copying, and generally manipulating formats and
their related structures. Basic prototyping has shown that a reasonably
large performance improvement could be made in this area. This patch is the
result of that project, which overhauled the media format architecture
and its usage in Asterisk to improve performance.
Generally, the new philosophy for handling formats is as follows:
* The ast_format structure is reference counted. This removed a large amount
of the memory allocations and copying that was done in prior versions.
* In order to prevent race conditions while keeping things performant, the
ast_format structure is immutable by convention and lock-free. Violate this
tenet at your peril!
* Because formats are reference counted, codecs are also reference counted.
The Asterisk core generally provides built-in codecs and caches the
ast_format structures created to represent them. Generally, to prevent
inordinate amounts of module reference bumping, codecs and formats can be
added at run-time but cannot be removed.
* All compatibility with the bit field representation of codecs/formats has
been moved to a compatibility API. The primary user of this representation
is chan_iax2, which must continue to maintain its bit-field usage of formats
for interoperability concerns.
* When a format is negotiated with attributes, or when a format cannot be
represented by one of the cached formats, a new format object is created or
cloned from an existing format. That format may have the same codec
underlying it, but is a different format than a version of the format with
different attributes or without attributes.
* While formats are reference counted objects, the reference count maintained
on the format should be manipulated with care. Formats are generally cached
and will persist for the lifetime of Asterisk and do not explicitly need
to have their lifetime modified. An exception to this is when the user of a
format does not know where the format came from *and* the user may outlive
the provider of the format. This occurs, for example, when a format is read
from a channel: the channel may have a format with attributes (hence,
non-cached) and the user of the format may last longer than the channel (if
the reference to the channel is released prior to the format's reference).
For more information on this work, see the API design notes:
https://wiki.asterisk.org/wiki/display/AST/Media+Format+Rewrite
Finally, this work was the culmination of a large number of developer's
efforts. Extra thanks goes to Corey Farrell, who took on a large amount of the
work in the Asterisk core, chan_sip, and was an invaluable resource in peer
reviews throughout this project.
There were a substantial number of patches contributed during this work; the
following issues/patch names simply reflect some of the work (and will cause
the release scripts to give attribution to the individuals who work on them).
Reviews:
https://reviewboard.asterisk.org/r/3814
https://reviewboard.asterisk.org/r/3808
https://reviewboard.asterisk.org/r/3805
https://reviewboard.asterisk.org/r/3803
https://reviewboard.asterisk.org/r/3801
https://reviewboard.asterisk.org/r/3798
https://reviewboard.asterisk.org/r/3800
https://reviewboard.asterisk.org/r/3794
https://reviewboard.asterisk.org/r/3793
https://reviewboard.asterisk.org/r/3792
https://reviewboard.asterisk.org/r/3791
https://reviewboard.asterisk.org/r/3790
https://reviewboard.asterisk.org/r/3789
https://reviewboard.asterisk.org/r/3788
https://reviewboard.asterisk.org/r/3787
https://reviewboard.asterisk.org/r/3786
https://reviewboard.asterisk.org/r/3784
https://reviewboard.asterisk.org/r/3783
https://reviewboard.asterisk.org/r/3778
https://reviewboard.asterisk.org/r/3774
https://reviewboard.asterisk.org/r/3775
https://reviewboard.asterisk.org/r/3772
https://reviewboard.asterisk.org/r/3761
https://reviewboard.asterisk.org/r/3754
https://reviewboard.asterisk.org/r/3753
https://reviewboard.asterisk.org/r/3751
https://reviewboard.asterisk.org/r/3750
https://reviewboard.asterisk.org/r/3748
https://reviewboard.asterisk.org/r/3747
https://reviewboard.asterisk.org/r/3746
https://reviewboard.asterisk.org/r/3742
https://reviewboard.asterisk.org/r/3740
https://reviewboard.asterisk.org/r/3739
https://reviewboard.asterisk.org/r/3738
https://reviewboard.asterisk.org/r/3737
https://reviewboard.asterisk.org/r/3736
https://reviewboard.asterisk.org/r/3734
https://reviewboard.asterisk.org/r/3722
https://reviewboard.asterisk.org/r/3713
https://reviewboard.asterisk.org/r/3703
https://reviewboard.asterisk.org/r/3689
https://reviewboard.asterisk.org/r/3687
https://reviewboard.asterisk.org/r/3674
https://reviewboard.asterisk.org/r/3671
https://reviewboard.asterisk.org/r/3667
https://reviewboard.asterisk.org/r/3665
https://reviewboard.asterisk.org/r/3625
https://reviewboard.asterisk.org/r/3602
https://reviewboard.asterisk.org/r/3519
https://reviewboard.asterisk.org/r/3518
https://reviewboard.asterisk.org/r/3516
https://reviewboard.asterisk.org/r/3515
https://reviewboard.asterisk.org/r/3512
https://reviewboard.asterisk.org/r/3506
https://reviewboard.asterisk.org/r/3413
https://reviewboard.asterisk.org/r/3410
https://reviewboard.asterisk.org/r/3387
https://reviewboard.asterisk.org/r/3388
https://reviewboard.asterisk.org/r/3389
https://reviewboard.asterisk.org/r/3390
https://reviewboard.asterisk.org/r/3321
https://reviewboard.asterisk.org/r/3320
https://reviewboard.asterisk.org/r/3319
https://reviewboard.asterisk.org/r/3318
https://reviewboard.asterisk.org/r/3266
https://reviewboard.asterisk.org/r/3265
https://reviewboard.asterisk.org/r/3234
https://reviewboard.asterisk.org/r/3178
ASTERISK-23114 #close
Reported by: mjordan
media_formats_translation_core.diff uploaded by kharwell (License 6464)
rb3506.diff uploaded by mjordan (License 6283)
media_format_app_file.diff uploaded by kharwell (License 6464)
misc-2.diff uploaded by file (License 5000)
chan_mild-3.diff uploaded by file (License 5000)
chan_obscure.diff uploaded by file (License 5000)
jingle.diff uploaded by file (License 5000)
funcs.diff uploaded by file (License 5000)
formats.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
bridges.diff uploaded by file (License 5000)
mf-codecs-2.diff uploaded by file (License 5000)
mf-app_fax.diff uploaded by file (License 5000)
mf-apps-3.diff uploaded by file (License 5000)
media-formats-3.diff uploaded by file (License 5000)
ASTERISK-23715
rb3713.patch uploaded by coreyfarrell (License 5909)
rb3689.patch uploaded by mjordan (License 6283)
ASTERISK-23957
rb3722.patch uploaded by mjordan (License 6283)
mf-attributes-3.diff uploaded by file (License 5000)
ASTERISK-23958
Tested by: jrose
rb3822.patch uploaded by coreyfarrell (License 5909)
rb3800.patch uploaded by jrose (License 6182)
chan_sip.diff uploaded by mjordan (License 6283)
rb3747.patch uploaded by jrose (License 6182)
ASTERISK-23959 #close
Tested by: sgriepentrog, mjordan, coreyfarrell
sip_cleanup.diff uploaded by opticron (License 6273)
chan_sip_caps.diff uploaded by mjordan (License 6283)
rb3751.patch uploaded by coreyfarrell (License 5909)
chan_sip-3.diff uploaded by file (License 5000)
ASTERISK-23960 #close
Tested by: opticron
direct_media.diff uploaded by opticron (License 6273)
pjsip-direct-media.diff uploaded by file (License 5000)
format_cap_remove.diff uploaded by opticron (License 6273)
media_format_fixes.diff uploaded by opticron (License 6273)
chan_pjsip-2.diff uploaded by file (License 5000)
ASTERISK-23966 #close
Tested by: rmudgett
rb3803.patch uploaded by rmudgetti (License 5621)
chan_dahdi.diff uploaded by file (License 5000)
ASTERISK-24064 #close
Tested by: coreyfarrell, mjordan, opticron, file, rmudgett, sgriepentrog, jrose
rb3814.patch uploaded by rmudgett (License 5621)
moh_cleanup.diff uploaded by opticron (License 6273)
bridge_leak.diff uploaded by opticron (License 6273)
translate.diff uploaded by file (License 5000)
rb3795.patch uploaded by rmudgett (License 5621)
tls_fix.diff uploaded by mjordan (License 6283)
fax-mf-fix-2.diff uploaded by file (License 5000)
rtp_transfer_stuff uploaded by mjordan (License 6283)
rb3787.patch uploaded by rmudgett (License 5621)
media-formats-explicit-translate-format-3.diff uploaded by file (License 5000)
format_cache_case_fix.diff uploaded by opticron (License 6273)
rb3774.patch uploaded by rmudgett (License 5621)
rb3775.patch uploaded by rmudgett (License 5621)
rtp_engine_fix.diff uploaded by opticron (License 6273)
rtp_crash_fix.diff uploaded by opticron (License 6273)
rb3753.patch uploaded by mjordan (License 6283)
rb3750.patch uploaded by mjordan (License 6283)
rb3748.patch uploaded by rmudgett (License 5621)
media_format_fixes.diff uploaded by opticron (License 6273)
rb3740.patch uploaded by mjordan (License 6283)
rb3739.patch uploaded by mjordan (License 6283)
rb3734.patch uploaded by mjordan (License 6283)
rb3689.patch uploaded by mjordan (License 6283)
rb3674.patch uploaded by coreyfarrell (License 5909)
rb3671.patch uploaded by coreyfarrell (License 5909)
rb3667.patch uploaded by coreyfarrell (License 5909)
rb3665.patch uploaded by mjordan (License 6283)
rb3625.patch uploaded by coreyfarrell (License 5909)
rb3602.patch uploaded by coreyfarrell (License 5909)
format_compatibility-2.diff uploaded by file (License 5000)
core.diff uploaded by file (License 5000)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419044 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Whenever possible, audiohooks and framehooks will now be copied over
to the channel that the masquerading channel gets cloned into. This
should occur for all audiohooks and most framehooks. As a result,
in Asterisk 12.5 and up, the AUDIOHOOK_INHERIT function is now
deprecated and its behavior is essentially the new default for all
audiohooks, plus some additional audiohooks/framehooks.
Review: https://reviewboard.asterisk.org/r/3721/
........
Merged revisions 418914 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch allows the current owner of a channel to define various
feature hooks to be made available once the channel has entered a
bridge. This includes any hooks that are setup on the
ast_bridge_features struct such as DTMF hooks, bridge event hooks
(join, leave, etc.), and interval hooks.
Review: https://reviewboard.asterisk.org/r/3649/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417361 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
During some performance testing of Asterisk with AGI, ARI, and lots of Local
channels, we noticed that there's quite a hit in performance during channel
creation and releasing to the dialplan (ARI continue). After investigating
the performance spike that occurs during channel creation, we discovered
that we create a lot of channel snapshots that are technically unnecessary.
This includes creating snapshots during:
* AGI execution
* Returning objects for ARI commands
* During some Local channel operations
* During some dialling operations
* During variable setting
* During some bridging operations
And more.
This patch does the following:
- It removes a number of fields from channel snapshots. These fields were
rarely used, were expensive to have on the snapshot, and hurt performance.
This included formats, translation paths, Log Call ID, callgroup, pickup
group, and all channel variables. As a result, AMI Status,
"core show channel", "core show channelvar", and "pjsip show channel" were
modified to either hit the live channel or not show certain pieces of data.
While this is unfortunate, the performance gain from this patch is worth
the loss in behaviour.
- It adds a mechanism to publish a cached snapshot + blob. A large number of
publications were changed to use this, including:
- During Dial begin
- During Variable assignment (if no AMI variables are emitted - if AMI
variables are set, we have to make snapshots when a variable is changed)
- During channel pickup
- When a channel is put on hold/unhold
- When a DTMF digit is begun/ended
- When creating a bridge snapshot
- When an AOC event is raised
- During Local channel optimization/Local bridging
- When endpoint snapshots are generated
- All AGI events
- All ARI responses that return a channel
- Events in the AgentPool, MeetMe, and some in Queue
- Additionally, some extraneous channel snapshots were being made that were
unnecessary. These were removed.
- The result of ast_hashtab_hash_string is now cached in stasis_cache. This
reduces a large number of calls to ast_hashtab_hash_string, which reduced
the amount of time spent in this function in gprof by around 50%.
#ASTERISK-23811 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3568/
........
Merged revisions 416211 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 415678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch is a re-do of r414122.
When r414122 was merged, a major problem with it was uncovered. UNBRIDGE soft
hangup flags have a catastrophic effect on the pbx core if they leak out from
the bridge layer: the channel gets hung up. With the number of threads
involved in a blind transfer, and with the initial patch, it was likely that
this would occur. This caused a large number of test failures
This patch is nearly identical with the one proposed in r414122, save for the
following changes:
- We explicitly clear the UNBRIDGE flag when setting an after goto on a
channel in a bridge
- Defensively, if we encounter an UNBRIDGE flag in the pbx core, we handle it
https://reviewboard.asterisk.org/r/3585/
........
Merged revisions 415443 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415444 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The Test Suite caught a few problems, undoing until those are resolved
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch fixes issues with direct media bridges that occur after a blind
transfer. These issues were caught by the (currently failing)
pjsip/transfers/blind_transfer/caller_direct_media test.
The test currently fails primarily for two reasons:
(1) When Bob and Charlie (the transfer target and the transfer destination)
enter a bridge together, the framehook remains on the transfer target
channel until both channels are in the bridge. As it consumes voice frames,
the initial bridge type is a simple bridge. The framehook is removed when
both channels are in the bridge; however, this does not currently cause the
bridging framework to re-evaluate the bridge. This patch adds a
AST_SOFTHANGUP_UNBRIDGE poke to the transfer target channel when a
framehook is removed so the bridge can re-evaluate itself.
(2) When a channel leaves a native RTP bridge, it may be leaving due to being
hung up. Sending a re-INVITE to a channel that is about to be hung up is
not nice - in fact, there's a good chance we'll send the BYE request before
the channel has had a chance to send back a 200 OK. To be somewhat nicer,
this patch adds a function to channel.h that allows the bridging framework
to query for exactly why a channel is leaving a bridge via the channel's
soft hangup flags. This allows it to only send the re-INVITE if there's a
chance the channel will survive the native bridging experience.
Review: https://reviewboard.asterisk.org/r/3535/
........
Merged revisions 414122 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414123 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
specific type.
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
........
Merged revisions 413681 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
specific type.
In the past framehooks have had no capability to determine what frame types a hook
is actually interested in consuming. This has meant that code has had to assume they
want all frames, thus preventing native bridging.
This change adds a callback which allows a framehook to be queried for whether it
is consuming a frame of a specific type. The native RTP bridging module has also
been updated to take advantange of this, allowing native bridging to occur when
previously it would not.
ASTERISK-23497 #comment Reported by: Etienne Lessard
ASTERISK-23497 #close
Review: https://reviewboard.asterisk.org/r/3522/
........
Merged revisions 413650 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413651 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
........
Merged revisions 413586 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 413587 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 413588 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
module is loaded.
The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross. Local channel optimization requires frames
flowing to trigger when optimization can happen. When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing. If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received. With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.
* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed. Asterisk now always uses internal
timing when needed if any timing module is loaded. The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used. The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.
* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().
* Removed ast_internal_timing_enabled(), AST_OPT_FLAG_INTERNAL_TIMING, and
ast_opt_internal_timing.
ASTERISK-22846 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3414/
........
Merged revisions 411715 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411716 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 411717 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Assert if a channel is destroyed but has the snapshot staging flag set.
In this case the final channel destruction snapshot would never get taken.
* Assert if what we just got out of the stasis cache is not what we were
looking for. This assert would have saved several days searching for a
bug and a lot of my hair.
* Assert if the music on hold message posts could not find the associated
channel. A crash will happen later when manager tries to send the MOH AMI
message. This assert catches the problem when the stasis message is
posted instead of by the thread processing the defective message.
* Always generate a backtrace when an ast_assert() fails.
Review: https://reviewboard.asterisk.org/r/3411/
........
Merged revisions 411701 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Playing back a file to a channel in an ARI bridge would attempt to wait until
the playback concluded before returning. The method used involved signaling the
waiting thread in the ARI custom playback function.
The problem with this is that there were some corner cases that were not accounted for:
* If a bridge channel could not be found, then we never would attempt the playback but
would still attempt to wait for the playback to complete.
* If the bridge playfile action failed to queue, we would still attempt to wait for the
playback to complete.
* If the bridge playfile action were queued but some circumstance caused the playback
not to occur (the bridge dies, the channel is removed from the bridge), then we would
never be notified.
The solution to this is to move the waiting logic into the bridge code. A new bridge
API function is added to queue a synchronous action on a bridge. The waiting thread
is notified when the queued frame has been freed, either due to an error occurring
or due to successful playback. As a failsafe, the waiting thread has a 10 minute
timeout just in case there is a frame leak somewhere.
Review: https://reviewboard.asterisk.org/r/3338
........
Merged revisions 410673 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410684 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
started/stopped.
* Made res_musiconhold.c always post the MusicOnHoldStart/MusicOnHoldStop
events when it actually starts/stops the music streams. This allows the
events to always happen when MOH starts/stops. The event posting code was
moved to the MOH alloc/release routines.
* Made channel_do_masquerade() stop any MOH on the original channel before
masquerading so the original channel will get a stop event with correct
information.
* Cleaned up a couple odd codings in moh_files_alloc() and moh_alloc()
dealing with the music state variable.
(issue ASTERISK-23311)
Reported by: Benjamin Keith Ford
Review: https://reviewboard.asterisk.org/r/3306/
........
Merged revisions 410493 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410494 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.
Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.
The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.
Credit to Olle Johansson for pointing me in the right direction on this issue.
(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
........
Merged revisions 408642 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 408643 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 408644 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408645 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The ast_filestream object gets tacked on to a channel via
chan->timingdata. It's a reference counted object, but the reference
count isn't used when putting it on a channel. It's theoretically
possible for another thread to interfere with the channel while it's
unlocked and cause the filestream to get destroyed.
Use the astobj2 reference count to make sure that as long as this code
path is holding on the ast_filestream and passing it into the file.c
playback code, that it knows it's valid.
Bug reported by Leif Madsen.
Review: https://reviewboard.asterisk.org/r/3135/
........
Merged revisions 406566 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 406567 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 406574 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
'core show channeltypes' type column is being sliced, resulting in incomplete
type names.
(closes issue ASTERISK-22919)
Reported by: outtolunc
Patches:
svn_channel.c.format_15.diff.txt uploaded by outtolunc (license 5198)
........
Merged revisions 404579 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404581 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Implements the following cli commands:
pjsip list aors
pjsip list auths
pjsip list channels
pjsip list contacts
pjsip list endpoints
pjsip show aor(s)
pjsip show auth(s)
pjsip show channels
pjsip show endpoint(s)
Also...
Minor modifications made to the AMI command implementations to facilitate
reuse.
New function ast_variable_list_sort added to config.c and config.h to implement
variable list sorting.
(issue ASTERISK-22610)
patches:
pjsip_cli_v2.patch uploaded by george.joseph (License 6322)
........
Merged revisions 404480 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404507 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
For the explanation, here is a copy-paste of the review board explanation:
Initially, it was discovered that performing an attended transfer of a
multiparty bridge with a PJSIP channel would cause a deadlock. A PBX thread
started a masquerade and reached the point where it was calling the fixup()
callback on the "original" channel. For chan_pjsip, this involves pushing a
synchronous task to the session's serializer. The problem was that a task ahead
of the fixup task was also attempting to perform a channel masquerade. However,
since masquerades are designed in a way to only allow for one to occur at a
time, the task ahead of the fixup could not continue until the masquerade
already in progress had completed. And of course, the masquerade in progress
could not complete until the task ahead of the fixup task had completed.
Deadlock.
The initial fix was to change the fixup task to be asynchronous. While this
prevented the deadlock from occurring, it had the frightful side effect of
potentially allowing for tasks in the session's serializer to operate on a
zombie channel.
Taking a step back from this particular deadlock, it became clear that the
problem was not really this one particular issue but that masquerades
themselves needed to be addressed. A PJSIP attended transfer operation calls
ast_channel_move(), which attempts to both set up and execute a masquerade. The
problem was that after it had set up the masquerade, the PBX thread had swooped
in and tried to actually perform the masquerade. Looking at changes that had
been made to Asterisk 12, it became clear that there never is any time now that
anyone ever wants to set up a masquerade and allow for the channel thread to
actually perform the masquerade. Everyone always is calling ast_channel_move(),
performs the masquerade itself before returning.
In this patch, I have removed all blocks of code from channel.c that will
attempt to perform a masquerade if ast_channel_masq() returns true. Now, there
is no distinction between setting up a masquerade and performing the
masquerade. It is one operation. The only remaining checks for
ast_channel_masq() and ast_channel_masqr() are in ast_hangup() since we do not
want to interrupt a masquerade by hanging up the channel. Instead, now
ast_hangup() will wait for a masquerade to complete before moving forward with
its operation.
The ast_channel_move() function has been modified to basically in-line the
logic that used to be in ast_channel_masquerade(). ast_channel_masquerade() has
been killed off for real. ast_channel_move() now has a lock associated with it
that is used to prevent any simultaneous moves from occurring at once. This
means there is no need to make sure that ast_channel_masq() or
ast_channel_masqr() are already set on a channel when ast_channel_move() is
called. It also means the channel container lock is not pulling double duty by
both keeping the container locked and preventing multiple masquerades from
occurring simultaneously.
The ast_do_masquerade() function has been renamed to do_channel_masquerade()
and is now internal to channel.c. The function now takes explicit arguments of
which channels are involved in the masquerade instead of a single channel.
While it probably is possible to do some further refactoring of this method, I
feel that I would be treading dangerously. Instead, all I did was change some
comments that no longer are true after this changeset.
The other more minor change introduced in this patch is to res_pjsip.c to make
ast_sip_push_task_synchronous() run the task in-place if we are already a SIP
servant thread. This is related to this patch because even when we isolate the
channel masquerade to only running in the SIP servant thread, we would still
deadlock when the fixup() callback is reached since we would essentially be
waiting forever for ourselves to finish before actually running the fixup. This
makes it so the fixup is run without having to push a task into a serializer at
all.
(closes issue ASTERISK-22936)
Reported by Jonathan Rose
Review: https://reviewboard.asterisk.org/r/3069
........
Merged revisions 404356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404368 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 404332 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404333 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Original commit message by mmichelson (asterisk 12 r403311):
"This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change makes ast_channel_alloc return allocated channels
locked. By doing so no other thread can acquire, lock, and manipulate
the channel before it is completely set up.
(closes issue AST-1256)
Review: https://reviewboard.asterisk.org/r/3067/
........
Merged revisions 404204 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404210 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
of "available"
(issue ASTERISK-23021)
(closes issue ASTERISK-23021)
Reported by: Jeremy Lainé
Tested by: Rusty Newton
Patches:
available.patch uploaded by Jeremy Lainé (license 6561)
........
Merged revisions 404046 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404047 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The change contains a slightly adjusted patch that was on the issue
(submitted by kmoore). A fix was made by adding in a bridge lock
while calling bridge_start/stop from the framehook callback. Since
the framehook callback is not called from the bridging core the bridge
is not locked, but needs to be before calling bridge_start.
(closes issue ASTERISK-22749)
Reported by: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/3066/
Patches:
lock_inversion.diff uploaded by kmoore (license 6273)
........
Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 403398 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
