summaryrefslogtreecommitdiff
path: root/channels
AgeCommit message (Collapse)Author
2010-07-10Add support for devices with less than 3 lines on the LCD.Russell Bryant
(closes issue #17600) Reported by: minaguib Patches: ast_unistim_height_v2.patch uploaded by minaguib (license 1078) Tested by: minaguib git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275466 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Fix error in parsing SIP registry strings from ASTdb.Mark Michelson
It was essentially an off-by-one error. The easiest way to fix this was to use the handy-dandy AST_NONSTANDARD_RAW_ARGS macro to parse the pieces of the registration string out. Tested and it works wonderfully. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Get more information about the Bamboo test failuresTilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275312 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Fix port parsing in check_via.Mark Michelson
If a Via header contained an IPv6 address, we would not properly parse the port. We would instead get the information after the first colon in the address. (closes issue #17614) Reported by: oej Patches: diff uploaded by sperreault (license 252) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Fix an issue where the port for p->ourip was being set to 0.Mark Michelson
This should fix all the CDR tests that were not passing. When they would originate a call, all fields in the INVITE that contained the source port would have the port set to 0. Most troubling of these was the Contact header. Tests are passing locally now and should also pass on the bamboo build agents. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Merged revisions 275241 via svnmerge from Paul Belanger
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r275241 | pabelanger | 2010-07-09 15:20:00 -0400 (Fri, 09 Jul 2010) | 8 lines Fix logging message for stale nonce. (closes issue #17582) Reported by: kenner Patches: chan_sip.c.diff uploaded by kenner (license 1040) Tested by: lmadsen ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Weird, no output and Bamboo still fails...Tilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Add some diagnostic feedback to our data testsTilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275172 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Kill some startup warnings and errors and make some messages more helpful in ↵Tilghman Lesher
tracking down the source. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Return logic of sip_debug_test_addr() to its original functionality.Mark Michelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275104 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Fix sip_uri_parse test comparison.Mark Michelson
Part of the change with the IPv6 changes is to treat a host:port as a single 'domain' entity. This test was not updated to have the correct expectation after calling parse_uri(). git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-09Copy the address into the peer structure after we set the default port
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-08Fix calls of ast_sockaddr_from_sin() from IPv6 integration.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-08Add IPv6 to Asterisk.Mark Michelson
This adds a generic API for accommodating IPv6 and IPv4 addresses within Asterisk. While many files have been updated to make use of the API, chan_sip and the RTP code are the files which actually support IPv6 addresses at the time of this commit. The way has been paved for easier upgrading for other files in the near future, though. Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne for their hard work on this. (closes issue #17565) Reported by: russell Patches: asteriskv6-test-report.pdf uploaded by russell (license 2) Review: https://reviewboard.asterisk.org/r/743 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-08Implement AstData API data providers as part of the GSOC 2010 project,Eliel C. Sardanons
midterm evaluation. Review: https://reviewboard.asterisk.org/r/757/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274727 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-07Fixes some ref count issues introduced by r274539David Vossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274686 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-07Add missing conditional around chan_dahdi mfcr2_skip_category config parameter.Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-07Merged revisions 274579 via svnmerge from Richard Mudgett
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r274579 | rmudgett | 2010-07-07 13:12:41 -0500 (Wed, 07 Jul 2010) | 1 line Close the DAHDI FD on error when processing chan_dahdi toneduration config parameter. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-07Use the relatedpeer field of a sip_pvt during INVITE processing.Mark Michelson
Review: https://reviewboard.asterisk.org/r/629 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274539 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-06Merged revisions 274280 via svnmerge from Terry Wilson
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines Add option to not do a call forward on 482 Loop Detected Asterisk has always set up a forwarded call when receiving a 482 Loop Detected. This prevents handling the call failure by just continuing on in the dialplan. Since this would be a change in behavior, the new option to disable this behavior is forwardloopdetected which defaults to 'yes'. Review: https://reviewboard.asterisk.org/r/764/ ........ (no option for trunk, just changing the behavior) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-06Status shows all non-CRC4 lines as "yellow", even if "yellow" was not in the ↵Tilghman Lesher
bitfield. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-03Merged revisions 273793 via svnmerge from Tilghman Lesher
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r273793 | tilghman | 2010-07-02 16:36:39 -0500 (Fri, 02 Jul 2010) | 9 lines Have the DEADLOCK_AVOIDANCE macro warn when an unlock fails, to help catch potentially large software bugs. (closes issue #17407) Reported by: pdf Patches: 20100527__issue17407.diff.txt uploaded by tilghman (license 14) Review: https://reviewboard.asterisk.org/r/751/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-02Fix various typos reported by LintianTzafrir Cohen
(Also fix the typos in the comments) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273641 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-07-01correct handling of get_destination return valuesDavid Vossel
A failure when calling the get_destination can mean multiple things. If the extension is not found, a 404 error is appropriate, but if the URI scheme is incorrect, a 404 is not approperiate. This patch adds the get_destination_result enum to differentiate between these and other failure types. The only logical difference in this patch is that we now send a "416 Unsupported URI scheme" response instead of a "404" when the scheme is not recognized. This indicates to the initiator of the INVITE to retry the request with a correct URI. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-29Merged revisions 273060 via svnmerge from Tilghman Lesher
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines Allow the "useragent" value to be restored into memory from the realtime backend. This value is purely informational. It does not alter configuration at all. (closes issue #16029) Reported by: Guggemand Patches: realtime-useragent.patch uploaded by Guggemand (license 897) Tested by: Guggemand ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-29send a 400 Bad Request on malformed sip requestDavid Vossel
RFC 2361 section 24.4.1 send a 400 Bad Request if the request can not be understood due to malformed syntax. Currently we simply ignore a packet with a missing callid, to, from, or via header. Instead of ignoring we now send the 400 Bad request. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-28rfc compliant sip option parsing + new unit testDavid Vossel
RFC 3261 section 8.2.2.3 states that if any unsupported options are found in the Require header field, a "420 (Bad Extension)" response should be sent with an Unsupported header field containing only the unsupported options. This is not currently being done correctly. Right now, if Asterisk detects any unsupported sip options in a Require header the entire list of options are returned in the Unsupported header even if some of those options are in fact supported. This patch fixes that by building an unsupported options character buffer when parsing the options that can be sent with the 420 response. A unit test verifying this functionality has been created. Some code refactoring was required. Review: https://reviewboard.asterisk.org/r/680/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-28Merged revisions 272804 via svnmerge from Mark Michelson
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r272804 | mmichelson | 2010-06-28 12:31:40 -0500 (Mon, 28 Jun 2010) | 5 lines Decode URI in contact header of 302 response. ABE-2352 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272805 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-28code guidelines cleanup for retrans_pkt() functionDavid Vossel
I am doing work in this function. I noticed a large number of coding guidline fixes that needed to be made. Rather than have those changes distract from my functional changes I decided to separate these into a separate patch. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-25chan_sip: more accurate retransmissionsDavid Vossel
RFC3261 states that Timer A should start at 500ms (T1) by default. In chan_sip this value initially started at 1000ms and I changed it to 500ms recently. After doing that I noticed in my packet captures that it still occasionally retransmitted starting at 1000ms instead of 500ms like I told it to. This occurs because the scheduler runs in the do_monitor thread. If a new retransmission is added while the do_monitor thread is sleeping then it may not detect that retransmission for nearly 1000ms. To fix this I just poke the do_monitor thread to wake up when a new packet is sent reliably requiring retransmits. The thread then detects the new scheduler entry and adjusts its sleep time to account for it. Review: https://reviewboard.asterisk.org/r/747 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-24Merged revisions 272446 via svnmerge from Richard Mudgett
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r272446 | rmudgett | 2010-06-24 16:58:49 -0500 (Thu, 24 Jun 2010) | 10 lines ss_thread calls pri_grab without lock during overlap dial Recent changes to chan_dahdi with relation to overlap dialing call pri_grab without first obtaining a lock. (closes issue #17414) Reported by: pdf Patches: bug17414.patch uploaded by jpeeler (license 325) ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-23Resolve some errors produced during module unload of chan_iax2.Russell Bryant
The external test suite stops Asterisk using the "core stop gracefully" command. The logs from the tests show that there are a number of problems with Asterisk trying to cleanly shut down. This patch addresses the following type of error that comes from chan_iax2: [Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy: chan_iax2.c line 11371 (iax2_process_thread_cleanup): Error destroying mutex &thread->lock: Device or resource busy For an example in the context of a build, see: http://bamboo.asterisk.org/browse/AST-TRUNK-739/log The primary purpose of this patch is to change the thread pool shutdown procedure to be more explicit to ensure that the thread exits from a point where it is not holding a lock. While testing that, I encountered various crashes due to the order of operations in unload_module() being problematic. I reordered some things there, as well. Review: https://reviewboard.asterisk.org/r/736/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-23Add new AMI command LocalOptimizeAway.Tim Ringenbach
This command lets you request a "/n" local channel optimize itself out of the way anyway. Review: https://reviewboard.asterisk.org/r/732/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-23D'oh! Defaultenabled FTL.Tilghman Lesher
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272150 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-23Load all lines from realtime, not just the first one.Tilghman Lesher
(closes issue #17144) Reported by: nahuelgreco Patches: 20100513__issue17144__trunk.diff.txt uploaded by tilghman (license 14) Tested by: tilghman git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272145 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-23Add extra protection for reinvite glare scenario.Mark Michelson
Testing proved that if Asterisk sent a connected line reinvite, and the endpoint to which the reinvite were being sent sent a reinvite, Asterisk would not properly respond with a 491 response. The reason is that on connected line reinvites, we set the dialog's invitestate to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line reinvites. For other reinvites we do not do this. Because of the current invitestate, when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus did not behave properly. The fix for this is to not enter the loop detection or spiral logic in handle_request_invite if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted, no matter what the nature of the reinvite may have been. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-22Don't try to lock/unlock an uninitialized lock on a dahdi_pri.Russell Bryant
This small changes prevents destroy_all_channels() from accessing a lock on an unused dahdi_pri struct, resolving a ton of ERRORs that get spewed out when shutting Asterisk down gracefully. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-22ignore CANCEL request after having already received final response to INVITEDavid Vossel
RFC 3261 section 9 states that a CANCEL has no effect on a request to a UAS that has already given a final response. This patch checks to make sure there is a pending invite before allowing a CANCEL request to be processed, otherwise it responds to the CANCEL with a "481 Call/Transaction Does Not Exist". Review: https://reviewboard.asterisk.org/r/697/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-22Merged revisions 271902 via svnmerge from Matthew Nicholson
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r271902 | mnicholson | 2010-06-22 12:31:57 -0500 (Tue, 22 Jun 2010) | 8 lines Decrease the module ref count in sip_hangup when SIP_DEFER_BYE_ON_TRANSFER is set. This is necessary to keep the ref count correct. (closes issue #16815) Reported by: rain Patches: chan_sip-unref-fix.diff uploaded by rain (license 327) (modified) Tested by: rain ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271903 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-22Merged revisions 271689 via svnmerge from Matthew Nicholson
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct. (closes issue #17326) Reported by: kenner Tested by: mnicholson, kenner Review: https://reviewboard.asterisk.org/r/693/ ........ This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-21fixes crash when From header URI is missing "sip:"David Vossel
(closes issue #17437) Reported by: klaus3000 Patches: sip_crash uploaded by dvossel (license 671) Tested by: klaus3000 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271553 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-17fixes some coding guideline issueDavid Vossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271300 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-17retransmit response to BYE requests until timer J expiresDavid Vossel
According to RFC 3261 section 17.2.2, which describes non-INVITE server transaction, when a dialog enters the Completed state it must destroy the dialog after Timer J (T1*64) fires. For a BYE transaction Asterisk terminates the dialog immediately during sip_hangup() when it should be waiting T1*64 ms. This results in some odd behavior. For instance if Asterisk receives a BYE and transmits a 200ok in response, if the endpoint never receives the 200ok it will retransmit the BYE to which Asterisk responds with a "481 Call leg/transaction does not exist" because the dialog is already gone. To resolve this I made a function called sip_scheddestroy_final(). This differs slightly from sip_schedestroy() in that it enables a flag that will prevent the destruction from ever being rescheduled or canceled afterwards. It also prevents the pvt's needdestroy flag from being set which triggers the destruction of the dialog within the do_monitor thread(). By using this function we are guaranteed destruction will not occur until the scheduled time. This allows Asterisk to respond to any possible retransmits for a dialog after we process the initial BYE request for T1*64 ms. Other changes: I removed two instances where sip_cancel_destroy is used right before calling sip_scheddestroy. sip_scheddestroy always calls sip_cancel_destroy before scheduling the new destruction so it is completely unnecessary. Review: https://reviewboard.asterisk.org/r/694/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-17Change expected operation from error to debug messageJeff Peeler
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271192 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16addition of more parse_uri test casesDavid Vossel
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271056 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16Fix the actual place that was pointed out, for previous commit.Jason Parker
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16Merged revisions 270980 via svnmerge from Jason Parker
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r270980 | qwell | 2010-06-16 16:10:09 -0500 (Wed, 16 Jun 2010) | 4 lines Need to lock the agent chan before access its internal bits. Pointed out by russellb on asterisk-dev mailing list. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16addition of G.719 pass-through supportDavid Vossel
(closes issue #16293) Reported by: malcolmd Patches: g719.passthrough.patch.7 uploaded by malcolmd (license 924) format_g719.c uploaded by malcolmd (license 924) git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16Merged revisions 270866 via svnmerge from David Vossel
https://origsvn.digium.com/svn/asterisk/branches/1.4 ........ r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines fixes chan_iax2 race condition There is code in chan_iax2.c that attempts to guarantee that only a single active thread will handle a call number at a time. This code works once the thread is added to an active_list of threads, but we are not currently guaranteed that a newly activated thread will enter the active_list immediately because it is left up to the thread to add itself after frames have been queued to it. This means that if two frames come in for the same call number at the same time, it is possible for them to grab two separate threads because the first thread did not add itself to the active_list fast enough. This causes some pretty complex problems. This patch resolves this race condition by immediately adding an activated thread to the active_list within the network thread and only depending on the thread to remove itself once it is done processing the frames queued to it. By doing this we are guaranteed that if another frame for the same call number comes in at the same time, that this thread will immediately be found in the active_list of threads. Review: https://reviewboard.asterisk.org/r/720/ ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2010-06-16Fix no call waiting caller IDJeff Peeler
Clearing the callwaitcas flag in analog_call was causing the incoming D digit to be ignored which triggers sending the caller ID. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-02 03:29:29 +0000