summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRichard Mudgett <rmudgett@digium.com>2011-05-25 22:28:01 +0000
committerRichard Mudgett <rmudgett@digium.com>2011-05-25 22:28:01 +0000
commitdbfac9cb55200f04871503fafbd689bece5a4293 (patch)
tree54ff2037ce5ad4d5c5b12b7ff35c444640829281
parent0096238b5256864fde6540b3b478705663f796a4 (diff)
Merged revisions 320883 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8 ........ r320883 | rmudgett | 2011-05-25 17:25:18 -0500 (Wed, 25 May 2011) | 17 lines Native SIP CCSS sends bad CC cancel SUBSCRIBE message. The SUBSCRIBE message used to cancel a CC request has incorrect To/From SIP headers. They are reversed and the dialog tags are the same when they should not be. If pedantic mode was disabled, then the cancel would have succeeded despite the incorrect message. * The SIP_OUTGOING flag was not set correctly for the dialog and I had to move some CC subscribe handling code as a result. * Initialized the dialog subscribed type to CALL_COMPLETION earlier. If a CC request SUBSCRIBE message comes in and the CC instance is not found, the 404 response was duplicated. JIRA AST-568 JIRA SWP-3493 ........ git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-rw-r--r--channels/chan_sip.c35
1 files changed, 24 insertions, 11 deletions
diff --git a/channels/chan_sip.c b/channels/chan_sip.c
index 0c515a954..6d8e3e0e5 100644
--- a/channels/chan_sip.c
+++ b/channels/chan_sip.c
@@ -1923,6 +1923,7 @@ static int sip_cc_monitor_request_cc(struct ast_cc_monitor *monitor, int *availa
ast_get_ccnr_available_timer(monitor->interface->config_params);
sip_pvt_lock(monitor_instance->subscription_pvt);
+ ast_set_flag(&monitor_instance->subscription_pvt->flags[0], SIP_OUTGOING);
create_addr(monitor_instance->subscription_pvt, monitor_instance->peername, 0, 1, NULL);
ast_sip_ouraddrfor(&monitor_instance->subscription_pvt->sa, &monitor_instance->subscription_pvt->ourip, monitor_instance->subscription_pvt);
monitor_instance->subscription_pvt->subscribed = CALL_COMPLETION;
@@ -20005,6 +20006,27 @@ static void handle_response_notify(struct sip_pvt *p, int resp, const char *rest
/* \brief Handle SIP response in SUBSCRIBE transaction */
static void handle_response_subscribe(struct sip_pvt *p, int resp, const char *rest, struct sip_request *req, int seqno)
{
+ if (p->subscribed == CALL_COMPLETION) {
+ struct sip_monitor_instance *monitor_instance;
+
+ if (resp < 300) {
+ return;
+ }
+
+ /* Final failure response received. */
+ monitor_instance = ao2_callback(sip_monitor_instances, 0,
+ find_sip_monitor_instance_by_subscription_pvt, p);
+ if (monitor_instance) {
+ ast_cc_monitor_failed(monitor_instance->core_id,
+ monitor_instance->device_name,
+ "Received error response to our SUBSCRIBE");
+ }
+ return;
+ }
+
+ if (p->subscribed != MWI_NOTIFICATION) {
+ return;
+ }
if (!p->mwi) {
return;
}
@@ -20738,16 +20760,6 @@ static void handle_response(struct sip_pvt *p, int resp, const char *rest, struc
ast_string_field_set(p, theirtag, tag);
}
- if (sipmethod == SIP_SUBSCRIBE && resp >= 400) {
- struct sip_monitor_instance *monitor_instance = ao2_callback(sip_monitor_instances,
- 0, find_sip_monitor_instance_by_subscription_pvt, p);
- if (monitor_instance) {
- ast_cc_monitor_failed(monitor_instance->core_id, monitor_instance->device_name,
- "Received error response to our SUBSCRIBE");
- return;
- }
- }
-
switch(resp) {
case 200:
if (sipmethod == SIP_INVITE) {
@@ -23896,6 +23908,8 @@ static int handle_cc_subscribe(struct sip_pvt *p, struct sip_request *req)
*param_separator = '\0';
}
+ p->subscribed = CALL_COMPLETION;
+
if (!(agent = find_sip_cc_agent_by_subscribe_uri(uri))) {
if (!expires) {
/* Typically, if a 0 Expires reaches us and we can't find
@@ -23927,7 +23941,6 @@ static int handle_cc_subscribe(struct sip_pvt *p, struct sip_request *req)
agent_pvt->subscribe_pvt = dialog_ref(p, "SIP CC agent gains reference to subscription dialog");
ast_cc_agent_accept_request(agent->core_id, "SIP caller %s has requested CC via SUBSCRIBE",
agent->device_name);
- p->subscribed = CALL_COMPLETION;
/* We don't send a response here. That is done in the agent's ack callback or in the
* agent destructor, should a failure occur before we have responded