The principal behind this patch is simple. During a transfer,
we manipulate channels that are owned by a separate thread than
the one we currently are running in, so it makes sense that we
need to grab a reference to the channels so that they cannot
disappear out from under us.
In the wild, crashes were sometimes seen when the transferring
party would hang up the call before the transfer target answered
the call. The most common place to see the crash occur was when
attempting to send a connected line update to the transferer
channel.
(closes issue ASTERISK-20226)
Reported by Jared Smith
Patches:
ASTERISK-20226.patch uploaded by Mark Michelson (License #5049)
Tested by: Jared Smith
........
Merged revisions 376901 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376916 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376917 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Websocket by default doesn't return an ast_str for the payload received. When
converting it to an ast_str on chan_sip the last character was being omitted,
because ast_str functions expects that the given length includes the trailing
0x00. payload_len only has the actual string length without counting the
trailing zero.
For most cases this passed unnoticed as most of SIP messages ends with \r\n.
(closes issue ASTERISK-20745)
Reported by: Iñaki Baz Castillo
Review: https://reviewboard.asterisk.org/r/2219/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk 11 follows RFC3265 that states that after every subscribe or resubscribe a notify should be sent.
Thus the console if filled continuously with the following after every subscribe;
== Extension Changed 8512[phones] new state IDLE for Notify User cisco1
In Asterisk 1.8 only changes would be sent. Thus only when a device state changed was anything emitted to the console.
fix:
Only print to console when device state isn't forced.
(closes issue ASTERISK-20706)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
........
Merged revisions 376540 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new field is will show up within the response if the requested peer has a
subscribe context set.
(closes issue ASTERISK-20626)
Reported by: Jaco Kroon
Patches:
asterisk-sip-ami-SubscrContext.patch uploaded by jkroon (license 5671)
-with modifications by jrose to conform to style guidelines
Review: https://reviewboard.asterisk.org/r/2195/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With ICE support enabled in chan_sip and a large number of interfaces on the system it was
possible for the produced SDP to be truncated due to some fixed size buffers. These buffers
have now been changed so they will dynamically grow as needed.
ICE support is now also enabled by default in res_rtp_asterisk to provide a smoother experience
for chan_motif users where it is required. To maintain the previous behavior in chan_sip it is
no longer enabled by default there.
(closes issue ASTERISK-20643)
Reported by: coopvr
........
Merged revisions 376130 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at some debug logs, I noticed that it was being reported that the
SDP origin line was unsupported or failed. Upon looking into this on my local
machine, I found that I too was getting this debug message yet everything seemed
to be getting processed properly. What was discovered is, that, the variable to
determine what is displayed in the debug message for the SDP line that was
processed, was not being set for the origin line when the result was successful.
This patch fixes this and was tested on local machine.
........
Merged revisions 375594 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375601 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375613 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375614 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
Mark Michelson
Richard Mudgett
Michael L. Young
Pedro Kiefer
Alec L Davis
Walter Doekes
Jonathan Rose
Joshua Colp
Andrew Latham
Matthew Jordan
Terry Wilson
Kinsey Moore
Darren Sessions