2854 Commits (110927bacc40706a110ad5d9f94e2eb85d8b9710)

Author	SHA1	Message	Date
Richard Mudgett	110927bacc	res_sorcery_memory_cache.c: Misc tweaks. ... Change-Id: I8cd32dffbb4f33bb0c39518d6e4c991e73573160	10 years ago
Richard Mudgett	14ac763ab3	res_sorcery_memory_cache.c: Made use OBJ_SEARCH_MASK. ... Change-Id: Ibca6574dc3c213b29cc93486e01ccd51f5caa46c	10 years ago
Matthew Jordan	39fe210fd9	res/res_pjsip_dlg_options: Add a module to handle in-dialog OPTIONS requests ... 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) Change-Id: Iefc901a7c5c88d9d4b853188f85092d9eb7b6ada	10 years ago
Mark Michelson	deccd2ef3c	Resolve race conditions involving Stasis bridges. ... This resolves two observed race conditions. First, a bit of background on what the Stasis application does: 1a Creates a stasis_app_control structure. This structure is linked into a global container and can be looked up using a channel's unique ID. 2a Puts the channel in an event loop. The event loop can exit either because the stasis_app_control structure has been marked done, or because of some other factor, such as a hangup. In the event loop, the stasis_app_control determines if any specific ARI commands need to be run on the channel and will run them from this thread. 3a Checks if the channel is bridged. If the channel is bridged, then ast_bridge_depart() is called since channels that are added to Stasis bridges are always imparted as departable. 4a Unlink the stasis_app_control from the container. When an ARI command is received by Asterisk, the following occurs 1b A thread is spawned to handle the HTTP request 2b The stasis_app_control(s) that corresponds to the channel(s) in the request is/are retrieved. If the stasis_app_control cannot be retrieved, then it is assumed that the channel in question has exited the Stasis app or perhaps was never in Stasis in the first place. 3b A command is queued onto the stasis_app_control, and the channel's event loop thread is signaled to run the command. 4b While most ARI commands do nothing further, some, such as adding or removing channels from a bridge, will block until the command they issued has been completed by the channel's event loop. The first race condition that is solved by this patch involves a crash that can occur due to faulty detection of the channel's bridged status in step 3a. What can happen is that in step 2a, the event loop may run the ast_bridge_impart() function to asynchronously place the channel into a bridge, then immediately exit the event loop because the channel has hung up. In step 3a, we would detect that the channel was not bridged and would not call ast_bridge_depart(). The reason that the channel did not appear to be bridged was that the depart_thread that is spawned by ast_bridge_impart() had not yet started. That is the thread where the channel is marked as being bridged. Since we did not call ast_bridge_depart(), the Stasis application would exit, and then the channel would be destroyed Then the depart_thread would start up and try to manipulate the destroyed channel, causing a crash. The fix for this is to switch from using ast_channel_is_bridged() to checking the NULLity of ast_channel_internal_bridge_channel() to determine if ast_bridge_depart() needs to be called. The channel's internal bridge_channel is set when ast_bridge_impart() is called and is NULLed by the call to ast_bridge_depart(). If the channel's internal bridge_channel is non-NULL, then the channel must have been imparted into the bridge and needs to be departed, even if the actual bridging operation has not yet started. By departing the channel when necessary, the thread that is running the Stasis application will block until the bridge gives the okay that the depart_thread has exited. The second race condition that is solved by this patch involves a leak of HTTP handler threads. The problem was that step 2b would successfully retrieve a stasis_app_control structure. Then step 2a would exit the channel from the event loop due to a hangup. Steps 3a and 4a would execute, and then finally steps 3b and 4b would. The problem is that at step 4b, when attempting to add a channel to a bridge, the thread would block forever since the channel would never execute the queued command since it was finished with the event loop. This meant that the HTTP handling thread would be leaked, along with any references that thread may have owned (in my case, I was seeing bridges leaked). The fix for this is to hone in better on when the channel has exited the event loop. The stasis_app_control structure has an is_done field that is now set at each point where the channel may exit the event loop. If step 2b retrieves a valid stasis_app_control structure but the control is marked as done, then the attempted operation exits immediately since there will be nothing to service the attempted command. ASTERISK-25091 #close Reported by Ilya Trikoz Change-Id: If66265b73b4c9f8f58599124d777fedc54576628	10 years ago
Mark Michelson	20702e0cf2	res_pjsip_pubsub: Eliminate race during initial NOTIFY. ... There is a slim chance of a race condition occurring where two threads can both attempt to manipulate the same area. Thread A can be handling an incoming initial SUBSCRIBE request. Thread A lets the specific subscription handler know that the subscription has been established. At this point, Thread B may detect a state change on the subscribed resource and queue up a notification task on Thread C, the subscription serializer thread. Now Thread A attempts to generate the initial NOTIFY request to send to the subscriber at the same time that Thread C attempts to generate a state change NOTIFY request to send to the subscriber. The result is that Threads A and C can step on the same memory area, resulting in a crash. The crash has been observed as happening when attempting to allocate more space to hold the body for the NOTIFY. The solution presented here is to queue the subscription establishment and initial NOTIFY generation onto the subscription serializer thread (Thread C in the above scenario). This way, there is no way that a state change notification can occur before the initial NOTIFY is sent, and if there is a quick succession of NOTIFYs, we can guarantee that the two NOTIFY requests will be sent in succession. Change-Id: I5a89a77b5f2717928c54d6efb9955e5f6f5cf815	10 years ago
Mark Michelson	8826e6c416	res_pjsip: Copy default_from_user to avoid crash. ... The default_from_user retrieval function was pulling the default_from_user from the global configuration struct in an unsafe way. If using a database as a backend configuration store, the global configuration struct is short-lived, so grabbing a pointer from it results in referencing freed memory. The fix here is to copy the default_from_user value out of the global configuration struct. Thanks go to John Hardin for discovering this problem and proposing the patch on which this fix is based. ASTERISK-25390 #close Reported by Mark Michelson Change-Id: I6b96067a495c1259da768f4012d44e03e7c6148c	10 years ago
George Joseph	943d5c0c99	res_pjsip: Validate that contact uris start with sip: or sips: ... 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 (cherry picked from commit 75666ad7c6)	10 years ago
Jonathan Rose	7b5bcbeebe	ParkAndAnnounce: Add variable inheritance ... In Asterisk 11, the announcer channel would receive channel variables from the channel being parked by means of normal channel inheritance. This functionality was lost during the big res_parking project in Asterisk 12. This patch restores that functionality. ASTERISK-25369 #close Review: https://gerrit.asterisk.org/#/c/1180/ Change-Id: Ie47e618330114ad2ea91e2edcef1cb6f341eed6e	10 years ago
Mark Michelson	500856b4f0	res_pjsip: Change default from user value. ... When Asterisk sends an outbound SIP request, if there is no direct reason to place a specific value for the username in the From header, Asterisk would generate a UUID. For example, this would happen when sending outbound OPTIONS requests when qualifying or when sending outbound INVITE requests when originating (if no explicit caller ID were provided). The issue is that some SIP providers reject these sorts of requests with a "Name too long" error response. This patch aims to fix this by changing the default outbound username in From headers to "asterisk". This value can be overridden by changing the default_from_user option in the global options if desired. ASTERISK-25377 #close Reported by Mark Michelson Change-Id: I6a4d34a56ff73ff4f661b0075aeba5461b7f3190	10 years ago
Mark Michelson	a1e1d8e815	res_pjsip: Fix contact refleak on stateful responses. ... When sending a stateful response, creation of the transaction can fail, most commonly because we are trying to create a transaction from a retransmitted request. When creation of the transaction fails, we end up leaking a reference to a contact that was bumped when the response was created. This patch adds the missing deref and fixes the reference leak. Change-Id: I2f97ad512aeb1b17e87ca29ae0abacb4d6395f07	10 years ago
Richard Mudgett	1c89230e2a	PJSIP XML, XPIDF: Fix buffer size overwrite memory corruption error. ... When res_pjsip body generator modules were generating XML or XPIDF response bodies, there was a chance that the generated body would be the exact size of the supplied buffer. Adding the nul string terminator would then write beyond the end of the buffer and potentially corrupt memory. * Fix MALLOC_DEBUG high fence violations caused by adding a nul string terminator on the end of a buffer for XML or XPIDF response bodies. * Made calls to pj_xml_print() safer if the XML prolog is requested. Due to a bug in pjproject, the return value could be -1 _or_ AST_PJSIP_XML_PROLOG_LEN if the supplied buffer is not large enough. * Updated the doxygen comment of AST_PJSIP_XML_PROLOG_LEN to describe the return value of pj_xml_print() when the supplied buffer is not large enough. ASTERISK-25168 Reported by: Carl Fortin Change-Id: Id70e1d373a6a2b2bd9e678b5cbc5e55b308981de	10 years ago
Mark Michelson	2f2c35e91d	res_pjsip_pubsub: re-re-fix persistent subscription storage. ... A recent change to res_pjsip_pubsub switched to using pjsip_msg_print as a means of writing an appropriate packet to persistent storage. While this partially solved the issue, it had its own problems. pjsip_msg_print will always add a Content-Length header to the message it prints. Frequent restarts of Asterisk can result in persistent subscriptions being written with five or more Content-Length headers. In addition, sometimes some apparent corruption of individual headers could be seen. This aims to fix the problem by not running a parsed message through an interpreter but rather by taking the raw message and saving it. The logic for what to save is going to be different depending on whether a SUBSCRIBE was received from the wire or if it was pulled from persistence. When receiving a packet from the wire, when using a streaming transport, the rdata->pkt_info.packet may contain multiple SIP messages or fragments. However, the rdata->msg_info.msg_buf will always contain the current SIP message to be processed. When pulling from persistence, though, the rdata->msg_info.msg_buf will be NULL since no transport actually handled the packet. However, since we know that we will always ever pull one SIP message from persistence, we are free to save directly from rdata->pkt_info.packet instead. ASTERISK-25365 #close Reported by Mark Michelson Change-Id: I33153b10d0b4dc8e3801aaaee2f48173b867855b	10 years ago
Joshua Colp	8842637d8f	res_pjsip_sdp_rtp: Fix multiple keepalive scheduled items. ... The keepalive support in res_pjsip_sdp_rtp currently assumes that a stream will only be negotiated once. This is false. If the stream is replaced and later added back it can be negotiated again causing multiple keepalive scheduled items to exist. This change explicitly deletes the existing keepalive scheduled item before adding the new one. The res_pjsip_sdp_rtp module also does not stop RTP keepalives or timeout timer if the stream has been replaced. This change adds a callback to the session media interface to allow a media stream to be stopped without the resources being destroyed. This allows the scheduled items and RTP to be stopped when the stream no longer exists. ASTERISK-25356 #close Change-Id: Ibe6a7cc0927c87326fd5f1c0d4ad889dbfbea1de	10 years ago
Joshua Colp	942d0ba96f	res_pjsip: Add common ast_sip_get_host_ip API. ... Modules commonly used the pj_gethostip function for retrieving the IP address of the host. This function does not cache the result and may result in a DNS lookup occurring, or additional work. If the DNS server is unreachable or network issues arise this can cause the pj_gethostip function to block for a period of time. This change adds an ast_sip_get_host_ip and ast_sip_get_host_ip_string function which does the same thing but caches the host IP address at module load time. This results in no additional work being done each time the local host IP address is needed. ASTERISK-25342 #close Change-Id: I3205deb679b01fa5ac05a94b623bfd620a2abe1e	10 years ago
Joshua Colp	4083e543fd	res_pjsip_pubsub: On recreated notify fail deleted sub_tree is referenced ... When recreating a subscription it is possible for a freed sub_tree to be referenced when the initial NOTIFY fails to be created. Change-Id: I681c215309aad01b21d611c2de47b3b0a6022788	10 years ago
Scott Griepentrog	0b04269e73	res_pjsip_pubsub: On notify fail deleted sub_tree is then referenced ... 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 (cherry picked from commit 8d4ce7cc2b)	10 years ago
Mark Michelson	f049ad951b	res_pjsip_sdp_rtp: Restore removed NULL check. ... When sending an RTP keepalive, we need to be sure we're not dealing with a NULL RTP instance. There had been a NULL check, but the commit that added the rtp_timeout and rtp_hold_timeout options removed the NULL check. Change-Id: I2d7dcd5022697cfc6bf3d9e19245419078e79b64	10 years ago
Joshua Colp	7089472637	res_http_websocket: When shutting down a session don't close closed socket ... Due to the use of ast_websocket_close in session termination it is possible for the underlying socket to already be closed when the session is terminated. This occurs when the close frame is attempted to be written out but fails. Change-Id: I7572583529a42a7dc911ea77a974d8307d5c0c8b	10 years ago
Joshua Colp	28a98b9715	Merge "res_http_websocket: Forcefully terminate on write errors." into certified/13.1	10 years ago
Joshua Colp	128d2348e6	res_http_websocket: Forcefully terminate on write errors. ... The res_http_websocket module will currently attempt to close the WebSocket connection if fatal cases occur, such as when attempting to write out data and being unable to. When the fatal cases occur the code attempts to write a WebSocket close frame out to have the remote side close the connection. If writing this fails then the connection is not terminated. This change forcefully terminates the connection if the WebSocket is to be closed but is unable to send the close frame. ASTERISK-25312 #close Change-Id: I10973086671cc192a76424060d9ec8e688602845	10 years ago
Richard Mudgett	739fca6084	res_pjsip.c: Fix crash from corrupt saved SUBSCRIBE message. ... If the saved SUBSCRIBE message is not parseable for whatever reason then Asterisk could crash when libpjsip tries to parse the message and adds an error message to the parse error list. * Made ast_sip_create_rdata() initialize the parse error rdata list. The list is checked after parsing to see that it remains empty for the function to return successful. ASTERISK-25306 Reported by Mark Michelson Change-Id: Ie0677f69f707503b1a37df18723bd59418085256	10 years ago
Joshua Colp	eae9adcc1f	Merge "res_pjsip: Ensure sanitized XML is NULL terminated." into certified/13.1	10 years ago
Mark Michelson	bfb15bea06	res_pjsip_pubsub: More accurately persist packet. ... The pjsip_rx_data structure has a pkt_info.packet field on it that is the packet that was read from the transport. For datagram transports, the packet read from the transport will correspond to the SIP message that arrived. For streamed transports, however, it is possible to read multiple SIP messages in one packet. In a recent case, Asterisk crashed on a system where TCP was being used. This is because at some point, a read from the TCP socket resulted in a 200 OK response as well as an incoming SUBSCRIBE request being stored in rdata->pkt_info.packet. When the SUBSCRIBE was processed, the combination 200 OK and SUBSCRIBE was saved in persistent storage. Later, a restart of Asterisk resulted in the crash because the persistent subscription recreation code ended up building the 200 OK response instead of a SUBSCRIBE request, and we attempted to access request-specific data. The fix here is to use the pjsip_msg_print() function in order to persist SUBSCRIBE requests. This way, rather than using the raw socket data, we use the parsed SIP message that PJSIP has given us. If we receive multiple SIP messages from a single read, we will be sure only to save off the relevant SIP message. There also is a safeguard put in place to make sure that if we do end up reconstructing a SIP response, it will not cause a crash. ASTERISK-25306 #close Reported by Mark Michelson Change-Id: I4bf16f7b76a2541d10b55de82bcd14c6e542afb2	10 years ago
Joshua Colp	9e93ad109b	res_pjsip: Ensure sanitized XML is NULL terminated. ... The ast_sip_sanitize_xml function is used to sanitize a string for placement into XML. This is done by examining an input string and then appending values to an output buffer. The function used by its implementation, strncat, has specific behavior that was not taken into account. If the size of the input string exceeded the available output buffer size it was possible for the sanitization function to write past the output buffer itself causing a crash. The crash would either occur because it was writing into memory it shouldn't be or because the resulting string was not NULL terminated. This change keeps count of how much remaining space is available in the output buffer for text and only allows strncat to use that amount. Since this was exposed by the res_pjsip_pidf_digium_body_supplement module attempting to send a large message the maximum allowed message size has also been increased in it. A unit test has also been added which confirms that the ast_sip_sanitize_xml function is providing NULL terminated output even when the input length exceeds the output buffer size. ASTERISK-25304 #close Change-Id: I743dd9809d3e13d722df1b0509dfe34621398302	10 years ago
Richard Mudgett	f6dcbd9707	res_pjsip_session: Fix double re-INVITE collision crash. ... 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/ Change-Id: Ib05700c3a13ceac53b17d66099ef0d296a5e1863	10 years ago
Mark Michelson	4350fd22c8	Fix problem where a hung channel could occur on a failed blind transfer. ... Different clients react differently to being told that a blind transfer has failed. Some will simply send a BYE and be done with it. Others will attempt to reinvite themselves back onto the call. In the latter case, we were creating a new channel and then leaving it to sit forever doing nothing. With this code change, that new channel will not be created and the dialog with the transferring channel will be cleaned up properly. ASTERISK-24624 #close Reported by Zane Conkle Review: https://reviewboard.asterisk.org/r/4339 Change-Id: I76e440e08e603c1eea40a14951e7b171c0472a55	10 years ago
Joshua Colp	fae081ad5b	pjsip: Add rtp_timeout and rtp_timeout_hold endpoint options. ... This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold' endpoint options. These allow the channel to be hung up if RTP is not received from the remote endpoint for a specified number of seconds. ASTERISK-25259 #close Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9	10 years ago
Joshua Colp	44c1eaf343	Merge "res_pjsip: Add rtp_keepalive endpoint option." into certified/13.1	10 years ago
Mark Michelson	d66abb6746	res_pjsip: Add rtp_keepalive endpoint option. ... This adds an "rtp_keepalive" option for PJSIP endpoints. Similar to the chan_sip option, this specifies an interval, in seconds, at which we will send RTP comfort noise frames. This can be useful for keeping RTP sessions alive as well as keeping NAT associations alive during lulls. ASTERISK-25242 #close Reported by Mark Michelson Change-Id: I683bdc206c8c7def586ecaa64dcf2b86550be3bf	10 years ago
Richard Mudgett	131f6ef8f5	res_parking: Fix crash if ATTENDEDTRANSFER set empty before Park. ... setup_park_common_datastore() was assuming that a non-NULL string returned for the ATTENDEDTRANSFER and BLINDTRANSFER channel variables are not empty strings. Things got crashy as a result. * Made setup_park_common_datastore() treat the channel variable values the same whether they are NULL or empty for ATTENDEDTRANSFER and BLINDTRANSFER. ASTERISK-25254 #close Reported by: Richard Mudgett Change-Id: I9a9c174b33f354f35f82cc6b7cea8303adbaf9c2	10 years ago
Mark Michelson	c8d53f2372	res_sorcery_memory_cache: Remove ASTERISK_REGISTER_FILE() macro. ... This was part of the backport of res_sorcery_memory_cache from master but will not compile in 13. Change-Id: I27b3d833acda9dd1770fdbe594964197b93779b0	10 years ago
Joshua Colp	a72cf6ce81	res_sorcery_memory_cache: Execute stale unit test last. ... In Jenkins there is currently a sporadic test failure of a variable number of sorcery memory cache unit tests. I have not been able to reproduce this on the build agents themselves or on my development machine. My working theory is that the stale unit test is causing a sorcery instance to persist longer than expected, causing subsequent tests to fail when setting up and initializing the next sorcery instance. To see if this is the case this change moves the stale unit test to execute last so no subsequent unit tests can have issues initializing their sorcery instance. Change-Id: Ifd6550a949613be774b75fa5db12c02110f82c4a	10 years ago
Joshua Colp	e0cd8216bb	res_sorcery_memory_cache: Remove 'prefetch' option. ... To prevent confusion I am removing the prefetch option until such time as it is implemented. All other functionality, however, has been implemented. ASTERISK-25067 Change-Id: I9ce6aa3e5c6c5bc3c5baa8ff90fa036d73939895	10 years ago
Joshua Colp	8b2bad7740	test_sorcery_memory_cache_thrash: Add unit tests for thrashing the memory cache. ... This change adds a CLI command which can perform memory cache thrashing as well as unit tests which perform thrashing under the following configurations: 1. Low number of unique objects that go stale after 1 second 2. Low number of unique objects that expire after 1 second 3. Low number of unique objects which are constantly updated 4. Large number of unique objects which exceed a defined cache size 5. Large number of unique objects which exceed a defined cache size that also expire and go stale rapidly 6. Large number of unique objects which expire and go stale rapidly 7. Large number of unique objects For all of the above there are a large number of threads constantly attempting to retrieve random objects and each test runs for a few seconds. ASTERISK-25067 Reported by: Matt Jordan Change-Id: I8c8ceff977332c80ed4a31f10d694d48552b2f78	10 years ago
Joshua Colp	8575c4f18d	res_sorcery_memory_cache: Implement expire_on_reload option. ... This change implements the expire_on_reload option for memory caches. If enabled and a reload is performed all objects within the cache will be expired and the cache emptied. ASTERISK-25067 Reported by: Matt Jordan Change-Id: Id46aa1957d660556700e689e195eed57c989b85e	10 years ago
Joshua Colp	da52527136	res_sorcery_memory_cache: Add test event when a refresh occurs. ... This change adds a testsuite event for when a refresh occurs. This is useful as it provides a guaranteed mechanism of knowing when it has occurred instead of waiting an arbitrary amount of time. ASTERISK-25067 Reported by: Matt Jordan Change-Id: Iaa6b8d2d6bab7f99ee08e1c8908b8272a8987e65	10 years ago
Joshua Colp	f596b4a85c	res_sorcery_memory_cache: Add CLI commands and AMI actions. ... This change adds the following CLI commands and AMI actions: sorcery memory cache show sorcery memory cache dump sorcery memory cache expire sorcery memory cache stale SorceryMemoryCacheExpire SorceryMemoryCacheExpireObject SorceryMemoryCacheStale SorceryMemoryCacheStaleObject These allow both examination and manipulation of sorcery memory caches from external sources. Cached objects can be explicitly expired from a cache or marked as stale. If expired they are immediately removed. If marked as stale they will be background refreshed when next retrieved. ASTERISK-25067 Reported by Matt Jordan Change-Id: I68e03cfd8c34b5e07f4b6ee4fd93a3f4a00a3d9e	10 years ago
Mark Michelson	9c2de310be	res_sorcery_memory_cache: Add support for refreshing stale objects. ... This change introduces a check of object_lifetime_stale when retrieving cached objects. If the amount of time the object has been in the cache exceeds the lifetime, then a task is scheduled to update the cached object based on an object retrieved from other sorcery wizards instead. To prevent the cached object from being retrieved during a refresh, thread-local storage is used to mark the thread as being a stale object update. This results in the cache returning no object, leading to sorcery querying other wizards for the object instead. A test has been added for stale objects as well. This test ensures that stale objects are retrieved the same as freshly-cached objects. The test also ensures that after an object is stale, changes in the backend are reflected in the cache, to include if the object has been deleted from the backend. ASTERISK-25067 Reported by Matt Jordan Change-Id: I9bd7c049adf6939bfe2899f393c2bfbbf412d217	10 years ago
Joshua Colp	9a7fccc50c	res_sorcery_memory_cache: Add support for object_lifetime_maximum. ... This makes the "object_lifetime_maximum" option operational. On the addition of an object to an empty memory cache a scheduled task is created which, when invoked, expires objects from the cache which have exceeded their lifetime. If more objects have been added the remaining life of the oldest object is used to schedule the next invocation of the scheduled task. If the oldest object is removed from the cache before it can be expired automatically the scheduled task is cancelled, if possible, and the lifetime of the next oldest is used to schedule the task. If during these two operations no additional objects exist in the cache then no task is scheduled. An additional unit test has been added which verifies this functionality. ASTERISK-25067 Reported by: Matt Jordan Change-Id: I87409674674a508e7717ee20739ca15cec6ba7b6	10 years ago
Mark Michelson	9ae9221d2b	res_sorcery_memory_cache: Add support for maximum_objects. ... This makes the "maximum_objects" option operational. A heap has been added alongside the hash table in the cache. When objects are added to the cache, they are also added to the heap. Similarly, when objects are removed from the cache, they are removed from the heap. The heap's use comes into play when an item is to be added to a "full" cache. When the cache is full, the oldest item is removed from the cache, using the heap to determine the oldest item. A unit test has been added that verifies that the maximum_objects option works as expected and that the oldest object is removed from the cache when an object beyond the maximum is added. ASTERISK-25067 #close Reported by Matt Jordan Change-Id: I490658830e9c4cbf0b3051e4cdc4913cf9f1b73a	10 years ago
Joshua Colp	e4d42119b5	res_sorcery_memory_cache: Add basic module implementation. ... This change adds a basic res_sorcery_memory_cache module which implements configuration option parsing, configuration file parsing for threading, sorcery interface implementation, and unit tests. Objects can be added, updated, deleted, and retrieved from the memory cache. Automatic expiration and stale handling will be added in the future. Note that unit tests exist within the module itself in case the threading done as a result of expiration results in asynchronous actions (which it likely will). Providing access and a notification mechanism for an external test module would be complicated and not worth it. ASTERISK-25067 #close Reported by: Matt Jordan Change-Id: Id8a6a357ef5a83d466f81eee56a67d13eeb118b9	10 years ago
Joshua Colp	d9e2d5b417	Merge "res/res_corosync: Always decline module load, instead of failing" into certified/13.1	10 years ago
George Joseph	f58c0acfa2	res/res_corosync: Always decline module load, instead of failing ... Returns a 'failure' from the module load routine indicates to Asterisk that it should abort loading completely. This is rarely - in fact, really, never - a good option. Aborting load of Asterisk from a dynamic module implies that the core, and the rest of the dynamic modules, don't matter: we should abandon all processing. res_corosync is really not that important. This patch updates the module such that, if it fails to load, it politely declines (emitting ERROR messages along the way), and allows Asterisk to continue to function. Note that this issue was keeping Asterisk unit tests from running on certain build agents. Change-Id: I252249e81fb9b1a68e0da873f54f47e21d648f0f	10 years ago
Mark Michelson	9cbd76630a	res_sorcery_realtime: Fix leak of sorcery object type. ... This prevents a leak of a sorcery object type when realtime sorcery objects are retrieved by fields or when multiple objects are retrieved. The extent of this leak is that sorcery object types would be leaked. These are allocated whenever an object type is registered with sorcery, meaning that on module shutdown, these objects would be leaked. This could be problematic if many reloads were performed, but it is not as severe as if every sorcery object retrieved from realtime were being leaked. ASTERISK-25165 #close Reported by Corey Farrell Change-Id: I625c3b50eee4576670b7eeb013c81ad043b4b4f8	10 years ago
Mark Michelson	8ba3de43ad	res_pjsip_nat: Adjust when contact should be rewritten. ... A previous change made the contact only get rewritten if the dialog's route set was not marked frozen. Unfortunately, while the intent of this is correct, the dialog's route set actually gets marked as frozen earlier than expected, especially for UAS dialogs. Instead, the idea is that the contact needs to not be rewritten if there is a pre-existing route set on the dialog. This is now accomplished by checking the dialog's route set list instead of checking if the route set is frozen. Doing this causes some broken tests to begin passing again. ASTERISK-25196 Reported by Mark Michelson Change-Id: I525ab251fd40a52ede327a52a2810a56deb0529e	10 years ago
Mark Michelson	56077bb1b0	Merge "res_pjsip_mwi: Set up unsolicited MWI upon registration." into certified/13.1	10 years ago
Mark Michelson	20f50131d7	res_pjsip_refer: Prevent sending duplicate headers. ... res_pjsip_refer will attempt to add Referred-By or Replaces headers to outbound INVITEs at times. If the INVITE gets challenged for authentication, then we will resend the INVITE. Prior to this patch, the Referred-By or Replaces header would be re-added to the outbound INVITE, resulting in duplicated headers. ASTERISK-25204 #close Reported by Mark Michelson Change-Id: I59fb5c08b4d253c0dba9ee3d3950b5025358222d	10 years ago
Mark Michelson	0d535df734	res_pjsip_nat: Rewrite route set when required. ... When performing some provider testing, the rewrite_contact option was interfering with proper construction of a route set when sending an ACK after receiving a 200 OK response to an INVITE. The initial INVITE was sent to address sip:foo. The 200 OK had a Contact header with URI sip:bar. In addition, the 200 OK had Record-Route headers for sip:baz and sip:foo, in that order. Since the Record-Route headers had the lr parameter, the result should have been: * Set R-URI of the ACK to sip:bar. * Add Route headers for sip:foo and sip:baz, in that order. However, the rewrite_contact option resulted in our rewriting the Contact header on the 200 OK to sip:foo. The result was: * R-URI remained sip:foo. * We added Route headers for sip:foo and sip:baz, in that order. The result was that sip:bar was not indicated in the ACK at all, so the far end never received our ACK. The call eventually dropped. The intention of rewrite_contact is to rewrite the most immediate destination of our SIP request to be the same address on which we received a request or response. In the case of processing a SIP response with Record-Route headers, this means that instead of rewriting the Contact header, we should instead rewrite the bottom-most Record-Route header. In the case of processing a SIP request with Record-Route headers, this means we rewrite the top-most Record-route header. Like when we rewrite the Contact header, we also ensure to update the dialog's route set if it exists. ASTERISK-25196 #close Reported by Mark Michelson Change-Id: I9702157c3603a2d0bd8a8215ac27564d366b666f	10 years ago
Joshua Colp	a35d6feae2	res_pjsip_mwi: Set up unsolicited MWI upon registration. ... The res_pjsip_mwi previously required a reload to set up the proper subscriptions to allow unsolicited MWI to work. This change makes it so the act of registering will also cause this to occur. This is particularly useful if realtime is involved as no reload needs to occur within Asterisk to cause the MWI information to get sent. ASTERISK-25180 #close Change-Id: Id847b47de4b8b3ab8858455ccc2f07b0f915f252	10 years ago
Mark Michelson	5f954e1e00	res_pjsip: Prevent access of NULL channels. ... It is possible to receive incoming requests or responses after the channel on an ast_sip_session has been destroyed and NULLed out. Handlers of these sorts of requests or responses need to be prepared for the possibility that the channel is NULL or else they could cause a crash. While several places have been amended to deal with NULL channels, there were still a couple of places that needed updating. res_pjsip_dtmf_info.c: When handling incoming INFO requests, we need to return early if there is no channel on the session. res_pjsip_session.c: When handling a 302 response, we need to stop the redirecting attempt if there is no channel on the session. ASTERISK-25148 #close reported by Mark Michelson Change-Id: Id1a75ffc3d0eaa168b0b28188fb54d6cf9fc47a9	10 years ago