- Mar 22, 2021
-
-
Joshua C. Colp authored
When using the ast_unreal_lock_all function no channel locks can be held before calling it. This change unlocks the channel that indicate was called on before doing so and then relocks it afterwards. ASTERISK-29035 Change-Id: Id65016201b5f9c9519a216e250f9101c629e19e9
-
Joshua C. Colp authored
Some configuration items for a transport do not result in the underlying transport changing, but instead are just state we keep ourselves and use. It is perfectly reasonable to change these items. These include local_net and external_* information. ASTERISK-29354 Change-Id: I027857ccfe4419f460243e562b5f098434b3d43a
-
- Mar 19, 2021
-
-
Jaco Kroon authored
ASTERISK-29348 Change-Id: I77e3466435f5a51a57538b29addb68d811af238d Signed-off-by:
Jaco Kroon <jaco@uls.co.za>
-
- Mar 17, 2021
-
-
Joshua C. Colp authored
When an SSRC change occurs the timestamps are likely to change as well. As a result we need to reset the timestamp mapping done in the calc_rxstamp function so that they map properly from timestamp to real time. This previously occurred but due to packet retransmission support the explicit setting of the marker bit was not effective. ASTERISK-29352 Change-Id: I2d4c8f93ea24abc1030196706de2d70facf05a5a
-
Joshua C. Colp authored
The "deprecated_in" and "removed_in" information can now be set in MODULEINFO for a module and is then displayed in menuselect so users can be aware of when a module is slated to be deprecated and then removed. ASTERISK-29337 Change-Id: I6952889cf08e0e9e99cf8b43f99b3cef4688087a
-
- Mar 16, 2021
-
-
Joshua C. Colp authored
Some modules have a different support level documented in their MODULEINFO XML and Asterisk module definition. This change brings the two in sync for the modules which were not matching. ASTERISK-29336 Change-Id: If2f819103d4a271e2e0624ef4db365e897fa3d35
-
Joshua C. Colp authored
ASTERISK-29337 Change-Id: I2211b7da8d29369f8649aeabce07679da0787f2b
-
Joshua C. Colp authored
This change embeds the MODULEINFO block of modules into the core XML documentation. This provides a shared mechanism for use by both menuselect and Asterisk for information and a definitive source of truth. ASTERISK-29335 Change-Id: Ifbfd5c700049cf320a3e45351ac65dd89bc99d90
-
- Mar 11, 2021
-
-
Kevin Harwell authored
ASTERISK~29244 added three new AMI events, so bump the version number. Change-Id: I0e77fa36d38fb27dec3481d4ef08131330da0632
-
Asterisk Development Team authored
-
- Mar 10, 2021
-
-
Joshua C. Colp authored
There exists an inconsistency with framehook usage such that it is only on reads that the frame should be freed, not on writes as well. ASTERISK-29071 Change-Id: I5ef918ebe4debac8a469e8d43bf9d6b673e8e472
-
Jaco Kroon authored
Change-Id: I75152cece8a00b7523d542e5ac22796f9595692b Signed-off-by:
Jaco Kroon <jaco@uls.co.za>
-
Jaco Kroon authored
Change-Id: I5c104dc1f8417ccd3d01faf86e84ccbf89bc3b31 Signed-off-by:
Jaco Kroon <jaco@uls.co.za>
-
Sean Bright authored
ASTERISK-29329 #close Change-Id: Ic58e7a17f1ff3f785a5b21dced88682581149601
-
Alexander Traud authored
see RFC 4855: parameter names are case-insensitive both in media type strings and in the default mapping to the SDP a=fmtp attribute. This change is required for H.263+ because some implementations are known to use even mixed-case. This does not fix ASTERISK~29268 because H.264 was not fixed. This approach here lowers/uppers both parameter names and parameter values. H.264 needs a different approach because one of its parameter values is not case-insensitive: sprop-parameter-sets is Base64. Change-Id: Idf2a73457be231647aed3c87b1da197afba86892
-
Alexander Traud authored
The system header strings was included mistakenly with commit 3de02044. That header is included via asterisk.h and there via the compat.h. Change-Id: I3dc49060e275295f785670c87cc65fd3c3abd24a
-
Sean Bright authored
ASTERISK-24434 #close Change-Id: I0144e8d65d878128da59dcf3df12ca8cee47d6db
-
Sean Bright authored
Because they modify their argument they are not pure functions and should not be marked as such, otherwise the compiler may optimize them away. ASTERISK-29306 #close Change-Id: Ibec03a08522dd39e8a137ece9bc6a3059dfaad5f
-
- Mar 08, 2021
-
-
Sean Bright authored
ao2_replace() bumps the reference count of the object that is doing the replacing, which is not what we want. We just want to drop the old ref on the old object and update the pointer to point to the new object. Pointed out by George Joseph in #asterisk-dev Change-Id: Ie8167ed3d4b52b9d1ea2d785f885e8c27206743d
-
Torrey Searle authored
For RTCP to work, we update the ssrc to be the one corresponding to the native bridge while active. However when the bridge ends we should generate a new SSRC as the sequence numbers will not continue from the native bridge left off. ASTERISK-29300 #close Change-Id: I23334b6934d2bf6490bda4bbf6414d96b8d17d10
-
- Mar 05, 2021
-
-
Joshua C. Colp authored
Some sorcery objects actually contain dynamic content that can change despite the underlying configuration itself not changing. A good example of this is the res_pjsip_endpoint_identifier_ip module which allows specifying hostnames. While the configuration may not change between reloads the DNS information of the hostnames can. This change adds the ability for a sorcery object to be marked as having dynamic contents which is then taken into account when reloading by the sorcery file based config module. If there is an object with dynamic content then a reload will be forced while if there are none then the existing behavior of not reloading occurs. ASTERISK-29321 Change-Id: I9342dc55be46cc00204533c266a68d972760a0b1
-
George Joseph authored
Although the dlg session count was incremented in a pjsip servant thread, there's no guarantee that the last thread to unref this progress object was one. Before we decrement, we need to make sure that this is either a servant thread or that we push the decrement to a serializer that is one. Because pjsip_dlg_dec_session requires the dialog lock, we don't want to wait on the task to complete if we had to push it to a serializer. Change-Id: I8ff2d5d94be3ff04298394070434e22a7d3cbc41
-
Joshua C. Colp authored
When registering it can be useful to see the source IP address and port in cases where multiple devices are using the same endpoint or when anonymous is in use. ASTERISK-29325 Change-Id: Ie178a6f55f53f8473035854c411bc3d056e0a2e0
-
- Mar 04, 2021
-
-
Joshua C. Colp authored
ASTERISK-29326 Change-Id: Ia95dbfb66e2d11ac4d1228444283bb2e4d77396a
-
Ben Ford authored
When Asterisk sends a reinvite negotiating T38 faxing, it's possible a crash can occur if the response contains a m=image and zero port. The reinvite callback code now checks session_media to see if it is null or not before trying to access the udptl variable on it. ASTERISK-29305 Change-Id: I1dfc51c5fa586e38579ede4bc228edee213ccaa9
-
- Mar 03, 2021
-
-
Alexander Traud authored
Fixed: * RFC 4629 does not allow the value "0" for MPI, K, and N. * Allow value "0" for PAR. * BPP is printed only when specified because "0" has a meaning. New: * Added CPCF and MaxBR. * Some implementations provide CIF without MPI: a=fmtp:xx CIF;F=1 Although a violation of RFC 3555 section 3, we can support that. Changed: * Resorts the CIFs from large to small which partly fixes ASTERISK~29267. Change-Id: I95a650c715007b8dde11a77cb37d9c6c123a441e
-
Joshua C. Colp authored
When sending a SIP response to an incoming REGISTER request we don't want to change the Contact header as it will contain the Contacts registered to the AOR and not our own Contact URI. ASTERISK-29235 Change-Id: I35a0723545281dd01fcd5cae497baab58720478c
-
Joshua C. Colp authored
A frame suppression API exists as part of channels which allows audio frames to or from a channel to be dropped. The MuteAudio AMI action uses this API to perform its job. This API uses a framehook to intercept flowing audio and drop it when appropriate. It is the responsibility of the framehook to free the frame it is given if it changes the frame. The suppression API failed to do this resulting in a leak of audio frames. This change adds the freeing of these frames. ASTERISK-29071 Change-Id: Ie50acd454d672d36af914050c327d2e120d8ba7b
-
Salah Ahmed authored
This change will check is the remote ICE session got reset or not by checking the offered ufrag and password with session. If the remote ICE reset session then Asterisk reset its local ufrag and password to reject binding request with Old ufrag and Password. ASTERISK-29266 Change-Id: I9c55e79a7af98a8fbb497d336b828ba41bc34eeb
-
- Mar 02, 2021
-
-
Holger Hans Peter Freyther authored
ASTERISK-29105 Change-Id: If1615fe7115fe544ef974b044d3cea5c48b94a38
-
Nico Kooijman authored
Implemented the english way of saying the year in ast_say_date_with_format_nl. Currently the numbers are spoken correctly until 2020 and stopped working this year. ASTERISK-29297 #close Reported-by: Jacek Konieczny Change-Id: If5918eed5ab05df31df4dd23f08a909a60f6aba4
-
Nick French authored
If set_outbound_initial_authentication_credentials() fails, handle_client_registration() bails early without creating or sending a register message. [set_outbound_initial_authentication_credentials() failures can occur during the process of retrieving an oauth access token.] The return from handle_client_registration is ignored, so returning an error doesn't do any good. This is a real problem when the registration request is a re-register, because then the registration will still be marked 'active' despite the re-register never being sent at all. So instead, log a warning but let the registration be created and sent (and probably fail) and follow the normal registration failed retry/abort logic. ASTERISK-29315 #close Change-Id: I2e03b1ea7fba1fa1a8279086aa4b17679e7fa7fa
-
Alexei Gradinari authored
If the remote Station ID contains invalid UTF-8 characters the asterisk fails to publish the Stasis and ReceiveFax status messages. json.c: Error building JSON from '{s: s, s: s}': Invalid UTF-8 string. 0: /usr/sbin/asterisk(ast_json_vpack+0x98) [0x4f3f28] 1: /usr/sbin/asterisk(ast_json_pack+0x8c) [0x4f3fcc] 2: /usr/sbin/asterisk(ast_channel_publish_varset+0x2b) [0x57aa0b] 3: /usr/sbin/asterisk(pbx_builtin_setvar_helper+0x121) [0x530641] 4: /usr/lib64/asterisk/modules/res_fax.so(+0x44fe) [0x7f27f4bff4fe] ... stasis_channels.c: Error creating message json.c: Error building JSON from '{s: s, s: s, s: s, s: s, s: s, s: s, s: o}': Invalid UTF-8 string. 0: /usr/sbin/asterisk(ast_json_vpack+0x98) [0x4f3f28] 1: /usr/sbin/asterisk(ast_json_pack+0x8c) [0x4f3fcc] 2: /usr/lib64/asterisk/modules/res_fax.so(+0x5acd) [0x7f27f4c00acd] ... res_fax.c: Error publishing ReceiveFax status message This patch replaces the invalid UTF-8 Station IDs with an empty string. ASTERISK-29312 #close Change-Id: Ieb00b6ecf67db3bfca787649caa8517f29d987db
-
- Feb 26, 2021
-
-
Sean Bright authored
ASTERISK-16799 #close Change-Id: I40367b0d6dbf66a39721bde060c8b2d734a61cf4
-
George Joseph authored
Although refer_progress_notify() always runs in the progress serializer, the pjproject evsub module itself can cause the subscription to be destroyed which then triggers refer_progress_on_evsub_state() to clean it up. In this case, it's possible that refer_progress_notify() could get the subscription pulled out from under it while it's trying to use it. At one point we tried to have refer_progress_on_evsub_state() push the cleanup to the serializer and wait for its return before returning to pjproject but since pjproject calls its state callbacks with the dialog locked, this required us to unlock the dialog while waiting for the serialized cleanup, then lock it again before returning to pjproject. There were also still some cases where other callers of refer_progress_notify() weren't using the serializer and crashes were resulting. Although all callers of refer_progress_notify() now use the progress serializer, we decided to simplify the locking so we didn't have to unlock and relock the dialog in refer_progress_on_evsub_state(). Now, refer_progress_notify() holds the dialog lock for its duration and since pjproject also holds the dialog lock while calling refer_progress_on_evsub_state() (which does the cleanup), there should be no more chances for the subscription to be cleaned up while still being used to send NOTIFYs. To be extra safe, we also now increment the session count on the dialog when we create a progress object and decrement the count when the progress is destroyed. ASTERISK-29313 Change-Id: I97a8bb01771a3c85345649b8124507f7622a8480
-
Kevin Harwell authored
For some RTCP packet types the report count is actually the packet's subtype. This was not being reflected in the packet debug output. This patch makes it so for some RTCP packet types a "Packet Subtype" is now output in the debug replacing the "Reception reports" (i.e count). Change-Id: Id4f4b77bb37077a4c4f039abd6a069287bfefcb8
-
- Feb 25, 2021
-
-
Boris P. Korzun authored
Added a SELECT 'LIMIT' clause to realtime_pgsql() and refactored the function. ASTERISK-29293 #close Change-Id: If5a6d4b1072ea2e6e89059b21139d554a74b34f5
-
Ben Ford authored
Removes an unnecessary check for the conditional that compares the stream topologies to see if they are equal to suppress re-invites. This was a problem when a Digium phone received an INVITE that offered codecs different than what it supported, causing Asterisk to send the re-invite. ASTERISK-29303 Change-Id: I04dc91befb2387904e28a9aaeaa3bcdbcaa7fa63
-
Jaco Kroon authored
Also improve the in-process documentation to clarify that the value is initialised from the DSN and not default false, but that the DSN's value is default false if unset. ASTERISK-29311 #close Change-Id: I46e2379f7b0656034442bce77cb37ccd4e61098d Signed-off-by:
Jaco Kroon <jaco@uls.co.za>
-
Joshua C. Colp authored
When PJSIP receives a re-INVITE without an SDP offer the INVITE session library will first call the on_create_offer callback and if unavailable then use the active negotiated SDP as the offer. In some cases this would result in a different SDP then was previously used without an incremented SDP version number. The two known cases are: 1. Sending an initial INVITE with a set of codecs and having the remote side answer with a subset. The active negotiated SDP would have the pruned list but would not have an incremented SDP version number. 2. Using re-INVITE for unhold. We would modify the active negotiated SDP but would not increment the SDP version. To solve these, and potential other unknown cases, the on_create_offer callback has now been implemented which produces a fresh offer with incremented SDP version number. This better fits within the model provided by the INVITE session library. ASTERISK-28452 Change-Id: I2d81048d54edcb80fe38fdbb954a86f0a58281a1
-