If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397756 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397757 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 397758 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 397759 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397710 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397711 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 397712 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 397713 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397753 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
........
Merged revisions 397525 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397528 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds pass through support for Opus and VP8. That includes:
* Format attribute negotiation for Opus. Note that unlike some other codecs,
the draft RFC specifies having spaces delimiting the attributes in addition
to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in
chan_sip, so a small tweak was also included in this patch for that.
* A format attribute negotiation module for Opus, res_format_attr_opus
* Fast picture update for VP8. Since VP8 uses a different RTCP packet number
than FIR, this really is specific to VP8 at this time.
Note that the format attribute negotiation in res_pjsip_sdp_rtp was written
by mjordan. The rest of this patch was written completely by Lorenzo Miniero.
Review: https://reviewboard.asterisk.org/r/2723/
(closes issue ASTERISK-21981)
Reported by: Tzafrir Cohen
patches:
asterisk_opus+vp8_passthrough_20130718.patch uploaded by lminiero (License 6518)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397526 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a response to an initial incoming INVITE results in a transport error
the INVITE transaction is removed from the INVITE session. Any attempts
to answer the INVITE session after this results in a crash as it requires
the INVITE transaction to exist. This change explicitly locks the dialog
and checks to ensure that the INVITE transaction exists before answering.
(closes issue AST-1203)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397515 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a From header on an outbound out-of-call SIP MESSAGE were
malformed, the result could crash Asterisk.
In addition, if a From header on an incoming out-of-call SIP
MESSAGE request were malformed, the message was happily accepted
rather than being rejected up front. The incoming message path
would not result in a crash, but the behavior was bad nonetheless.
(closes issue ASTERISK-22185)
reported by Zhang Lei
........
Merged revisions 397254 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP_CODEC family of variables let you set the preferred codec to be
offered on an outbound INVITE request. However, for video calls, you need to
be able to set both the audio and video codecs to be offered. This patch lets
the SIP_CODEC variables accept a comma delineated list of codecs. The first
codec in the list is set as the preferred codec; additional codecs are still
offered however.
This lets a dialplan writer set both audio and video codecs, e.g.,
Set(SIP_CODEC=ulaw,h264)
Note that this feature was written by both Dennis Guse and Frank Haase
Review: https://reviewboard.asterisk.org/r/2728
(closes issue ASTERISK-21976)
Reported by: Denis Guse
Tested by: mjordan, sysreq
patches:
patch-channels-chan__sip.c-393919 uploaded by dennis.guse (license 6513)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397243 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
........
Merged revisions 397204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397205 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change protects accesses of res_parking such that it can unload
safely once transient uses of its registered functions are complete.
The parking API has been restructured such that its consumers do not
have access to the vtable exposed by the parking provider, but instead
route through stubs to prevent consumers from holding on to function
pointers.
This adds calls to all the parking unload functions and moves
application loading and unloading into functions in
parking_applications.c similar to the rest of the parts of res_parking.
Review: https://reviewboard.asterisk.org/r/2763/
(closes issue ASTERISK-22142)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396890 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This removes unused code, event types, IE pltypes, and event IE types
where possible and makes several functions private that were once
public. This includes a renumbering of the remaining event and IE types
which breaks binary compatibility with previous versions. The last
remaining consumers of the old event system (or parts thereof) are
main/security_events.c, res/res_security_log.c, tests/test_cel.c,
tests/test_event.c, main/cel.c, and the CEL backends.
Review: https://reviewboard.asterisk.org/r/2703/
(closes issue ASTERISK-22139)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This makes it so that we can detect failures to originate as with
earlier versions of Asterisk, which restores the Asterisk 11 behavior
for the originate manager action. This was causing the ACL tests for
SIP and IAX2 to fail since those tests expected originate failures
when ACLs would cause rejections. Also, this patch fixes crashes in
chan_sip when ACLs rejected peers during registration verification.
(closes issue ASTERISK-22212)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2753/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396498 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code adds chan_dahdi the command 'dahdi create channels <range>'
(where <range> is a single <n>-<m> or 'new') and updates 'dahdi destroy
channel' with a similar 'dahdi destroy channels'. It allows DAHDI
channels and spans to be added after the initial channel load
(without destroying all other channels as in 'dahdi restart').
It also includes some fixes to the D-Channel / span destruction code
(r394552).
This change is intended to provide a hook for a script running from
udev once a span has been assigned ("registered") / unassigned
("unregistered") for its channels. The udev hook configures the span's
channels with dahdi_cfg -S, and can then ask Asterisk to create ethe
channels. See the scripts added to DAHDI-tools in 2.7.0.
Review: https://reviewboard.asterisk.org/r/1598/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396474 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does three things:
1. It provides a Surrogate channel technology with a consolidated
"implementation detail flag" on the channel technology. This tells
consumers of Stasis that the creation of this channel is an implementation
detail in Asterisk and can be ignored (if they so choose). This
consolidates the conference recorder/announcer flags as well - these flags
had no additional meaning beyond "ignore this channel please".
2. It modifies allocation of a channel in two ways:
(a) If a channel technology can be determined from the name, we set it
directly in the allocation routine. This prevents the initial
publication of the message from going out with a NULL channel technology
where possible. This lets Stasis consumers get the right channel
technology on the first publication.
(b) It reorganizes allocation to make use of the 'finalized' property on the
channel. This was already used to know that a channel had completely
finished its construction in the masquerade routine; now we also use it
to know whether or not the setting of certain channel properties is
occurring during or post construction. The various set routines were
modified accordingly as well.
3. The masquerade event is now dead, Jim. It no longer served any purpose
whatsoever - if you perform a call pickup you'll get a Pickup event;
if you perform an attended transfer you will still get those events; if you
steal a channel to put it elsewhere you'll get the corresponding NewExten or
BridgeEnter events.
Review: https://reviewboard.asterisk.org/r/2740
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396392 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
........
Merged revisions 396240 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 396248 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396253 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit is smaller than the initial review placed on review board. This is because
a change to allow for channel drivers to access parking functionality externally was
committed and invalidated quite a few of the changes initially made.
(closes issue ASTERISK-22039)
reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/2717
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396103 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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 patch does the following:
* It adds support for externally initiated parking requests. In particular,
chan_skinny has a protocol level message that initiates a call park.
This patch now supports that option, as well as the protocol specific
mechanisms in chan_dahdi/sig_analog and chan_mgcp.
* A parking bridge features virtual table has been added that provides
access to the parking functionality that the Bridging API needs. This
includes requests to park an entire 'call' (with little or no additional
information, thank you chan_skinny), perform a blind transfer to a parking
extension, determine if an extension is a parking extension, as well as the
actual "do the parking" request from the Bridging API.
* Refactoring in chan_mgcp, chan_skinny, and chan_dahdi to make use of the new
functions
* The removal of some - but not all - dead parking code from features.c
This also fixed blind transferring a multi-party bridge to a parking lot (which
was implemented, but had at least one code path where using the parking features
kK might not have worked)
Review: https://reviewboard.asterisk.org/r/2710
(closes issue ASTERISK-22134)
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396028 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
The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:
* The word "Gulp" in dialstrings, functions, and CLI commands is now
"PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 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
Created a native_dahdi bridging technology for use with the new bridging
API.
The new bridging technology is part of the chan_dahdi channel driver
because it is very specific to that driver. Rather than include the new
code directly into chan_dahdi.c the new bridge technology is in its own
file and linked into chan_dahdi.so. A large part of this change is the
mechanical process of moving declarations around so chan_dahdi.c can be
split up into more files later.
* Changed the bridging core to pass NULL frames into the channel
technologies instead of discarding them. The channel technologies may
need the proding to determine if their configuration is still valid.
(closes issue ASTERISK-21886)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2681/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
