[svn-commits] rmudgett: branch group/CCSS r248102 - in /team/group/CCSS: apps/ channels/ co...
SVN commits to the Digium repositories
svn-commits at lists.digium.com
Fri Feb 19 18:14:17 CST 2010
Author: rmudgett
Date: Fri Feb 19 18:14:12 2010
New Revision: 248102
URL: http://svnview.digium.com/svn/asterisk?view=rev&rev=248102
Log:
Pesky whitespace cleanup in CCSS changes.
Modified:
team/group/CCSS/apps/app_dial.c
team/group/CCSS/channels/chan_dahdi.c
team/group/CCSS/channels/chan_sip.c
team/group/CCSS/configs/ccss.conf.sample
team/group/CCSS/doc/tex/ccss.tex
team/group/CCSS/include/asterisk/channel.h
Modified: team/group/CCSS/apps/app_dial.c
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/apps/app_dial.c?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/apps/app_dial.c (original)
+++ team/group/CCSS/apps/app_dial.c Fri Feb 19 18:14:12 2010
@@ -1113,7 +1113,7 @@
case AST_CONTROL_RINGING:
/* XXX This is a tricky area to get right when using a native
* CC agent. The reason is that we do the best we can to send only a
- * single ringing notification to the caller. *
+ * single ringing notification to the caller.
*
* Call completion complicates the logic used here. CCNR is typically
* offered during a ringing message. Let's say that party A calls
Modified: team/group/CCSS/channels/chan_dahdi.c
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/channels/chan_dahdi.c?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/channels/chan_dahdi.c (original)
+++ team/group/CCSS/channels/chan_dahdi.c Fri Feb 19 18:14:12 2010
@@ -17634,8 +17634,8 @@
static int setup_dahdi(int reload)
{
int res;
- struct dahdi_chan_conf base_conf = dahdi_chan_conf_default();
- struct dahdi_chan_conf conf = dahdi_chan_conf_default();
+ struct dahdi_chan_conf base_conf = dahdi_chan_conf_default();
+ struct dahdi_chan_conf conf = dahdi_chan_conf_default();
if (base_conf.chan.cc_params && conf.chan.cc_params) {
res = setup_dahdi_int(reload, &base_conf, &conf);
Modified: team/group/CCSS/channels/chan_sip.c
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/channels/chan_sip.c?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/channels/chan_sip.c (original)
+++ team/group/CCSS/channels/chan_sip.c Fri Feb 19 18:14:12 2010
@@ -875,11 +875,11 @@
* acts appropriately based on the content of those requests.
*
* ESC:
- * The main structure in chan_sip is the event_state_compositor. There is an
- * event_state_compositor structure for each event package supported (as of Nov 2009
- * this is only the call-completion package). The structure contains data which is
- * intrinsic to the event package itself, such as the name of the package and a set
- * of callbacks for handling incoming PUBLISH requests. In addition, the
+ * The main structure in chan_sip is the event_state_compositor. There is an
+ * event_state_compositor structure for each event package supported (as of Nov 2009
+ * this is only the call-completion package). The structure contains data which is
+ * intrinsic to the event package itself, such as the name of the package and a set
+ * of callbacks for handling incoming PUBLISH requests. In addition, the
* event_state_compositor struct contains an ao2_container of sip_esc_entries.
*
* A sip_esc_entry corresponds to an entity which has sent a PUBLISH to Asterisk. We are
@@ -975,22 +975,24 @@
};
struct cc_epa_entry {
- /* The core ID of the CC transaction
- * for which this EPA entry belongs. This
- * essentially acts as a unique identifier
- * for the entry and is used in the hash
- * and comparison functions
- */
+ /*!
+ * The core ID of the CC transaction
+ * for which this EPA entry belongs. This
+ * essentially acts as a unique identifier
+ * for the entry and is used in the hash
+ * and comparison functions
+ */
int core_id;
- /* We keep the last known state of the
- * device in question handy in case
- * it needs to be known by a third party.
- * Also, in the case where for some reason
- * we get asked to transmit state that we
- * already sent, we can just ignore the
- * request.
- */
- enum sip_cc_publish_state current_state;
+ /*!
+ * We keep the last known state of the
+ * device in question handy in case
+ * it needs to be known by a third party.
+ * Also, in the case where for some reason
+ * we get asked to transmit state that we
+ * already sent, we can just ignore the
+ * request.
+ */
+ enum sip_cc_publish_state current_state;
};
struct sip_epa_entry;
@@ -1028,32 +1030,38 @@
static void cc_handle_publish_error(struct sip_pvt *pvt, const int resp, struct sip_request *req, struct sip_epa_entry *epa_entry);
struct sip_epa_entry {
- /* When we are going to send a publish, we need to
+ /*!
+ * When we are going to send a publish, we need to
* know the type of PUBLISH to send.
*/
enum sip_publish_type publish_type;
- /* When we send a PUBLISH, we have to be
- * sure to include the entity tag that we
- * received in the previous response.
- */
+ /*!
+ * When we send a PUBLISH, we have to be
+ * sure to include the entity tag that we
+ * received in the previous response.
+ */
char entity_tag[SIPBUFSIZE];
- /* The destination to which this EPA should send
+ /*!
+ * The destination to which this EPA should send
* PUBLISHes. This may be the name of a SIP peer
* or a hostname.
*/
char destination[SIPBUFSIZE];
- /* The body of the most recently-sent PUBLISH message.
+ /*!
+ * The body of the most recently-sent PUBLISH message.
* This is useful for situations such as authentication,
* in which we must send a message identical to the
* one previously sent
*/
char body[SIPBUFSIZE];
- /* Every event package has some constant data and
+ /*!
+ * Every event package has some constant data and
* callbacks that all instances will share. This
* data resides in this field.
*/
const struct epa_static_data *static_data;
- /* In addition to the static data that all instances
+ /*!
+ * In addition to the static data that all instances
* of sip_epa_entry will have, each instance will
* require its own instance-specific data.
*/
@@ -1123,7 +1131,7 @@
* The name of the party who
* sent us the PUBLISH. This will more
* than likely correspond to a peer name.
- *
+ *
* This field's utility isn't really that
* great. It's mainly just a user-recognizable
* handle that can be printed in debug messages.
@@ -1256,7 +1264,7 @@
* 1. The Request-URI will be one that we sent in a NOTIFY to let the phone know that
* the called party has become available.
* 2. The PUBLISH is sent in the SUBSCRIBE-NOTIFY dialog.
- *
+ *
* Since we're focusing for now specifically on SIP PUBLISH support, and not how it ties
* in with CC specifically, I'm leaving this as a TODO XXX type thing.
*/
@@ -1376,7 +1384,7 @@
{
int i, res = 0;
for (i = 0; i < ARRAY_LEN(event_state_compositors); i++) {
- if (!((event_state_compositors[i].compositor) =
+ if (!((event_state_compositors[i].compositor) =
ao2_container_alloc(ESC_MAX_BUCKETS, esc_hash_fn, esc_cmp_fn))) {
res = -1;
}
@@ -2061,7 +2069,7 @@
static void sip_cc_agent_ack(struct ast_cc_agent *agent)
{
struct sip_cc_agent_pvt *agent_pvt = agent->private_data;
-
+
sip_pvt_lock(agent_pvt->subscribe_pvt);
ast_set_flag(&agent_pvt->subscribe_pvt->flags[1], SIP_PAGE2_DIALOG_ESTABLISHED);
transmit_response(agent_pvt->subscribe_pvt, "200 OK", &agent_pvt->subscribe_pvt->initreq);
@@ -10438,7 +10446,7 @@
}
agent_pvt = agent->private_data;
-
+
if (!ast_strlen_zero(agent_pvt->subscribe_uri)) {
ast_copy_string(uri, agent_pvt->subscribe_uri, sizeof(uri));
} else {
@@ -11317,7 +11325,7 @@
generate_uri(subscription, agent_pvt->notify_uri, sizeof(agent_pvt->notify_uri));
snprintf(uri, sizeof(uri) - 1, "cc-URI: %s\r\n", agent_pvt->notify_uri);
}
- add_header_contentLength(&req, strlen(state_str) +
+ add_header_contentLength(&req, strlen(state_str) +
(state == CC_READY ? strlen(uri) : 0));
add_line(&req, state_str);
if (state == CC_READY) {
@@ -21912,7 +21920,7 @@
struct ast_xml_node *node_iterator;
struct ast_xml_ns *ns;
const char *entity;
-
+
if (!presence_node) {
ast_log(LOG_WARNING, "Unable to retrieve root node of the XML document\n");
return FALSE;
@@ -22046,7 +22054,7 @@
struct ast_xml_node *status_node;
struct ast_xml_node *status_children;
struct ast_xml_node *basic_node;
-
+
if (!agent) {
ast_log(LOG_WARNING, "Could not find agent using uri '%s'\n", uri);
transmit_response(pvt, "412 Conditional Request Failed", req);
@@ -22236,7 +22244,7 @@
if (!res) {
transmit_response_with_sip_etag(p, "200 OK", req, esc_entry, 1);
- }
+ }
/* Ref from finding the esc_entry earlier in function */
ao2_unlink(esc->compositor, esc_entry);
@@ -22348,7 +22356,7 @@
/* Typically, if a 0 Expires reaches us and we can't find
* the corresponding agent, it means that the CC transaction
* has completed and so the calling side is just trying to
- * clean up its subscription. We'll just respond with a
+ * clean up its subscription. We'll just respond with a
* 200 OK and be done with it
*/
transmit_response(p, "200 OK", req);
Modified: team/group/CCSS/configs/ccss.conf.sample
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/configs/ccss.conf.sample?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/configs/ccss.conf.sample (original)
+++ team/group/CCSS/configs/ccss.conf.sample Fri Feb 19 18:14:12 2010
@@ -18,7 +18,7 @@
;---------------------------------------------------------------------
; Timers
;---------------------------------------------------------------------
-;There are three configurable timers for all types of CC: the
+;There are three configurable timers for all types of CC: the
;cc_offer_timer, the ccbs_available_timer, and the ccnr_available_timer.
;In addition, when using a generic agent, there is a fourth timer,
;the cc_recall_timer. All timers are configured in seconds, and the
Modified: team/group/CCSS/doc/tex/ccss.tex
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/doc/tex/ccss.tex?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/doc/tex/ccss.tex (original)
+++ team/group/CCSS/doc/tex/ccss.tex Fri Feb 19 18:14:12 2010
@@ -312,7 +312,7 @@
an Expires header set to the number of seconds that the available
timer should run. If the Asterisk server that receives this SUBSCRIBE
has a maxexpiry set lower than what is in the received Expires header,
-then the available timer will only run for maxexpiry seconds.
+then the available timer will only run for maxexpiry seconds.
\item As with all Asterisk components, CC is not perfect. If you should
find a bug or wish to enhance the feature, please open an issue on
@@ -370,25 +370,25 @@
Mark picks up his phone and dials Richard by dialing 2000. Richard is
currently on a call, so Mark hears a busy signal. Mark then hangs up,
picks up the phone and dials 30 to call the CallCompletionRequest
-application. After some time, Richard finishes his call and hangs up.
-Mark is automatically called back by Asterisk. When Mark picks up his
+application. After some time, Richard finishes his call and hangs up.
+Mark is automatically called back by Asterisk. When Mark picks up his
phone, Asterisk will dial extension 2000 for him.
\item Scenario 2:
Richard picks up his phone and dials Mark by dialing 1000. Mark has stepped
away from his desk, and so he is unable to answer the phone within the
20 second dial timeout. Richard hangs up, picks the phone back up and then
-dials 30 to request call completion. Mark gets back to his desk and dials
-somebody's number. When Mark finishes the call, Asterisk detects that Mark's
-phone has had some activity and has become available again and rings Richard's
-phone. Once Richard picks up, Asterisk automatically dials exteision 1000 for
+dials 30 to request call completion. Mark gets back to his desk and dials
+somebody's number. When Mark finishes the call, Asterisk detects that Mark's
+phone has had some activity and has become available again and rings Richard's
+phone. Once Richard picks up, Asterisk automatically dials exteision 1000 for
him.
\item Scenario 3:
Much like scenario 1, Mark calls Richard and Richard is busy. Mark hangs up,
picks the phone back up and then dials 30 to request call completion. After
a little while, Mark realizes he doesn't actually need to talk to Richard, so
-he dials 31 to cancel call completion. When Richard becomes free, Mark will
+he dials 31 to cancel call completion. When Richard becomes free, Mark will
not automatically be redialed by Asterisk.
\item Scenario 4:
@@ -407,8 +407,8 @@
\item Scenario 6:
Mark calls Richard, and Richard does not respond within the 20 second dial timeout.
-Mark requests call completion. Richard does not use his phone again for another
-4 hours (144000 seconds). Since Mark has the default ccnr\_available\_timer
-of 7200 seconds set, Mark will not be automatically recalled by Asterisk when
+Mark requests call completion. Richard does not use his phone again for another
+4 hours (144000 seconds). Since Mark has the default ccnr\_available\_timer
+of 7200 seconds set, Mark will not be automatically recalled by Asterisk when
Richard finishes his call.
\end{itemize}
Modified: team/group/CCSS/include/asterisk/channel.h
URL: http://svnview.digium.com/svn/asterisk/team/group/CCSS/include/asterisk/channel.h?view=diff&rev=248102&r1=248101&r2=248102
==============================================================================
--- team/group/CCSS/include/asterisk/channel.h (original)
+++ team/group/CCSS/include/asterisk/channel.h Fri Feb 19 18:14:12 2010
@@ -521,7 +521,7 @@
* This is a highly specialized callback that is not likely to be needed in many
* channel drivers. When dealing with a busy channel, for instance, most channel
* drivers will successfully return a channel to the requester. Once called, the channel
- * can then queue a busy frame when it receives an appropriate message from the far end.
+ * can then queue a busy frame when it receives an appropriate message from the far end.
* In such a case, the channel driver has the opportunity to also queue a CC frame.
* The parameters for the CC channel can be retrieved from the channel structure.
*
@@ -529,7 +529,7 @@
* driver will not return a channel when one is requested. In such a scenario, there is never
* an opportunity for the channel driver to queue a CC frame since the channel is never
* called. Furthermore, it is not possible to retrieve the CC configuration parameters
- * for the desired channel because no channel is ever allocated or returned to the
+ * for the desired channel because no channel is ever allocated or returned to the
* requester. In such a case, call completion may still be a viable option. What we do is
* pass the same string that the requester used originally to request the channel to the
* channel driver. The channel driver can then find any potential channels/devices that
@@ -2835,7 +2835,7 @@
/*!
* \since 1.8
* \brief Find the appropriate CC agent type to use given a channel
- *
+ *
* \details
* During call completion, we will need to create a call completion agent structure. To
* figure out the type of agent to construct, we need to ask the channel driver for the
More information about the svn-commits
mailing list