| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
Change-Id: Ia0b2e15773894c599e5c5748bbc70e99f434192a
|
|
Change-Id: I110d3e3572598289fcd4215d966cf0c858f98632
|
|
Change-Id: I0da80a3c3e0eae0c52ff27e7412ba027d6f52353
|
|
|
|
A feature of chan_sip that service providers relied upon was the ability to
identify by the Authorization username. This is most often used when customers
have a PBX that needs to register rather than identify by IP address. From my
own experiance, this is pretty common with small businesses who otherwise
don't need a static IP.
In this scenario, a register from the customer's PBX may succeed because From
will usually contain the PBXs account id but an INVITE will contain the caller
id. With nothing recognizable in From, the service provider's Asterisk can
never match to an endpoint and the INVITE just stays unauthorized.
The fixes:
A new value "auth_username" has been added to endpoint/identify_by that
will use the username and digest fields in the Authorization header
instead of username and domain in the the From header to match an endpoint,
or the To header to match an aor. This code as added to
res_pjsip_endpoint_identifier_user rather than creating a new module.
Although identify_by was always a comma-separated list, there was only
1 choice so order wasn't preserved. So to keep the order, a vector was added
to the end of ast_sip_endpoint. This is only used by res_pjsip_registrar
to find the aor. The res_pjsip_endpoint_identifier_* modules are called in
globals/endpoint_identifier_order.
Along the way, the logic in res_pjsip_registrar was corrected to match
most-specific to least-specific as res_pjsip_endpoint_identifier_user does.
The order is:
username@domain
username@domain_alias
username
Auth by username does present 1 problem however, the first INVITE won't have
an Authorization header so the distributor, not finding a match on anything,
sends a securty_alert. It still sends a 401 with a challenge so the next
INVITE will have the Authorization header and presumably succeed. As a result
though, that first security alert is actually a false alarm.
To address this, a new feature has been added to pjsip_distributor that keeps
track of unidentified requests and only sends the security alert if a
configurable number of unidentified requests come from the same IP in a
configurable amout of time. Those configuration options have been added to
the global config object. This feature is only used when auth_username
is enabled.
Finally, default_realm was added to the globals object to replace the hard
coded "asterisk" used when an endpoint is not yet identified.
The testsuite tests all pass but new tests are forthcoming for this new
feature.
ASTERISK-25835 #close
Reported-by: Ross Beer
Change-Id: I30ba62d208e6f63439600916fcd1c08a365ed69d
|
|
files" into 13
|
|
|
|
A recent change to func_odbc made it so that a single connection was
maintained per DSN. The problem was that the code was optimistic about
the health of the connection after initially opening it and did nothing
to re-connect in case the connection had died.
This change adds a check before executing a query to ensure that the
connection to the database is still up and running.
ASTERISK-25963 #close
Reported by Ross Beer
Change-Id: Id33c86eb04ff48ca088bb2e3086c27b3b683491d
|
|
This patch added new global pjsip option 'disable_multi_domain'.
Disabling Multi Domain can improve Realtime performance by reducing
number of database requests.
ASTERISK-25930 #close
Change-Id: I2e7160f3aae68475d52742107949a799aa2c7dc7
|
|
into 13
|
|
|
|
The unload process currently tells each TCP/TLS to terminate but
does not wait for them to do so. This introduces a race condition
where the container holding the threads may be destroyed before
the threads are able to remove themselves from it. When they
finally do the container is invalid and can't be used causing a
crash.
A previous change existed which waited a bit to wait for any
stranglers to finish. This change extends this and waits longer.
ASTERISK-25961 #close
Change-Id: Idc6262b670ca49ede32061159e323b7b63c6f3c6
|
|
When unloading the app_queue module the members in each queue are
destroyed and as part of this they are removed from the pending
members container. Unfortunately a crash would occur as the container
was destroyed before the members were removed.
This change tweaks ordering so the container destruction occurs
after the members are destroyed.
ASTERISK-16115
Change-Id: I48c728668c55aee3d05b751a5d450fb57e87f44b
|
|
* changes:
test_message.c: Wait longer in case dialplan also processes the test message.
Manager: Short circuit AMI message processing.
manager.c: Eliminate most RAII_VAR usage.
manager_channels.c: Fix allocation failure crash.
|
|
* changes:
Bridge system: Fix memory leaks and double frees on impart failure.
bridge_softmix.c: Fix crash if channel fails to join mixing tech.
|
|
A patch I did back in 2014 modified ast_config_text_file_save2 to check the
writability of the main file and include files before truncating and re-writing
them. An unintended side-effect of this was that if a file doesn't exist,
the check fails and the write is aborted.
This patch causes ast_config_text_file_save2 to check the writability of the
parent directory of missing files instead of checking the file itself. This
allows missing files to be created again. A unit test was also added to
test_config to test saving of config files.
The regression was discovered when app_voicemail's passwordlocation=spooldir
feature stopped working.
ASTERISK-25917 #close
Reported-by: Jonathan Rose
Change-Id: Ic4dbe58c277a47b674679e49daed5fc6de349f80
|
|
|
|
Since Stasis has been introduced, an attempt to send AMI messages by an
autocreated peer caused a crash, and all events from autocreated peers were
semi-inadvertently disabled altogether in 0b83761. This change restores the
disabled functionality.
ASTERISK-25950
Change-Id: Iecc350f23db603fadb2f302064643ebe9664e974
|
|
|
|
It was possible for a queue member that is a member of at least 2 or more
queues to receive mulitiple calls at the same time. This happened because
of a race between when a member was being rung and when the device state
notified the other queue(s) member object of the state change.
This patch makes it so when a queue member is being rung it gets added to
a global pool of queue members. If that same member is tried again, e.g.
from another queue, and it is found to already exist in the pending member
container then it will not ring that member.
ASTERISK-16115 #close
Change-Id: I546dd474776d158c2b6be44205353dee5bac7e48
|
|
|
|
ASTERISK-25954 #close
Reported by: Javier Acosta
Change-Id: I00be83d45cc7e8385de2523012bd196aafeeb256
|
|
The run_agi function is eating control frames when it shouldn't be. This is
causing issues when an AGI is run from CONNECTED_LINE_SEND_SUB in a blond
transfer.
Alice calls Bob. Bob attended transfers to Charlie but hangs up before Charlie
answers.
Alice gets the COLP UPDATE indicating Charlie but Charlie never gets an UPDATE
and is left thinking he's connected to Bob.
In this case, when CONNECTED_LINE_SEND_SUB runs on Alice's channel and it calls
an AGI, the extra eaten frames prevent CONNECTED_LINE_SEND_SUB from running on
Charlie's channel.
The fix was to accumulate deferrable frames in the "forever" loop instead of
dropping them, and re-queue them just before running the actual agi command
or exiting.
ASTERISK-25951 #close
Change-Id: I0f4bbfd72fc1126c2aaba41da3233a33d0433645
|
|
|
|
|
|
|
|
|
|
Bumped the wait from 1 second to 5 seconds. The test message was hitting my
default call handler and failing the test because it took longer.
Change-Id: I3a03737f25e92983de00548fcc7bbc50dd7544ba
|
|
Improve AMI message processing performance if there are no consumers
listening for the messages. We now skip creating the AMI event message
text strings.
Change-Id: I7b22fc5ec4e500d00635c1a467aa8ea68a1bb2b3
|
|
* Made ast_manager_event_blob_create() not allocate the ao2 event object
with a lock as it is not needed.
Change-Id: I8e11bfedd22c21316012e0b9dd79f5918f644b7c
|
|
An earlier allocation failure failed to create a channel snapshot for the
AMI HangupRequest/SoftHangupRequest event which resulted in a crash in
channel_hangup_request_cb(). Where the stasis message gets generated
cannot tell if the NULL snapshot returned was because of an allocation
failure or the channel was a dummy channel.
* Made channel_hangup_request_cb() check if the channel blob has a
snapshot and exit if it doesn't.
* Eliminated the RAII_VAR usage in channel_hangup_request_cb().
Change-Id: I0b6a1c4e95cbb7d80b2a7054c6eadecc169dfd24
|
|
You cannot reference the passed in features struct after calling
ast_bridge_impart(). Even if the call fails.
Change-Id: I902b88ba0d5d39520e670fb635078a367268ea21
|
|
softmix_bridge_join() failed because of an allocation failure. To address
this, the softmix bridge technology now checks if the channel failed to
join softmix successfully. In addition, the bridge now begins the process
of kicking the channel out of the bridge so we don't have channels
partially in the bridge for very long.
* Fix the test_channel_feature_hooks.c unit tests. The test channel must
have a valid codec to join the simple_bridge technology. This patch makes
joining a bridge more strict by not allowing partially joined channels to
remain in the bridge.
Change-Id: I97e2ade6a2bcd1214f24fb839fda948825b61a2b
|
|
res_odbc was changed in Asterisk 13.8.0 to remove connection management,
opting instead to let unixodbc maintain open connections and return
those to Asterisk as requested.
This was a boon for realtime, since it meant that multiple threads could
potentially run parallel queries since they could each be using their
own database connections.
However, on the user-facing side, func_odbc, there were some inherent
behaviors being relied on that no longer hold true after the change.
One such reported behavior was that MySQL's LAST_INSERTED_ID() works
per-connection. This means that if Asterisk uses separate connections
for every database operation, whereas before it used one connection for
everything, we have broken expectations and functionality.
The fix provided in this patch is to make func_odbc use a single
database connection per DSN. This way, user-facing database usage will
have the same behavior as it did pre-13.8.0. However, realtime, which is
the real workhorse of database interaction, will continue to let
unixodbc manage connections.
ASTERISK-25938 #close
Reported by Edwin Vandamme
Change-Id: Iac961fe79154c6211569afcdfec843c0c24c46dc
|
|
Option was removed in commit 7f883ef495b57ae9182e47213d01d5e8009dbf3f
ASTERISK-25927 #close
Change-Id: I92f9b0196d9fc41d1d58354c07340c465ef1fcf8
|
|
into 13
|
|
*lt is NULL if t->tracking == 0
ASTERISK-25948 #close
Change-Id: I4a81af28f9c82a74aa82413d772a7dc8fa6f45ba
|
|
We lose the fact that there is a swap channel if there is one. We
currently wind up rejoining the stasis bridge as a normal join after the
swap channel has already been kicked from the bridge.
This patch preserves the swap channel so the AMI/ARI events can note that
the channel joining the bridge is swapping with another channel. Another
benefit to swaqpping in one operation is if there are any channels that
get lonely (MOH, bridge playback, and bridge record channels). The lonely
channels won't leave before the joining channel has a chance to come back
in under stasis if the swap channel is the only reason the lonely channels
are staying in the bridge.
ASTERISK-25947 #close
Reported by: Richard Mudgett
ASTERISK-24649
Reported by: John Bigelow
ASTERISK-24782
Reported by: John Bigelow
Change-Id: If37ea508831d1fed6dbfac2f191c638fc0a850ee
|
|
An earlier patch blocked the ast_bridge_impart() call until the channel
either entered the target bridge or it failed. Unfortuantely, if the
target bridge is stasis and the imprted channel is not a stasis channel,
stasis bounces the channel out of the bridge to come back into the bridge
as a proper stasis channel. When the channel is bounced out, that
released the block on ast_bridge_impart() to continue. If the impart was
a result of a transfer, then it became a race to see if the swap channel
would get hung up before the imparted channel could come back into the
stasis bridge. If the imparted channel won then everything is fine. If
the swap channel gets hung up first then the transfer will fail because
the swap channel is leaving the bridge.
* Allow a chain of ast_bridge_impart()'s to happen before any are
unblocked to prevent the race condition described above. When the channel
finally joins the bridge or completely fails to join the bridge then the
ast_bridge_impart() instances are unblocked.
ASTERISK-25947
Reported by: Richard Mudgett
ASTERISK-24649
Reported by: John Bigelow
ASTERISK-24782
Reported by: John Bigelow
Change-Id: I8fef369171f295f580024ab4971e95c799d0dde1
|
|
into 13
|
|
When create_new_id_hdr creates a new RPID or PAI header, it starts by cloning
the From header, then it overwrites the display name and uri from the channel's
connected.id. If the connected.id.name wasn't valid, create_new_id_hdr was
leaving the display name from the From header in the new RPID or PAI header.
On an attended transfer where the originator had a caller id number set but not
a display name, the re-INVITE to the final transferee had the number of the
originator but the display name of the transferer.
Added a check to clear out the display name in the new header if
connected.id.name was invalid.
ASTERISK-25942 #close
Change-Id: I60b4bf7a7ece9b7425eba74151c0b4969cd2738b
|
|
into 13
|
|
This module is used as part of testsuite tests to confirm
stuff works. I'm accordingly marking it as core as it is
required by those tests.
Change-Id: I558e7af7679b22b8ed641d7dd37ee4ca35b11e88
|
|
The PJSIP parsing functions provide a nice concise way to check the
length of a hostname in a SIP URI. The problem is that in order to use
those parsing functions, it's required to use them from a thread that
has registered with PJLib.
On startup, when parsing AOR configuration, the permanent URI handler
may not be run from a PJLib-registered thread. Specifically, this could
happen when Asterisk was started in daemon mode rather than
console-mode. If PJProject were compiled with assertions enabled, then
this would cause Asterisk to crash on startup.
The solution presented here is to do our own parsing of the contact URI
in order to ensure that the hostname in the URI is not too long. The
parsing does not attempt to perform a full SIP URI parse/validation,
since the hostname in the URI is what is important.
ASTERISK-25928 #close
Reported by Joshua Colp
Change-Id: Ic3d6c20ff3502507c17244a8b7e2ca761dc7fb60
|
|
|
