Prior to this patch, when a WebSocket connection is made, ARI would not
be informed of the connection until after the WebSocket layer had
accepted the connection. This created a brief race condition where the
ARI client would be notified that it was connected, a channel would be
sent into the Stasis dialplan application, but ARI would not yet have
registered the Stasis application presented in the HTTP request that
established the WebSocket.
This patch resolves this issue by doing the following:
* When a WebSocket attempt is made, a callback is made into the ARI
application layer, which verifies and registers the apps presented in
the HTTP request. Because we do not yet have a WebSocket, we cannot
have an event session for the corresponding applications. Some
defensive checks were thus added to make the application objects
tolerant to a NULL event session.
* When a WebSocket connection is made, the registered application is
updated with the newly created event session that wraps the WebSocket
connection.
ASTERISK-24988 #close
Reported by: Joshua Colp
Change-Id: Ia5dc60dc2b6bee76cd5aff0f69dd53b36e83f636
This patch refactors the transaction timeout processing to eliminate
calling the lower level public pjsip functions and reverts to calling
pjsip_endpt_send_request again. This is the result of me noticing
a possible incompatibility with pjproject-2.4 which was causing
contact status flapping.
The original version of this feature used the lower level calls to
get access to the tsx structure in order to cancel the transaction
when our own timer expires. Since we no longer have that access,
if our own timer expires before the pjsip timer, we call the callbacks
and just let the pjsip transaction take it's own course. When the
transaction ends, it discovers the callbacks have already been run
and just cleans itself up.
A few messages in pjsip_configuration were also added/cleaned up.
ASTERISK-25105 #close
Change-Id: I0810f3999cf63f3a72607bbecac36af0a957f33e
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
When an inbound call is received the To header is checked
for the "line" option. Some remote servers will place this
in the request URI instead. This adds an additional check for
the option in the request URI.
ASTERISK-25072 #close
Reported by: Dmitriy Serov
Change-Id: Id4e44debbb80baad623b914a88574371575353c8
Use ast_manager_register_xml for res_mwi_external_ami manager
actions. This ensures the module is held open while any of
the actions are being run.
ASTERISK-25117 #close
Reported by: Corey Farrell
Change-Id: Iececfdc2da498b2c32b9e09042f5f12292007ac7
This patch updates http_websocket and its corresponding implementation
with a pre-session established callback. This callback allows for
WebSocket server consumers to be notified when a WebSocket connection is
attempted, but before we accept it. Consumers can choose to reject the
connection, if their application specific logic allows for it.
As a result, this patch pulls out the previously private
websocket_protocol struct and makes it public, as
ast_websocket_protocol. In order to preserve backwards compatibility
with existing modules, the existing APIs were left as-is, and new APIs
were added for the creation of the ast_websocket_protocol as well as for
adding a sub-protocol to a WebSocket server.
In particular, the following new API calls were added:
* ast_websocket_add_protocol2 - add a protocol to the core WebSocket
server
* ast_websocket_server_add_protocol2 - add a protocol to a specific
WebSocket server
* ast_websocket_sub_protocol_alloc - allocate a sub-protocol object.
Consumers can populate this with whatever callbacks they wish to
support, then add it to the core server or a specified server.
ASTERISK-24988
Reported by: Joshua Colp
Change-Id: Ibe0bbb30c17eec6b578071bdbd197c911b620ab2
The config wizard was always pulling the first occurrence of
a variable from an ast_variable list but this gets the template
value from the list instead of any overridden value. This patch
creates ast_variable_find_last_in_list() in config.c and updates
res_pjsip_config_wizard to use it instead of
ast_variable_find_in_list. Now the overridden values, where they
exist, are used instead of template variables.
Updated test_config to test the new API.
ASTERISK-25089 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: Ifa7ddefc956a463923ee6839dd1ebe021c299de4
First byte of DTLS packet shall be in range 20-63, not 20-64. Refer to RFC
https://tools.ietf.org/html/rfc5764#section-5.1.2 for correct values.
Change-Id: Iae6fa0d72b37c36a27fe40686e0ae6fba3afec31
While trying to get WebRTC working with chan_pjsip, I was running
into the following error:
Attempted to set an invalid DTLS-SRTP configuration on RTP
instance...
Josh helpfully pointed out that res_srtp.so might not be loaded, and
sure enough, it wasn't. This patch adds a ERROR indiciating as much
to hopefully help others having a similar problem.
Change-Id: I13aa477b47b299876728a21b130998a0ea6cd19f
The res_pjsip_exten_state module currently has a race condition between
processing the extension state callback from the PBX core and processing
the subscription shutdown callback from res_pjsip_pubsub. There is currently
no synchronization between the two. This can present a problem as while
the SIP subscription will remain valid the tree it points to may not.
This is in particular a problem as a task to send a NOTIFY may get queued
which will try to use the tree that may no longer be valid.
This change does the following to fix this problem:
1. All access to the subscription tree is done within the task that
sends the NOTIFY to ensure that no other thread is modifying or
destroying the tree. This task executes on the serializer for the
subscriptions.
2. A reference to the subscription serializer is kept to ensure it
remains valid for the lifetime of the extension state subscription.
3. The NOTIFY task has been changed so it will no longer attempt
to send a NOTIFY if the subscription has already been terminated.
ASTERISK-25057 #close
Reported by: Matt Jordan
Change-Id: I0b3cd2fac5be8d9b3dc5e693aaa79846eeaf5643
Creating a snoop channel in ARI and spying only on a single direction (in or
out) results in CPU utilization continually increasing until the CPU is fully
consumed. This occurs because frames are being put in the opposing direction's
slin factory queue, but not being removed.
Fixed the problem by always reading and disposing of frames from the opposite
queue of the direction selected.
ASTERISK-24938 #closes
Change-Id: I935bfd15f1db958f364d9d6b3b45582c0113dd60
Missed this module in the previous commit. res_ari_bridges uses symbols
from res_stasis_playback and res_stasis_recording.
ASTERISK-25027 #close
Reported by: Corey Farrell
Change-Id: I90bf756abd25adfc4920d2869ebe7feb636b8c5f
Apply the negative connection cache setting to all connections,
even those that are not pooled. This ensures that the connection
will not be re-established before the negative connection cache
time is met.
ASTERISK-22708 #close
Change-Id: I431cc2e8584ab0b6908b3523d0a0e18c9a527271
Removed the extra space before "MODULEINFO" in res_pjsip_dlg_options.
This extra space prevented any of the dependencies from being seen by
menuselect, so building with default options would fail if PJSIP was
not installed.
This also makes the tool that extracts information for menuselect
tolerant of multiple spaces in the future.
ASTERISK-25033 #close
Reported by: Peter Whisker
Change-Id: Iccd54846f70c4a7a50cb5bf70b7bb5cb4bab3698
The Asterisk 13 version of the fix for outbound registration was missing
a key component that set the outbound authenticator's callback that
creates an authenticated request based on an old request. This was
picked up by some outbound registration tests failing in the testsuite.
Change-Id: I5ca9379698c606da36bc38eaffccedaf64211ce3
The res_ari_device_states module depends on res_stasis_device_state,
not res_stasis_device_states.
Change-Id: I26e02ad37f9e36bcc859867e2fad1b90452ec3de
When the PJSIP pjsip_regc_send function is invoked and an error
status returned the caller currently decrements the reference count
of the client state that it just incremented, assuming the
registration callback would not have been invoked. In practice
this is not correct. If the failure happens after the transaction
has been set up the callback will still be invoked. This will
cause the reference count to be incorrectly decremented twice, once
by the registration callback and second by the caller of
pjsip_regc_send.
This change makes it so that whether the callback is invoked or
not is known by the caller of pjsip_regc_send. Depending on
this it can know whether it is responsible for decrementing the
reference count of the client state or not.
ASTERISK-25037 #close
Reported by: Joshua Colp
Change-Id: I749dc12f3a22115c49c5d7d95ff42a5fa45319de
A previous set of patches (see: ASTERISK-22790 & ASTERISK-23231) made it so
a v.27 modem was not allowed to have a minimum transmission rate of 2400 bits
per second. This reverts all or some of those patches since according to the
v.27ter standard a rate of 2400 bits per second is also supported.
One of the original patches also added 9600 bits per second support for v.27.
This patch also removes that since v.27ter only supports 2400/4800 bits per
second.
Also, since Asterisk specifically supports v.27ter the enum was renamed to
better reflect this.
ASTERISK-24955 #close
Reported by: Matt Jordan
Change-Id: I4b9dfb6bf7eff08463ab47ee1a74224f27cae733
Sections Exist in pjsip.conf
This patch modifies the current loading strategy of the pjsip configuration. If
duplicate sections (e.g. sections containing the same [id/type]) are defined in
[pjsip.conf], the loader will consider the configuration for the given type as
invalid when the duplicate section is encountered. The entire configuration
(including what was previously loaded) for the duplicate [id/type] sections
will be rejected and destroyed, an error message is logged and the load
processing for the given stops.
ASTERISK-24996
Reported By: Ashley Sanders
Change-Id: I35090ca4cd40f1f34881dfe701a329145c347aef
Virtual line support establishes a relationship between messages
related to an outbound registration and a local endpoint. This is
accomplished by attaching a parameter to the Contact of the outbound
registration and looking for it on any received requests. If the
parameter exists and can be matched to an outbound registration
the configured endpoint is associated with the request.
ASTERISK-24949 #close
Reported by: Joshua Colp
Change-Id: I7df909d2625479110a83fdd354c21ac539e8615d
ARI modules that are generated by 'make ari-stubs' are all dependent on
res_ari_model. Additionally some of the same modules depend on one or more
res_stasis_* modules.
ASTERISK-25027 #close
Reported by: Corey Farrell
Change-Id: I8e07fe7e81fedacb87232f2b6f8b5f47927b4153
This is the Asterisk 13 version of a change to master that allows for
registration responses to be processed successfully potentially after
the original transaction has timed out. The main difference between this
and the master change is that the master version has API changes that
are unacceptable for 13. For 13, this is worked around by adding a new
API call that the outbound registration code uses instead.
The following is the text from the master version of this commit:
Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.
Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.
To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now also hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.
ASTERISK-25020
Reported by Mark Michelson
Change-Id: If1ee5f601be839479a219424f0358a229f358f7c
When problems occur regarding outbound registrations, it currently
is difficult to debug. Most off-nominal paths had warning messages,
but sometimes we want to know what's going on before hitting the
off-nominal path. This patch adds lots of debugging output that
should give a clearer picture of what is happening with regards
to outbound registrations.
ASTERISK-25020
Reported by Mark Michelson
Change-Id: I577bde7860be0a6c872b5bcb4d5047340bf45d45
ao2 ref leak in res_rtp_asterisk.c when a DTLS policy is created.
The resources are linked into a table, but the original alloc refs
are never released. ast_strdup leak in rtp_engine.c. If
ast_rtp_dtls_cfg_copy() is called twice on the same destination struct,
a pointer to an alloc'd string is overwritten before the string is free'd.
ASTERISK-25022
Reported by: one47
Change-Id: I62a8ceb8679709f6c3769136dc6aa9a68202ff9b
Permanent contacts that hadn't been qualified yet were missing
their contact_status entries causing SEGVs when running CLI
commands.
This patch makes sure that contact_statuses are created for
both dynamic and permanent contacts when they are created.
It also adds checks in the CLI code to make sure there's a
contact_status, just in case.
ASTERISK-25018 #close
Reported-by: Ivan Poddubny
Tested-by: Ivan Poddubny
Tested-by: George Joseph
Change-Id: I3cc13e5cedcafb24c400368b515b02d7fb81e029
The way PJSIP generates an authenticated request is to use a previous
request as a template. This means that the authenticated request will
have the same Call-ID, From header (including tag), and CSeq as the
original request. PJSIP generates a new branch on the Via header to
indicate that this is a new transaction, though.
There are some SIP implementations, though, that do not notice the
change in the branch and therefore will match the authed request to the
original request's transaction. Since the CSeq is the same, the server
will repeat the response it sent to the original request.
This patch aids interoperability by increasing the CSeq of the authed
request by one.
ASTERISK-24845 #close
Reported by: Carl Fortin
Tested by: Carl Fortin
Change-Id: I39c4ca52e688a9f83bcc1878371334becdc5be01
When Asterisk originates a channel to an application, the channel is
hung up once the application finishes executing. When the application
in question is SendFax, the Asterisk PJSIP code will attempt to reinvite
the T.38 session to audio after the FAX completes. The hangup of the
channel happens in the midst of this reinvite transaction. In most
circumstances, this works out okay because the BYE is delayed until the
reinvite transaction can complete.
However, if the reinvite that Asterisk sends receives a 401/407
response, then Asterisk's attempt to re-send the reinvite with
authentication will fail. This is because the session supplement in
res_pjsip_t38 makes the assumption that the channel on the session will
always be non-NULL. Since the channel has been hung up, though, the
channel is now NULL. Attempting to operate on the channel causes a
crash.
This patch fixes the issue by ensuring that the channel on the session
is not NULL before attempting to mess with the T.38 framehook.
This patch also contains some corrections for comments that were
incorrect and really confused me when I first started looking at the
code.
ASTERISK-25004 #close
Reported by Mark Michelson
Change-Id: Ic5a1230668369dda4bb13524098aed9306ab45a0
Currently we use pjsip_parse_hdr to validate contact uris but it
appears that it allows uris without a scheme if there's a port
supplied. I.E myexample.com will fail but myexample.com:5060 will
pass even though it has no scheme. This causes SEGVs later on
whenever the uri is used.
To prevent this, permanent_contact_validate has been updated to check
that the scheme is either 'sip' or 'sips'.
2 uses of possibly-null endpoint have also been fixed in
create_out_of_dialog_request.
ASTERISK-24999
Change-Id: Ifc17d16a4923e1045d37fe51e43bbe29fa556ca2
Reported-by: Brad Latus
clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.
Exanple:
unsigned int x = 4;
if (x > 0) // x is always going to be bigger than 0
Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.
rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.
ASTERISK-24917
Change-Id: I0557ae0154a0b7de68883848a609309cdf0aee6a
On some systems, res_corosync isn't compatible with the installed version of
corosync so corosync_cfg_initialize fails, load_module returns LOAD_FAILURE,
and Asterisk terminates. The work around has been to remember to add
res_corosync as a noload in modules.conf. A better solution though is to have
res_corosync check for its config file before attempting to call corosync apis
and return LOAD_DECLINE if there's no config file. This lets Asterisk loading
continue.
If you have a res_corosync.conf file and res_corosync fails, you get the same
behavior as today and the fatal error tells you something is wrong with the
install.
ASTERISK-24998
Change-Id: Iaf94a9431a4922ec4ec994003f02135acfdd3889
clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.
Exanple:
unsigned int x = 4;
if (x > 0) // x is always going to be bigger than 0
Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.
rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.
ASTERISK-24917
Change-Id: Ief23ef68916192b9b72dabe702b543ecfeca0b62
Currently the res_pjsip_mwi module only sends an unsolicited MWI NOTIFY upon
a mailbox state change (such as a new message being left, or one being deleted).
In practice this is not sufficient to keep clients aware of the current MWI status.
This change makes the module send unsolicited MWI NOTIFY on startup so that
clients are guaranteed to have the most up to date MWI information. It also makes
clients receive an unsolicited MWI NOTIFY upon registration so if they are unaware
of the current MWI status they receive it.
ASTERISK-24982 #close
Reported by: Joshua Colp
Change-Id: I043f20230227e91218f18a82c7d5bb2aa62b1d58
When SUBSCRIBE dialogs were established, we never associated
the endpoint that created the subscription with the dialog
we end up creating. In most cases, this ended up not causing
any problems.
The actual bug that was observed was that when a device that
was behind NAT established a subscription with Asterisk, Asterisk
would end up sending in-dialog NOTIFY requests to the device's
private IP addres instead of the public address of the NAT router.
When Asterisk receives the initial SUBSCRIBE from the device,
res_pjsip_nat rewrites the contact to the public address on which the
SUBSCRIBE was received. This allows for the dialog to have its target
address set to the proper public address. Asterisk then would send a 200
OK response to the SUBSCRIBE, then a NOTIFY with the initial
subscription state. The device would then send a 200 OK response to
Asterisk's NOTIFY.
Here's where things went wrong. When the 200 OK arrived, res_pjsip_nat
did not rewrite the address in the Contact header. Then, when the PJSIP
dialog layer processed the 200 OK, PJSIP would perform a comparison
between the IP address in the Contact header and its saved target
address for the dialog. Since they differed, PJSIP would update the
target dialog address to be the address in the Contact header. From this
point, if Asterisk needed to send a NOTIFY to the device, the result was
that the NOTIFY would be sent to the private address that the device
placed in the Contact header.
The reason why res_pjsip_nat did not rewrite the address when it
received the 200 OK response was that it could not associate the
incoming response with a configured endpoint. This is because on a
response, the only way to associate the response to an endpoint is by
finding the dialog that the response is associated with and then finding
the endpoint that is associated with that dialog. We do not perform
endpoint lookups on responses. res_pjsip_pubsub skipped the step of
associating the endpoint with the dialog we created, so res_pjsip_nat
could not find the associated endpoint and therefore couldn't rewrite
the contact.
This commit message is like 50x longer than the actual fix.
ASTERISK 24981 #close
Reported by Mark Michelson
Change-Id: I2b963c58c063bae293e038406f7d044a8a5377cd
Contact status rtt is an int64_t and needs the PRId64 macro to
properly create the format specifier on 32-bit systems.
Change-Id: I4b8ab958fc1e9a179556a9b4ffa49673ba9fdec7
The "Add qualify_timeout processing and eventing" patch introduced
an issue where contacts that had qualify_frequency set to 0 were
showing Unavailable instead Unknown. This patch checks for
qualify_frequency=0 and create an "Unknown" contact_status
with an RTT = 0.
Previously, the lack of contact_status implied Unknown but since
we're now changing endpoint state based on contact_status, I've
had to add new UNKNOWN status so that changes could trigger the
appropriate contact_status observers.
ASTERISK-24977: #close
Change-Id: Ifcbc01533ce57f0e4e584b89a395326e098b8fe7
Three fax related tests started failing as a result of changes made for
ASTERISK-24841:
tests/fax/pjsip/gateway_t38_g711
tests/fax/sip/gateway_mix1
tests/fax/sip/gateway_mix3
Historically, ast_channel_make_compatible() did nothing if the channels
were already "compatible" even if they had a sub-optimal translation path
already setup. With the changes from ASTERISK-24841 this is no longer
true in order to allow the best translation paths to always be picked. In
res_fax.c:fax_gateway_framehook() code manually setup the channels to go
through slin and then called ast_channel_make_compatible(). With the
previous version of ast_channel_make_compatible() this was always a
no-operation.
* Remove call to ast_channel_make_compatible() in fax_gateway_framehook()
that now undoes what was just setup when the framehook is attached.
* Fixed locking around saving the channel formats in
fax_gateway_framehook() to ensure that the formats that are saved are
consistent.
* Fix copy pasta errors in fax_gateway_framehook() that confuses read and
write when dealing with saved channel formats.
ASTERISK-24841
Reported by: Matt Jordan
Change-Id: I6fda0877104a370af586a5e8cf9e161a484da78d
A potential problem that can arise is the following:
* Bob's phone is programmed to automatically forward to Carol.
* Carol's phone is programmed to automatically forward to Bob.
* Alice calls Bob.
If left unchecked, this results in an endless loops of call forwards
that would eventually result in some sort of fiery crash.
Asterisk's method of solving this issue was to track which interfaces
had been dialed. If a destination were dialed a second time, then
the attempt to call that destination would fail since a loop was
detected.
The problem with this method is that call forwarding has evolved. Some
SIP phones allow for a user to manually forward an incoming call to an
ad-hoc destination. This can mean that:
* There are legitimate use cases where a device may be dialed multiple
times, or
* There can be human error when forwarding calls.
This change removes the old method of detecting forwarding loops in
favor of keeping a count of the number of destinations a channel has
dialed on a particular branch of a call. If the number exceeds the
set number of max forwards, then the call fails. This approach has
the following advantages over the old:
* It is much simpler.
* It can detect loops involving local channels.
* It is user configurable.
The only disadvantage it has is that in the case where there is a
legitimate forwarding loop present, it takes longer to detect it.
However, the forwarding loop is still properly detected and the
call is cleaned up as it should be.
Address review feedback on gerrit.
* Correct "mfgium" to "Digium"
* Decrement max forwards by one in the case where allocation of the
max forwards datastore is required.
* Remove irrelevant code change from pjsip_global_headers.c
ASTERISK-24958 #close
Change-Id: Ia7e4b7cd3bccfbd34d9a859838356931bba56c23
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint. Only dynamic contact add/delete actions
update the endpoint. Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.
This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...
1. A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message. The default is 3000ms. When the timer expires, the contact is
marked unavailable.
2. Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'. When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'. The
existing endpoint events are generated appropriately.
ASTERISK-24863 #close
Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
This change makes the send_notify of the sub_tree
not happen when the sub_tree has been deleted due
to the notify call failing, which avoids a crash.
ASTERISK-24970 #close
Change-Id: I1f20ffc08b192f59c457293b218025a693992cbf
This is the first follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
Since we currently have no control over pjproject transaction timeout, this
patch pulls the pjsip_endpt_send_request function out of pjproject and into
res_pjsip/endpt_send_transaction in order to implement that capability.
Now when the transaction is initiated, we also schedule our own pj_timer with
our own desired timeout.
If the transaction completes before either timeout, pjproject cancels its timer,
and calls our tsx callback where we cancel our timer and run the app callback.
If the pjproject timer times out first, pjproject calls our tsx callback where
we cancel our timer and run the app callback.
If our timer times out first, we terminate the transaction which causes
pjproject to cancel its timer and call our tsx callback where we run the app
callback.
Regardless of the scenario, pjproject is calling the tsx callback inside the
group_lock and there are checks in the callback to make sure it doesn't run
twice.
As part of this patch ast_sip_send_out_of_dialog_request was created to replace
its similarly named private function. It takes a new timeout argument in
milliseconds (<= 0 to disable the timeout).
ASTERISK-24863 #close
Reported-by: George Joseph <george.joseph@fairview5.com>
Tested-by: George Joseph <george.joseph@fairview5.com>
Change-Id: I0778dc730d9689c5147a444a04aee3c1026bf747
Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup. So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.
This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies. This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.
If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random(). If not set,
qualify_timeout is used.
The default is "0" (disabled).
ASTERISK-24863 #close
Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>
OPTIONAL_API has conditionals to define AST_OPTIONAL_API and
AST_OPTIONAL_API_ATTR differently based on if AST_API_MODULE is defined.
Unfortunately this is inside the include protection block, so only the
first status of AST_API_MODULE is respected. For example res_monitor
is an optional API provider, but uses func_periodic_hook. This makes
func_periodic_hook non-optional to res_monitor.
ASTERISK-17608 #close
Reported by: Warren Selby
Change-Id: I8fcf2a5e7b481893e17484ecde4f172c9ffb5679
Add the .gitignore and .gitreview files to the asterisk repo.
NB: You can add local ignores to the .git/info/exclude file
without having to do a commit.
Common ignore patterns are in the top-level .gitignore file.
Subdirectory-specific ignore patterns are in their own .gitignore
files.
Change-Id: I4c8af3b8e3739957db545f7368ac53f38e99f696
Tested-by: George Joseph
Prior to this patch, the far_max_datagram value on the UDPTL structure would
remain -1 if the remote endpoint fails to provide the SDP media attribute
T38FaxMaxDatagram. This can result in the INVITE request being rejected. With
this patch, we will now properly initialize the value with either the default
value or with the value provided by pjsip.conf's t38_udptl_maxdatagram
parameter.
Review: https://reviewboard.asterisk.org/r/4589
ASTERISK-24928 #close
Reported by: Juergen Spies
Tested by: Juergen Spies
patches:
pjsipT38patch20150331.txt submitted by Juergen Spies (License 6698)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.
* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.
* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.
* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.
* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.
* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.
This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/https://reviewboard.asterisk.org/r/4605/
ASTERISK-24841 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4609/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434637 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While investigating other unload issues I realized that the load/unload process
for the config wizard was pretty ugly so I've refactored it as follows...
When the res_pjsip sorcery instance is created the config_wizard bumps it's own
module reference to prevent it from unloading while the sorcery instance is
still active. When res_pjsip unloads and it's sorcery instance is destroyed,
the config wizard unrefs itself which then allows itself to unload cleanly.
Since the config wizard now can't load after res_pjsip or unload before it
(which should have been the correct behavior all along), I was able to remove
the chunks of code in both load_module and unload_module that handled that case.
Ran the testsuite tests to insure there were no functional changes and REF_DEBUG
to insure that Asterisk was shutting down cleanly with no FRACKs or leaks.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4610/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the ChannelHold event was added, the 'musicclass' parameter was
erroneously removed. This caused the ChannelHold events to be rejected as
they failed model validation. This patch updates the Swagger schema such that
it now properly reflects the event that is being created.
Hooray for tests that catch things like this.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434597 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_pjsip_phoneprov_provider was leaking references to phoneprov objects due to
a missing OBJ_NODATA in an ao2_callback in load_users(). Rather than adding the
OBJ_NODATA, I changed load_users to use a more straightforward ao2_iterator.
This plugged the leak but exposed an unload order issue between
res_pjsip_phoneprov_provider, res_phoneprov and res_pjsip.
res_pjsip_phoneprov_provider unloads first, then res_phoneprov, then res_pjsip.
Since res_pjsip_phoneprov_provider uses res_pjsip's sorcery instance, when it
unloads, it's objects are still in the sorcery instance. When res_pjsip
unloads, it destroys all its objects including res_pjsip_phoneprov_provider's.
The phoneprov destructor then attempts to unregister the extension from
res_phoneprov but because res_phoneprov is already cleaned up, its users
container is gone and we get a FRACK.
Simple solution, check for the NULL users container before attempting to remove
the entry. Duh.
Ran tests/res_phoneprov/res_phoneprov_provider. No leaks in
res_pjsip_phoneprov_provider and no FRACKs.
Reported-by: Corey Farrell
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4608/
ASTERISK-24935 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new session supplement that handles in-dialog OPTIONS
requests. Said OPTIONS requests are sent a 200 OK, as an endpoint lookup
for the OPTIONS request would already have been done by the time the
session supplement receives the inbound request.
ASTERISK-24862 #close
Reported by: yaron nahum
patches:
res_pjsip_dlg_options.c submitted by yaron nahum (License 6676)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434506 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Without this patch, if a PJSIP endpoint with udptl enabled and authentication
set attempted to use sendFax, the FAX session would fail during setup. This
was because the invite issued in response to being auth challenged would cause
the PJSIP channel performing the FAX to receive a second T38 framehook and
this would cause frames to be consumed in an inappropriate manner.
ASTERISK-24933 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4577/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes several warnings pointed out by the clang compiler.
* chan_pjsip: Removed check for data->text, as it will always be non-NULL.
* app_minivm: Fixed evaluation of etemplate->locale, which will always
evaluate to 'true'. This patch changes the evaluation to use
ast_strlen_zero.
* app_queue:
- Fixed evaluation of qe->parent->monfmt, which always evaluates to
true. Instead, we just check to see if the dereferenced pointer
evaluates to true.
- Fixed evaluation of mem->state_interface, wrapping it with a call to
ast_strlen_zero.
* res_smdi: Wrapped search_msg->mesg_desk_term with calls to ast_strlen_zero.
Review: https://reviewboard.asterisk.org/r/4541
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4541.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434285 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434286 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive a MESSAGE request that we cannot send a response
to, we should not send the incoming MESSAGE to the dialplan.
This commit should help the bouncing message_retrans test to
pass consistently.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For some applications - such as SLA - a phone pressing hold should not behave
in the fashion that the Asterisk core would like it to. Instead, the hold
action has some application specific behaviour associated with it - such as
disconnecting the channel that initiated the hold; only playing MoH to channels
in the bridge if the channels are of a particular type, etc.
One way of accomplishing this is to use a framehook to intercept the
hold/unhold frames, raise an event, and eat the frame. Tasty. This patch
accomplishes that using a new dialplan function, HOLD_INTERCEPT.
In addition, some general cleanup of raising hold/unhold Stasis messages was
done, including removing some RAII_VAR usage.
Review: https://reviewboard.asterisk.org/r/4549/
ASTERISK-24922 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When setting the configuration option 'timers' equal to 'no' the bit flag was
not properly negated. This patch clears all associated flags and only sets the
specified one. pjsip will handle any necessary flag combinations. Also went
ahead and did similar for the '100rel' option.
ASTERISK-24910 #close
Reported by: Ray Crumrine
Review: https://reviewboard.asterisk.org/r/4582/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes a warning caught by clang, in which it detected that large
chunks of extconf were unused. Frankly, I wish we could pretend that all of
extconf was unused, but alas, that is not yet the case.
A few extraneous functions in the parking tests were removed as well, for
the same reason.
Review: https://reviewboard.asterisk.org/r/4553
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4553.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434093 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434097 65c4cc65-6c06-0410-ace0-fbb531ad65f3
res_pjsip_phoneprov_provider is using ao2_callback with OBJ_MULTIPLE, then
ignoring the return. OBJ_NODATA flag was to prevent a reference leak, but
this caused the module to FRACK on unload. Revert change until this can
be investigated further.
ASTERISK-24935
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4578/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434025 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a change to align behavior with that of Asterisk 11 and previous versions.
In those versions, if a parked call were retrieved, and the call ended, the parked
call retriever would be hung up after the ParkedCall application ran. Prior to this
patch, in Asterisk 13, the same situation would result in the parked call retriever
falling through to additional priorities in the extension where the ParkedCall
application was called. With this patch, the behavior between Asterisk 11 and 13
aligns.
ASTERISK-24899 #close
Reported by Malcolm Davenport
Patches:
ASTERISK-24899.patch uploaded by Mark Michelson(license #5049)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@434022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Outbound SIP MESSAGEs had the potential to be sent out
of order from how they were specified in a set of
dialplan steps.
This change creates a serializer for sending outbound
MESSAGE requests on. This ensures that the MESSAGEs are
sent by Asterisk in the same order that they were sent
from the dialplan.
ASTERISK-24937 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/4579
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433968 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some invalid enum conversion warnings caught by clang. In
particular:
* chan_sip: Several functions mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects the functions to use the
right enum.
* chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state.
* strings: Fixed incorrect usage of AO2 flags with strings container.
* res_stasis: Change a return enumeration to stasis_app_user_event_res.
Review: https://reviewboard.asterisk.org/r/4535
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433747 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes clange compiler warnings for initializer overrides.
Specifically:
res_pjsip/config_transport maps PJSIP_TLSV1_METHOD to the same enumeration
value as PJSIP_SSL_DEFAULT_METHOD. When initializing an array containing
those enum values, we therefore initialize the value twice to two different
values, "tlsv1" and "default". This patch changes it to just initialize
the index in the array to "tlsv1".
Review: https://reviewboard.asterisk.org/r/4539/
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4539.patch submitted by dkdegroot (License 6600)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433682 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had an issue where retransmissions of MESSAGE requests resulted in
Asterisk processing the retransmission as if it were a new MESSAGE request.
This patch fixes the issue by creating a transaction in PJSIP on the incoming
request. This way, if a retransmission arrives, the PJSIP transaction layer
will resend the response and Asterisk will not ever see the retransmission.
ASTERISK-24920 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/4532/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch updates the kqueue timing module to conform to current timer API.
This fixes issues with using the kqueue timing source on Asterisk 13 on
FreeBSD 10. These issues include:
- Remove support for kevent64(). The values used to support Asterisk timers
fit within 32bits and so can be handled on all platforms via kevent().
- Provide debug logging for, but do not track, unacked events. This matches
the behavior of all other timer implementations.
- Implement continuous mode by triggering and leaving active, a user event.
This ensures that the file descriptor for the timer returns immediately from
poll(), without placing the load of a high speed timer on the kernel.
- In kqueue_timer_get_max_rate(), don't overstate the capability of the timer.
On some platforms, UINT_MAX is greater than INTPTR_MAX, the largest integer
type kqueue supports for timers.
- In kqueue_timer_get_event(), assume the caller woke up from poll() and just
return the mode the timer is currently in. This matches all other timer
implementations.
- Adjust the test code now that unacked events are not tracked.
Review: https://reviewboard.asterisk.org/r/4465/
ASTERISK-24857 #close
Reported by: scsiguy
Tested by: Ed Hynan
patches:
rb4465.patch submitted by scsiguy (License 6692)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433574 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Move most of res_pjsip:module_unload to unload_pjsip to resolve crashes
caused by running PJSIP functions from non-PJSIP threads.
* Remove call to pjsip_endpt_destroy(ast_pjsip_endpoint), it was causing
crashes in some cases. In theory pj_shutdown() should take care of this.
* Mark res_pjsip_keepalive and res_pjsip_session as allowed to unload at
shutdown.
* Resolve leaked config global in res_pjsip_notify.
* Unregister pubsub pjsip service module.
* Implement cleanup for res_pjsip_session.
ASTERISK-24731 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4498/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* In res/res_sorcery_realtime.c: Broke long line.
* In main/bucket.c: Eliminated unnecessary NULL check as
ast_sorcery_unref() is NULL tolerant and set the global object to NULL
after unref in the system shutdown bucket_cleanup().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a quirk in the configuration handling of res_xmpp, the 'autoregister'
setting was never actually processed. This was due to not properly copying
over the global settings to the client settings when applying the
configuration to the run-time object.
Review: https://reviewboard.asterisk.org/r/4496/
ASTERISK-14233
ASTERISK-24780 #close
Reported by: Simon Arlott
patches:
asterisk-13.1.0-24780 uploaded by Simon Arlott (License 5756)
........
Merged revisions 433395 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Incoming PJSIP call legs that have not been answered yet send unnecessary
"180 Ringing" or "183 Progress" messages every time a connected line
update happens. If the outgoing channel is also PJSIP then the incoming
channel will always send a "180 Ringing" or "183 Progress" message when
the outgoing channel sends the INVITE.
Consequences of these unnecessary messages:
* The caller can start hearing ringback before the far end even gets the
call.
* Many phones tend to grab the first connected line information and refuse
to update the display if it changes. The first information is not likely
to be correct if the call goes to an endpoint not under the control of the
first Asterisk box.
When connected line first went into Asterisk in v1.8, chan_sip received an
undocumented option "rpid_immediate" that defaults to disabled. When
enabled, the option immediately passes connected line update information
to the caller in "180 Ringing" or "183 Progress" messages as described
above.
* Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
"183 Progress" messages. The default is "no" to disable sending the
unnecessary messages.
ASTERISK-24781 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4473/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with
ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending
responses to OPTIONS requests, processing MESSAGE requests, and
res_pjsip supplements implementing the incoming_request callback.
* Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in
res/res_pjsip.c:supplement_on_rx_request(),
res/res_pjsip/pjsip_options.c:send_options_response(),
res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and
res/res_pjsip_messaging.c:send_response().
* Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in
res/res_pjsip_nat.c:nat_on_rx_message().
* Fixed inconsistent but benign return value in
res/res_pjsip/pjsip_options.c:options_on_rx_request().
Review: https://reviewboard.asterisk.org/r/4511/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found a memory leak and invalid access.
* Fix invalid access by sscanf() being fed a non-nul terminated string of
digits in res/res_pjsip_sdp_rtp.c:get_codecs().
* Fix memory leak in main/sorcery.c:sorcery_object_field_destructor().
* Fix potential NULL pointer dereference in
main/xmldoc.c:xmldoc_get_syntax_config_option().
Review: https://reviewboard.asterisk.org/r/4513/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433199 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with ast_sockaddr_resolve().
Most of the leaks had already been fixed by earlier memory leak hunt
patches. This patch performs an audit of ast_sockaddr_resolve() and found
one more.
* Fix ast_sockaddr_resolve() memory leak in
apps/app_externalivr.c:app_exec().
* Made main/netsock2.c:ast_sockaddr_resolve() always set the addrs
parameter for safety so the pointer will never be uninitialized on return.
The same goes for res/res_pjsip_acl.c:extract_contact_addr().
* Made functions that call ast_sockaddr_resolve() with RAII_VAR()
controlling the addrs variable use ast_free instead of ast_free_ptr to
provide better MALLOC_DEBUG information.
Review: https://reviewboard.asterisk.org/r/4509/
........
Merged revisions 433056 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433057 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated some documentation stating that endpoint identifiers registered without
a name are place at the front of the lookup list. Also renamed register method
'ast_sip_register_endpoint_identifier_by_name' to
'ast_sip_register_endpoint_identifier_with_name'
ASTERISK-24840
Reported by: Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433031 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes previously reverted code that caused binary incompatibility
problems with some modules. And like the original patch it makes sure that
no matter what order the endpoint identifier modules were loaded, priority is
given based on the ones specified in the new global 'endpoint_identifier_order'
option.
ASTERISK-24840
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4489/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@433028 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_pjsip modules were manually checking both name and number
presentation values when there is a function that determines the combined
presentation for a party ID struct. The function takes into account if
the name or number components are valid while the manual code rarely
checked if the data was even valid.
* Made use ast_party_id_presentation() rather than manually checking party
ID presentation values.
* Ensure that set_id_from_pai() and set_id_from_rpid() will not return
presentation values other than what is pulled out of the SIP headers. It
is best if the code doesn't assume that AST_PRES_ALLOWED and
AST_PRES_USER_NUMBER_UNSCREENED are zero.
* Fixed copy paste error in add_privacy_params() dealing with RPID
privacy.
* Pulled the id->number.valid test from add_privacy_header() and
add_privacy_params() up into the parent function add_id_headers() to skip
adding PAI/RPID headers earlier.
* Made update_connected_line_information() not send out connected line
updates if the connected line number is invalid. Lower level code would
not add the party ID information and thus the sent message would be
unnecessary.
* Eliminated RAII_VAR usage in send_direct_media_request().
Review: https://reviewboard.asterisk.org/r/4472/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432892 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to a break in binary compatibility with some other modules these changes
are being reverted until the issue can be resolved.
ASTERISK-24840
Reported by: Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a type=global section is not defined in pjsip.conf the global
defaults are not applied. As a result the mandatory Max-Forwards header
is not added to SIP messages for res_pjsip/chan_pjsip.
The handling of pjsip.conf type=global objects has several problems:
1) If the global object is missing the defaults are not applied.
2) If the global object is missing the default_outbound_endpoint's default
value is not returned by ast_sip_global_default_outbound_endpoint().
3) Defines are needed so default values only need to be changed in one
place.
* Added a sorcery instance observer callback to check if there were any
type=global sections loaded. If there were more than one then issue an
error message. If there were none then apply the global defaults.
* Fixed ast_sip_global_default_outbound_endpoint() to return the
documented default when no type=global object is defined.
* Made defines for the global default values.
* Increased the default_useragent[] size because SVN version strings can
get lengthy and 128 characters may not be enough.
* Fixed an off-nominal code path ref leak in global_alloc() if the string
fields fail to initialize.
* Eliminated RAII_VAR in get_global_cfg() and
ast_sip_global_default_outbound_endpoint().
ASTERISK-24807 #close
Reported by: Anatoli
Review: https://reviewboard.asterisk.org/r/4467/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432766 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When escaping backslashes with MySQL, the proper way to escape the characters
in a LIKE clause is to escape the '\' four times, i.e., '\\\\'. To quote the
MySQL manual:
"Because MySQL uses C escape syntax in strings (for example, “\n” to represent
a newline character), you must double any “\” that you use in LIKE strings.
For example, to search for “\n”, specify it as “\\n”. To search for “\”,
specify it as “\\\\”; this is because the backslashes are stripped once by the
parser and again when the pattern match is made, leaving a single backslash to
be matched against."
ASTERISK-24808 #close
Reported by: Javier Acosta
patches:
res_config_odbc.diff uploaded by Javier Acosta (License 6690)
........
Merged revisions 432720 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432721 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A race condition happened between initiating a transfer and requesting
that a dialog termination be delayed. Occasionally, the transferrer
channels would exit the bridge and hangup before the dialog termination
delay was requested.
* Made request dialog termination delay before initiating the transfer
action. If the transfer fails then cancel the delayed dialog termination
request.
ASTERISK-24755 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4460/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432668 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It's possible to have a scenario that will create a conflict between endpoint
identifiers. For instance an incoming call could be identified by two different
endpoint identifiers and the one chosen depended upon which identifier module
loaded first. This of course causes problems when, for example, the incoming
call is expected to be identified by username, but instead is identified by ip.
This patch adds a new 'global' option to res_pjsip called
'endpoint_identifier_order'. It is a comma separated list of endpoint
identifier names that specifies the order by which identifiers are processed
and checked.
ASTERISK-24840 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4455/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As pjproject is now used as a shared library a different define,
HAVE_PJPROJECT, is used to specify if pjproject is present.
ASTERISK-24830 #close
Reported by: Stefan Engström
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432614 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Made safely get the TRANSFER_CONTEXT channel value while the channel is
locked in refer_incoming_attended_request() and
refer_incoming_blind_request(). The pointer returned by
pbx_builtin_getvar_helper() is only valid while the channel is locked.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unfortunately, while initial testing with ConfBridge did not reproduce the
audio problem alluded to in the comment in res_pjsip_sdp_rtp, further testing
did show that bridge_softmix and/or ConfBridge has a severe problem bridging
two or more participants at different sampling rates. Sometimes, it even picks
odd sampling rates that cause hideous audio problems.
This patch backs out the offending portion of the code until the issues in
the affected bridging modules can be more properly analyzed.
ASTERISK-24841
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432423 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Sending the following ARI commands caused Asterisk to crash if the JSON
body 'variables' object passes values of types other than strings.
POST /ari/channels
POST /ari/channels/{channelid}
PUT /ari/endpoints/sendMessage
PUT /ari/endpoints/{tech}/{resource}/sendMessage
* Eliminated RAII_VAR usage in ast_ari_channels_originate_with_id(),
ast_ari_channels_originate(), ast_ari_endpoints_send_message(), and
ast_ari_endpoints_send_message_to_endpoint().
ASTERISK-24751 #close
Reported by: jeffrey putnam
Review: https://reviewboard.asterisk.org/r/4447/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some WebSocket applications, like [chan_respoke][], require a larger
frame size than the default 8k; this patch bumps the default to 16k.
This patch also fixes some problems exacerbated by large frames.
The sanity counter was decremented on every fread attempt in
ws_safe_read(), regardless of whether data was read from the socket or
not. For large frames, this could result in loss of sanity prior to
reading the entire frame. (16k frame / 1448 bytes per segment = 12
segments).
This patch changes the sanity counter so that it only decrements when
fread() doesn't read any bytes. This more closely matches the original
intention of ws_safe_read(), given that the error message is
"Websocket seems unresponsive".
This patch also properly logs EOF conditions, so disconnects are no
longer confused with unresponsive connections.
[chan_respoke]: https://github.com/respoke/chan_respoke
Review: https://reviewboard.asterisk.org/r/4431/
........
Merged revisions 432236 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so that if a channel variable is requested and it does not exist
a 404 response will be returned instead of an allocation failed response. This makes
it easier to debug and figure out what is going on for a user.
ASTERISK-24677 #close
Reported by: Joshua Colp
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some implementations don't pay attention to the expires for individual contacts.
In this case they may consider the lack of an Expires header in the 200 OK as
unregistered. This change makes it so if an Expires header is present in the REGISTER
we will add one in the 200 OK.
ASTERISK-24785 #close
Reported by: Ross Beer
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432136 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Hoskins reported that res_pjsip_publish_asterisk wouldn't pull config from
realtime. Turns out it was just missing a call ast_sorcery_apply_config().
res_pjsip_acl was missing it as well, so I added it. The other pjsip modules
looked OK.
ASTERISK-24811 #close
Reported-by: Matt Hoskins
Tested-by: George Joseph
Tested-by: Matt Hoskins
patches:
res_pjsip_publish_asterisk.c.patch submitted by Matt Hoskins (license 6688)
Review: https://reviewboard.asterisk.org/r/4433/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@432033 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed hangup handling of the session->channel after answer if the
ast_channel_move() or ast_bridge_impart() fails. We are still the thread
controlling the session->channel so we need to call ast_hangup() to kill
the channel.
* Fixed debug messages in refer_incoming_invite_request() referencing
incorrect channnels on success. Code comments now say why the
session->channel cannot be used.
Review: https://reviewboard.asterisk.org/r/4422/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431956 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Analyzing a one-off crash on a busy system showed that processing a REFER
request had a NULL session channel pointer. The only way I can think of
that could cause this is if an outgoing BYE transaction overlapped the
incoming REFER transaction in a collision. Asterisk sends a BYE while the
phone sends a REFER to complete an attended transfer.
* Made check the session channel pointer before processing an incoming
REFER request in res_pjsip_refer.
* Fixed similar crash potential for res_pjsip supplement incoming request
processing for res_pjsip_sdp_rtp INFO, res_pjsip_caller_id INVITE/UPDATE,
res_pjsip_messaging MESSAGE, and res_pjsip_send_to_voicemail REFER
messages.
* Made res_pjsip_messaging respond to a message body too large with a 413
instead of ignoring it.
ASTERISK-24700 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4417/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When RTCP debugging was enabled, an RTCP report without a report block would
cause a crash. This was due to the verbose output not checking to see if the
report_block pointer was NULl before dereferencing it.
This patch adds the necessary check to prevent printing any verbose output
if the far side hasn't provided us the information they should have.
ASTERISK-24791 #close
Reported by: JoshE
Tested by: JoshE
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431879 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_sorcery_config module currently uses a fixed bucket
size of 53. This means that depending on the number of objects
you either end up with excess buckets or a lot of collisions.
Due to the way that res_sorcery_config is implemented it's actually
possible to make the bucket size dynamic based on the number of
objects. This is due to the fact that each loading of the config file
produces a new container and does not modify the existing one.
This change uses the number of expected objects and finds a prime
number near it. In practice depending on the number of objects this
can speed up lookups anywhere from 2X to 15X. This change also removes
the lock from the container as it is not needed.
Review: https://reviewboard.asterisk.org/r/4423/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When debugging things it can be useful to know absolutely what
version of pjproject res_pjsip is running against. This change
adds a "pjsip show version" CLI command which can be used to
query for this.
ASTERISK-24685 #close
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/4424/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During some refactoring the way private information for timers
was stored was changed. As a result of this the action which normally
removed the timer upon closure in res_timing_pthread was also removed
causing the timer to remain after it should using up resources.
This change ensures that the timer is removed upon closure.
ASTERISK-24768 #close
Reported by: Matthias Urlichs
patches:
timer.patch submitted by Matthias Urlichs (license 5508)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431807 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A multi-asterisk box setup with direct media enabled would occasionally
crash when two re-INVITE collisions on a call leg happen in a row.
The re-INVITE logic only had one timer struct to defer the re-INVITE.
When the second collision happens the timer struct is overwritten and put
into the timer heap again. Resources for the first timer are leaked and
the heap has two positions occupied by the same timer struct. Now the
heap ordering is potentially corrupted, the timer will fire twice, and any
resources allocated for the second timer will be released twice.
* The solution is to put the collided re-INVITE into the delayed requests
queue with all the other delayed requests and cherry pick the next request
that can come off the queue when an event happens.
* Changed to put delayed BYE requests at the head of the delayed queue.
There is no sense in processing delayed UPDATEs and re-INVITEs when a BYE
has been requested.
* Made the start of a BYE request flush the delayed requests queue to
prevent a delayed request from overlapping the BYE transaction. I saw a
few cases where a delayed re-INVITE got started after the BYE transaction
started.
* Changed the delayed_request struct to use an enum instead of a string
for the request method. Cherry picking the queue is easier with an enum
than string comparisons and the compiler can warn if a switch statement
does not cover all defined enum values.
* Improved the debug output to give more information. It helps to know
which channel is involved with an endpoint. Trunks can have many channels
associated with the endpoint at the same time.
ASTERISK-24727 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4414/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431734 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431717 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There have been a couple of times where a crash occurred in the dtls_handler
section of the code for res_pjsip. Unfortunately, in working this issue the
problem was unable to be reproduced. After looking at the backtraces and
through the code the current best guess as to why this happened might be due
to a reentrance problem and the strtok function. So, the current fix is to
convert the strtok function into the reentrant version of the function,
strtok_r.
ASTERISK-24741 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4409/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431698 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Looking at the Super Awesome Company sample reminded me that creating hints is
just plain gruntwork. So you can now have the pjsip conifg wizard auto-create
them for you.
Specifying 'hint_exten' in the wizard will create
'exten => <hint_exten>,hint/PJSIP/<wizard_id>'
in whatever is specified for 'hint_context'.
Specifying 'hint_application' in the wizard will create
'exten => <hint_exten>,1,<hint_application>'
in whatever is specified for 'hint_context'.
The default for 'hint_context' is the endpoint's context.
There's no default for 'hint_application'. If not specified, no app is added.
There's no default for 'hint_exten'. If not specified, neither the hint itself
nor the application will be created.
Some may think this is the slippery slope to users.conf but hints are a basic
necessity for phones unlike voicemail, manager, etc that users.conf creates.
Tested-by: George Joseph
Review: https://reviewboard.asterisk.org/r/4383/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431643 65c4cc65-6c06-0410-ace0-fbb531ad65f3
One of the canonical reasons for hanging up a channel is because the far end
failed to answer - or because someone else answered, and we want to get rid of
this channel. This patch adds the missing value to the 'reason' query parameter
for the DELETE /channels operation.
Review: https://reviewboard.asterisk.org/r/4400
ASTERISK-24745 #close
Reported by: Ben Merrills
patches:
add_no_answer_ari_hangup_cause.diff uploaded by Ben Merrills (License 6678)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies the ast_odbc_find_table function such that it only performs
a lookup of the requested table if the table is not already known. Prior to
this patch, a queries would be executed against the database even if the table
was already known and cached.
Review: https://reviewboard.asterisk.org/r/4405/
ASTERISK-24742 #close
Reported by: ibercom
patches:
patch.diff uploaded by ibercom (License 6599)
........
Merged revisions 431617 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an SDP is created for an outgoing request/response, the ICE candidates
obtained from the RTP instance are currently leaked. This causes the ao2
container that holds the candidates to never properly be reclaimed when the
RTP instance is destroyed.
This patch properly decrements the ICE candidates' container if it is
successfully obtained.
ASTERISK-24769 #close
Reported by: Matt Jordan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk attempts to send SIP outbound publish information and no response
is ever received (no 200 okay, 412, 423) the system eventually crashes. A
response is never received because the system Asterisk is attempting to send
publish information to is not available. The underlying pjsip framework attempts
to send publish information. After several attempts it calls back into the
Asterisk outbound publish code. At this point if the "client->queue" is empty
Asterisk attempts to schedule a refresh which utilizes "rdata" and since no
response was received the given "rdata" struture is NULL. Attempting to
dereference a NULL object of course results in a crash.
The fix here removes the dependency on rdata for schedule_publish_refresh.
Instead param->expiration is now passed to it as this is set to -1 if no
response is received. Also added a notification when no response is received.
ASTERISK-24635 #close
Reported by: Marco Paland
Review: https://reviewboard.asterisk.org/r/4384/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When swapping a Local channel in place of one already
in a bridge (to complete a bridge attended transfer),
the channel that was swapped out can actually be hung
up before the stasis bridge push callback executes on
the independant transfer thread. This results in the
stasis app loop dropping out and removing the control
that has the the app name which the local replacement
channel needs so it can re-enter stasis.
To avoid this race condition a new push_peek callback
has been added, and called from the ast_bridge_impart
thread before it launches the independant thread that
will complete the transfer. Now the stasis push_peek
callback can copy the stasis app name before the swap
channel can hang up.
ASTERISK-24649
Review: https://reviewboard.asterisk.org/r/4382/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431450 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in res_pjsip/chan_pjsip.c
Review: https://reviewboard.asterisk.org/r/4345
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431426 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to an inversion error, setting 100rel=no would not actually
change the current value of the setting (which defaulted to "yes").
With this fix, the inversion is corrected.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431420 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent security fix for OpenSSL broke DTLS negotiation for many
applications. This was caused by read ahead not being enabled when it
should be. While a commit has gone into OpenSSL to force read ahead
on for DTLS it may take some time for a release to be made and the
change to be present in distributions (if at all). As enabling read
ahead is a simple one line change this commit does that and fixes
the issue.
ASTERISK-24711 #close
Reported by: Jared Biel
........
Merged revisions 431384 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/13@431385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Matt Jordan
Joshua Colp
George Joseph
demon-ru
Corey Farrell
Yousf Ateya
Sean Bright
Kevin Harwell
Martin Tomec
Mark Michelson
Ashley Sanders
Steve Davies
Diederik de Groot
Richard Mudgett
Scott Griepentrog
Jonathan Rose
Scott Griepentrog
David M. Lee