74 Commits (d2bcdb71f8d288561d5bd2b1c43e04e21f9e6ba5)

Author	SHA1	Message	Date
Terry Wilson	34c55e8e7c	Opaquify char * and char[] in ast_channel ... Review: https://reviewboard.asterisk.org/r/1733/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@354968 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Terry Wilson	04da92c379	Replace direct access to channel name with accessor functions ... There are many benefits to making the ast_channel an opaque handle, from increasing maintainability to presenting ways to kill masquerades. This patch kicks things off by taking things a field at a time, renaming the field to '__do_not_use_${fieldname}' and then writing setters/getters and converting the existing code to using them. When all fields are done, we can move ast_channel to a C file from channel.h and lop off the '__do_not_use_'. This patch sets up main/channel_interal_api.c to be the only file that actually accesses the ast_channel's fields directly. The intent would be for any API functions in channel.c to use the accessor functions. No more monkeying around with channel internals. We should use our own APIs. The interesting changes in this patch are the addition of channel_internal_api.c, the moving of the AST_DATA stuff from channel.c to channel_internal_api.c (note: the AST_DATA stuff will have to be reworked to use accessor functions when ast_channel is really opaque), and some re-working of the way channel iterators/callbacks are handled so as to avoid creating fake ast_channels on the stack to pass in matching data by directly accessing fields (since "name" is a stringfield and the fake channel doesn't init the stringfields, you can't use the ast_channel_name_set() function). I went with ast_channel_name(chan) for a getter, and ast_channel_name_set(chan, name) for a setter. The majority of the grunt-work for this change was done by writing a semantic patch using Coccinelle ( http://coccinelle.lip6.fr/ ). Review: https://reviewboard.asterisk.org/r/1655/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@350223 65c4cc65-6c06-0410-ace0-fbb531ad65f3	13 years ago
Richard Mudgett	31bcafab5b	Merged revisions 321924 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r321924 | rmudgett | 2011-06-03 16:49:17 -0500 (Fri, 03 Jun 2011) | 5 lines Be more explicit for CCSS generic device state event subscription. Make CCSS generic device state event subscription specify the AST_EVENT_IE_STATE ie exists to be safe. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321925 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	b33fc4db48	Merged revisions 319758 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r319758 | rmudgett | 2011-05-19 11:50:48 -0500 (Thu, 19 May 2011) | 21 lines CCSS generic agent with POTS and ISDN phones fail caller busy call-back test. If the following is true after a CCSS activation: * The generic agent is for an analog phone or ISDN phone. (Caller party) * The called party becomes available. * The caller party is not available. When the caller party becomes available, the caller is not alerted to the called party being available. The generic agent still thinks the caller is busy. * Fixed the generic agent device state event subscription to look for all device states that are considered available. * Encapsulated the device state test for CCSS generic device available in cc_generic_is_device_available(). Made the generic agent and monitor use the new function instead of the manually coded inline equivalent. JIRA AST-559 JIRA SWP-3462 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319759 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	eddc32a3b3	Merged revisions 319259 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r319259 | rmudgett | 2011-05-16 15:33:37 -0500 (Mon, 16 May 2011) | 13 lines Deadlock between generic CCSS agent and native ISDN CCSS. Deadlock can occur when the generic CCSS agent is deleting duplicate CC offers and the native ISDN CC driver is processing an incoming CC message. The cc_core_instances container lock cannot be held when an agent or monitor callback is invoked without the possibility of a deadlock. * Make kill_duplicate_offers() remove the reference in cc_core_instances outside of the container lock. JIRA AST-566 JIRA SWP-3469 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319260 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	ae2926b5d0	Add Device State Information CCSS for Generic Devices. ... Add Asterisk Device State information and callbacks to the Call Completion Supplemental Services for generic agents. There are currently not many devices that have native support for CCSS. Even as the devices become available there may be other reasons why one may choose to not take advantage of the native abilities and stick with the generic implementation. The generic implementation is quite capable and could be greatly enhanced by adding device state capabilities. A phone could then subscribe to the device state with a BLF key in conjunction with Asterisk hints. The advantages of the device state information would allow a single button to: request CCSS, cancel a CCSS request, and display the current state of a CCSS request. For example, you may have a single button that when not lit, there is no active CCSS request. When you press that button, the dialplan can query the DEVICE_STATE() associated with that caller to determine whether they should be calling CallCompletionRequest() or CallCompletionCancel(). If there is currently a pending request, then the dialplan would cancel it. This also has the advantage of showing the true state of a request, which is an asynchronous call, even when CallCompletionRequest() thinks it was successful. The actual request could ultimately fail. Once lit, further feedback can be provided to the caller about the current state of their request since it will be updated by the CCSS State Machine as appropriate. The DEVICE_STATE mapping is configurable since the BLF being used on a given phone type may vary. The idea is to allow some level of customization as to the phone's behavior. As an example, you may want the BLF key to go solid once you have requested a callback. You may then want the LED to blink (typically ringing) when either the callback is in process, which is a visual indication that the incoming call is the desired callback. You may want it to blink when the callee is ready but you are busy, giving you a visual indication that the target is available as you may want to get off the line so that the callback can be successful. Device state information is sent back via the ast_devstate_prov_add() callback for any generic CCSS device as it traverses through the state machine. You simply provide a map between CC_STATE values and the corresponding AST_DEVICE state values. You could then generate hints against these states similar to what is possible today with Custom Devstates or MeetMe states. For example, you may have an extension 3000 that is currently associated with device SIP/3000. You could then create a feature code for that extension that may look something like: exten => *823000,hint,ccss:sip/3000 You would then subscribe a BLF button to *823000 which would point to the dialplan that handled CCSS requests/cancels using the available DEVICE_STATE() information about ccss:sip/3000 to make the decision about what to do. (closes issue #18788) Reported by: p_lindheimer Patches: ccss.trunk.18788.patch uploaded by p lindheimer (license 558) Modified with final reviewboard comments. Tested by: p_lindheimer, loloski Review: https://reviewboard.asterisk.org/r/1105/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313744 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	75594e6e4a	Merged revisions 312461 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r312461 | rmudgett | 2011-04-01 16:31:39 -0500 (Fri, 01 Apr 2011) | 25 lines CallCompletionRequest()/CallCompletionCancel() exit non-zero if fail. The CallCompletionRequest()/CallCompletionCancel() dialplan applications exit nonzero on normal failure conditions. The nonzero exit causes the dialplan to hangup immediately. The dialplan author has no opportunity to report success/failure to the user. * Made always return zero so the dialplan can continue. * Made set CC_REQUEST_RESULT/CC_REQUEST_REASON and CC_CANCEL_RESULT/CC_CANCEL_REASON channel variables respectively. Also documented the values set. * Reduced the warning about no core instance in CallCompletionCancel() to a debug message. It is a normal event and should not be output at the WARNING level. (closes issue #18763) Reported by: p_lindheimer Patches: ccss.patch uploaded by p lindheimer (license 558) Modified Tested by: p_lindheimer, rmudgett JIRA SWP-3042 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312462 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	b2ef13cb60	Merged revisions 307879 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines No response sent for SIP CC subscribe/resubscribe request. Asterisk does not send a response if we try to subscribe for call completion after we have received a 180 Ringing. You can only subscribe for call completion when the call has been cleared. When we receive the 180 Ringing, for this call, its call-completion state is 'CC_AVAILABLE'. If we then send a subscribe message to Asterisk, it trys to change the call-completion state to 'CC_CALLER_REQUESTED'. Because this is an invalid state change, it just ignores the message. The only state Asterisk will accept our subscribe message is in the 'CC_CALLER_OFFERED' state. Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears the call by sending a CANCEL. Asterisk should always send a response. Even if its a negative one. The fix is to allow for the CCSS core to notify a CC agent that a failure has occurred when CC is requested. The "ack" callback is replaced with a "respond" callback. The "respond" callback has a parameter indicating either a successful response or a specific type of failure that may need to be communicated to the requester. (closes issue #18336) Reported by: GeorgeKonopacki Tested by: mmichelson, rmudgett JIRA SWP-2633 (closes issue #18337) Reported by: GeorgeKonopacki Tested by: mmichelson JIRA SWP-2634 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307883 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Mark Michelson	0074165356	Merged revisions 307065 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r307065 | mmichelson | 2011-02-08 15:13:08 -0600 (Tue, 08 Feb 2011) | 6 lines Add a couple of useful channel variables for the CC recall macro. CC_EXTEN and CC_CONTEXT will allow you to determine the channel and context that will be called when the recall occurs. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307071 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Mark Michelson	f4ea670a6a	Merged revisions 306575 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r306575 | mmichelson | 2011-02-07 11:36:56 -0600 (Mon, 07 Feb 2011) | 9 lines Rearrange a bit of code in the generic CC recall operation. By waiting to call the callback macro after the CC_INTERFACES, extension, priority, and context have been set, this information can be accessed more easily within the callback macro. Reported by Philippe Lindheimer. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306576 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
David Vossel	c26c190711	Asterisk media architecture conversion - no more format bitfields ... This patch is the foundation of an entire new way of looking at media in Asterisk. The code present in this patch is everything required to complete phase1 of my Media Architecture proposal. For more information about this project visit the link below. https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal The primary function of this patch is to convert all the usages of format bitfields in Asterisk to use the new format and format_cap APIs. Functionally no change in behavior should be present in this patch. Thanks to twilson and russell for all the time they spent reviewing these changes. Review: https://reviewboard.asterisk.org/r/1083/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	4e354aebc9	Merged revisions 304554 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r304554 | rmudgett | 2011-01-27 13:08:14 -0600 (Thu, 27 Jan 2011) | 4 lines Warning message if CALLCOMPLETION(cc_callback_macro or cc_agent_dialstring) are empty. Test if the value pointer is not NULL instead of not ast_strlen_zero(). ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@304555 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Richard Mudgett	9974f89a7d	Merged revisions 303153 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ................ r303153 | rmudgett | 2011-01-20 14:31:20 -0600 (Thu, 20 Jan 2011) | 22 lines Merged revision 303098 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier .......... r303098 | rmudgett | 2011-01-20 12:11:45 -0600 (Thu, 20 Jan 2011) | 15 lines CC_INTERFACES does not get built correctly with local channels. If local channels are used with CCSS, CC_INTERFACES gets garbage prepended to it so the CC recall fails. Also CC_INTERFACES gets "&(null)" appended to it. * Initialize the buffer to eliminate the prepended garbage. * Filter out the empty interface strings to eliminate the latter. * Added a diagnostic message if the CC_INTERFACES is ever empty. JIRA ABE-2740 JIRA SWP-2848 .......... ................ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303154 65c4cc65-6c06-0410-ace0-fbb531ad65f3	14 years ago
Russell Bryant	cc0b7e7df5	Some scheduler API cleanup and improvements. ... Previously, I had added the ast_sched_thread stuff that was a generic scheduler thread implementation. However, if you used it, it required using different functions for modifying scheduler contents. This patch reworks how this is done and just allows you to optionally start a thread on the original scheduler context structure that has always been there. This makes it trivial to switch to the generic scheduler thread implementation without having to touch any of the other code that adds or removes scheduler entries. In passing, I made some naming tweaks to add ast_ prefixes where they were not there before. Review: https://reviewboard.asterisk.org/r/1007/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299091 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Richard Mudgett	8bc5bf82df	Merged revisions 282098 via svnmerge from ... https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r282098 | rmudgett | 2010-08-12 17:06:06 -0500 (Thu, 12 Aug 2010) | 7 lines Separate call completion config parameter allocation and default initialization. If you ever have a need to reset the call completion config parameters to defaults, now you can. And no Virginia, C++ idioms do not always work in C. ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282099 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Richard Mudgett	ec37ffbdaf	ast_callerid restructuring ... The purpose of this patch is to eliminate struct ast_callerid since it has turned into a miscellaneous collection of various party information. Eliminate struct ast_callerid and replace it with the following struct organization: struct ast_party_name { char *str; int char_set; int presentation; unsigned char valid; }; struct ast_party_number { char *str; int plan; int presentation; unsigned char valid; }; struct ast_party_subaddress { char *str; int type; unsigned char odd_even_indicator; unsigned char valid; }; struct ast_party_id { struct ast_party_name name; struct ast_party_number number; struct ast_party_subaddress subaddress; char *tag; }; struct ast_party_dialed { struct { char *str; int plan; } number; struct ast_party_subaddress subaddress; int transit_network_select; }; struct ast_party_caller { struct ast_party_id id; char *ani; int ani2; }; The new organization adds some new information as well. * The party name and number now have their own presentation value that can be manipulated independently. ISDN supplies the presentation value for the name and number at different times with the possibility that they could be different. * The party name and number now have a valid flag. Before this change the name or number string could be empty if the presentation were restricted. Most channel drivers assume that the name or number is then simply not available instead of indicating that the name or number was restricted. * The party name now has a character set value. SIP and Q.SIG have the ability to indicate what character set a name string is using so it could be presented properly. * The dialed party now has a numbering plan value that could be useful to have available. The various channel drivers will need to be updated to support the new core features as needed. They have simply been converted to supply current functionality at this time. The following items of note were either corrected or enhanced: * The CONNECTEDLINE() and REDIRECTING() dialplan functions were consolidated into func_callerid.c to share party id handling code. * CALLERPRES() is now deprecated because the name and number have their own presentation values. * Fixed app_alarmreceiver.c write_metadata(). The workstring[] could contain garbage. It also can only contain the caller id number so using ast_callerid_parse() on it is silly. There was also a typo in the CALLERNAME if test. * Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id number string. ast_callerid_parse() alters the given buffer which in this case is the channel's caller id number string. Then using ast_shrink_phone_number() could alter it even more. * Fixed caller ID name and number memory leak in chan_usbradio.c. * Fixed uninitialized char arrays cid_num[] and cid_name[] in sig_analog.c. * Protected access to a caller channel with lock in chan_sip.c. * Clarified intent of code in app_meetme.c sla_ring_station() and dial_trunk(). Also made save all caller ID data instead of just the name and number strings. * Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge() function. * Corrected some weirdness with app_privacy.c's use of caller presentation. Review: https://reviewboard.asterisk.org/r/702/ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Leif Madsen	c672763af8	Fix some doxygen warnings. ... (closes issue #17336) Reported by: snuffy Patches: doxygen-fixes1.diff uploaded by snuffy (license 35) Tested by: russell git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268969 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Russell Bryant	4e77fc3c58	Remove a LOG_WARNING. ... This came up when using the sample configs, and just indicates expected behavior. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267714 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Richard Mudgett	dafb48fe09	Avoid crash in generic CC agent init if caller name or number is NULL. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@264711 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	5fd23b2ed4	Shuffle some casts to make builds on bamboo happier. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259533 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	57c8eea6fe	Change cc_ref and cc_unref from macros to inline functions. ... The hope is that Solaris won't be as whiny after this change. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@259357 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	69c252c290	Fix issue where recall would not happen when it should. ... Specifically, the situation would happen when multiple callers would request CC for a single generically-monitored device. If the monitored device became available but the caller did not answer the recall, then there was nothing that would poke the CC core to let it know that it should attempt to recall someone else instead. After careful consideration, I came to the conclusion that the only area of Asterisk that needed to be touched was the generic CC monitor. All other types of CC would require something outside of Asterisk to invoke a recall for a separate device. This was accomplished by changing the generic monitor destructor to poke other generic monitor instances if the device is currently available and the specific instance was currently not suspended. In order to not accidentally trigger recalls at bad times, the fit_for_recall flag was also added to the generic_monitor_instance_list struct. This gets set as soon as a monitored device becomes available. It gets cleared if a CCNR request triggers the creation of a new generic monitor instance. By doing this, we don't accidentally try to recall a device when the monitored device was being monitored for CCNR and never actually became available for recall in the first place. This error was discovered by Steve Pitts during in-house testing at Digium. git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256985 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	9afa6af881	Remove status_response callbacks where they are not needed. ... git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256661 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago
Mark Michelson	e24661fd18	Merge Call completion support into trunk. ... From Reviewboard: CCSS stands for Call Completion Supplementary Services. An admittedly out-of-date overview of the architecture can be found in the file doc/CCSS_architecture.pdf in the CCSS branch. Off the top of my head, the big differences between what is implemented and what is in the document are as follows: 1. We did not end up modifying the Hangup application at all. 2. The document states that a single call completion monitor may be used across multiple calls to the same device. This proved to not be such a good idea when implementing protocol-specific monitors, and so we ended up using one monitor per-device per-call. 3. There are some configuration options which were conceived after the document was written. These are documented in the ccss.conf.sample that is on this review request. For some basic understanding of terminology used throughout this code, see the ccss.tex document that is on this review. This implements CCBS and CCNR in several flavors. First up is a "generic" implementation, which can work over any channel technology provided that the channel technology can accurately report device state. Call completion is requested using the dialplan application CallCompletionRequest and can be canceled using CallCompletionCancel. Device state subscriptions are used in order to monitor the state of called parties. Next, there is a SIP-specific implementation of call completion. This method uses the methods outlined in draft-ietf-bliss-call-completion-06 to implement call completion using SIP signaling. There are a few things to note here: * The agent/monitor terminology used throughout Asterisk sometimes is the reverse of what is defined in the referenced draft. * Implementation of the draft required support for SIP PUBLISH. I attempted to write this in a generic-enough fashion such that if someone were to want to write PUBLISH support for other event packages, such as dialog-state or presence, most of the effort would be in writing callbacks specific to the event package. * A subportion of supporting PUBLISH reception was that we had to implement a PIDF parser. The PIDF support added is a bit minimal. I first wrote a validation routine to ensure that the PIDF document is formatted properly. The rest of the PIDF reading is done in-line in the call-completion-specific PUBLISH-handling code. In other words, while there is PIDF support here, it is not in any state where it could easily be applied to other event packages as is. Finally, there are a variety of ISDN-related call completion protocols supported. These were written by Richard Mudgett, and as such I can't really say much about their implementation. There are notes in the CHANGES file that indicate the ISDN protocols over which call completion is supported. Review: https://reviewboard.asterisk.org/r/523 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@256528 65c4cc65-6c06-0410-ace0-fbb531ad65f3	15 years ago