A regression was introduced in chan_sip by changes to sip reload introduced by
r349097. That patch moved peer purging from the beginning of the reload to
after the general configuration was finished. This patch fixes that by undoing
the repositioning of the original peer purging code and using a similar
function after performing general configuration that purges only autocreated
peers that were created when persist mode isn't enabled.
(closes issue ASTERISK-20611)
Reported by: Alisher
Review: https://reviewboard.asterisk.org/r/2171/
........
Merged revisions 375575 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a "sip reload" is issued for a SIP peer, then his
IP address will be cleared, thus resulting in forgetting the
public IP address. Asterisk will then attempt to route SIP
traffic to the private IP address.
The fix here is to make "sip reload" ignore realtime peers
when "host = dynamic" is spotted. Realtime peers can now only
have their IP address reset if they have gone from being not
dynamic to being dynamic.
(closes issue ASTERISK-18203)
reported by daren ferreira
(closes issue ASTERISK-20572)
reported by JoshE
Patches:
fix_nat_realtime.diff uploaded by JoshE (license #6075)
........
Merged revisions 375415 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375417 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375437 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove the "RTP Read too short" warning for RTP keepalives. Remove the
the warning about the application delimiter switch from pipe to comma.
(You should've done this by now.) Make cdr_odbc report more when an
insert fails. Make chan_sip warn less when the peer wants SRTP (and we
don't) or sends a zero port to disable a media type.
Review: https://reviewboard.asterisk.org/r/2167
(closes issue ASTERISK-20538)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In many cases (for peers behind NAT or for TCP sockets) we do not need
to look up any hostname in the Contact (or Route) when sending an
in-dialog request. This should reduce netsock2.c: getaddrinfo errors in
certain scenarios.
Review: https://reviewboard.asterisk.org/r/2156
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
........
Merged revisions 374905 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374906 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374914 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During testing, it was discovered that having chan_sip
export global symbols was problematic.
The biggest problem was that load order was affected.
Trying to use realtime could be problematic since in
all likelihood the necessary realtime driver(s) would
not be loaded before chan_sip.
In addition, it was found that it was impossible to
use the Digium Phone Module for Asterisk since it
must be loaded before chan_sip since it must hook
into chan_sip's configuration parsing.
The solution is to use a virtual table in the same
manner that other modules in Asterisk do, like
app_voicemail.
(closes issue ASTERISK-20545)
Reported by: kmoore
........
Merged revisions 374842 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for the REDIRECTING dialplan function to be
used to set the reason to any string.
The SIP channel driver has been modified to set the redirecting
reason string to the value received in a Diversion header. In
addition, SIP 480 response reason text will set the redirecting
reason as well.
(closes issue AST-942)
reported by Malcolm Davenport
(closes issue AST-943)
reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/2101
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP session timer mechanism contains a mandatory 'refresher' parameter
(included in the Session-Expires header) which is used in the session timer
offer/answer signaling within a SIP Invite dialog. It looks like asterisk is
interpreting the uac resp. uas role only as the initial role of client and
server (caller is uac, callee is uas). The standard rfc 4028 however assigns
the client role to the ((RE)-Invite) requester, the server role to the
((RE)-Invite) responder.
This patch has Asterisk track the actual refresher as "us" or "them" as opposed
to relying on just the configured "uas" or "uac" properties.
(closes issue AST-922)
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/2118/
........
Merged revisions 373652 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373665 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373690 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When setting CALLERID(pres)=unavailable in the dialplan, the From header
in the SIP message contains "Anonymous" <sip:Anonymous@anonymous.invalid>.
For consistency, Asterisk should use a lowercase a in the userpart of the
URI.
* Make the From header use a lowercase A in the userpart of the anonymous
URI.
(closes issue ASTERISK-19838)
Reported by: Antti Yrjola
Patches:
chan_sip_patch_ASTERISK-19838.patch (license #6383) patch uploaded by Antti Yrjola
........
Merged revisions 373500 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373501 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373502 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk v1.8 and later was not as vulnerable to this issue.
* Made find_call() lock each private as it processes the found dialogs.
(Primary cause of ABE-2876)
* Made the other functions that traverse the dialogs container lock each
private as it examines them.
* Fix race condition in sip_call() if the thread that sent the INVITE is
held up long enough for a response to be processed. The p->initid for the
INVITE retransmission could be added after it was canceled by the response
processing.
* Made __sip_destroy() clean up resource pointers after freeing. This is
primarily defensive in case someone has a stale private pointer.
* Removed redundant memset() in reqprep(). The call to init_req() already
does the memset() and is the first reference to req in reqprep().
* Removed useless set of req.method in transmit_invite(). The calls to
initreqprep() and reqprep() have to do this because they memset() the req.
JIRA ABE-2876
..........
Merged -r373423 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 373424 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373466 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If conditions were right it was possible for both the PBX core and chan_sip to deadlock by both having a lock that the other
wants. In the case of the PBX core it had the contexts lock and wanted a SIP dialog lock, while in the case of chan_sip it
had the SIP dialog lock and wanted the contexts lock.
This fix unlocks the SIP dialog before getting the extension state so that the other thread will not block on trying to lock
it. Once the extension state is retrieved the SIP dialog is locked again and life carries on.
As the SIP dialog is reference counted it is not possible for it to go away after unlocking.
(closes issue ASTERISK-20437)
Reported by: jhutchins
........
Merged revisions 373438 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373440 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373454 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The H.264 format attribute module compares two format attribute structures to determine if they are
compatible or not. In some instances it was possible for this check to determine that both structures
were incompatible when they actually should be considered compatible. This check has now been made even
more permissive by assuming that if no attribute information is available the two structures are compatible.
If both structures contain attribute information a base level comparison of the H.264 IDC value is done to
see if they are compatible or not.
The above issue uncovered a secondary issue in chan_sip where the SDP being produced would be incorrect if
the formats were considered incompatible. This has now been fixed by checking that all information required
to produce the SDP is available instead of assuming it is.
(closes issue ASTERISK-20464)
Reported by: Leif Madsen
........
Merged revisions 373413 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373414 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Whitespace, doc-blocks, spelling, case, missing and incorrect tags.
* Add cleanup to Makefile for the Doxygen configuration update
* Start updating Doxygen configuration for cleaner output
* Enable inclusion of configuration files into documentation
* remove mantisworkflow...
* update documentation README
* Add markup to Tilghman's email and talk with him about updating his email, he knows...
* no code changes on this commit other than the mentioned Makefile change
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As mentioned on the review for this, WebRTC has moved towards choosing
DTLS-SRTP as the mechanism for key exchange for SRTP. This commit adds
support for this but makes it available for normal SIP clients as well.
Testing has been done to ensure that this introduces no regressions with
existing behavior and also that it functions as expected.
Review: https://reviewboard.asterisk.org/r/2113/
........
Merged revisions 373229 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the patch to handle arbitrary SDP stream arrangements went into
Asterisk, it also included an ability to transparently decline unknown
stream types. The scanf calls used were not checked properly causing
this part of the functionality to be broken.
(closes issue ASTERISK-20203)
........
Merged revisions 373211 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves two sources of memory leaks when using TLS in Asterisk:
1) It removes improper initialization (and multiple re-initializations) of
portions of the SSL library. Asterisk calls SSL_library_init and
SSL_load_error_strings during SSL initialization; collectively this
obviates the need for calling any of the following during initialization
or client connection handling:
* ERR_load_crypto_strings (handled by SSL_load_error_strings)
* OpenSSL_add_all_algorithms (synonym for SSL_library_init)
* SSLeay_add_ssl_algorithms (synonym for SSL_library_init)
2) Failure to completely clean up all memory allocated by Asterisk and by
the SSL library for TLS clients. This included not freeing the SSL_CTX
object in the SIP channel driver, as well as not clearing the error
stack when the TLS client exited.
Note that these memory leaks were found by Thomas Arimont, and this patch
was essentially written by him with some minor tweaks.
(closes issue AST-889)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
patches:
(bugAST-889.patch) by Thomas Arimont (license 5525)
Review: https://reviewboard.asterisk.org/r/2105
........
Merged revisions 373061 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373062 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373079 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, The acknowledgement wasn't produced until after
executing the sip_poke_peer action actually responsible for
qualifying the peer. Now the response is given immediately once it is
known that a peer will be qualified and a SIPqualifypeerdone event
is issued when the process is finished. Thanks to OEJ for identifying
the problem and helping to come up with a solution.
(issue AST-969)
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/2098/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to 1.8, it was not necessary for an explicit "type" to be set for an
asterisk LDAP realtime peer. Now the routine find_peer actually checks the
type field during registration and fails to find the peer if it is not set.
The attached patch makes the realtime type equal whatever type is being
searched for if the type is 0 upon return from routine build_peer.
(closes issue ASTERISK-17222)
Reported by: John Covert
Patch by: David Vossel
Tested by: Darren Sessions
Review: https://reviewboard.asterisk.org/r/2095/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem had to do with logic used when checking for what the oldest ringing channel
was. The problem was that if no channel was found, then no notification would be sent.
For custom device states, there is no associated channel, so no notification would get
sent. This fixes the issue by still sending the notification even if no associated
channel can be found for a ringing device state change.
(closes issue ASTERISK-20297)
Reported by Noah Engelberth
........
Merged revisions 372137 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@372138 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes numerous doxygen warnings across Asterisk. It also updates
the makefile to regenerate the doxygen configuration on the local system
before running doxygen to help prevent warnings/errors on the local system.
Much thanks to Andrew for tackling one of the Asterisk janitor projects!
(issue ASTERISK-20259)
Reported by: Andrew Latham
Patches:
doxygen_partial.diff uploaded by Andrew Latham (license 5985)
make_progdocs.diff uploaded by Andrew Latham (license 5985)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Jordan informed me that it was more appropriate to use an
astman_send_ack here instead of making an event response. I've also
used this opportunity to update UPGRADE.txt to mention this change
in behavior.
(issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371889 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Issuing SIPqualifypeer either resulted in an
error or if it succeeded, a few \r\ns. This patch adds a
SIPqualifypeerComplete event issued as a response when the command
is successfully executed.
(closes issue AST-969)
Reported by: John Bigelow
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371823 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The helper function, get_address_family_filter, in chan_sip for dns resolution
by address family was not recognizing the websockets transport and resulting in
a null pointer being sent to functions in netsock2, in an attempt to determine
if we are bound to ANY address ([::]) or not.
This patch fixes this issue by handling the transport types SIP_TRANSPORT_WS and
SIP_TRANSPORT_WSS which results in a sock address being set properly for use in
determining the address family.
(closes issue ASTERISK-20221)
Reported by: Sven Beisiegel
Tested by: Sven Beisiegel, James Mortensen
Patches:
asterisk-20221-ws-family-filter.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 371295 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds HANGUPCAUSE information to called channels so that hangup
handlers can, in conjunction with predial dialplan execution, access
the hangupcause information when the dialed channel hangs up on a
one-to-one basis instead of a many-to-one basis as with HANGUPCAUSE
usage on the caller channel.
Review: https://reviewboard.asterisk.org/r/2069/
(closes issue ASTERISK-20198)
........
Merged revisions 371258 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the feature "Private representation of caller, connected
and redirecting party ids", as previously discussed with us (DATUS) and
Digium.
1. Feature motivation
Until now it is quite difficult to modify a party number or name which can
only be seen by exactly one particular instantiated technology channel
subscriber. One example where a modified party number or name on one
channel is spread over several channels are supplementary services like
call transfer or pickup. To implement these features Asterisk internally
copies caller and connected ids from one channel to another. Another
example are extension subscriptions. The monitoring entities (watchers)
are notified of state changes and - if desired - of party numbers or names
which represent the involving call parties. One major feature where a
private representation of party names is essentially needed, i.e. where a
party name shall be exclusively signaled to only one particular user, is a
private user-specific name resolution for party numbers. A lookup in a
private destination-dependent telephone book shall provide party names
which cannot be seen by any other user at any time.
2. Feature Description
This feature comes along with the implementation of additional private
party id elements for caller id, connected id and redirecting ids inside
Asterisk channels.
The private party id elements can be read or set by the user using
Asterisk dialplan functions.
When a technology channel is initiating a call, receives an internal
connected-line update event, or receives an internal redirecting update
event, it merges the corresponding public id with the private id to create
an effective party id. The effective party id is then used for protocol
signaling.
The channel technologies which initially support the private id
representation with this patch are SIP (chan_sip), mISDN (chan_misdn) and
PRI (chan_dahdi).
Once a private name or number on a channel is set and (implicitly) made
valid, it is generally used for any further protocol signaling until it is
rewritten or invalidated.
To simplify the invalidation of private ids all internally generated
connected/redirecting update events and also all connected/redirecting
update events which are generated by technology channels -- receiving
regarding protocol information - automatically trigger the invalidation of
private ids.
If not using the private party id representation feature at all, i.e. if
using only the 'regular' caller-id, connected and redirecting related
functions, the current characteristic of Asterisk is not affected by the
new extended functionality.
3. User interface Description
To grant access to the private name and number representation from the
Asterisk dialplan, the CALLERID, CONNECTEDLINE and REDIRECTING dialplan
functions are extended by the following data types. The formats of these
data types are equal to the corresponding regular 'non-private' already
existing data types:
CALLERID:
priv-all
priv-name priv-name-valid priv-name-charset priv-name-pres
priv-num priv-num-valid priv-num-plan priv-num-pres
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
CONNECTEDLINE:
priv-name priv-name-valid priv-name-pres priv-name-charset
priv-num priv-num-valid priv-num-pres priv-num-plan
priv-subaddr priv-subaddr-valid priv-subaddr-type priv-subaddr-odd
priv-tag
REDIRECTING:
priv-orig-name priv-orig-name-valid priv-orig-name-pres priv-orig-name-charset
priv-orig-num priv-orig-num-valid priv-orig-num-pres priv-orig-num-plan
priv-orig-subaddr priv-orig-subaddr-valid priv-orig-subaddr-type priv-orig-subaddr-odd
priv-orig-tag
priv-from-name priv-from-name-valid priv-from-name-pres priv-from-name-charset
priv-from-num priv-from-num-valid priv-from-num-pres priv-from-num-plan
priv-from-subaddr priv-from-subaddr-valid priv-from-subaddr-type priv-from-subaddr-odd
priv-from-tag
priv-to-name priv-to-name-valid priv-to-name-pres priv-to-name-charset
priv-to-num priv-to-num-valid priv-to-num-pres priv-to-num-plan
priv-to-subaddr priv-to-subaddr-valid priv-to-subaddr-type priv-to-subaddr-odd
priv-to-tag
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2030/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371120 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent change made it so that device state changes that were
not actual "changes" would not get reported to subscribers. The
problem was that this inadvertently blocked presence updates as
well.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@371113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Quote from review board:
This patch extends the extension state callbacks so that monitoring channels
(as chan_sip) get more information of the devices which are responsible for
an extension state change. The additional information is needed by chan_sip
to present names/numbers of the caller and callee in an early-state SIP
notification. Users of extenstion state callback not interested in the
additional information are not affected by the changes.
Motivation: to present the involved party's name/number in an early-state
nofification (used by the notified device as a pickup offer) one after another
so that a user can see which call he will pick up in an undirected pickup.
Such a pickup offer to a user shall indicate the same call (number/name-A calls
number/name-B) as the call which would be picked up when an undirected pickup
is executed.
Users interested in additional state info must use the new functions
ast_extension_state_add_extended() resp.
ast_extension_state_add_destroy_extended() to register an extended state
callback. When the callback is registered this way, an extra member
device_state_info of struct ast_state_cb_info is passed to the callback in
addition to the aggregated extension state. This container holds an object for
every device of the monitored extension hint consisting of the device name, the
device state and a channel reference to the channel which (presumably) caused
the device state.
The information is used by chan_sip for early-state notifications. When the
state of a device changes and the new state contains AST_EVENT_RINGING, an
early-state notification is sent to the subscribed devices with the
caller/callee names/numbers of the oldest ringing channel of the monitored
extension. The notified user may then invoke a direct pickup, which will pickup
exactly this channel.
Users of the old non-extended callbacks will only be called when the aggregated
state did change (same behavior as before). Users of the extended callback will
also be called when the state is unchanged but does contain AST_EVENT_RINGING.
That could be the case if two channels are ringing at one device and one of
them hangs up, so the aggregated state does not change. This way the monitoring
channel can create a new early-state notification with the now ringing
party-ids.
Review: https://reviewboard.asterisk.org/r/2048
This contribution comes from Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370979 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds named calledgroups/pickupgroups to Asterisk. Named groups are
implemented in parallel to the existing numbered callgroup/pickupgroup
implementation. However, unlike the existing implementation, which is limited
to a maximum of 64 defined groups, the number of defined groups allowed for
named callgroups/pickupgroups is effectively unlimited.
Named groups are configured with the keywords "namedcallgroup" and
"namedpickupgroup". This corresponds to the numbered group definitions of
"callgroup" and "pickupgroup". Note that as the implementation of named groups
coexists with the existing numbered implementation, a defined named group of
"4" does not equate to numbered group 4.
Support for the named groups has been added to the SIP, DAHDI, and mISDN channel
drivers.
Review: https://reviewboard.asterisk.org/r/2043
Uploaded by:
Guenther Kelleter(license #6372)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r370769 | mmichelson | 2012-08-03 16:35:00 -0500 (Fri, 03 Aug 2012) | 24 lines
Fix error in the "IPorHost" section of a SIP dialstring.
This is based on the review request posted by Walter Doekes
(referenced lower in the commit message)
The main fix here is to treat the IPorHost portion of the dial
string as a temporary outbound proxy. This ensures requests
get sent to the proper location.
Due to the age of the request, some parts were no longer relevant.
For instance, the request moved outbound proxy parsing code into
a single method. This is done in a previous commit, so it was not
necessary to do again.
Also, the review request fixed some errors with regards to request
routing for CANCEL and ACK requests. This has also been fixed in
more recent commits.
(closes issue ASTERISK-19677)
reported by Walter Doekes
Review https://reviewboard.asterisk.org/r/1859
........
r370770 | mmichelson | 2012-08-03 16:39:35 -0500 (Fri, 03 Aug 2012) | 3 lines
Remove unused variable.
........
r370771 | mmichelson | 2012-08-03 16:43:52 -0500 (Fri, 03 Aug 2012) | 5 lines
Seriously? Another compilation error fixed.
Somebody beat me.
........
Merged revisions 370769-370771 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370772 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the chan_sip cleanup went in, a typo was included that caused some
subscriptions of non-Polycom phones to be limited to the same
capabilities as Polycom phones. This resolves the failures in the test
suite resulting from this regression.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a patch from kkm from review board.
This is useful for adding headers to REFER requests that
emanate from a Transfer() dialplan application call.
This also fixes some uses of the Referred-by header, removing
an extra set of angle brackets.
I've modified the reporter's original patch to not require
any additions to the sip_refer header and to just remove the
referred_by_name from sip_refer since it is no longer needed
or used.
(closes Issue ASTERISK-17639)
reported by Kirill Katsnelson
Patches:
019059-sip-refer-addheaders-trunk-353549.diff
uploaded by Kirill Katsnelson (license #5845)
Review: https://reviewboard.asterisk.org/r/1159
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With a large number of SIP peers registered, performing a SIP reload causes a
flood of SIP OPTIONS request packets. These are immediately sent out, and, as
responses come back, can cause peers to be flagged as 'lagged' due to handling
of the many response messages.
This fix prevents this "packet storm" and schedules the pokes for a random
time. That time varies between 1 ms and the peer's qualify time, or, if
the qualify time is unknown, the global qualifyfreq setting.
The committed patch has some very small modifications to the patch schmidts
wrote for the review.
(closes issue ASTERISK-19154)
Reported by: Nicolo Mazzon
patches:
issue19154.patch license #6034 uploaded by schmidts
Review: https://reviewboard.asterisk.org/r/1652
........
Merged revisions 370666 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 370672 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370677 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This clean up was broken out from
https://reviewboard.asterisk.org/r/1976/ and addresses the following:
- struct sip_refer converted to use the stringfields API.
- sip_{refer|notify}_allocate -> sip_{notify|refer}_alloc to match
other *alloc functions.
- Replace get_msg_text, get_msg_text2 and get_pidf_body -> No, not
get_pidf_msg_text_body3 but get_content, to match add_content.
- get_body doesn't get the request body, renamed to get_content_line.
- get_body_by_line doesn't get the body line, and is just a simple if
test. Moved code inline and removed function.
- Remove camelCase in struct sip_peer peer state variables,
onHold -> onhold, inUse -> inuse, inRinging -> ringing.
- Remove camelCase in struct sip_request rlPart1 -> rlpart1,
rlPart2 -> rlpart2.
- Rename instances of pvt->randdata to pvt->nonce because that is what
it is, no need to update struct sip_pvt because _it already has a
nonce field_.
- Removed struct sip_pvt randdata stringfield.
- Remove useless (and inconsistent) 'header' suffix on variables in
handle_request_subscribe.
- Use ast_strdupa on Event header in handle_request_subscribe to avoid
overly complicated strncmp calls to find the event package.
- Move get_destination check in handle_request_subscribe to avoid
duplicate checking for packages that don't need it.
- Move extension state callback management in handle_request_subscribe
to avoid duplicate checking for packages that don't need it.
- Remove duplicate append_date prototype.
- Rename append_date -> add_date to match other add_xxx functions.
- Added add_expires helper function, removed code that manually added
expires header.
- Remove _header suffix on add_diversion_header (no other header adding
functions have this).
- Don't pass req->debug to request handle_request_XXXXX handlers if req
is also being passed.
- Don't pass req->ignore to check_auth as req is already being passed.
- Don't create a subscription in handle_request_subscribe if
p->expiry == 0.
- Don't walk of the back of referred_by_name when splitting string in
get_refer_info
- Remove duplicate check for no dialog in handle_incoming when
sipmethod == SIP_REFER, handle_request_refer checks for that.
Review: https://reviewboard.asterisk.org/r/1993/
Patch-by: gareth
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370636 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch was submitted by mnicholson a while back. It adds a new AMI action
which allows users to request SIP peer status on demand similar to existing
PeerStatus events and to the output you would see from CLI with sip show peer
Review: https://reviewboard.asterisk.org/r/1098/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370518 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The HANGUPCAUSE hash (trunk only) meant to replace SIP_CAUSE has now
been replaced with the HANGUPCAUSE and HANGUPCAUSE_KEYS dialplan
functions to better facilitate access to the AST_CAUSE translations
for technology-specific cause codes. The HangupCauseClear application
has also been added to remove this data from the channel.
(closes issue SWP-4738)
Review: https://reviewboard.asterisk.org/r/2025/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A number of applications/AMI commands in Asterisk have specific behavioral
differences depending on the resource or channel technology those
applications are executed on. For example, the MessageSend application/
command is technology agnostic, but how the channel drivers that support
that functionality behave is dependant on the protocols and channel
driver implementation. Prior to this patch, those details were either
documented in the application/command documentation itself, or were left
undocumented.
This patch adds a new element to the documentation schema, <info/>. An info
node is essentially a piece of technology specific reference information that
can be included by any top level XML documentation node. For example, the
MessageSend application can now include XMPP/SIP specific information, where
that technology specific information can be defined in chan_motif/res_xmpp/
chan_sip. Likewise, that information can also be included in the MessageSend
AMI command.
Review: https://reviewboard.asterisk.org/r/2049
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370278 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fix involves moving the allocation of some temporary codec structures to the heap and also reduces the number of maximum payloads to something more sane for both regular and low memory builds.
(closes issue ASTERISK-20140)
Reported by: jonnt
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@370171 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds Named ACL functionality to Asterisk. This allows system
administrators to define an ACL and refer to it by a unique name. Configurable
items can then refer to that name when specifying access control lists.
It also includes updates to all core supported consumers of ACLs. That includes
manager, chan_sip, and chan_iax2. This feature is based on the deluxepine-trunk
by Olle E. Johansson and provides a subset of the Named ACL functionality
implemented in that branch. For more information on this feature, see acl.conf
and/or the Asterisk wiki.
Review: https://reviewboard.asterisk.org/r/1978/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369959 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk now generates image stream declinations with the same
transport case that it used to before the stream declination
improvements. (udptl vs UDPTL)
(closes issue SWP-4736)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369900 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Commits r369557 and r369579 were done to improve handling of re-INVITEs
when the UA that was supposed to receive the re-INVITE fails to respond.
A limitation of those patches occurred when a UA sent a provisional
response to the re-INVITE. This triggered a sending of a BYE in
check_pending. This patch tweaks the handling of the re-INVITE such that
a BYE is not sent in response to those messages.
(issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies
patches:
(reinvite_tweak.diff license #5012 by Steve Davies)
........
Merged revisions 369626 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369627 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369628 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The basic problem is that if a re-INVITE is sent by Asterisk and it receives a
provisional response, but no final response, then the dialog is never torn
down. In addition to leaking memory, this also leaks file descriptors and will
eventually lead to Asterisk no longer being able to process calls.
This patch just keeps track of whether there is an outstanding re-INVITE, and if
there is goes ahead and cleans up everything as though there was no outstanding
reinvite.
Review: https://reviewboard.asterisk.org/r/2009/
(closes issue ASTERISK-19992)
Reported by: Steve Davies
Tested by: Steve Davies, Terry Wilson
........
Merged revisions 369436 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369437 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369449 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives an INVITE from an external domain when allowexternaldomains=no
send a 403 instead of a 404. This is consistent with Asterisk's behavior when receiving
a REGISTER in this situation.
(Closes issue ASTERISK-19601)
Reported by Matthew Jordan
Patches:
ASTERISK-19601-no401.patch uploaded by Mark Michelson (License #5049)
........
Merged revisions 369302 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369303 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The sendonly/recvonly/sendrecv/inactive media stream attributes were
parsed for video, but nothing was ever done with them. With this code
removed, an UNSUPPORTED message is produced when these attributes are
used in conjunction with a video stream which is the better behavior
since they were never really supported in the first place.
........
Merged revisions 369195 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369206 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk was incorrectly setting the destination of CANCELs
and ACKs for error responses to the URI of the initial INVITE.
This resulted in further requests, such as INVITEs with authentication
credentials, to be routed incorrectly. Instead, when these CANCEL
or ACKs are to be sent, we should simply keep the destination the
same as what it previously was. There is no need to alter it any.
(closes issue ASTERISK-20008)
Reported by Marcus Hunger
Patches:
ASTERISK-20008.patch uploaded by Mark Michelson (license #5049)
........
Merged revisions 369066 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 369067 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369068 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change replaces the static array of four representable media
streams with an AST_LIST so that chan_sip can keep track of offered
media streams. This allows chan_sip to deal with offers containing
multiple same-type streams and many other situations without rejecting
the SDP offer in its entirety, yet still generating a valid response.
This also covers cases where Asterisk can not comprehend the offer if
it is in the correct format.
Previously, chan_sip would reject SDP offers or entirely ignore
individual stream offers in an effort to be more compatible which
would often result in invalid SDP responses.
Review: https://reviewboard.asterisk.org/r/1988/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@369028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On incoming calls, we were setting the cid_tag on the dialog only if there was
no remote party information (Remote-Party-ID or P-Asserted-Identity) present.
The Caller ID tag is an invented parameter, though, and should be set no matter
the circumstance.
(closes issue ASTERISK-19859)
Reported by Thomas Arimont
(closes issue AST-884)
Reported by Trey Blancher
........
Merged revisions 368807 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368808 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r367163, "send to voicemail" functionality was added to the SIP channel
driver. This required updating the party redirecting information for the
channel based on the headers provided in the REFER request. When the
redirecting party information is updated on the channel, a call to
ast_indicate_data occurs. Because handle_request_refer still had the sip_pvt
locked, a deadlock could occur between the pbx_thread and the do_monitor thread
servicing the REFER request.
This patch preserves the proper locking order between the channel and the
sip_pvt by ensuring that the sip_pvt is unlocked prior to updating the party
redirecting information on the channel.
(closes issue AST-903)
Reported by: Matt Jordan
patches:
jira_ast_903_trunk.patch by rmudgett (license 5621)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368793 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ANI2 information is now parsed out of SIP From headers when present in
the oli, isup-oli, and ss7-oli parameters and is available via the
CALLERID(ani2) dialplan function.
(closes issue ASTERISK-19912)
Patch-by: Rob Gagnon
Review: https://reviewboard.asterisk.org/r/1947/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a dialog-starting INVITE contains a to-tag, then Asterisk
will respond with a 481. In this case, the resulting incoming
ACK would not be matched, so Asterisk would continue retransmitting
the 481 until the transaction times out.
There were two issues. Asterisk, upon creating a sip_pvt would generate
a local tag. However, when the time came to transmit the 481, since there
was a to-tag in the INVITE, Asterisk would place this original to-tag
in the 481 response. When the ACK came in, Asterisk would attempt to
match the to-tag in the ACK to the generated local tag. Unfortunately,
Asterisk never actually transmitted a response with the generated local
tag, so the to-tag in the ACK would not match.
The other problem was that when the 481 was sent, nothing was set
on the sip_pvt to indicate what CSeq is expected in the ACK.
To fix the first problem, we zero out the to-tag seen in the incoming
INVITE. This way, Asterisk, when time to send a response, will send
its generated local tag instead.
To fix the second problem, we set the sip_pvt's pendinginvite to the
CSeq of the INVITE when we send a 481.
(closes issue ASTERISK-19892)
Reported by Mark Michelson
........
Merged revisions 368625 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368629 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This was essentially duplicated functionality where normal channels used
AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used
AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage
into AST_CAUSE_ANSWERED_ELSEWHER usage.
Review: https://reviewboard.asterisk.org/r/1944
(closes issue ASTERISK-19865)
Patch-by: Birger Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 351130 broke corect HANGUPCAUSE setting
for the 404 case in chan_sip. Other cases were also
potentially broken. This patch fixes the relaying
of causes to be what they used to be.
(closes issue ASTERISK-19914)
Reported by Pavel Troller
Tested by Walter Doekes (via a reviewboard test to be committed later)
Patches:
chan_sip.diff uploaded by Pavel Troller (license #6302)
........
Merged revisions 368498 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368499 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Presence support has been added. This is accomplished by
allowing for presence hints in addition to device state
hints. A dialplan function called PRESENCE_STATE has been
added to allow for setting and reading presence. Presence
can be transmitted to Digium phones using custom XML
elements in a PIDF presence document.
Voicemail has new APIs that allow for moving, removing,
forwarding, and playing messages. Messages have had a new
unique message ID added to them so that the APIs will work
reliably. The state of a voicemail mailbox can be obtained
using an API that allows one to get a snapshot of the mailbox.
A voicemail Dialplan App called VoiceMailPlayMsg has been
added to be able to play back a specific message.
Configuration hooks have been added. Configuration hooks
allow for a piece of code to be executed when a specific
configuration file is loaded by a specific module. This is
useful for modules that are dependent on the configuration
of other modules.
chan_sip now has a public method that allows for a custom
SIP INFO request to be sent mid-dialog. Digium phones use
this in order to display progress bars when files are played.
Messaging support has been expanded a bit. The main
visible difference is the addition of an AMI action
MessageSend.
Finally, a ParkingLots manager action has been added in order
to get a list of parking lots.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk should not accept SDP offers that contain unknown RTP profiles (for
audio/video streams) or unknown top-level media types. When it does, it answers
with an SDP that does not match the offer properly, and this will nearly
always result in a broken call. This patch causes such offers to be rejected.
Review: https://reviewboard.asterisk.org/r/1811/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 'Unsupported media type' is only reported when that is in fact the case,
not when a supported media type is included in an 'm' line that has an
invalid format.
* All warning messages related to parsing 'm' lines now include the 'm' line contents.
* (minor bugfix) newline added to port-number-zero warning messages.
* Warning messages improved to use RFC-specified terminology for various items.
* Warnings for offers that include more than one port for a single media type now
include the media type.
Review: https://reviewboard.asterisk.org/r/1811/
........
Merged revisions 368218 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368267 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk servers are set up back-to-back, and
direct media is to be used betweeen endpoints, it is
fairly common for the two Asterisk servers to send
direct media reinvites to each other simultaneously.
This results in 491s and ACKs being exchanged between
the servers. While the media eventually gets set up
properly, the problem is that there can be a noticeable
delay for the streams to stabilize.
This patch adds a new directmedia option called "outgoing".
With this set, an immediate direct media reinvite will only
be sent if the call direction is outgoing. For incoming
dialogs, an immediate direct media reinvite will not be sent,
but further "reactionary" direct media reinvites may be sent.
Review: https://reviewboard.asterisk.org/r/1954
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pvt_sip allowtransfer was not being set to that of the peer's setting.
Therefore, the global allowtransfer setting was being used instead which would
lead to calls not being transfered if the global setting was set to 'no' despite
the setting on the peer being 'yes' and vice versa, calls would be allowed to
transfer even if the peer's setting was 'no' but the global setting was 'yes'.
(Closes issue ASTERISK-19856)
Reported by: Jacek
Tested by: Michael L. Young, Jacek
Patches:
issue-asterisk-19856-branch10-v3.diff uploaded by
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1923/
........
Merged revisions 367730 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367731 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When remotely bridging calls with directmedia, Asterisk would check
the address of the peers/users holding directmedia ACLs (set via
directmediapermit/directmediadeny) instead of the bridged peer. This
is similar to r366547, but trunk specific and involves changes to
the rtpengine instead of just chan_sip.
(closes issue AST-876)
review: https://reviewboard.asterisk.org/r/1924/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, MWI logic utilized a counter called 'lastmsgssent' to know whether
or not MWI NOTIFY requests had been sent to a specific peer. When MWI
notifications were changed to use the internal event framework, this value was
no longer needed for its original purpose. Hence, it was no longer updated
with the new/old message counts for a peer. The value was previously removed
for Asterisk 10; however, since it was still present in Asterisk 1.8 and still
useful for reporting purposes, it was decided to re-add the value.
This patch re-adds the 'LastMsgsSent' field in the response to an AMI/CLI 'sip
show peer [peer]' command, and makes it so that the value of lastmsgssent is
updated appropriately. The value should now display the new/old message counts
for a particular peer.
(closes issue ASTERISK-17866)
Reported by: Steve Davies
patches by:
ast-17866-rb1272.patch (License #5041 by irroot)
Modified slightly for this commit
Review: https://reviewboard.asterisk.org/r/1939
........
Merged revisions 367362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367369 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change accommodates two methods by which calls can be directed to
a user's voicemail.
* Incoming calls can be redirected to any user's voicemail.
* Established calls can be blind transferred to any user's voicemail.
Digium phones indicate the desire to direct a call to voicemail by using
a Diversion header with a reason parameter of "send_to_vm".
This patch adds the "send_to_vm" reason as a valid redirecting reason. In
addition, chan_sip.c has been modified to update redirecting information
on the transferred channel by reading a Diversion header on a REFER request.
(closes issue AST-871)
Reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/1925
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SSL_CTX structures were allocated but never freed. This was a bigger
issue for clients than servers since new SSL_CTX structures could be
allocated for each connection. Servers, on the other hand, typically
set up a single SSL_CTX for their lifetime.
This is solved in two ways:
1. In __ssl_setup(), if a tcptls_cfg has an ssl_ctx on it, it is
freed so that a new one can take its place.
2. A companion to ast_ssl_setup() called ast_ssl_teardown() has
been added so that servers can properly free their SSL_CTXs.
(issue ASTERISK-19278)
........
Merged revisions 367002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367003 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds to what was fixed in r366880. Specifically, it addresses the
following:
* chan_sip: dispose of an allocated frame in off nominal code paths in
sip_rtp_read
* func_odbc: when disposing of an allocated resultset, ensure that any rows
that were appended to that resultset are also disposed of
* cli: free the created return string buffer in another off nominal code
path
* chan_dahdi: free a frame that was allocated by the dsp layer if we choose
not to process that frame
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
........
Merged revisions 366944 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366948 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch improves the handling of call id logging significantly with regard
to transfers and adding APIs to better handle specific aspects of logging.
Also, changes have been made to chan_sip in order to better handle the creation
of callids and to enable the monitor thread to bind itself to a particular
call id when a dialog is determined to be related to a callid. It then unbinds
itself before returning to normal monitoring.
review: https://reviewboard.asterisk.org/r/1886/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To make a long story short, reinvite glares were broken
because Asterisk would invert the To and From headers
when ACKing a 491 response.
The reason was because the initreq of the dialog was being
changed to the incoming glared reinvite instead of being
set to the outgoing glared reinvite. This change has three
parts
* In handle_incoming, we never will reject an ACK because it
has a to-tag present, even if we think the request may be out
of dialog.
* In handle_request_invite, we do not change the initreq when
receiving a reinvite to which we will respond with a 491.
* In handle_request_invite, several superflous settings up
pendinginvite have been removed since this is dones automatically
by transmit_response_reliable
Review: https://reviewboard.asterisk.org/r/1911
........
Merged revisions 366389 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366390 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves core findings from ASTERISK-19650 numbers 0-2, 6, 7, 9-11, 14-20,
22-24, 28, 30-32, 34-36, 42-56, 82-84, 87, 89-90, 93-102, 104, 105, 109-111,
and 115. Finding numbers 26, 33, and 29 were already resolved. Those skipped
were either extended/deprecated or in areas of code that shouldn't be
disturbed.
(Closes issue ASTERISK-19650)
........
Merged revisions 366167 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366168 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip was coded under the assumption that a SIP dialog with an owner channel
will always be destroyed after the owner channel has been hung up.
However, there are situations where the SIP dialog can time out and auto destruct
before the corresponding channel has hung up. A typical example of this would be
if the 'h' extension in the dialplan takes a long time to complete. In such cases,
__sip_autodestruct() would complain about the dialog being auto destroyed with
an owner channel still in place. The problem is that even once the owner channel
was hung up, the sip_pvt would still be linked in its ao2_container because nothing
would ever unlink it.
The fix for this is that if __sip_autodestruct() is called for a sip_pvt that still
has an owner channel in place, the destruction is rescheduled for 10 seconds in the
future. This will continue until the owner channel is finally hung up.
(closes issue ASTERISK-19425)
reported by David Cunningham
Patches:
ASTERISK-19425.patch uploaded by Mark Michelson (License #5049)
(closes issue ASTERISK-19455)
reported by Dean Vesvuio
Tested by Dean Vesvuio
........
Merged revisions 365896 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365898 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the calling channel's caller ID and connected line information
to populate the remote and local identities in the dialog-info NOTIFY when
an extension is ringing.
There is a bit of an oddity here, and that is that we seed the remote target
with the To header of the outbound call rather than the from header. This
is because it was reported that seeding with the from header caused hints
to be broken with certain SNOM devices. A comment has been added to the code
to explain this.
(closes issue ASTERISK-16735)
reported by Maciej Krajewski
patches:
local_remote_hint2.diff uploaded by Mark Michelson (license #5049)
16735_tweak1.diff uploaded by Mark Michelson (license #5049)
Tested by Niccolo Belli
........
Merged revisions 365574 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365575 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the changes here are trivial NULL checks. There are a couple
optimizations to remove the need to check for NULL and outboundproxy parsing
in chan_sip.c was rewritten to avoid use of strtok. Additionally, a bug was
found and fixed with the parsing of outboundproxy when "outboundproxy=," was
set.
(Closes issue ASTERISK-19654)
........
Merged revisions 365398 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365399 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reason I'm removing this is that Coverity reported a STRAY_SEMICOLON
issue here. Since the function has been unused for so long, I just elected
to remove it altogether.
(closes issue ASTERISK-19660)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 360862 was intended to improve identities sent in dialog-info
NOTIFY requests. Some users reported that hint became broken once this
was done. It's not clear exactly what part of the patch has caused this
regression, but broken hints are bad.
For now, this revision is being reverted so that the next releases of
Asterisk do not have bad behavior in them. The original reported issue
will have to be fixed differently in the next version of Asterisk.
(issue ASTERISK-16735)
........
Merged revisions 364706 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364707 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If enabled using the keepalive option in sip.conf a small packet will be sent
at a regular interval to keep the NAT mapping open. This is lightweight as the
remote side does not need to parse and handle a SIP message.
(closes issue AST-783)
Review: https://reviewboard.asterisk.org/r/1756/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unref the SIP pvt stored in the refer structure as soon as it is no longer
needed so that the pvt and associated file descriptors can be freed sooner.
This change makes a reference decrement unnecessary in code that handles SIP
BYE/Also transfers which should not touch the reference anyway.
(Closes issue ASTERISK-19579)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
........
Merged revisions 364258 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364259 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog. This can occur, for example, when
certain phones request a SIP hold.
Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored. This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.
(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Review: https://reviewboard.asteriskorg/r/1885/
........
Merged revisions 364203 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364204 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reference held for SIP blind transfers using the Replaces header in an
INVITE was never freed on success and also failed to be freed in some error
conditions. This caused a file descriptor leak since the RTP structures in use
at the time of the transfer were never freed. This reference leak and another
relating to subscriptions in the same code path have now been corrected.
(closes issue ASTERISK-19579)
........
Merged revisions 363986 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363987 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363988 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If Asterisk receives a SIP UPDATE request after a call has been terminated and
the channel has been destroyed but before the SIP dialog has been destroyed, a
condition exists where a connected line update would be attempted on a
non-existing channel. This would cause Asterisk to crash. The patch resolves
this by first ensuring that the SIP dialog has an owning channel before
attempting a connected line update. If an UPDATE request is received and no
channel is associated with the dialog, a 481 response is sent.
(closes issue ASTERISK-19770)
Reported by: Thomas Arimont
Tested by: Matt Jordan
Patches:
ASTERISK-19278-2012-04-16.diff uploaded by Matt Jordan (license 6283)
........
Merged revisions 363106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363107 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bind address is set to an ANY address (udpbindport=::), a warning message
is displayed stating that "Address remapping activated in sip.conf but we're
using IPv6, which doesn't need it. Please remove 'localnet' and/or 'externaddr'
settings." But if one is running dual stack, we shouldn't be told to turn those
settings off.
This patch checks if the bind address is an ANY address or not. The warning
message will now only be displayed if the bind address is NOT an ANY address and
IPv6 is being used.
Also, updated the copyright year.
(closes issue ASTERISK-19456)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
chan_sip_ipv6_message.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 362253 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362264 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes use of connected party information in addition to caller ID in order
to populate local and remote XML elements in the dialog-info NOTIFYs.
(closes issue ASTERISK-16735)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
Patches:
local_remote_hint2.diff uploaded by Mark Michelson (license 5049)
........
Merged revisions 360862 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360863 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk detects a hangup and cannot send a BYE due to a pending
INVITE, it sets the pendingbye flag and waits for the final response to that
INVITE. When the response is received, it transmits the BYE. If, however,
that INVITE request is a pending re-INVITE, it needs to first send a CANCEL
request to terminate the pending re-INVITE. In that circumstance, Asterisk
was, in some scenarios, clearing the pendingbye flag after processing the
CANCEL request and not checking for a pending BYE when receiving the final
487 response to the INVITE.
This patch ensures that if the pendingbye flag is set, it is honored
regardless of the nature of the INVITE request currently in flight.
(closes issue ASTERISK-19365)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
bugASTERISK-19365_2012_03_08.patch uploaded by mjordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1807
........
Merged revisions 360086 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360088 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Using "transport=" multiple times would cause them to add to one
another like allow/deny. This patch changes that behavior to simply use the transport
option specified last. Also, if no transport option is applied now, the default will
automatically be UDP.
(closes ASTERISK-19352)
Reported by: jamicque
Patches:
asterisk-19352-transport-warning-message-v1.patch uploaded by Michael L. Young (license 5026)
issueA19352_no_transport_is_udp.patch uploaded by Walter Doekes (license 5674)
Review: https://reviewboard.asterisk.org/r/1745/diff/#index_header
........
Merged revisions 357266 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 357271 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@357288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
send_diversion=no will prevent Diversion headers from being added to SIP
requests. This doesn't prevent Diversion from being added with dialplan
such as with SIPAddHeader.
(closes issue ASTERISK-16862)
Reported by: rsw686
Review: https://reviewboard.asterisk.org/r/1769/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356987 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Custom parking extensions may not be coded such that the first and only
extension priority is the Park application. These custom parking
extensions will not be recognized as parking extensions. When a call is
blind transferred to an extension that is not recognized as a parking
extension, the normal blind transfer code causes the transferred channel
to start executing dialplan. Calls that get parked in this manner do not
know the original channel name that parked the call so the original parker
could never be called back if the parked call is not retrieved before the
timeout time. The parking space is also announced to the call being
parked as a side effect of not knowing the original parking channel.
* Fix handling of BLINDTRANSFER channel variable for call parking.
* Fixed SIP blind transfer using the wrong dialplan context variable to
check for the parking extension.
(closes issue ASTERISK-19322)
Reported by: aragon
Tested by: rmudgett, jparker
Review: https://reviewboard.asterisk.org/r/1730/
JIRA AST-766
........
Merged revisions 356521 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 356522 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we send an ACK for a 2xx response to an INVITE, we are supposed
to use the learned route set. However, when we receive a non-2xx final
response to an INVITE, we are supposed to send the ACK to the same place
we initially sent the INVITE.
We had been doing this up until the changes went in that would build a route
set from provisional responses. That introduced a regression where we would
use the learned route set under all circumstances.
With this change, we now will set the destination of our ACK based on the
invitestate. If it is INV_COMPLETED then that means that we have received
a non-2xx final response (INV_TERMINATED indicates a 2xx response was received).
If it is INV_CANCELLED, then that means the call is being canceled, which
means that we should be ACKing a 487 response.
The other change introduced here is setting the invitestate to INV_CONFIRMED
when we send an ACK *after* the reqprep instead of before. This way, we can
tell in reqprep more easily what the invitestate is prior to sending the ACK.
(closes issue ASTERISK-19389)
reported by Karsten Wemheuer
patches:
ASTERISK-19389v2.patch uploaded by Mark Michelson (license #5049)
(with some slight modifications prior to commit)
........
Merged revisions 356475 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 356476 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356477 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r356215 | mjordan | 2012-02-22 08:53:53 -0600 (Wed, 22 Feb 2012) | 32 lines
Merged revisions 356214 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r356214 | mjordan | 2012-02-22 08:50:20 -0600 (Wed, 22 Feb 2012) | 27 lines
Fix potential buffer overrun and memory leak when executing "sip show peers"
The "sip show peers" command uses a fix sized array to sort the current peers
in the peers ao2_container. The size of the array is based on the current
number of peers in the container. However, once the size of the array is
determined, the number of peers in the container can change, as the peers
container is not locked. This could cause a buffer overrun when populating
the array, if peers were added to the container after the array was created.
Additionally, a memory leak of the allocated array would occur if a user
caused the _show_peers method to return CLI_SHOWUSAGE.
We now create a snapshot of the current peers using an ao2_callback with the
OBJ_MULTIPLE flag. This size of the array is set to the number of peers
that the iterator will iterate over; hence, if peers are added or removed
from the peers container it will not affect the execution of the "sip show
peers" command.
Review: https://reviewboard.asterisk.org/r/1738/
(closes issue ASTERISK-19231)
(closes issue ASTERISK-19361)
Reported by: Thomas Arimont, Jamuel Starkey
Tested by: Thomas Arimont, Jamuel Starkey
Patches: sip_show_peers_2012_02_16.diff uploaded by mjordan (license 6283)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@356216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes two main issues:
1. Asterisk would send a CANCEL to the route created by the provisional response
instead of using the same destination it did in the initial INVITE.
2. If a new route set arrives in a 200 OK than was in the 1XX response (perfectly
possible if our outbound INVITE gets forked), then the route set in the 200 OK
needs to overwrite the route set in the 1XX response.
(closes issue ASTERISK-19358)
Reported by: Karsten Wemheuer
Tested by: Karsten Wemheuer
patches:
ASTERISK-19358.patch uploaded by Mark Michelson (license 5049)
ASTERISK-19358.patch uploaded by Stefan Schmidt (license 6034)
Review: https://reviewboard.asterisk.org/r/1749
........
Merged revisions 355732 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 355733 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@355745 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds the auto_force_rport and auto_comedia NAT options. It
also converts the nat= setting to a list of comma-separated combinable
options: no, force_rport, comedia, auto_force_rport, and auto_comedia.
nat=yes remains as an undocumented option equal to
"force_rport,comedia". The first instance of 'yes' or 'no' in the list
stops parsing and overrides any previously set options. If an auto_*
option is specified with its non-auto_ counterpart, the auto setting
takes precedence.
This patch builds upon the patch posted to ASTERISK-17860 by JIRA user
pedro-garcia.
(closes issue ASTERISK-17860)
Review: https://reviewboard.asterisk.org/r/1698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-18924, SIP INFO DTMF handlingw as changed to account for both
lowercase alphatbetic DTMF events, as well as uppercase alphabetic DTMF
events. When this occurred, the comparison of the character buffer containing
the event code was changed such that the buffer was first compared again '0'
and '9' to determine if it was numeric. Unfortunately, since the first
character in the buffer will typically be '1' in the case of non-numeric
event codes (10-16), this caused those codes to be converted to a DTMF event
of '1'. This patch fixes that, and cleans up handling of both
application/dtmf-relay and application/dtmf content types.
Review: https://reviewboard.asterisk.org/r/1722/
(closes issue ASTERISK-19290)
Reported by: Ira Emus
Tested by: mjordan
........
Merged revisions 354542 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 354543 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is based on the one by David Vossel, developer extrodinaire, at
https://reviewboard.asterisk.org/r/344/. If multiple peers are defined with the
same host/port, but differing callbackextensions, it chooses the peer with the
matching callbackextension. Since callbackextension creates an outbound
registration with the callbackextension as the Contact address, matching an
incoming request by that (in addition to the host/port) makes a lot of sense.
This patch also adds support for callbackextension to realtime by querying all
peers with callbackextensions on reload and adding registrations for them.
(closes issue ASTERISK-13456)
Review: https://reviewboard.asterisk.org/r/344/
Review: https://reviewboard.asterisk.org/r/1717/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354458 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After R340970 Asterisk was still polling the RTCP file descriptor after RTCP is
shut down and removed. If the descriptor happened to have data ready when the
removal occured then Asterisk would go into an infinite loop trying to read
data that it can never actually access. This change disables the audio RTCP
file descriptor for the duration of the T.38 transaction.
(closes issue ASTERISK-18951)
Reported-by: Kristijan Vrban
........
Merged revisions 353915 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353916 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A previous patch I committed from ASTERISK-16930 unexpectedly changed some output for
the AMI action "sippeers" which this patch changes back. Also, this aligns the output
for the cli command "sip show peers" and fixes another issue that patch introduced by
using ast_sockaddr_stringify calls multiple times without immediately using the pointer.
I also went ahead and did a little janitorial work to clean up whitespace in
_sip_show_peers.
(issue ASTERISK-16930)
(closes issue ASTERISK-19281)
Reported by: Patrick El Youssef
Patches:
ASTERISK-19281.diff uploaded by Walter Doekes (license 5674)
........
Merged revisions 353769 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353771 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are a number of cleaner looking wrappers for ast_sockaddr_stringify_fmt
available which are slightly more readable than using a direct call to
ast_sockaddr_stringify_fmt. This patch switches a number of those calls in
chan_sip to use those wrappers and is generally harmless.
(Closes issue ASTERISK-16930)
Reported by: Michael L. Young
Patches:
chan_sip-broken-registration-1.8.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 353720 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353721 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353725 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk's dnsmgr currently takes a pointer to an ast_sockaddr and updates it
anytime an address resolves to something different. There are a couple of
issues with this. First, the ast_sockaddr is usually the address of an
ast_sockaddr inside a refcounted struct and we never bump the refcount of those
structs when using dnsmgr. This makes it possible that a refresh could happen
after the destructor for that object is called (despite ast_dnsmgr_release
being called in that destructor). Second, the module using dnsmgr cannot be
aware of an address changing without polling for it in the code. If an action
needs to be taken on address update (like re-linking a SIP peer in the
peers_by_ip table), then polling for this change negates many of the benefits
of having dnsmgr in the first place.
This patch adds a function to the dnsmgr API that calls an update callback
instead of blindly updating the address itself. It also moves calls to
ast_dnsmgr_release outside of the destructor functions and into cleanup
functions that are called when we no longer need the objects and increments the
refcount of the objects using dnsmgr since those objects are stored on the
ast_dnsmgr_entry struct. A helper function for returning the proper default SIP
port (non-tls vs tls) is also added and used.
This patch also incorporates changes from a patch posted by Timo Teräs to
ASTERISK-19106 for related dnsmgr issues.
(closes issue ASTERISK-19106)
Review: https://reviewboard.asterisk.org/r/1691/
........
Merged revisions 353371 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353397 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353418 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r353321 | alecdavis | 2012-01-31 11:16:22 +1300 (Tue, 31 Jan 2012) | 25 lines
Merged revisions 353320 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r353320 | alecdavis | 2012-01-31 10:57:49 +1300 (Tue, 31 Jan 2012) | 18 lines
RFC3261 Section 8.1.1.5. The sequence number value MUST be expressible as a 32-bit unsigned integer
* fix: use %u instead of %d when dealing with CSeq numbers - to remove possibility of -ve numbers.
* fix: change all uses of seqno and friends (ocseq icseq) from 'int' or 'unsigned int' to uint32_t.
Summary of CSeq numbers.
An initial CSeq number must be less than 2^31
A CSeq number can increase in value up to 2^32-1
An incrementing CSeq number must not wrap around to 0.
Tested with Asterisk 1.8.8.2 with Grandstream phones.
alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1699/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, if an m-line in an SDP offer or answer had a port number of zero,
that line was skipped, and resulted in an 'Unsupported SDP media type...'
warning message. This was misleading, as the media type was not unsupported,
but was ignored because the m-line indicated that the media stream had been
rejected (in an answer) or was not going to be used (in an offer).
........
Merged revisions 353260 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 353261 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@353262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r352863 | alecdavis | 2012-01-27 13:08:03 +1300 (Fri, 27 Jan 2012) | 19 lines
Merged revisions 352862 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r352862 | alecdavis | 2012-01-27 13:05:30 +1300 (Fri, 27 Jan 2012) | 12 lines
rfc4235 - Section 4.1: Versions MUST be representable using a non-negative 32 bit integer.
If a BLF subscription exists for long enough, using %d may print negative version numbers.
Unlikely, as 2^32 at 1 update per second is ~137 years, or half that before the versions number started going negative.
Tested with Asterisk 1.8.8.2 with Grandstream phones.
alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/1694/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352864 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For whatever reason, we don't have a single function for copying data like this
from SIP peers to the SIP pvt. This patch adds the copying of amaflags to the
sip_pvt, but it would probably be worth discussing this function along with
the others that essentially just copy some amount of data from a peer to a
private.
(Closes issue ASTERISK-19029)
Reported by: Matt Lehner
........
Merged revisions 352755 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 352756 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix authenticate MESSAGE losing custom headers added by the MESSAGE_DATA
function in the authorization attempt.
* Pass up better From header contents for SIP to use. Now is in the
"display-name" <URI> format expected by MessageSend. (Note that this is a
behavior change that could concievably affect some people.)
* Block user from adding standard headers that are added automatically.
(To, From,...)
* Allow the user to override the Content-Type header contents sent by
MessageSend.
* Decrement Max-Forwards header if the user transferred it from an
incoming message.
* Expand SIP short header names so the dialplan and other code only has to
deal with the full names.
* Documents what SIP expects in the MessageSend(from) parameter.
(closes issue ASTERISK-18992)
Reported by: Yuri
(closes issue ASTERISK-18917)
Reported by: Shaun Clark
Review: https://reviewboard.asterisk.org/r/1683/
........
Merged revisions 352520 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352538 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Continue channel opaque-ification by wrapping all of the stringfields.
Eventually, we will restrict what can actually set these variables, but
the purpose for now is to hide the implementation and keep people from
adding code that directly accesses the channel structure. Semantic
changes will follow afterward.
Review: https://reviewboard.asterisk.org/r/1661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a blind transfer were initiated using a REFER without a prior
reINVITE to place the call on hold, AND if Asterisk were sending
RTCP reports, then there was a reference for the RTP instance
of the transferer.
This fixes the issue by merging two similar but slightly conflicting
sections of code into a single area. It also adds a stop_media_flows()
call in the case that the transferer's UA never sends a BYE to us
like it is supposed to.
(issue ASTERISK-19192)
Review: https://reviewboard.asterisk.org/r/1681/
........
Merged revisions 352014 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 352015 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@352018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add an AMI event in the Call category that is issued when a call is terminated
due to either RTP stream inactivity or SIP session timer expiration.
Event description:
Event: SessionTimeout
Source: source
Channel: channel-name
Uniqueid: channel-unique-id
`source` can be either RTPTimeout or SIPSessionTimer
(closes issue ASTERISK-16467)
Patch-by: Kirill Katsnelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix corner cases in get_calleridname() parsing and ensure that the
output buffer is nul terminated.
* Make get_calleridname() truncate the name it parses if the given buffer
is too small rather than abandoning the parse and not returning anything
for the name. Adjusted get_calleridname_test() unit test to handle the
truncation change.
* Fix get_in_brackets_test() unit test to check the results of
get_in_brackets() correctly.
* Fix parse_name_andor_addr() to not return the address of a local buffer.
This function is currently not used.
* Fix potential NULL pointer dereference in sip_sendtext().
* No need to memset(calleridname) in check_user_full() or tmp_name in
get_name_and_number() because get_calleridname() ensures that it is nul
terminated.
* Reply with an accurate response if get_msg_text() fails in
receive_message(). This is academic in v1.8 because get_msg_text() can
never fail.
........
Merged revisions 351618 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351646 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351667 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a Contact or a Record-Route header had a quoted string with an
item in angle brackets, then we would mis-parse it. For instance,
"Bob <1234>" <1234@example.org>
would be misparsed as having the URI "1234"
The fix for this is to use parsing functions from reqresp_parser.h
since they are heavily tested and are awesome.
(issue ASTERISK-18990)
........
Merged revisions 351284 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351286 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r351183 | russell | 2012-01-16 20:43:19 -0500 (Mon, 16 Jan 2012) | 29 lines
Merged revisions 351182 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r351182 | russell | 2012-01-16 20:37:03 -0500 (Mon, 16 Jan 2012) | 22 lines
Add some missing locking in chan_sip.
This patch adds some missing locking to the function
send_provisional_keepalive_full(). This function is called from the scheduler,
which is processed in the SIP monitor thread. The associated channel (or pbx)
thread will also be using the same sip_pvt and ast_channel so locking must be
used. The sip_pvt_lock_full() function is used to ensure proper locking order
in a safe manner.
In passing, document a suspected reference counting error in this function.
The "fix" is left commented out because when the "fix" is present, crashes
occur. My theory is that fixing it is exposing a reference counting error
elsewhere, but I don't know where. (Or my analysis of this being a problem
could have been completely wrong in the first place). Leave the comment in
the code for so that someone may investigate it again in the future.
Also add a bit of doxygen to transmit_provisional_response().
(closes issue ASTERISK-18979)
Review: https://reviewboard.asterisk.org/r/1648
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351184 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling a non-2xx final response on an INVITE transaction, we have to
keep the transaction around after we send an ACK in case we receive a
retransmission of the response so we can re-transmit the ACK, but also tear
down the ast_channel as soon as we transmit the ACK. Before this patch, we
could fail at both of these things. Calling sip_alreadygone/needdestroy
prevented us from keeping the transaction up and retransmitting the ACK, and
queueing CONGESTION was not sufficient to cause the channel to be torn down
when originating calls via the CLI, for example.
This patch queues a hangup with CONGESTION instead of just queueing CONGESTION
for these responses and removes the sip_alreadygone and sip_needdestroy calls
from handle_response_invite on non-2xx responses. It relies on the hangup
calling sip_scheddestroy.
For more information, see section 17.1.1.1 of RFC 3261.
(closes issue ASTERISK-17717)
Review: https://reviewboard.asterisk.org/r/1672/
........
Merged revisions 351130 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351131 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk is the UAS (incoming call, endpoint is re-inviting) the SIP session timer expires after half the time the sip endpoint indicates in the Session-expires header in proc_session_timer(). The session timer was being stopped totally and being handled as an error case instead of running again until the second expiry. This patch treats the half-time expiry as a non-error case and continues the timer until the true expiry.
(closes issue ASTERISK-18996)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches: session_timer_fix.diff by Terry Wilson (License #5357)
based on session_timer.patch by Thomas Arimont (License #5525)
........
Merged revisions 351080 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351081 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, the udptl struct was allocated and initialized when a
dialog was associated with a peer that supported T.38, when a new SIP
channel was allocated, or what an INVITE request was received. This resulted
in any dialog associated with a peer that supported T.38 having udptl support
assigned to it, including the UDP ports needed for communication. This
occurred even in non-INVITE dialogs that would never send image media.
This patch creates and initializes the udptl structure only when the SDP
for a dialog specifies that image media is supported, or when Asterisk
indicates through the appropriate control frame that a dialog is to support
T.38.
(closes issue ASTERISK-16698)
Reported by: under
Tested by: Stefan Schmidt
Patches: udptl_20120113.diff uploaded by mjordan (License #6283)
(closes issue ASTERISK-16794)
Reported by: Elazar Broad
Tested by: Stefan Schmidt
review: https://reviewboard.asterisk.org/r/1668/
........
Merged revisions 351027 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 351028 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@351029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are many benefits to making the ast_channel an opaque handle, from
increasing maintainability to presenting ways to kill masquerades. This patch
kicks things off by taking things a field at a time, renaming the field to
'__do_not_use_${fieldname}' and then writing setters/getters and converting the
existing code to using them. When all fields are done, we can move ast_channel
to a C file from channel.h and lop off the '__do_not_use_'.
This patch sets up main/channel_interal_api.c to be the only file that actually
accesses the ast_channel's fields directly. The intent would be for any API
functions in channel.c to use the accessor functions. No more monkeying around
with channel internals. We should use our own APIs.
The interesting changes in this patch are the addition of
channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to
channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to
use accessor functions when ast_channel is really opaque), and some re-working
of the way channel iterators/callbacks are handled so as to avoid creating fake
ast_channels on the stack to pass in matching data by directly accessing fields
(since "name" is a stringfield and the fake channel doesn't init the
stringfields, you can't use the ast_channel_name_set() function). I went with
ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a
setter.
The majority of the grunt-work for this change was done by writing a semantic
patch using Coccinelle ( http://coccinelle.lip6.fr/ ).
Review: https://reviewboard.asterisk.org/r/1655/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adds two new options to SIP peers allowing them to specify features (dynamic or builtin)
to use when sending INFO/record requests. Recordonfeature activates whatever feature
is specified when recieving a record: on request while recordofffeature activates
whatever feature is specified when receiving a record: off request. Both of these
features can be disabled by setting the feature to an empty string.
(closes issue ASTERISK-16507)
Reported by: Jon Bright
Review: https://reviewboard.asterisk.org/r/1634/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves destruction of sip peers to immediately after the general section of
sip.conf is read so that autocreatepeer setting can be read before deletion of peers.
If autocreatepeer=persist at reload, then peers created by the autocreatepeer setting
will be skipped when purging the current SIP peer list.
(closes ASTERISK-16508)
Reported by: Kirill Katsnelson
Patches:
017797-kkm-persist-autopeers-1.8.patch uploaded by Kirill Katsnelson (license 5845)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@349097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Chan_sip gives a dialog reference to the extension state callback and
assumes that when ast_extension_state_del() returns, the callback cannot
happen anymore. Chan_sip then reduces the dialog reference count
associated with the callback. Recent changes (ASTERISK-17760) have
resulted in the potential for the callback to happen after
ast_extension_state_del() has returned. For chan_sip, this could be very
bad because the dialog pointer could have already been destroyed.
* Added ast_extension_state_add_destroy() so chan_sip can account for the
sip_pvt reference given to the extension state callback when the extension
state callback is deleted.
* Fix pbx.c awkward statecbs handling in ast_extension_state_add_destroy()
and handle_statechange() now that the struct ast_state_cb has a destructor
to call.
* Ensure that ast_extension_state_add_destroy() will never return -1 or 0
for a successful registration.
* Fixed pbx.c statecbs_cmp() to compare the correct information. The
passed in value to compare is a change_cb function pointer not an object
pointer.
* Make pbx.c ast_merge_contexts_and_delete() not perform callbacks with
AST_EXTENSION_REMOVED with locks held. Chan_sip is notorious for
deadlocking when those locks are held during the callback.
* Removed unused lock declaration for the pbx.c store_hints list.
(closes issue ASTERISK-18844)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/1635/
........
Merged revisions 348940 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 348952 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@348953 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch resolves the issue where MWI subscriptions are orphaned
by subsequent SIP SUBSCRIBE messages. When a peer is removed, either
by pruning realtime SIP peers or by unloading / loading chan_sip, the
MWI subscriptions that were orphaned would still be on the event engine
list of valid subscriptions but have a pointer to a peer that no longer
was valid. When an MWI event would occur, this would cause a seg fault.
(closes issue ASTERISK-18663)
Reported by: Ross Beer
Tested by: Ross Beer, Matt Jordan
Patches:
blf_mwi_diff_12_06_11.txt uploaded by Matt Jordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1610/
........
Merged revisions 347058 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 347068 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@347069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code that allowed admins to create users with domain-only uri's had
stopped to work in 1.8 because of the reqresp parser rewrites. This is
fixed now: if you have a [mydomain.com] sip user, you can register with
useraddr sip:mydomain.com. Note that in that case -- if you're using
domain ACLs (a configured domain list) -- mydomain.com must be in the
allow list as well.
Reviewboard r1606 shows a list of registration combinations and which
SIP response codes are returned.
Review: https://reviewboard.asterisk.org/r/1533/
Reviewed by: Terry Wilson
(closes issue ASTERISK-18389)
(closes issue ASTERISK-18741)
........
Merged revisions 346899 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 346900 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346901 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The previous patch (r346040) incorrectly parsed the URI in the presence
of a port, e.g., user@hostname:port would fail as the port would be
double appended to the SIP message. This patch uses the parse_uri function
to correctly parse the URI into its username and hostname parts, and places
them in the correct fields in the sip_pvt structure.
(issue ASTERISK-18903)
Review: https://reviewboard.asterisk.org/r/1597/
........
Merged revisions 346856 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346857 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cleaning up chan_sip/tcptls file descriptor closing.
This patch attempts to eliminate various possible instances of undefined behavior caused
by invoking close/fclose in situations where fclose may have already been issued on a
tcptls_session_instance and/or closing file descriptors that don't have a valid index
for fd (-1). Thanks for more than a little help from wdoekes.
(closes issue ASTERISK-18700)
Reported by: Erik Wallin
(issue ASTERISK-18345)
Reported by: Stephane Cazelas
(issue ASTERISK-18342)
Reported by: Stephane Chazelas
Review: https://reviewboard.asterisk.org/r/1576/
........
Merged revisions 346564 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 346565 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch attempts to eliminate various possible instances of undefined behavior caused
by invoking close/fclose in situations where fclose may have already been issued on a
tcptls_session_instance and/or closing file descriptors that don't have a valid index
for fd (-1). Thanks for more than a little help from wdoekes.
(closes issue ASTERISK-18700)
Reported by: Erik Wallin
(issue ASTERISK-18345)
Reported by: Stephane Cazelas
(issue ASTERISK-18342)
Reported by: Stephane Chazelas
Review: https://reviewboard.asterisk.org/r/1576/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346525 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using the MessageSend application to send a SIP MESSAGE to a non-peer,
chan_sip attempted to validate the hostname or IP Address. In the process,
it stripped off the extension and failed to add it back to the sip_pvt
structure before transmitting. This patch adds the full URI passed in
from the message core to the sip_pvt structure.
(closes issue ASTERISK-18903)
Reported by: Shaun Clark
Tested by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1597/
........
Merged revisions 346040 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@346053 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The recent fix for ASTERISK-17288 to get RFC3578 SIP overlap support
working correctly removed a long standing ability to do overlap dialing
using DTMF in the early media phase of a call.
See ASTERISK-18702 it has a very good description of the issue.
I started with Pavel Troller's chan_sip.diff patch on issue
ASTERISK-18702.
* Added 'dtmf' enum value to sip.conf allowoverlap config option. The new
option value causes the Incomplte application to not send anything with
chan_sip so the caller can supply more digits via DTMF.
* Renames SIP_GET_DEST_PICKUP_EXTEN_FOUND to SIP_GET_DEST_EXTEN_MATCHMORE
since that is what it really means.
* Fixed get_destination() inconsistency with the pickup extension
matching.
* Fixed initialization of PAGE3 of global_flags in reload_config().
(closes issue ASTERISK-18702)
Reported by: Pavel Troller
Review: https://reviewboard.asterisk.org/r/1517/
Review: https://reviewboard.asterisk.org/r/1582/
........
Merged revisions 345273 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 345275 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@345276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix bug ASTERISK-16558 which dealt with the order of responses to incoming
streams defined by SDP.
Fix unreported bug where offering multiple same-type streams would cause
Asterisk to reply with an incorrect SDP response missing one or more streams
without a proper declination.
Fix bugs related to a single non-audio stream being offered with responses
requesting codecs that were not offered in the initial invite along with an
additional audio stream that was not in the initial invite.
Review: https://reviewboard.asterisk.org/r/1516/
........
Merged revisions 344385 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 344386 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@344387 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Another deadlock between the conlock/hints and channels/channel locking
orders.
* Don't hold the channel and private lock in sip_new() when calling
ast_exists_extension().
(closes issue ASTERISK-18740)
Reported by: Byron Clark
Patches:
sip_exists_exten_dlock_3.diff (license #5041) patch uploaded by Gregory Hinton Nietsky
ASTERISK-18740.patch (license #6157) patch uploaded by Byron Clark
Tested by: Byron Clark
........
Merged revisions 344268 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 344271 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@344272 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The domain matching code prior to 1.8 used to manually remove the port
from the host:port string when determining if an incoming request
matched the list of domains. When switching to the new parsing
functions, the documentation implied that the "domain" was being
returned by these functions, when instead it was returning the
"hostport" as defined by RFC 3261. This led to confusion and resulted
in 1.8+ rejecting an incoming request from x.x.x.x:xxxxx when
domain=x.x.x.x was set in sip.conf.
This patch renames the "domain" variables in the parsing functions to
"hostport" to more accurately describe what it is that they are
returning and also properly truncates the resulting hostport strings
when dealing with domain matching.
Review: https://reviewboard.asterisk.org/r/1574/
........
Merged revisions 344215 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 344216 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@344217 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
........
r343900 | dvossel | 2011-11-08 12:29:33 -0600 (Tue, 08 Nov 2011) | 11 lines
Fixes regression caused by r343635
There was a missing unlock for a function return that is only
present in Asterisk 10 and Asterisk Trunk.
(closes issue ASTERISK-18839)
Reported by: Michael L. Young
Patches:
asterisk-18839-missing-lock-trunk-v2.diff (License #5026) patch uploaded by Michael L. Young
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@343905 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed a LOG_ERROR message referencing the config variable list v that
had previously been processed and became NULL.
* Added error return value set that was missing in an ast_append_ha()
error return path.
(closes issue ASTERISK-18743)
Reported by: Michele
Patches:
issueA18743-fix_dynamic_exclude_static_bad_host_log.patch (license #5674) patch uploaded by Walter Doekes
Tested by: Michele
........
Merged revisions 343851 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 343852 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@343853 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A dialog cannot be destroyed by the ao2_callback dialog_needdestroy
because of a deadlock between the dialogs container lock and the RWLOCK of
the events subscription list.
* Create dialogs_to_destroy container to hold dialogs that will be
destroyed.
* Ensure that the event subscription callback will never happen with an
invalid peer pointer by making the event callback removal the first thing
in the peer destructor callback.
NOTE: This particular deadlock will not happen with Asterisk 10, but some
of the changes still apply.
(closes issue ASTERISK-18747)
Reported by: Gregory Hinton Nietsky
Review: https://reviewboard.asterisk.org/r/1564/
........
Merged revisions 343577 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 343578 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@343579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This option is not only useless, but has been broken since inception since
the flag was never copied from the peer where it is set to the pvt where
it was checked. RFC 3261 specificially states that you should not send a
provisional response to a non-INVITE request, and if we did fix the code
so that it worked, it would cause the same kind of user enumeration
vulnerability that we've discussed with the nat= setting. This patch
removes registertrying option and any code that would have sent a 100
response to a register.
Review: https://reviewboard.asterisk.org/r/1562/
........
Merged revisions 343220 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 343221 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@343222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were several problems with the dynamic realtime peer/user lookup
code. The lookup logic had become rather hard to read due to lots of
incremental changes to the realtime_peer function. And, during the
addition of the sipregs functionality, several possibilities for memory
leaks had been introduced. The insecure=port matching has always been
broken for anyone using the sipregs family. And, related, the broken
implementation forced those using sipregs to *still* have an ipaddr
column on their sippeers table.
Thanks Terry Wilson for comprehensive testing and finding and fixing
unexpected behaviour from the multientry realtime call which caused
the realtime_peer to have a completely unused code path.
This changeset fixes the leaks, the lookup inconsistenties and that
you won't need an ipaddr column on your sippeers table anymore (when
you're using sipregs). Beware that when you're using sipregs, peers
with insecure=port will now start matching!
(closes issue ASTERISK-17792)
(closes issue ASTERISK-18356)
Reported by: marcelloceschia, Walter Doekes
Reviewed by: Terry Wilson
Review: https://reviewboard.asterisk.org/r/1395
........
Merged revisions 342927 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 342929 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@342930 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix potential deadlocks in SIP and IAX blind transfer to parking.
* Fix SIP, IAX, DAHDI analog, and MGCP channel drivers to respect the
parkext_exclusive option with transfers (Park(,,,,,exclusive_lot)
parameter). Created ast_park_call_exten() and ast_masq_park_call_exten()
to maintian API compatibility.
* Made masq_park_call() handle a failed ast_channel_masquerade() setup.
* Reduced excessive struct parkeduser.peername[] size.
........
Merged revisions 341254 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 341255 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@341256 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/10
................
r340971 | kmoore | 2011-10-14 15:50:37 -0500 (Fri, 14 Oct 2011) | 15 lines
Merged revisions 340970 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r340970 | kmoore | 2011-10-14 15:49:39 -0500 (Fri, 14 Oct 2011) | 8 lines
Quiet RTCP Receiver Reports during fax transmission
RTCP is now disabled for "inactive" RTP audio streams during SIP T.38 sessions.
The ability to disable RTCP streams in res_rtp_asterisk was missing, so this
code was added to support the bug fix.
(closes issue ASTERISK-18400)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@340972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jonathan Rose
Mark Michelson
Walter Doekes
Andrew Latham
Joshua Colp
Matthew Jordan
Terry Wilson
Richard Mudgett
Kinsey Moore
Darren Sessions
Michael L. Young
Kevin P. Fleming
Jason Parker
Alec L Davis
Paul Belanger
Stefan Schmidt
Russell Bryant
Tilghman Lesher
David Vossel
Matthew Nicholson