- Nov 25, 2015
-
-
Walter Doekes authored
Several issues are addressed here: - main() is large, and half of it is only used if we're not rasterisk; fixed by spliting up the daemon part into a separate function. - Call ast_term_init from rasterisk as well. - Remove duplicate code reading/writing asterisk history file. - Attempt to tackle background color issues and color changes that occur. Tested by starting asterisk -c until the colors stopped changing at odd locations. ASTERISK-25585 #close Change-Id: Ib641a0964c59ef9fe6f59efa8ccb481a9580c52f
-
- Nov 24, 2015
-
-
Corey Farrell authored
The usage info for 'pjsip send notify' previously referenced the chan_sip configuration sip_notify.conf. Fix this to reference the correct configuration pjsip_notify.conf. ASTERISK-25590 #close Change-Id: I3898271a8e8a8b1db201741e790ebe2c6bf5cdea
-
Joshua Colp authored
-
Mark Michelson authored
-
- Nov 23, 2015
-
-
Richard Mudgett authored
If the sorcery object type is not found a NULL is returned. Unfortunately, sorcery_realtime_filter_objectset() will crash after complaining about not finding the object type and saying to expect errors. * Use ao2_cleanup() instead of ao2_ref() to prevent the crash. ASTERISK-25165 Reported by Corey Farrell Change-Id: Ic3b64453ea3058cb68d5c26d97d4fe7b8eea2e97
-
Matt Jordan authored
-
Matt Jordan authored
-
Matt Jordan authored
-
Matt Jordan authored
-
Matt Jordan authored
-
Matt Jordan authored
-
Matt Jordan authored
When a channel is in a direct media bridge, a re-INVITE may arrive that forces Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge must change its technology to a simple bridge, and re-INVITE the media back to Asterisk. Generally, this logic mostly already exists in Asterisk. However, prior to this patch, there were a few bugs: (1) The T.38 framehook currently prevents a channel capable of T.38 faxes from ever entering into a direct media bridge. This applies even when the only media being passed over the channel is audio. This patch fixes this bug by having the framehook specify that it defers caring about any frame type. This allows the channels to enter into a direct media bridge, which will be broken when a re-INVITE is received. (2) When a re-INVITE is received, nothing instructed the bridging layer to re-inspect the allowed bridging technology. This now occurs when either a re-INVITE is received from a peer, or when a response is received from the far end (that is, when the T.38 state changes to either T38_PEER_REINVITE or T38_LOCAL_REINVITE). (3) chan_pjsip needs to do a small amount of work to prevent a direct media bridge from being chosen when a T.38 session is in progress. When a T.38 session supplement has a t38 datastore - which is added when we detect we should start thinking about T.38 on a channel - we now refuse a native RTP bridge. (4) When a BYE request is received, we don't terminate the T.38 session. If the other side of a T.38 fax survives the hangup (due to the 'g' flag in Dial, for example), we don't currently re-INVITE the media on the other channel back to audio. This patch now has res_pjsip_t38 intercept BYE requests and inform the far side that the T.38 session is terminated. This naturally causes the correct re-INVITEs to be sent. ASTERISK-25582 Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
-
- Nov 21, 2015
-
-
Joshua Colp authored
-
Joshua Colp authored
-
Matt Jordan authored
-
Matt Jordan authored
This patch adds some debug statements to res_pjsip_t38. These statements help to determine which SDP negotiation callbacks are being executed, and, when a particular callback exits, why a callback may not have applied its logic to the local or remote SDP. Change-Id: I61b3fb9183b7ebbb5da8e9f48b59a5d9d7042d77
-
Matt Jordan authored
Because the context, extension, and application are stored in stringfields, checking for them being NULL doesn't work so well. This patch uses the appropriate string library call, ast_strlen_zero, to see if there is a value in the context/exten/app values. Change-Id: Ie09623bfdf35f5a8d3b23dd596647fe3c97b9a23
-
- Nov 20, 2015
-
-
Mark Michelson authored
-
Joshua Colp authored
-
- Nov 19, 2015
-
-
Matt Jordan authored
This patch adds a module that emits StatsD statistics about Asterisk endpoints. This includes: * A GUAGE statistic for endpoint states, tracking how many endpoints are in a particular state. * A GUAGE statistic for each endpoint, counting the number of channels currently associated with an endpoint. ASTERISK-25572 Change-Id: If7e1333c5aeda8d136850b30c2101c0ee1c97305
-
Matt Jordan authored
This patch adds the ability to send StatsD statistics related to the state of PJSIP contacts. This includes: * A GUAGE statistic measuring the count of contacts in a particular state. This measures how many contacts are reachable, unreachable, etc. * The RTT time for each contact, if those contacts are qualified. This provides StatsD engines useful time-based data about each contact. ASTERISK-25571 Change-Id: Ib8378d73afedfc622be0643b87c542557e0b332c
-
Matt Jordan authored
This patch adds outbound registration statistics for StatsD. This includes the following: * A GUAGE metric for the overall count of outbound registrations. * A GUAGE metric for each state an outbound registration can be in. As the outbound registrations change state, the overall count of how many outbound registrations are in the particular state is changed. These statistics are particularly useful for systems with a large number of SIP trunks, and where measuring the change in state of the trunks is useful for monitoring. ASTERISK-25571 Change-Id: Iba6ff248f5d1c1e01acbb63e9f0da1901692eb37
-
Matt Jordan authored
When Asterisk is configured to use a dynamic sorcery backend (such as res_sorcery_astdb) with 'registration' objects, it will fail to create the internal state objects associated with the registration objects on module load. This is due to nothing actually querying for the specific objects and calling their sorcery apply handler during module load. This patch fixes that by calling get_registrations in the sorcery observer's object_type_loaded handler. Doing this causes the sorcery backends to be asked for the current state of all registration objects, which causes the apply handler to be called and the internal run-time state to be created. ASTERISK-25575 #close Change-Id: Ie9306e797098c6d4da7bcf4a5434a15891508b23
-
Alexander Traud authored
Previously, a trancoding module did not have access to the joint but cached format. Therefore, the module did not have access to the attributes negotiated via SDP (line fmtp). Now, a translation module receives the joint format. ASTERISK-25545 #close Change-Id: Id6878a989b50573298dab115d3371ea369e1a718
-
Alexander Traud authored
When no parameter is present, Asterisk does not generate the line fmtp, as expected. However, because a buffer was reset, even rtpmap and fmtp of previous media codecs got removed. Now, Asterisk does not reset other codecs in case of no parameter for H.264. ASTERISK-25573 #close Change-Id: I93811331f4a28c45418a9e14ee46c0debd47a286
-
- Nov 18, 2015
-
-
Matt Jordan authored
Often, the metric names of statistics we are generating for StatsD have some dynamic component to them. This can be the name of a particular resource, or some internal status label in Asterisk. With the current set of functions, callers of the statsd API must first build the metric name themselves, then pass this to the API functions. This results in a large amount of boilerplate code and usage of either fixed length static buffers or dynamic memory allocation, neither of which is desireable. This patch adds two new functions to the StatsD API that support a printf style format specifier for constructing the metric name. A dynamic string, allocated in threadstorage, is used to build the metric name. This eases the burden on users of the StatsD API. Change-Id: If533c72d1afa26d807508ea48b4d8c7b32f414ea
-
Richard Mudgett authored
Change-Id: Ie16f5053ebde0dc6507845393709b4d6a3ea526d
-
Richard Mudgett authored
Receiving a 423 Interval Too Brief response after authentication for an outbound registration attempt results in assuming that the registrar has rejected the registration permanently. If there are no configured retries for fatal responses then the outbound registration is stopped for that endpoint. For registrations, PJSIP/PJPROJECT intercepts the handling of 423 responses and does not include any authentication in the updated registration request. When the updated request is challenged then the Asterisk code assumes that we were challenged again because the peer rejected the authentication we sent earlier. * Made registration challenges keep track of the CSeq number to determine if the received challenge response was for the request we thought we sent. If the response's CSeq number differs from the CSeq number we last sent with authentication then authenticate again because it is a challenge to a different request. Change-Id: I81b4bd36d1be095bab606e34b8b44e6302971b09
-
tcambron authored
Added a new api to res_statsd.c to allow it to receive a character pointer for the value argument. This allows for a '+' and a '-' to easily be sent with the value. ASTERISK-25419 Reported By: Ashley Sanders Change-Id: Id6bb53600943d27347d2bcae26c0bd5643567611
-
Matt Jordan authored
-
- Nov 17, 2015
-
-
Matt Jordan authored
-
Matt Jordan authored
-
Joshua Colp authored
-
- Nov 16, 2015
-
-
Matt Jordan authored
When a request is sent using pjsip_endpt_send_request and fails, a condition exists where the request wrapper, which is an AO2 object, may be de-ref'd more times than it should. This occurs when the request's callback is called, and, in the callback, the timer on the PJSIP heap is cancelled. When that occurs, the request wrapper's lifetime is decremented. When pjsip_endpt_send_request fails, we unilaterally decrement the lifetime of the request wrapper again, even though we've already cancelled the reference associated with the timer. This patch checks the return result of pj_timer_heap_cancel_if_active before removing the reference associated with the timer. We now only decrement it in this case if a timer is cancelled as a result of the function call. Change-Id: I21332343a1a019c1117076f9bf2df27be2850102
-
Mark Michelson authored
This option adds the ability to specify a timeout, in seconds, for a participant in a ConfBridge. When the user's timeout has been reached, the user is ejected from the conference with the CONFBRIDGE_RESULT channel variable set to "TIMEOUT". The rationale for this change is that there have been times where we have seen channels get "stuck" in ConfBridge because a network issue results in a SIP BYE not being received by Asterisk. While these channels can be hung up manually via CLI/AMI/ARI, adding some sort of automatic cleanup of the channels is a nice feature to have. ASTERISK-25549 #close Reported by Mark Michelson Change-Id: I2996b6c5e16a3dda27595f8352abad0bda9c2d98
-
Alec Davis authored
commit aae45acb (Mark Michelson 2015-04-15 10:38:02 -0500 6525) refer ASTERISK-24958 above commit removed ast_channel_lock(qe->chan); but failed to remove corresponding ast_channel_unlock(qe->chan); ASTERISK-25561 #close Reported Alec Davis Change-Id: Ie05f4e2d08912606178bf1fded57cc022c7a2e1a
-
- Nov 14, 2015
-
-
Joshua Colp authored
The hashtab API is pretty NULL tolerant which has resulted in remaining callers not doing much checks themselves. Unfortunately the function to destroy an iterator does not do a NULL check and will result in a crash if passed NULL. This change fixes that. ASTERISK-25552 #close Change-Id: Ic1bf8eec3639e5a440f1c941d3ae3893ac6ed619
-
- Nov 13, 2015
-
-
Richard Mudgett authored
If an authenticated incoming caller does not respond to our 200 OK INVITE response with an ACK then PJSIP will hangup the call. Unfortunately, there is a chance that the session's channel will go away between one use of the channel pointer and another when building the BYE request because the BYE is being built by the monitor thread and not the call's serializer thread. * Added a check to ensure that the thread trying to add the Reason header is the call's serializer thread. This ensures that the channel will not go away on us. Change-Id: I866388d2b97ea2032eaae3f3ab3f1ca6cbd2df89
-
Mark Michelson authored
In practical tests, we have seen certain taskprocessors, specifically Stasis subscription taskprocessors, cross the recently-added high-water mark and emit a warning. This high-water mark warning is only intended to be emitted when things have tanked on the system and things are heading south quickly. In the practical tests, the Stasis taskprocessors sometimes had a max depth of 180 tasks in them, and Asterisk wasn't in any danger at all. As such, this ups the high-water mark to 500 tasks instead. It also redefines the SIP threadpool request denial number to be a multiple of the taskprocessor high-water mark. Change-Id: Ic8d3e9497452fecd768ac427bb6f58aa616eebce
-
Alexander Traud authored
In Asterisk 13, cached formats are created before their corresponding format- attribute module is registered. Cached formats are involved when a local extension is called. Therefore, ast_format_generate_sdp_fmtp did not work on local extensions. This change affects the Opus Codec, H.263 (Plus), H.264, and format-attribute modules provided externally. ASTERISK-25160 #close Change-Id: I1ea1f0483e5261e2a050112e4ebdfc22057d1354
-