Age | Commit message (Collapse) | Author |
|
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
|
|
authenticator callback." into 13
|
|
callback.
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
|
|
Change-Id: Ic8322f04e37842848ad72cf2871bd0378f67c4ac
|
|
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
|
|
Remove incorrect MODULEINFO block and unneeded header includes
from presence_xml.c.
ASTERISK-25027
Reported by: Corey Farrell
Change-Id: I977c609ab9d1fe05373027c4138900f6985990eb
|
|
Change-Id: I7a8a7beec3334cec304943f2dd7597eabe2e3150
|
|
|
|
13." into 13
|
|
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
|
|
T.38 FAX." into 13
|
|
|
|
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
|
|
registers.
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
|
|
into 13
|
|
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>
|
|
timeout" into 13
|
|
qualifies" into 13
|