4780 Commits (3913dcbc40039ca3c1942b7300fc45daeb4970ea)

Author	SHA1	Message	Date
Kevin P. Fleming	b36f0b9340	revert accidental commit ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	2c027162a2	Use proper hostname for downloading sound files. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218497 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	395e431ab6	Fix handling of DAHDI_EVENT_REMOVED event to prevent crash in do_monitor. ... After talking to rmudgett about some of his recent iflist locking changes, it was determined that the only place that would destroy a channel without being explicitly to do so was in handle_init_event. The loop to walk the interface list has been modified to wait to destroy the channel until the dahdi_pvt of the channel to be destroyed is no longer needed. (closes issue #15378) Reported by: samy git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@218401 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	fb591b9f93	Backport realtime fix to 1.4 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217917 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	92acf5ac29	IAX2 encryption regression ... The IAX2 Call Token security patch inadvertently broke the use of encryption due to the reorganization of code in the socket_process() function. When encryption is used, an incoming full frame must first be decrypted before the information elements can be parsed. The security release mistakenly moved IE parsing before decryption in order to process the new Call Token IE. To resolve this, decryption of full frames is once again done before looking into the frame. This involves searching for an existing callno, checking the pvt to see if encryption is turned on, and decrypting the packet before the internal fields of the full frame are accessed. associated with AST-2009-006 (closes issue #15834) Reported by: karesmakro Patches: iax2_encryption_fix_1.4.diff uploaded by dvossel (license 671) Tested by: dvossel, karesmakro Review: https://reviewboard.asterisk.org/r/355/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217806 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Olle Johansson	b546a14a99	Remove harmful code that causes endless loops. ... Remove code that causes loops in registrations. We have agreed that the patch that this code was part of was bad. I am ripping out the code that causes the issue. putnopvut needs to check the rest of the patch, if it needs to be changed as well. This solves the issue reported in #15540, but needs more work before we close it (as described above). git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@217668 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Michiel van Baak	da349b0e75	make chan_sip compile under devmode again ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216432 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Olle Johansson	05899c19a1	Make apps send PROGRESS control frame for early media and fix too early media issue in SIP ... The issue at hand is that some legacy (dying) PBX systems send empty media frames on PRI links *before* any call progress. The SIP channel receives these frames and by default signals 183 Session progress and starts sending media. This will cause phones to play silence and ignore the later 180 ringing message. A bad user experience. The fix is twofold: - We discovered that asterisk apps that support early media ("noanswer") did not send any PROGRESS frame to indicate early media. Fixed. - We introduce a setting in chan_sip so that users can disable any relay of media frames before the outbound channel actually indicates any sort of call progress. In 1.4, 1.6.0 and 1.6.1, this will be disabled for backward compatibility. In later versions of Asterisk, this will be enabled. We don't assume that it will change your Asterisk phone experience - only for the better. We encourage third-party application developers to make sure that if they have applications that wants to send early media, add a PROGRESS control frame transmission to make sure that all channel drivers actually will start sending early media. This has not been the default in Asterisk previous to this patch, so if you got inspiration from our code, you need to update accordingly. Sorry for the trouble and thanks for your support. This code has been running for a few months in a large scale installation (over 250 servers with PRI and/or BRI links to old PBX systems). That's no proof that this is an excellent patch, but, well, it's tested :-) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216430 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	ed1951d895	Merge code associated with AST-2009-006 ... (closes issue #12912) Reported by: rathaus Tested by: tilghman, russell, dvossel, dbrooks git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@216000 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Terry Wilson	82b1e162e1	Re-send non-100 provisional responses to prevent cancellation ... From section 13.3.1.1 of RFC 3261: If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an "extension" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. (closes issue #11157) Reported by: rjain Tested by: twilson Review: https://reviewboard.asterisk.org/r/315/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@215682 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	fa27e8dffa	Also unlock the "other" channel, when returning, due to glare. ... (closes issue #15787) Reported by: tim_ringenbach Patches: chan_local.diff uploaded by tim ringenbach (license 540) Tested by: tim_ringenbach git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@214940 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	79221dad8d	Ensure that T.38 INVITEs generated by Asterisk properly result in T.38 being enabled. ... (closes issue #15373) Reported by: dcolombo Patches: chan_sip.patch uploaded by mbrancaleoni (license 342) Tested by: dcolombo, mbrancaleoni git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@213631 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	309898993f	Removed some deadwood and added some doxygen comments. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212727 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	d924b5349e	Fix segfault when reloading chan_misdn. ... If more ports were specified than configured in misdn.conf a reload would crash asterisk. The problem was the unconfigured port was using data from the previously configured port. When the data for an unconfigured port was freed a crash would result from the double free. (closes issue #12113) Reported by: agupta Patches: bug12113.patch uploaded by jpeeler (license 325) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212498 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	00de2431be	Fix uninitialized variable. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@212430 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	ad76c40551	Backport fix so that outbound CANCEL requests have same branch as challenged INVITEs. ... There already was code present to be sure that a CANCEL will contain the same branch-id as the INVITE it is cancelling. However, for INVITES which are challenged downstream, this mechanism did not work properly. Now this is taken care of. This is a backport of a fix already present in all 1.6.X branches and in trunk. It also fixes ABE-1907. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@211807 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	63cc189747	AST-2009-005 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@211528 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	20d63bd1c0	Dialplan starts execution before the channel setup is complete. ... * Issue 15655: For the case where dialing is complete for an incoming call, dahdi_new() was asked to start the PBX and then the code set more channel variables. If the dialplan hungup before these channel variables got set, asterisk would likely crash. * Fixed potential for overlap incoming call to erroneously set channel variables as global dialplan variables if the ast_channel structure failed to get allocated. * Added missing set of CALLINGSUBADDR in the dialing is complete case. (closes issue #15655) Reported by: alecdavis git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210575 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Brooks	29f865ad17	Fixes dialplan wildcard extension taking precedence over call pickup code. ... Prior to this patch, a wildcard extension in the dialplan (for example, _*.) would take precedence over picking up a call in the channel's pickup group. This patch simply moves the block of code handling pickup group matching to above the extension matching code. (closes issue #14735) Reported by: stevedavies Review: https://reviewboard.asterisk.org/r/319/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210067 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Tilghman Lesher	ca0f026f41	Reverting index() fix, applying a different methodology, based upon developer discussions. ... (related to issue #15639) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@210066 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	b5bea3704c	Minor changes inspired by testing with latest GCC. ... The latest GCC (what will become 4.5.x) has a few new warnings, that in these cases found some either downright buggy code, or at least seriously poorly designed code that could be improved. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@209759 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	f622e06bbe	Fix logic errors from 208746 ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208923 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	fc5db2b241	Fix compiling under dev-mode with gcc 4.4.0. ... Mostly trivial changes, but I did not know of any other way to fix the "dereferencing type-punned pointer will break strict-aliasing rules" error without creating a tmp variable in chan_skinny. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208746 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	38e98f42bc	Only send a BYE when hanging up a channel that is up. ... For cases where Asterisk sends an INVITE and receives a non 2XX final response, Asterisk would follow the INVITE transaction by immediately sending a BYE, which was unnecessary. (closes issue #14575) Reported by: chris-mac git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208587 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	1c46ba9635	Fix a problem where a 491 response could be sent out of dialog. ... This generalizes the fix for issue 13849. The initial fix corrected the problem that Asterisk would reply with a 491 if a reinvite were received from an endpoint and we had not yet received an ACK from that endpoint for the initial INVITE it had sent us. This expansion also allows Asterisk to appropriately handle an INVITE with authorization credentials if Asterisk had not received an ACK from the previous transaction in which Asterisk had responded to an unauthorized INVITE with a 407. (closes issue #14239) Reported by: klaus3000 Patches: 14239.patch uploaded by mmichelson (license 60) Tested by: klaus3000 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208386 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	594a236e12	Only set the priindication setting when not performing a reload ... (closes issue #14696) Reported by: fdecher git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208380 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	94bc859e81	Remove inaccurate XXX comment. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208312 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	eb5f3170fc	Properly handle 183 responses which do not contain an SDP. ... (closes issue #15442) Reported by: ffloimair Patches: 15442.patch uploaded by mmichelson (license 60) Tested by: tkarl, ffloimair git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@208262 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	e07afa4876	Wait for wink before dialing when using E&M wink signaling ... There was already code for other signaling types in dahdi_handle_event to handle dialing if a dial operation dial string was present. Simply add SIG_EMWINK to the list. (closes issue #14434) Reported by: araasch git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207827 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	dca651b85d	Revert r207573, this approach could potentially block for an unacceptable ... amount of time. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207786 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Kevin P. Fleming	75f1eaf2a1	Ensure that user-provided CFLAGS and LDFLAGS are honored. ... This commit changes the build system so that user-provided flags (in ASTCFLAGS and ASTLDFLAGS) are supplied to the compiler/linker *after* all flags provided by the build system itself, so that the user can effectively override the build system's flags if desired. In addition, ASTCFLAGS and ASTLDFLAGS can now be provided *either* in the environment before running 'make', or as variable assignments on the 'make' command line. As a result, the use of COPTS and LDOPTS is no longer necessary, so they are no longer documented, but are still supported so as not to break existing build systems that supply them when building Asterisk. git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207647 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	8b940dbeb7	Wait for wink before dialing when using E&M wink signaling ... This patch adds a new dahdi_wait function to specifically wait for the wink event. If the wink is not eventually received the channel is hung up. (closes issue #14434) Reported by: araasch Patches: emwinkmod uploaded by araasch (license 693) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207573 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	423a444c0b	Answer video SDP offers properly when videosupport is not enabled. ... Copied from Review board: In issue 12434, the reporter describes a situation in which audio and video is offered on the call, but because videosupport is disabled in sip.conf, Asterisk gives no response at all to the video offer. According to RFC 3264, all media offers should have a corresponding answer. For offers we do not intend to actually reply to with meaningful values, we should still reply with the port for the media stream set to 0. In this patch, we take note of what types of media have been offered and save the information on the sip_pvt. The SDP in the response will take into account whether media was offered. If we are not otherwise going to answer a media offer, we will insert an appropriate m= line with the port set to 0. It is important to note that this patch is pretty much a bandage being applied to a broken bone. The patch *only* helps for situations where video is offered but videosupport is disabled and when udptl_pt is disabled but T.38 is offered. Asterisk is not guaranteed to respond to every media offer. Notable cases are when multiple streams of the same type are offered. The 2 media stream limit is still present with this patch, too. In trunk and the 1.6.X branches, things will be a bit different since Asterisk also supports text in SDPs as well. (closes issue #12434) Reported by: mnnojd Review: https://reviewboard.asterisk.org/r/311 Review: https://reviewboard.asterisk.org/r/313 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207423 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	d162e4b055	Fix format specifier to print out an unsigned long long. ... Yep, it's even ifdefed out code. But it made it to the RR list... (closes issue #14726) Reported by: lmadsen git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207155 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Jeff Peeler	1e30dcf61c	Enhance configuration option for overlapdial allowing direction choice ... Previously overlap dialing could only be turned on or off for both incoming and outgoing calls. New parameters incoming, outgoing, and both have been added to allow further control. There is no change in default behavior with these new options and allows in band DTMF to be accepted in one direction if required. (closes issue #14471) Reported by: eboscani git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207092 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	98a6820737	sip option flags handled incorrectly ... (issue #15376) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@207033 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	7c82de7d7e	SIP incorrect From: header information when callpres is prohib ... Some ITSP make use of the "Anonymous" display name to detect a requirement to withhold caller id across the PSTN. This does not work if the display name is "Unknown". (closes issue #14465) Reported by: Nick_Lewis Patches: chan_sip.c-callerpres.patch uploaded by Nick (license 657) chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671) Tested by: Nick_Lewis, dvossel git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206938 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	7782df0963	Merged revision 206700 from ... https://origsvn.digium.com/svn/asterisk/be/branches/C.2-... .......... Fixed chan_misdn crash because mISDNuser library is not thread safe. With Asterisk the mISDNuser library is driven by two threads concurrently: 1. channels/misdn/isdn_lib.c::manager_event_handler() 2. channels/misdn/isdn_lib.c::misdn_lib_isdn_event_catcher() Calls into the library are done concurrently and recursively from isdn_lib.c. Both threads can fiddle with the master/child layer3_proc_t lists. One thread may traverse the list when the other interrupts it and then removes the list element which the first thread was currently handling. This is exactly what caused the crash. About 60 calls were needed to a Gigaset CX475 before it occurred once. This patch adds locking when calling into the mISDNuser library. This also fixes some cb_log calls with wrong port parameter. JIRA ABE-1913 Patches: misdn-locking.patch (Modified with mostly cosmetic changes) .......... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206706 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	6db6a73b8d	Fixes several call transfer issues with chan_misdn. ... * issue #14355 - Crash if attempt to transfer a call to an application. Masquerade the other pair of the four asterisk channels involved in the two calls. The held call already must be a bridged call (not an applicaton) or it would have been rejected. * issue #14692 - Held calls are not automatically cleared after transfer. Allow the core to initate disconnect of held calls to the ISDN port. This also fixes a similar case where the party on hold hangs up before being transferred or taken off hold. * JIRA ABE-1903 - Orphaned held calls left in music-on-hold. Do not simply block passing the hangup event on held calls to asterisk core. * Fixed to allow held calls to be transferred to ringing calls. Previously, held calls could only be transferred to connected calls. * Eliminated unused call states to simplify hangup code. * Eliminated most uses of "holded" because it is not a word. (closes issue #14355) (closes issue #14692) Reported by: sodom Patches: misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664) Tested by: rmudgett git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206487 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Russell Bryant	8d5516a153	Merged revisions 206384 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.2 ........ r206384 | russell | 2009-07-14 09:45:47 -0500 (Tue, 14 Jul 2009) | 6 lines Ensure apathetic replies are sent out on the proper socket. chan_iax2 supports multiple address bindings. The send_apathetic_reply() function did not attempt to send its response on the same socket that the incoming message came in on. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206385 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	9f3cd22c7a	Fix some memory leaks in chan_misdn. ... JIRA ABE-1911 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@206284 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	12b5e7706c	Properly ACK 487 responses to canceled INVITEs. ... From the review board request: The fix from review 298 has exposed a new bug in chan_sip. When we hang up an outgoing call, we first will dump all the outstanding packets on the sip_pvt using __sip_pretend_ack. Then, if we can, we send a CANCEL. The problem with this is that since destroyed all the outstanding packets on the dialog, we cannot match the incoming 487 response to our INVITE. Because we cannot match the response, we do not send an ACK. To correct this, instead of using __sip_pretend_ack, I have changed the code to loop through the list of packets and call __sip_semi_ack on each one instead. This causes us to stop retransmitting the requests, but we still have them around in case we get responses for them. When discussing this earlier today with Josh Colp, we both agreed that in the majority of cases, this would be enough of a fix. However, we also agreed that we should have a safety net in place in case we never receive a response to our initial INVITE. To handle this, I have modified __sip_autodestruct to behave similar to the way it does in Asterisk 1.4. If there are outstanding packets on the sip_pvt, the needdestroy flag is not set, and the last request on the dialog was either a CANCEL or BYE, then we set the needdestroy flag and reschedule destruction for 10 seconds in the future. If, though, the needdestroy flag is set, then we use __sip_pretend_ack to kill the remaining outstanding packets so that the monitor thread can destroy the sip_pvt. I ran two separate tests. First, I placed a call from my Aastra phone to my Polycom phone. I hung up the Aastra before the Polycom answered. I verified through sip debug output that Asterisk properly ACKed the 487 received from the Polycom. For my second test, I set up a SIPp UAS scenario so that it would send a 200 OK in response to a CANCEL but would not send a 487 for the original INVITE. I verified that after about 40 seconds, Asterisk properly cleans up the outgoing sip_pvt for the call. Review: https://reviewboard.asterisk.org/r/308 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205877 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	1678f43bfa	SIP registration auth loop caused by stale nonce ... If an endpoint sends two registration requests in a very short period of time with the same nonce, both receive 401 responses from Asterisk, each with a different nonce (the second 401 containing the current nonce and the first one being stale). If the endpoint responds to the first 401, it does not match the current nonce so Asterisk sends a third 401 with a newly generated nonce (which updates the current nonce)... Now if the endpoint responds to the second 401, it does not match the current nonce either and Asterisk sends a fourth 401 with a newly generated nonce... This loop goes on and on. There appears to be a simple fix for this. If the nonce from the request does not match our nonce, but is a good response to a previous nonce, instead of sending a 401 with a newly generated nonce, use the current one instead. This breaks the loop as the nonce is not updated until a response is received. Additional logic has been added to make sure no nonce can be responded to twice though. (closes issue #15102) Reported by: Jamuel Patches: patch-bug_0015102 uploaded by Jamuel (license 809) nonce_sip.diff uploaded by dvossel (license 671) Tested by: Jamuel Review: https://reviewboard.asterisk.org/r/289/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205804 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	43a5245325	Ensure that outbound NOTIFY requests are properly routed through stateful proxies. ... With this change, we make note of Record-Route headers present in any SUBSCRIBE request that we receive so that our outbound NOTIFY requests will have the proper Route headers in them. (closes issue #14725) Reported by: ibc git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205775 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	fb1c512a40	No audio on calls from Asterisk to various ISDN devices until DTMF sent by caller. ... Add missing clearing of the dialing flag when the ISDN call is CONNECTED. (i.e. When libpri generates the event PRI_EVENT_ANSWER.) (closes issue #15420) Reported by: scottbmilne Patches: bug15420-1.4.25.1-diff2.txt uploaded by alecdavis (license 585) Tested by: scottbmilne, alecdavis (closes issue #15416) Reported by: avinoash (closes issue #15389) Reported by: alecdavis This patch should also fix the following issue: (issue #15205) Reported by: vinsik git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205728 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
David Vossel	beaf6217b3	Fixes 8khz assumptions ... Many calculations assume 8khz is the codec rate. This is not always the case. This patch only addresses chan_iax.c and res_rtp_asterisk.c, but I am sure there are other areas that make this assumption as well. Review: https://reviewboard.asterisk.org/r/306/ git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@205471 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Richard Mudgett	202f9967c6	Removed confusing warning message "Got Busy in Connected State" ... If an incoming mISDN call is answered with the Answer application and a subsequent Dial gets a busy endpoint then it is valid for that already connected channel to get the busy indication. Asterisk will play the busy tones until the dialplan plays something else or hangs up the call. (closes issue #11974) Reported by: fvdb git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204834 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	e5bef05d8f	Add error message so that it is clear why a SIP peer was not processed when ... a DNS lookup fails on a host or outboundproxy. (closes issue #13432) Reported by: p_lindheimer Patches: outboundproxy.patch uploaded by p (license 558) git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204300 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	439ce618c5	Fix build oops. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204246 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago
Mark Michelson	9589d9fb2e	Fix a problem where chan_sip would ignore "old" but valid responses. ... chan_sip has had a problem for quite a long time that would manifest when Asterisk would send multiple SIP responses on the same dialog before receiving a response. The problem occurred because chan_sip only kept track of the highest outgoing sequence number used on the dialog. If Asterisk sent two requests out, and a response arrived for the first request sent, then Asterisk would ignore the response. The result was that Asterisk would continue retransmitting the requests and ignoring the responses until the maximum number of retransmissions had been reached. The fix here is to rearrange the code a bit so that instead of simply comparing the sequence number of the response to our latest outgoing sequence number, we walk our list of outstanding packets and determine if there is a match. If there is, we continue. If not, then we ignore the response. In doing this, I found a few completely useless variables that I have now removed. (closes issue #11231) Reported by: flefoll Review: https://reviewboard.asterisk.org/r/298 git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.4@204243 65c4cc65-6c06-0410-ace0-fbb531ad65f3	17 years ago