Age | Commit message (Collapse) | Author |
|
This patch does the following:
* It moves the pickup code out of features.c and into pickup.c
* It removes the vast majority of dead code out of features.c. In particular,
this includes the parking code.
(issue ASTERISK-22134)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396060 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This prevents XML documentation duplication by expanding channel and
bridge snapshot tags into channel and bridge snapshot parameter sets
with a given prefix or defaulting to no prefix. This also prevents
documentation from becoming fractured and out of date by keeping all
variations of the documentation in template form such that it only
needs to be updated once and keeps maintenance to a minimum.
Review: https://reviewboard.asterisk.org/r/2708/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395985 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In working with res_stasis, I discovered a significant limitation to
the current structure of stasis_caching_topics: you cannot subscribe
to cache updates for a single channel/bridge/endpoint/etc.
To address this, this patch splits the cache away from the
stasis_caching_topic, making it a first class object. The stasis_cache
object is shared amongst individual stasis_caching_topics that are
created per channel/endpoint/etc. These are still forwarded to global
whatever_all_cached topics, so their use from most of the code does
not change.
In making these changes, I noticed that we frequently used a similar
pattern for bridges, endpoints and channels:
single_topic ----------------> all_topic
^
|
single_topic_cached ----+----> all_topic_cached
|
+----> cache
This pattern was extracted as the 'Stasis Caching Pattern', defined in
stasis_caching_pattern.h. This avoids a lot of duplicate code between
the different domain objects.
Since the cache is now disassociated from its upstream caching topics,
this also necessitated a change to how the 'guaranteed' flag worked
for retrieving from a cache. The code for handling the caching
guarantee was extracted into a 'stasis_topic_wait' function, which
works for any stasis_topic.
(closes issue ASTERISK-22002)
Review: https://reviewboard.asterisk.org/r/2672/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395954 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch makes it so that all registration attempts that fail that
also permanently modify the registration state will raise an appropriate
AMI event.
Note that this patch was forward ported to trunk and the Stasis Core
message bus by mjordan.
(closes issue ASTERISK-21368)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Demon (license 6479)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch renames the bridging* files to bridge*. This may seem pedantic
and silly, but it fits better in line with current Asterisk naming conventions:
* channel is not "channeling"
* monitor is not "monitoring"
etc.
A bridge is an object. It is a first class citizen in Asterisk. "Bridging" is
the act of using a bridge on a set of channels - and the API that fulfills that
role is more than just the action.
(closes issue ASTERISK-22130)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch introduces DTLS-SRTP support to chan_pjsip and the options
necessary to configure it including an option to allow choosing between
32 and 80 byte SRTP tag lengths.
During the implementation and testing of this patch, three other bugs
were found and their fixes are included with this patch. The two in
chan_sip were a segfault relating to DTLS setup and mistaken call
rejection. The third bug fix prevents chan_pjsip from attempting to
perform bridge optimization between two endpoints if either of them is
running any form of SRTP.
Review: https://reviewboard.asterisk.org/r/2683/
(closes issue ASTERISK-21419)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395121 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This adds CEL support for blind and attended transfers and call pickup.
During the course of adding this functionality I noticed that
CONF_ENTER, CONF_EXIT, and BRIDGE_TO_CONF events are particularly
useless without a bridge identifier, so I added that as well.
This adds tests for blind transfers, several types of attended
transfers, and call pickup.
The extra field in CEL records now consists of a JSON blob whose fields
are defined on a per-event basis.
Review: https://reviewboard.asterisk.org/r/2658/
(closes issue ASTERISK-21565)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394858 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Temporary peers do not have an associated Stasis endpoint and quite a
bit of code in chan_sip assumes that all peers have a Stasis endpoint.
All endpoint accesses in chan_sip are now wrapped in an endpoint
NULL-check.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Instead of formatting a NULL pointer into a "%s" format string (which is
usually not a good thing to do), we instead print "Unknown".
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@394278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This also shuffles the stasis system topic and related handling.
(closes issue ASTERISK-21488)
Review: https://reviewboard.asterisk.org/r/2631/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393804 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch does the following:
* It merges Jaco Kroon's patch from ASTERISK-20754, which provides channel
information in the RTCP events. Because Stasis provides a cache, Jaco's
patch was modified to pass the channel uniqueid to the RTP layer as
opposed to a pointer to the channel. This has the following benefits:
(1) It keeps the RTP engine 'clean' of references back to channels
(2) It prevents circular dependencies and other potential ref counting issues
* The RTP engine now allows any RTP implementation to raise RTCP messages.
Potentially, other implementations (such as res_rtp_multicast) could also
raise RTCP information. The engine provides structs to represent RTCP headers
and RTCP SR/RR reports.
* Some general refactoring in res_rtp_asterisk was done to try and tame the
RTCP code. It isn't perfect - that's *way* beyond the scope of this work -
but it does feel marginally better.
* A few random bugs were fixed in the RTCP statistics. (Example: performing an
assignment of a = a is probably not correct)
* We now raise RTCP events for each SR/RR sent/received. Previously we wouldn't
raise an event when we sent a RR report.
Note that this work will be of use to others who want to monitor call quality
or build modules that report call quality statistics. Since the events are now
moving across the Stasis message bus, this is far easier to accomplish. It is
also a first step (though by no means the last step) towards getting Olle's
pinefrog work incorporated.
Again: note that the patch by Jaco Kroon was modified slightly for this work;
however, he did all of the hard work in finding the right places to set the
channel in the RTP engine across the channel drivers. Much thanks goes to Jaco
for his hard work here.
Review: https://reviewboard.asterisk.org/r/2603/
(closes issue ASTERISK-20574)
Reported by: Jaco Kroon
patches:
asterisk-rtcp-channel.patch uploaded by jkroon (License 5671)
(closes issue ASTERISK-21471)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This change removes JitterBufStats, ChannelReload, and ChannelUpdate
and refactors the following events to travel over Stasis-Core:
* LocalBridge
* DAHDIChannel
* AlarmClear
* SpanAlarmClear
* Alarm
* SpanAlarm
* DNDState
* MCID
* SIPQualifyPeerDone
* SessionTimeout
Review: https://reviewboard.asterisk.org/r/2627/
(closes issue ASTERISK-21476)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This creates stasis messages that are sent during a blind or
attended transfer. The stasis messages also are converted to
AMI events.
Review: https://reviewboard.asterisk.org/r/2619
(closes issue ASTERISK-21337)
Reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@393182 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
There was a misunderstanding about ast_bridge_impart()'s handling of the
imparted channel's reference. The channel reference is passed by the
caller unless ast_bridge_impart() returns an error.
* Fixed a memory leak in conf_announce_channel_push() if the impart
failed.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392934 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
1. Security events
2. Websocket support
3. Diversion header + redirecting support
4. An anonymous endpoint identifier
5. Inbound extension state subscription support
6. PIDF notify generation
7. One touch recording support (special thanks Sean Bright!)
8. Blind and attended transfer support
9. Automatic inbound registration expiration
10. SRTP support
11. Media offer control dialplan function
12. Connected line support
13. SendText() support
14. Qualify support
15. Inband DTMF detection
16. Call and pickup groups
17. Messaging support
Thanks everyone!
Side note: I'm reminded of the song "How Far We've Come" by Matchbox Twenty.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
chan_pjsip device state.
(closes issue ASTERISK-21489)
(closes issue ASTERISK-21503)
Review: https://reviewboard.asterisk.org/r/2601/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@392538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch is the initial push to update Asterisk's CDR engine for the new
bridging framework. This patch guts the existing CDR engine and builds the new
on top of messages coming across Stasis. As changes in channel state and bridge
state are detected, CDRs are built and dispatched accordingly. This
fundamentally changes CDRs in a few ways.
(1) CDRs are now *very* reflective of the actual state of channels and bridges.
This means CDRs track well with what an actual channel is doing - which
is useful in transfer scenarios (which were previously difficult to pin
down). It does, however, mean that CDRs cannot be 'fooled'. Previous
behavior in Asterisk allowed for CDR applications, channels, and other
properties to be spoofed in parts of the code - this no longer works.
(2) CDRs have defined behavior in multi-party scenarios. This behavior will not
be what everyone wants, but it is a defined behavior and as such, it is
predictable.
(3) The CDR manipulation functions and applications have been overhauled. Major
changes have been made to ResetCDR and ForkCDR in particular. Many of the
options for these two applications no longer made any sense with the new
framework and the (slightly) more immutable nature of CDRs.
There are a plethora of other changes. For a full description of CDR behavior,
see the CDR specification on the Asterisk wiki.
(closes issue ASTERISK-21196)
Review: https://reviewboard.asterisk.org/r/2486/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@391947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Features configuration is handled in its own API in
features_config.h and features_config.c. This way, features
configuration is accessible to anything that needs it.
In addition, features configuration has been altered to
be more channel-oriented. Most callers of features API
code will be supplying a channel so that the individual
channel's settings will be acquired rather than the global
setting.
Missing from this commit is XML documentation for the
features configuration. That will be handled in a separate
commit.
Review: https://reviewboard.asterisk.org/r/2578/
(issue ASTERISK-21542)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@390751 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This now uses the core API for performing attended transfers.
Review https://reviewboard.asterisk.org/r/2513
(Closes issue ASTERISK-21520)
reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
masquerades.
The attended transfer API call can complete the attended transfer in a number of ways
depending on the current bridged states of the channels involved.
The hiding of masquerades is done in some bridging-related functions, such as the manager
Bridge action and the Bridge dialplan application. In addition, call pickup was edited
to "move" a channel rather than masquerade it.
Review: https://reviewboard.asterisk.org/r/2511
(closes issue ASTERISK-21334)
Reported by Matt Jordan
(closes issue Asterisk-21336)
Reported by Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389848 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(closes issue ASTERISK-21487)
Review: https://reviewboard.asterisk.org/r/2565/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
This patch moves a number of AMI events over to the Stasis-Core message bus.
This includes:
* ChanSpyStart/Stop
* MonitorStart/Stop
* MusicOnHoldStart/Stop
* FullyBooted/Reload
* All Voicemail/MWI related events
In addition, it adds some Stasis-Core and AMI support for generic AMI messages,
refactors the message router in AMI to use a single router with topic
forwarding for the topics that AMI cares about, and refactors MWI message
types and topics to be more name compliant.
Review: https://reviewboard.asterisk.org/r/2532
(closes issue ASTERISK-21462)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389733 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Breaks many things until they can be reworked. A partial list:
chan_agent
chan_dahdi, chan_misdn, chan_iax2 native bridging
app_queue
COLP updates
DTMF attended transfers
Protocol attended transfers
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389378 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r388005, macros were introduced to consistently define message
types. This added an assert if a message type was used either before
it was initialized or after it had been cleaned up. It turns out that
this assertion fires during shutdown.
This actually exposed a hidden shutdown ordering problem. Since
unsubscribing is asynchronous, it's possible that the message types
used by the subscription could be freed before the final message of
the subscription was processed.
This patch adds stasis_subscription_join(), which blocks until the
last message has been processed by the subscription. Since joining was
most commonly done right after an unsubscribe, a
stasis_unsubscribe_and_join() convenience function was also added.
Similar functions were also added to the stasis_caching_topic and
stasis_message_router, since they wrap subscriptions and have similar
problems.
Other code in trunk was refactored to join() where appropriate, or at
least verify that the subscription was complete before being
destroyed.
Review: https://reviewboard.asterisk.org/r/2540
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@389011 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Also moves ACL messages to the security topic and gets rid of the
ACL topic
(closes issue ASTERISK-21103)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2496/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388975 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The prior code committed, r385473, failed to take into consideration that not
all outgoing calls will be to a peer. My fault.
This patch does the following:
* Check if there is a related peer involved. If there is, check and set NAT
settings according to the peer's settings.
* Fix a problem with realtime peers. If the global setting has auto_force_rport
set and we issued a "sip reload" while a peer is still registered, the peer's
flags for NAT are reset to off. When this happens, we were always setting the
contact address of the peer to that of the full contact info that we had.
(closes issue ASTERISK-21374)
Reported by: jmls
Tested by: Michael L. Young
Patches:
asterisk-21374-fix-crash-and-rt-peers.diff by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2524/
........
Merged revisions 388601 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388602 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 388253 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@388254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
An endpoint is an external device/system that may offer/accept
channels to/from Asterisk. While this is a very useful concept for end
users, it is surprisingly not a core concept within Asterisk itself.
This patch defines ast_endpoint as a separate object, which channel
drivers may use to expose their concept of an endpoint. As the channel
driver creates channels, it can use ast_endpoint_add_channel() to
associate channels to the endpoint. This updated the endpoint
appropriately, and forwards all of the channel's events to the
endpoint's topic.
In order to avoid excessive locking on the endpoint object itself, the
mutable state is not accessible via getters. Instead, you can create a
snapshot using ast_endpoint_snapshot_create() to get a consistent
snapshot of the internal state.
This patch also includes a set of topics and messages associated with
endpoints, and implementations of the endpoint-related RESTful
API. chan_sip was updated to create endpoints with SIP peers, but the
state of the endpoints is not updated with the state of the peer.
Along for the ride in this patch is a Stasis test API. This is a
stasis_message_sink object, which can be subscribed to a Stasis
topic. It has functions for blocking while waiting for conditions in
the message sink to be fulfilled.
(closes issue ASTERISK-21421)
Review: https://reviewboard.asterisk.org/r/2492/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387932 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
retries fail
RFC6665 4.2.2: ... after a failed State NOTIFY transaction remove the subscription
The problem is that the State Notify requests rely on the 200OK reponse for pacing control
and to not confuse the notify susbsystem.
The issue is, the pendinginvite isn't cleared if a response isn't received,
thus further notify's are never sent.
The solution, follow RFC 6665 4.2.2's 'SHOULD' and remove the subscription after failure.
(closes issue ASTERISK-21677)
Reported by: Dan Martens
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2475/
........
Merged revisions 387875 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387880 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-21103)
Review: https://reviewboard.asterisk.org/r/2490/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
interval when not the refresher
RFC 4028 Section 10
if the side not performing refreshes does not receive a
session refresh request before the session expiration, it SHOULD send
a BYE to terminate the session, slightly before the session
expiration. The minimum of 32 seconds and one third of the session
interval is RECOMMENDED.
Prior to this asterisk would refresh at 1/2 the Session-Expires interval,
or if the remote device was the refresher, asterisk would timeout at interval end.
Now, when not refresher, timeout as per RFC noted above.
(closes issue ASTERISK-21742)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2488/
........
Merged revisions 387344 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387345 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387369 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
asterisk is the refresher.
RFC 4028 Section 7.2
"UACs MUST be prepared to receive a Session-Expires header field in a
response, even if none were present in the request."
What changed
After ASTERISK-20787, inbound calls to asterisk with no Session-Expires in the INVITE are now are offered
a Session-Expires (1800 asterisk default) in the response, with asterisk as the refresher.
Symptom:
After 900 seconds (asterisk default refresher period 1800), asterisk RE-INVITEs the device, the device
may respond with a much lower Session-Expires (180 in our case) value that it is now using.
Asterisk ignores this response, as it's deemed both an INBOUND CALL, and a RE-INVITE.
After 180 seconds the device times out and sends BYE (hangs up), asterisk is still working with the
refresher period of 1800 as it ignored the 'Session Expires: 180' in the previous 200OK response.
Fix:
handle_response_invite() when 200OK, remove check for outbound and reinvite.
(closes issue ASTERISK-21664)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2463/
........
Merged revisions 387312 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 387319 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387327 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When you have lots of SIP peers (according to the issue reporter, around 3500),
the 'sip show peers' CLI command or AMI action can crash due to a poorly placed
string duplication that occurs on the stack. This patch refactors the command
to not allocate the string on the stack, and handles the formatting of a single
peer in a separate function call.
(closes issue ASTERISK-21466)
Reported by: Guillaume Knispel
patches:
fix_sip_show_peers_stack_overflow_asterisk_11.3.0-v2.patch uploaded by gknispel (License 6492)
........
Merged revisions 387134 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
(issue ASTERISK-21103)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2481/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@387037 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Use comedia_string() to display correctly the symmetric rtp setting when
running "sip show settings"
........
Merged revisions 386486 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386487 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
* Change "ForcerPort" to "Forcerport" to match everywhere else it is displayed
........
Merged revisions 386483 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 386484 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@386485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When we reload Asterisk or chan_sip, the flags force_rport and comedia that are
turned on and off when using the auto_force_rport and auto_comedia nat settings
go back to the default setting off. These flags are turned on when needed or
off when not needed at the time that a peer registers, re-registers or initiates
a call. This would apply even when only the default global setting
"nat=auto_force_rport" is being used, which in this case would only affect the
force_rport flag.
Everything is good except for the following: The nat setting is set to
auto_force_rport and auto_comedia. We reload Asterisk and the peer's
registration has not expired. We load in the settings for the peer which turns
force_rport and comedia back to off. Since the peer has not re-registered or
placed a call yet, those flags remain off. We then initiate a call to the peer
from the PBX. The force_rport and comedia flags stay off. If NAT is involved,
we end up with one-way audio since we never checked to see if the peer is behind
NAT or not.
This patch does the following:
* Moves the checking of whether a peer is behind NAT into its own function
* Create a function to set the peer's NAT flags if they are using the auto_* NAT
settings
* Adds calls in sip_request_call() to these new functions in order to setup the
dialog according to the peer's settings
(closes issue ASTERISK-21374)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
asterisk-21374-auto-nat-outgoing-fix_v2.diff Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2421/
........
Merged revisions 385473 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a BYE request is processed in chan_sip, the current SIP dialog is detached
from its associated Asterisk channel structure. The tech_pvt pointer in the
channel object is set to NULL, and the dialog persists for an RFC mandated
period of time to handle re-transmits.
While this process occurs, the channel is locked (which is good).
Unfortunately, operations that are initiated externally have no way of knowing
that the channel they've just obtained (which is still valid) and that they are
attempting to lock is about to have its tech_pvt pointer removed. By the time
they obtain the channel lock and call the channel technology callback, the
tech_pvt is NULL.
This patch adds a few checks to some channel callbacks that make sure the
tech_pvt isn't NULL before using it. Prime offenders were the DTMF digit
callbacks, which would crash if AMI initiated a DTMF on the channel at the
same time as a BYE was received from the UA. This patch also adds checks on
sip_transfer (as AMI can also cause a callback into this function), as well
as sip_indicate (as lots of things can queue an indication onto a channel).
Review: https://reviewboard.asterisk.org/r/2434/
(closes issue ASTERISK-20225)
Reported by: Jeff Hoppe
........
Merged revisions 385170 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 385173 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@385174 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
The initial report was that the "nat" setting in the [general] section was not
having any effect in overriding the default setting. Upon confirming that this
was happening and looking into what was causing this, it was discovered that
other default settings would not be overriden as well.
This patch works similar to what occurs in build_peer(). We create a temporary
ast_flags structure and using a mask, we override the default settings with
whatever is set in the [general] section.
In the bug report, the reporter who helped to test this patch noted that the
directmedia settings were being overriden properly as well as the nat settings.
This issue is also present in Asterisk 1.8 and a separate patch will be applied
to it.
(issue ASTERISK-21225)
Reported by: Alexandre Vezina
Tested by: Alexandre Vezina, Michael L. Young
Patches:
asterisk-21225-handle-options-default-prob_v4.diff
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2385/
........
Merged revisions 384827 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
........
Merged revisions 384162 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 384163 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384164 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When authenticating a SIP request with alwaysauthreject enabled, allowguest
disabled, and autocreatepeer disabled, Asterisk discloses whether a user
exists for INVITE, SUBSCRIBE, and REGISTER transactions in multiple ways. The
information is disclosed when:
* A "407 Proxy Authentication Required" response is sent instead of a
"401 Unauthorized" response
* The presence or absence of additional tags occurs at the end of "403
Forbidden" (such as "(Bad Auth)")
* A "401 Unauthorized" response is sent instead of "403 Forbidden" response
after a retransmission
* Retransmission are sent when a matching peer did not exist, but not when a
matching peer did exist.
This patch resolves these various vectors by ensuring that the responses sent
in all scenarios is the same, regardless of the presence of a matching peer.
This issue was reported by Walter Doekes, OSSO B.V. A substantial portion of
the testing and the solution to this problem was done by Walter as well - a
huge thanks to his tireless efforts in finding all the ways in which this
setting didn't work, providing automated tests, and working with Kinsey on
getting this fixed.
(closes issue ASTERISK-21013)
Reported by: wdoekes
Tested by: wdoekes, kmoore
patches:
AST-2013-003-1.8 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-10 uploaded by kmoore, wdoekes (License 6273, 5674)
AST-2013-003-11 uploaded by kmoore, wdoekes (License 6273, 5674)
........
Merged revisions 384003 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@384019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In r373424, several reentrancy problems in chan_sip were addressed. As a
result, the SIP channel driver is now properly locking the channel driver
private information in certain operations that it wasn't previously. This
exposed two latent problems either in register_verify or by functions called
by register_verify. This includes:
* Holding the private lock while calling sip_send_mwi_to_peer. This can create
a new sip_pvt via sip_alloc, which will obtain the channel container lock.
This is a locking inversion, as any channel related lock must be obtained
prior to obtaining the SIP channel technology private lock.
Note that this issue was already fixed in Asterisk 11.
* Holding the private lock while calling sip_poke_peer. In the same vein as
sip_send_mwi_to_peer, sip_poke_peer can create a new SIP private, causing
the same locking inversion.
Note that this locking inversion typically occured when CLI commands were run
while a SIP REGISTER request was being processed, as many CLI commands (such
as 'sip show channels', 'core show channels', etc.) have to obtain the channel
container lock.
(issue ASTERISK-21068)
Reported by: Nicolas Bouliane
(issue ASTERISK-20550)
Reported by: David Brillert
(issue ASTERISK-21314)
Reported by: Badalian Vyacheslav
(issue ASTERISK-21296)
Reported by: Gabriel Birke
........
Merged revisions 383863 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383878 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Remove MWI's dependency on the event system by moving it to
Stasis-core. This also introduces forwarding topic pools in Stasis-core
which aggregate many dynamically allocated topics into a single primary
topic.
Review: https://reviewboard.asterisk.org/r/2368/
(closes issue ASTERISK-21097)
Patch-by: Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
AMI, HTTP, and chan_sip all support TLS in some way, but none of them
support all the options that Asterisk's TLS core is capable of
interpreting. This prevents consumers of the TLS/SSL layer from setting
TLS/SSL options that they do not support.
This also gets tlsverifyclient closer to a working state by requesting
the client certificate when tlsverifyclient is set. Currently, there is
no consumer of main/tcptls.c in Asterisk that supports this feature and
so it can not be properly tested.
Review: https://reviewboard.asterisk.org/r/2370/
Reported-by: John Bigelow
Patch-by: Kinsey Moore
(closes issue AST-1093)
........
Merged revisions 383165 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383166 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383167 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
When a session timer expires during a dialog that has re-negotiated to T.38
and Asterisk is the refresher, Asterisk will send a re-INVITE with an SDP
containing audio media only. This causes some hilarity with the poor fax
session under weigh.
This patch corrects that by sending T.38 parameters if we are in the middle of
a T.38 session.
(closes issue ASTERISK-21232)
Reported by: Nitesh Bansal
patches:
dont-send-audio-reinvite-for-sess-timer-in-t38-call.patch uploaded by nbansal (License 6418)
........
Merged revisions 383124 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 383125 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@383126 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
In ASTERISK-17888, the AMI Registry event during SIP registrations was supposed
to include the Username field. Somehow, one of the events was missed. This
patch corrects that - the Username field should be included in all AMI Registry
events involving SIP registrations.
(issue ASTERISK-17888)
(closes issue ASTERISK-21201)
Reported by: Dmitriy Serov
patches:
chan_sip.c.diff uploaded by Dmitriy Serov (license 6479)
........
Merged revisions 382847 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 382848 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382852 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Added an option "discard_remote_hold_retrieval" (default "no") that if set does
not trigger the music on hold event. This essentially stops telling the peer
to start music on hold.
(issue ABE-2899)
Reported by: Denis Alberto Martinez
Review: https://reviewboard.asterisk.org/r/2336/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|
|
Prior to this change, certain conditions for sending the message would
result in an address of '(null)' being used in the via header of the
SIP message because a NULl value of pvt->ourip was used when initially
generating the via header. This is fixed by adding a call to build_via
when the address is set before sending the message.
(closes issue ASTERISK-21148)
Reported by: Zhi Cheng
Patches:
700-sip_msg_send_via_fix.patch uploaded by Zhi Cheng (license 6475)
........
Merged revisions 382739 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@382746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
|