asterisk/res/res_pjsip_mwi.c

1638 lines
45 KiB
C
Raw Normal View History

/*
* Asterisk -- An open source telephony toolkit.
*
* Copyright (C) 2013, Digium, Inc.
*
* Mark Michelson <mmichelson@digium.com>
*
* See http://www.asterisk.org for more information about
* the Asterisk project. Please do not directly contact
* any of the maintainers of this project for assistance;
* the project provides a web site, mailing lists and IRC
* channels for your use.
*
* This program is free software, distributed under the terms of
* the GNU General Public License Version 2. See the LICENSE file
* at the top of the source tree.
*/
/*** MODULEINFO
<depend>pjproject</depend>
<depend>res_pjsip</depend>
<depend>res_pjsip_pubsub</depend>
<support_level>core</support_level>
***/
#include "asterisk.h"
#include <pjsip.h>
#include <pjsip_simple.h>
#include <pjlib.h>
#include "asterisk/res_pjsip.h"
#include "asterisk/res_pjsip_pubsub.h"
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
#include "asterisk/res_pjsip_body_generator_types.h"
#include "asterisk/module.h"
#include "asterisk/logger.h"
#include "asterisk/astobj2.h"
#include "asterisk/taskprocessor.h"
#include "asterisk/serializer.h"
#include "asterisk/sorcery.h"
#include "asterisk/stasis.h"
#include "asterisk/mwi.h"
struct mwi_subscription;
AO2_GLOBAL_OBJ_STATIC(mwi_unsolicited);
AO2_GLOBAL_OBJ_STATIC(mwi_solicited);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
static char *default_voicemail_extension;
#define STASIS_BUCKETS 13
#define MWI_BUCKETS 53
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
#define MWI_TYPE "application"
#define MWI_SUBTYPE "simple-message-summary"
#define MWI_DATASTORE "MWI datastore"
/*! Number of serializers in pool if one not supplied. */
#define MWI_SERIALIZER_POOL_SIZE 8
/*! Max timeout for all threads to join during an unload. */
#define MAX_UNLOAD_TIMEOUT_TIME 10 /* Seconds */
/*! Pool of serializers to use if not supplied. */
static struct ast_serializer_pool *mwi_serializer_pool;
static void mwi_subscription_shutdown(struct ast_sip_subscription *sub);
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
static void mwi_to_ami(struct ast_sip_subscription *sub, struct ast_str **buf);
static int mwi_new_subscribe(struct ast_sip_endpoint *endpoint,
const char *resource);
static int mwi_subscription_established(struct ast_sip_subscription *sub);
static void *mwi_get_notify_data(struct ast_sip_subscription *sub);
static struct ast_sip_notifier mwi_notifier = {
.default_accept = MWI_TYPE"/"MWI_SUBTYPE,
.new_subscribe = mwi_new_subscribe,
.subscription_established = mwi_subscription_established,
.get_notify_data = mwi_get_notify_data,
};
static struct ast_sip_subscription_handler mwi_handler = {
.event_name = "message-summary",
.body_type = AST_SIP_MESSAGE_ACCUMULATOR,
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
.accept = { MWI_TYPE"/"MWI_SUBTYPE, },
.subscription_shutdown = mwi_subscription_shutdown,
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
.to_ami = mwi_to_ami,
.notifier = &mwi_notifier,
};
/*!
* \brief Wrapper for stasis subscription
*
* An MWI subscription has a container of these. This
* represents a stasis subscription for MWI state.
*/
struct mwi_stasis_subscription {
/*! The MWI stasis subscription */
struct ast_mwi_subscriber *mwi_subscriber;
/*! The mailbox corresponding with the MWI subscription. Used as a hash key */
char mailbox[1];
};
/*!
* \brief A subscription for MWI
*
* This subscription is the basis for MWI for an endpoint. Each
* endpoint that uses MWI will have a corresponding mwi_subscription.
*
* This structure acts as the owner for the underlying SIP subscription.
* When the mwi_subscription is destroyed, the SIP subscription dies, too.
* The mwi_subscription's lifetime is governed by its underlying stasis
* subscriptions. When all stasis subscriptions are destroyed, the
* mwi_subscription is destroyed as well.
*/
struct mwi_subscription {
/*! Container of \ref mwi_stasis_subscription structures.
* A single MWI subscription may be for multiple mailboxes, thus
* requiring multiple stasis subscriptions
*/
struct ao2_container *stasis_subs;
/*! The SIP subscription. Unsolicited MWI does not use this */
struct ast_sip_subscription *sip_sub;
/*! AORs we should react to for unsolicited MWI NOTIFY */
char *aors;
/*! Is the MWI solicited (i.e. Initiated with an external SUBSCRIBE) ? */
unsigned int is_solicited;
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/*! True if this subscription is to be terminated */
unsigned int terminate;
/*! Identifier for the subscription.
* The identifier is the same as the corresponding endpoint's stasis ID.
* Used as a hash key
*/
char id[1];
};
static void mwi_stasis_cb(void *userdata, struct stasis_subscription *sub,
Multiple revisions 399887,400138,400178,400180-400181 ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
struct stasis_message *msg);
static struct mwi_stasis_subscription *mwi_stasis_subscription_alloc(const char *mailbox, struct mwi_subscription *mwi_sub)
{
struct mwi_stasis_subscription *mwi_stasis_sub;
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
if (!mwi_sub) {
return NULL;
}
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
mwi_stasis_sub = ao2_alloc(sizeof(*mwi_stasis_sub) + strlen(mailbox), NULL);
if (!mwi_stasis_sub) {
return NULL;
}
/* Safe strcpy */
strcpy(mwi_stasis_sub->mailbox, mailbox);
ao2_ref(mwi_sub, +1);
mwi_stasis_sub->mwi_subscriber = ast_mwi_subscribe_pool(mailbox, mwi_stasis_cb, mwi_sub);
if (!mwi_stasis_sub->mwi_subscriber) {
/* Failed to subscribe. */
ao2_ref(mwi_stasis_sub, -1);
ao2_ref(mwi_sub, -1);
return NULL;
}
stasis_subscription_accept_message_type(
ast_mwi_subscriber_subscription(mwi_stasis_sub->mwi_subscriber),
stasis_subscription_change_type());
return mwi_stasis_sub;
}
static int stasis_sub_hash(const void *obj, const int flags)
{
const struct mwi_stasis_subscription *object;
const char *key;
switch (flags & OBJ_SEARCH_MASK) {
case OBJ_SEARCH_KEY:
key = obj;
break;
case OBJ_SEARCH_OBJECT:
object = obj;
key = object->mailbox;
break;
default:
ast_assert(0);
return 0;
}
return ast_str_hash(key);
}
static int stasis_sub_cmp(void *obj, void *arg, int flags)
{
const struct mwi_stasis_subscription *sub_left = obj;
const struct mwi_stasis_subscription *sub_right = arg;
const char *right_key = arg;
int cmp;
switch (flags & OBJ_SEARCH_MASK) {
case OBJ_SEARCH_OBJECT:
right_key = sub_right->mailbox;
/* Fall through */
case OBJ_SEARCH_KEY:
cmp = strcmp(sub_left->mailbox, right_key);
break;
case OBJ_SEARCH_PARTIAL_KEY:
cmp = strncmp(sub_left->mailbox, right_key, strlen(right_key));
break;
default:
cmp = 0;
break;
}
if (cmp) {
return 0;
}
return CMP_MATCH;
}
static void mwi_subscription_destructor(void *obj)
{
struct mwi_subscription *sub = obj;
ast_debug(3, "Destroying MWI subscription for endpoint %s\n", sub->id);
res_pjsip_pubsub: Solidify lifetime and ownership of objects. There have been crashes and general instability seen in the pubsub code, so this patch introduces three changes to increase the stability. First, the ownership model for subscriptions has been modified. Due to RLS, subscriptions are stored in memory as a tree structure. Prior to my patch, the PJSIP subscription was the owner of the subscription tree. When the PJSIP subscription told us that it was terminating, we started destroying the subscription tree along with all of the individual leaf subscriptions that belong to the tree. The problem with this model is that the two actors in play here, the PJSIP subscription and the individual leaf subscriptions, need to have joint ownership of the subscription tree. So now, the PJSIP subscription and the individual leaf subscriptions each have a reference to the subscription tree. This way, we will not actually free memory until no players are left that care. The PJSIP subscription is a bigger stakeholder, in that if the PJSIP subscription's reference to the subscription tree is removed, the subscription tree instructs the leaf subscriptions to shut down and drop their references to the subscription tree when possible. The individual leaf subscriptions, upon being told to shut down, can drop their stasis subscriptions or whatever they use to learn of new state, and then drop their reference to the subscription tree once they are ready to die. Second, the lifetime of a PJSIP subscription's reference to our subscription tree has been altered. As I learned from doing a deep dive, the PJSIP evsub code can tell Asterisk multiple times that the subscription has been terminated, and not all of these times are especially helpful. I have altered the message flow that we use for SIP subscriptions such that we will always drop the PJSIP subscription's reference to the subscription tree when we send the NOTIFY that terminates a SIP subscription. This also means that we will now queue NOTIFY requests to be sent after responding to incoming SUBSCRIBEs so that we can have predictable state changes from the PJSIP evsub code. Third, the synchronization of operations has been improved. PJSIP can call into our code from a serializer thread (e.g. upon receiving an incoming request) or from the monitor thread (e.g. when a subscription times out). Because of this, there is the possibility of competing threads stepping on each other. PJSIP attempts to do some synchronization on its own by always keeping the dialog lock held when it calls into us. However, since we end up pushing tasks into the serializer, the result was that serialized operations were not grabbing the dialog lock and could, as a result, step on something that was being attempted by a different thread. Now we ensure that serialized operations grab the dialog lock, then check for extenuating circumstances, then proceed with their operation if they can. Change-Id: Iff2990c40178dad9cc5f6a5c7f76932ec644b2e5
2015-09-01 20:47:19 +00:00
if (sub->is_solicited) {
ast_sip_subscription_destroy(sub->sip_sub);
}
ao2_cleanup(sub->stasis_subs);
ast_free(sub->aors);
}
static struct mwi_subscription *mwi_subscription_alloc(struct ast_sip_endpoint *endpoint,
unsigned int is_solicited, struct ast_sip_subscription *sip_sub)
{
struct mwi_subscription *sub;
const char *endpoint_id = ast_sorcery_object_get_id(endpoint);
sub = ao2_alloc(sizeof(*sub) + strlen(endpoint_id),
mwi_subscription_destructor);
if (!sub) {
return NULL;
}
/* Safe strcpy */
strcpy(sub->id, endpoint_id);
/* Unsolicited MWI doesn't actually result in a SIP subscription being
* created. This is because a SIP subscription associates with a dialog.
* Most devices expect unsolicited MWI NOTIFYs to appear out of dialog. If
* they receive an in-dialog MWI NOTIFY (i.e. with a to-tag), then they
* will reject the NOTIFY with a 481, thus resulting in message-waiting
* state not being updated on the device
*/
if (is_solicited) {
res_pjsip_pubsub: Solidify lifetime and ownership of objects. There have been crashes and general instability seen in the pubsub code, so this patch introduces three changes to increase the stability. First, the ownership model for subscriptions has been modified. Due to RLS, subscriptions are stored in memory as a tree structure. Prior to my patch, the PJSIP subscription was the owner of the subscription tree. When the PJSIP subscription told us that it was terminating, we started destroying the subscription tree along with all of the individual leaf subscriptions that belong to the tree. The problem with this model is that the two actors in play here, the PJSIP subscription and the individual leaf subscriptions, need to have joint ownership of the subscription tree. So now, the PJSIP subscription and the individual leaf subscriptions each have a reference to the subscription tree. This way, we will not actually free memory until no players are left that care. The PJSIP subscription is a bigger stakeholder, in that if the PJSIP subscription's reference to the subscription tree is removed, the subscription tree instructs the leaf subscriptions to shut down and drop their references to the subscription tree when possible. The individual leaf subscriptions, upon being told to shut down, can drop their stasis subscriptions or whatever they use to learn of new state, and then drop their reference to the subscription tree once they are ready to die. Second, the lifetime of a PJSIP subscription's reference to our subscription tree has been altered. As I learned from doing a deep dive, the PJSIP evsub code can tell Asterisk multiple times that the subscription has been terminated, and not all of these times are especially helpful. I have altered the message flow that we use for SIP subscriptions such that we will always drop the PJSIP subscription's reference to the subscription tree when we send the NOTIFY that terminates a SIP subscription. This also means that we will now queue NOTIFY requests to be sent after responding to incoming SUBSCRIBEs so that we can have predictable state changes from the PJSIP evsub code. Third, the synchronization of operations has been improved. PJSIP can call into our code from a serializer thread (e.g. upon receiving an incoming request) or from the monitor thread (e.g. when a subscription times out). Because of this, there is the possibility of competing threads stepping on each other. PJSIP attempts to do some synchronization on its own by always keeping the dialog lock held when it calls into us. However, since we end up pushing tasks into the serializer, the result was that serialized operations were not grabbing the dialog lock and could, as a result, step on something that was being attempted by a different thread. Now we ensure that serialized operations grab the dialog lock, then check for extenuating circumstances, then proceed with their operation if they can. Change-Id: Iff2990c40178dad9cc5f6a5c7f76932ec644b2e5
2015-09-01 20:47:19 +00:00
sub->sip_sub = sip_sub;
}
sub->stasis_subs = ao2_container_alloc_hash(AO2_ALLOC_OPT_LOCK_MUTEX, 0,
STASIS_BUCKETS, stasis_sub_hash, NULL, stasis_sub_cmp);
if (!sub->stasis_subs) {
ao2_cleanup(sub);
return NULL;
}
sub->is_solicited = is_solicited;
if (!is_solicited && !ast_strlen_zero(endpoint->aors)) {
sub->aors = ast_strdup(endpoint->aors);
if (!sub->aors) {
ao2_ref(sub, -1);
return NULL;
}
}
ast_debug(3, "Created %s MWI subscription for endpoint %s\n", is_solicited ? "solicited" : "unsolicited", sub->id);
return sub;
}
static int mwi_sub_hash(const void *obj, const int flags)
{
const struct mwi_subscription *object;
const char *key;
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
switch (flags & OBJ_SEARCH_MASK) {
case OBJ_SEARCH_KEY:
key = obj;
break;
case OBJ_SEARCH_OBJECT:
object = obj;
key = object->id;
break;
default:
ast_assert(0);
return 0;
}
return ast_str_hash(key);
}
static int mwi_sub_cmp(void *obj, void *arg, int flags)
{
const struct mwi_subscription *sub_left = obj;
const struct mwi_subscription *sub_right = arg;
const char *right_key = arg;
int cmp;
switch (flags & OBJ_SEARCH_MASK) {
case OBJ_SEARCH_OBJECT:
right_key = sub_right->id;
/* Fall through */
case OBJ_SEARCH_KEY:
cmp = strcmp(sub_left->id, right_key);
break;
case OBJ_SEARCH_PARTIAL_KEY:
cmp = strncmp(sub_left->id, right_key, strlen(right_key));
break;
default:
cmp = 0;
break;
}
if (cmp) {
return 0;
}
return CMP_MATCH;
}
static int get_message_count(void *obj, void *arg, int flags)
{
struct mwi_stasis_subscription *mwi_stasis = obj;
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
struct ast_sip_message_accumulator *counter = arg;
struct ast_mwi_state *mwi_state;
mwi_state = ast_mwi_subscriber_data(mwi_stasis->mwi_subscriber);
if (!mwi_state) {
return 0;
}
counter->old_msgs += mwi_state->old_msgs;
counter->new_msgs += mwi_state->new_msgs;
ao2_ref(mwi_state, -1);
return 0;
}
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
static void set_voicemail_extension(pj_pool_t *pool, pjsip_sip_uri *local_uri,
struct ast_sip_message_accumulator *counter, const char *voicemail_extension)
{
pjsip_sip_uri *account_uri;
const char *vm_exten;
if (ast_strlen_zero(voicemail_extension)) {
vm_exten = default_voicemail_extension;
} else {
vm_exten = voicemail_extension;
}
if (!ast_strlen_zero(vm_exten)) {
account_uri = pjsip_uri_clone(pool, local_uri);
pj_strdup2(pool, &account_uri->user, vm_exten);
pjsip_uri_print(PJSIP_URI_IN_CONTACT_HDR, account_uri, counter->message_account, sizeof(counter->message_account));
}
}
struct unsolicited_mwi_data {
struct mwi_subscription *sub;
struct ast_sip_endpoint *endpoint;
pjsip_evsub_state state;
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
struct ast_sip_message_accumulator *counter;
};
static int send_unsolicited_mwi_notify_to_contact(void *obj, void *arg, int flags)
{
struct unsolicited_mwi_data *mwi_data = arg;
struct mwi_subscription *sub = mwi_data->sub;
struct ast_sip_endpoint *endpoint = mwi_data->endpoint;
pjsip_evsub_state state = mwi_data->state;
struct ast_sip_contact *contact = obj;
const char *state_name;
pjsip_tx_data *tdata;
pjsip_sub_state_hdr *sub_state;
pjsip_event_hdr *event;
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
pjsip_from_hdr *from;
pjsip_sip_uri *from_uri;
const pjsip_hdr *allow_events = pjsip_evsub_get_allow_events_hdr(NULL);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
struct ast_sip_body body;
struct ast_str *body_text;
struct ast_sip_body_data body_data = {
.body_type = AST_SIP_MESSAGE_ACCUMULATOR,
.body_data = mwi_data->counter,
};
if (ast_sip_create_request("NOTIFY", NULL, endpoint, NULL, contact, &tdata)) {
ast_log(LOG_WARNING, "Unable to create unsolicited NOTIFY request to endpoint %s URI %s\n", sub->id, contact->uri);
return 0;
}
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
body.type = MWI_TYPE;
body.subtype = MWI_SUBTYPE;
body_text = ast_str_create(64);
if (!body_text) {
pjsip_tx_data_dec_ref(tdata);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
return 0;
}
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
from = PJSIP_MSG_FROM_HDR(tdata->msg);
from_uri = pjsip_uri_get_uri(from->uri);
if (!ast_strlen_zero(endpoint->subscription.mwi.fromuser)) {
pj_strdup2(tdata->pool, &from_uri->user, endpoint->subscription.mwi.fromuser);
}
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
set_voicemail_extension(tdata->pool, from_uri, mwi_data->counter, endpoint->subscription.mwi.voicemail_extension);
if (ast_sip_pubsub_generate_body_content(body.type, body.subtype, &body_data, &body_text)) {
ast_log(LOG_WARNING, "Unable to generate SIP MWI NOTIFY body.\n");
ast_free(body_text);
pjsip_tx_data_dec_ref(tdata);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
return 0;
}
body.body_text = ast_str_buffer(body_text);
switch (state) {
case PJSIP_EVSUB_STATE_ACTIVE:
state_name = "active";
break;
case PJSIP_EVSUB_STATE_TERMINATED:
default:
state_name = "terminated";
break;
}
sub_state = pjsip_sub_state_hdr_create(tdata->pool);
pj_cstr(&sub_state->sub_state, state_name);
pjsip_msg_add_hdr(tdata->msg, (pjsip_hdr *) sub_state);
event = pjsip_event_hdr_create(tdata->pool);
pj_cstr(&event->event_type, "message-summary");
pjsip_msg_add_hdr(tdata->msg, (pjsip_hdr *) event);
pjsip_msg_add_hdr(tdata->msg, pjsip_hdr_shallow_clone(tdata->pool, allow_events));
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
ast_sip_add_body(tdata, &body);
ast_sip_send_request(tdata, NULL, endpoint, NULL, NULL);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
ast_free(body_text);
return 0;
}
static struct ast_sip_aor *find_aor_for_resource(struct ast_sip_endpoint *endpoint, const char *resource)
{
struct ast_sip_aor *aor;
char *aor_name;
char *aors_copy;
/* Direct match */
if ((aor = ast_sip_location_retrieve_aor(resource))) {
return aor;
}
if (!endpoint) {
return NULL;
}
/*
* This may be a subscribe to the voicemail_extension. If so,
* look for an aor belonging to this endpoint that has a matching
* voicemail_extension.
*/
aors_copy = ast_strdupa(endpoint->aors);
while ((aor_name = ast_strip(strsep(&aors_copy, ",")))) {
struct ast_sip_aor *check_aor = ast_sip_location_retrieve_aor(aor_name);
if (!check_aor) {
continue;
}
if (!ast_strlen_zero(check_aor->voicemail_extension)
&& !strcasecmp(check_aor->voicemail_extension, resource)) {
ast_debug(1, "Found an aor (%s) that matches voicemail_extension %s\n", aor_name, resource);
return check_aor;
}
ao2_ref(check_aor, -1);
}
return NULL;
}
static void send_unsolicited_mwi_notify(struct mwi_subscription *sub,
struct ast_sip_message_accumulator *counter)
{
RAII_VAR(struct ast_sip_endpoint *, endpoint, ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(),
"endpoint", sub->id), ao2_cleanup);
char *endpoint_aors;
char *aor_name;
if (!endpoint) {
ast_log(LOG_WARNING, "Unable to send unsolicited MWI to %s because endpoint does not exist\n",
sub->id);
return;
}
if (ast_strlen_zero(endpoint->aors)) {
ast_log(LOG_WARNING, "Unable to send unsolicited MWI to %s because the endpoint has no"
" configured AORs\n", sub->id);
return;
}
endpoint_aors = ast_strdupa(endpoint->aors);
ast_debug(5, "Sending unsolicited MWI NOTIFY to endpoint %s, new messages: %d, old messages: %d\n",
sub->id, counter->new_msgs, counter->old_msgs);
while ((aor_name = ast_strip(strsep(&endpoint_aors, ",")))) {
RAII_VAR(struct ast_sip_aor *, aor, ast_sip_location_retrieve_aor(aor_name), ao2_cleanup);
RAII_VAR(struct ao2_container *, contacts, NULL, ao2_cleanup);
struct unsolicited_mwi_data mwi_data = {
.sub = sub,
.endpoint = endpoint,
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
.counter = counter,
};
if (!aor) {
ast_log(LOG_WARNING, "Unable to locate AOR %s for unsolicited MWI\n", aor_name);
continue;
}
contacts = ast_sip_location_retrieve_aor_contacts(aor);
if (!contacts || (ao2_container_count(contacts) == 0)) {
ast_debug(1, "No contacts bound to AOR %s. Cannot send unsolicited MWI until a contact registers.\n", aor_name);
continue;
}
ao2_callback(contacts, OBJ_NODATA, send_unsolicited_mwi_notify_to_contact, &mwi_data);
}
}
static void send_mwi_notify(struct mwi_subscription *sub)
{
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
struct ast_sip_message_accumulator counter = {
.old_msgs = 0,
.new_msgs = 0,
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
.message_account[0] = '\0',
};
struct ast_sip_body_data data = {
.body_type = AST_SIP_MESSAGE_ACCUMULATOR,
.body_data = &counter,
};
ao2_callback(sub->stasis_subs, OBJ_NODATA, get_message_count, &counter);
if (sub->is_solicited) {
const char *resource = ast_sip_subscription_get_resource_name(sub->sip_sub);
struct ast_sip_endpoint *endpoint = ast_sip_subscription_get_endpoint(sub->sip_sub);
struct ast_sip_aor *aor = find_aor_for_resource(endpoint, resource);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
pjsip_dialog *dlg = ast_sip_subscription_get_dialog(sub->sip_sub);
pjsip_sip_uri *sip_uri = ast_sip_subscription_get_sip_uri(sub->sip_sub);
if (aor && dlg && sip_uri) {
set_voicemail_extension(dlg->pool, sip_uri, &counter, aor->voicemail_extension);
}
ao2_cleanup(aor);
ao2_cleanup(endpoint);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
ast_sip_subscription_notify(sub->sip_sub, &data, sub->terminate);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
Decouple subscription handling from NOTIFY/PUBLISH body generation. When the PJSIP pubsub framework was created, subscription handlers were required to state what event they handled along with what body types they knew how to generate. While this serves well when implementing a base RFC, it has problems when trying to extend the body to support non-standard or proprietary body elements. The code also was NOTIFY-specific, meaning that when the time comes that we start writing code to send out PUBLISH requests with MWI or presence bodies, we would likely find ourselves duplicating code that had previously been written. This changeset introduces the concept of body generators and body supplements. A body generator is responsible for allocating a native structure for a given body type, providing the primary body content, converting the native structure to a string, and deallocating resources. A body supplement takes the primary body content (the native structure, not a string) generated by the body generator and adds nonstandard elements to the body. With these elements living in their own module, it becomes easy to extend our support for body types and to re-use resources when sending a PUBLISH request. Body generators and body supplements register themselves with the pubsub core, similar to how subscription and publish handlers had done. Now, subscription handlers do not need to know what type of body content they generate, but they still need to inform the pubsub core about what the default body type for a given event package is. The pubsub core keeps track of what body generators and body supplements have been registered. When a SUBSCRIBE arrives, the pubsub core will check that there is a subscription handler for the event in the SUBSCRIBE, then it will check that there is a body generator that can provide the content specified in the Accept header(s). Because of the nature of body generators and supplements, it means res_pjsip_exten_state and res_pjsip_mwi have been completely gutted. They no longer worry about body types, instead calling ast_sip_pubsub_generate_body_content() when they need to generate a NOTIFY body. Review: https://reviewboard.asterisk.org/r/3150 ........ Merged revisions 407016 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407030 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2014-01-31 22:27:07 +00:00
return;
}
send_unsolicited_mwi_notify(sub, &counter);
}
static int unsubscribe_stasis(void *obj, void *arg, int flags)
{
struct mwi_stasis_subscription *mwi_stasis = obj;
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (mwi_stasis->mwi_subscriber) {
ast_debug(3, "Removing stasis subscription to mailbox %s\n", mwi_stasis->mailbox);
mwi_stasis->mwi_subscriber = ast_mwi_unsubscribe_and_join(mwi_stasis->mwi_subscriber);
}
return CMP_MATCH;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
static int create_unsolicited_mwi_subscriptions(struct ast_sip_endpoint *endpoint,
int recreate, int send_now, struct ao2_container *unsolicited_mwi, struct ao2_container *solicited_mwi);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
static void mwi_subscription_shutdown(struct ast_sip_subscription *sub)
{
struct mwi_subscription *mwi_sub;
struct ast_datastore *mwi_datastore;
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
struct ast_sip_endpoint *endpoint = NULL;
struct ao2_container *unsolicited_mwi;
struct ao2_container *solicited_mwi;
mwi_datastore = ast_sip_subscription_get_datastore(sub, MWI_DATASTORE);
if (!mwi_datastore) {
return;
}
mwi_sub = mwi_datastore->data;
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
ao2_callback(mwi_sub->stasis_subs, OBJ_UNLINK | OBJ_NODATA | OBJ_MULTIPLE, unsubscribe_stasis, NULL);
ast_sip_subscription_remove_datastore(sub, MWI_DATASTORE);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
endpoint = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", mwi_sub->id);
ao2_ref(mwi_datastore, -1);
solicited_mwi = ao2_global_obj_ref(mwi_solicited);
if (solicited_mwi) {
ao2_unlink(solicited_mwi, mwi_sub);
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/*
* When a solicited subscription is removed it's possible an unsolicited one
* needs to be [re-]created. Attempt to establish unsolicited MWI.
*/
unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (unsolicited_mwi && endpoint) {
ao2_lock(unsolicited_mwi);
create_unsolicited_mwi_subscriptions(endpoint, 1, 1, unsolicited_mwi, solicited_mwi);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
ao2_unlock(unsolicited_mwi);
ao2_ref(unsolicited_mwi, -1);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
}
ao2_cleanup(solicited_mwi);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
ao2_cleanup(endpoint);
}
static void mwi_ds_destroy(void *data)
{
struct mwi_subscription *sub = data;
ao2_ref(sub, -1);
}
static struct ast_datastore_info mwi_ds_info = {
.destroy = mwi_ds_destroy,
};
static int add_mwi_datastore(struct mwi_subscription *sub)
{
struct ast_datastore *mwi_datastore;
int res;
mwi_datastore = ast_sip_subscription_alloc_datastore(&mwi_ds_info, MWI_DATASTORE);
if (!mwi_datastore) {
return -1;
}
ao2_ref(sub, +1);
mwi_datastore->data = sub;
/*
* NOTE: Adding the datastore to the subscription creates a ref loop
* that must be manually broken.
*/
res = ast_sip_subscription_add_datastore(sub->sip_sub, mwi_datastore);
ao2_ref(mwi_datastore, -1);
return res;
}
/*!
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
* \internal
* \brief Determine if an MWI subscription already exists for the given endpoint/mailbox
*
* Search the given container, and attempt to find out if the given endpoint has a
* current subscription within. If so pass back the associated mwi_subscription and
* mwi_stasis_subscription objects.
*
* \note If a subscription is located then the caller is responsible for removing the
* references to the passed back mwi_subscription and mwi_stasis_subscription objects.
*
* \note Must be called with the given container already locked.
*
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
* \param container The ao2_container to search
* \param endpoint The endpoint to find
* \param mailbox The mailbox potentially subscribed
* \param[out] mwi_sub May contain the located mwi_subscription
* \param[out] mwi_stasis May contain the located mwi_stasis_subscription
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
*
* \retval 1 if a subscription was located, 0 otherwise
*/
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
static int has_mwi_subscription(struct ao2_container *container,
struct ast_sip_endpoint *endpoint, const char *mailbox,
struct mwi_subscription **mwi_sub, struct mwi_stasis_subscription **mwi_stasis)
{
struct ao2_iterator *mwi_subs;
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
*mwi_sub = NULL;
*mwi_stasis = NULL;
if (!container) {
return 0;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
mwi_subs = ao2_find(container, ast_sorcery_object_get_id(endpoint),
OBJ_SEARCH_KEY | OBJ_MULTIPLE | OBJ_NOLOCK);
if (!mwi_subs) {
return 0;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
while ((*mwi_sub = ao2_iterator_next(mwi_subs))) {
*mwi_stasis = ao2_find((*mwi_sub)->stasis_subs, mailbox, OBJ_SEARCH_KEY);
if (*mwi_stasis) {
/* If found then caller is responsible for unrefs of passed back objects */
break;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
ao2_ref(*mwi_sub, -1);
}
ao2_iterator_destroy(mwi_subs);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
return *mwi_stasis ? 1 : 0;
}
/*!
* \internal
* \brief Allow and/or replace the unsolicited subscription
*
* Checks to see if solicited subscription is allowed. If allowed, and an
* unsolicited one exists then prepare for replacement by removing the
* current unsolicited subscription.
*
* \param endpoint The endpoint
* \param mailbox The mailbox
* \param unsolicited_mwi A container of unsolicited mwi objects
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
*
* \retval 1 if a solicited subscription is allowed for the endpoint/mailbox
* 0 otherwise
*/
static int allow_and_or_replace_unsolicited(struct ast_sip_endpoint *endpoint, const char *mailbox,
struct ao2_container *unsolicited_mwi)
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
{
struct mwi_subscription *mwi_sub;
struct mwi_stasis_subscription *mwi_stasis;
if (!has_mwi_subscription(unsolicited_mwi, endpoint, mailbox, &mwi_sub, &mwi_stasis)) {
/* If no unsolicited subscription then allow the solicited one */
return 1;
}
if (!endpoint->subscription.mwi.subscribe_replaces_unsolicited) {
/* Has unsolicited subscription and can't replace, so disallow */
ao2_ref(mwi_stasis, -1);
ao2_ref(mwi_sub, -1);
return 0;
}
/*
* The unsolicited subscription exists, and it is allowed to be replaced.
* So, first remove the unsolicited stasis subscription, and if aggregation
* is not enabled then also remove the mwi_subscription object as well.
*/
ast_debug(1, "Unsolicited subscription being replaced by solicited for "
"endpoint '%s' mailbox '%s'\n", ast_sorcery_object_get_id(endpoint), mailbox);
unsubscribe_stasis(mwi_stasis, NULL, 0);
ao2_unlink(mwi_sub->stasis_subs, mwi_stasis);
if (!endpoint->subscription.mwi.aggregate) {
ao2_unlink(unsolicited_mwi, mwi_sub);
}
ao2_ref(mwi_stasis, -1);
ao2_ref(mwi_sub, -1);
/* This solicited subscription is replacing an unsolicited one, so allow */
return 1;
}
static int send_notify(void *obj, void *arg, int flags);
/*!
* \internal
* \brief Determine if an unsolicited MWI subscription is allowed
*
* \param endpoint The endpoint
* \param mailbox The mailbox
* \param unsolicited_mwi A container of unsolicited mwi objects
* \param solicited_mwi A container of solicited mwi objects
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
*
* \retval 1 if an unsolicited subscription is allowed for the endpoint/mailbox
* 0 otherwise
*/
static int is_unsolicited_allowed(struct ast_sip_endpoint *endpoint, const char *mailbox,
struct ao2_container *unsolicited_mwi, struct ao2_container *solicited_mwi)
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
{
struct mwi_subscription *mwi_sub;
struct mwi_stasis_subscription *mwi_stasis;
if (ast_strlen_zero(mailbox)) {
return 0;
}
/*
* First check if an unsolicited subscription exists. If it does then we don't
* want to add another one.
*/
if (has_mwi_subscription(unsolicited_mwi, endpoint, mailbox, &mwi_sub, &mwi_stasis)) {
ao2_ref(mwi_stasis, -1);
ao2_ref(mwi_sub, -1);
return 0;
}
/*
* If there is no unsolicited subscription, next check to see if a solicited
* subscription exists for the endpoint/mailbox. If not, then allow.
*/
if (!has_mwi_subscription(solicited_mwi, endpoint, mailbox, &mwi_sub, &mwi_stasis)) {
return 1;
}
/*
* If however, a solicited subscription does exist then we'll need to see if that
* subscription is allowed to replace the unsolicited one. If is allowed to replace
* then disallow the unsolicited one.
*/
if (endpoint->subscription.mwi.subscribe_replaces_unsolicited) {
ao2_ref(mwi_stasis, -1);
ao2_ref(mwi_sub, -1);
return 0;
}
/* Otherwise, shutdown the solicited subscription and allow the unsolicited */
mwi_sub->terminate = 1;
send_notify(mwi_sub, NULL, 0);
ao2_ref(mwi_stasis, -1);
ao2_ref(mwi_sub, -1);
return 1;
}
/*!
* \brief Determine if an endpoint is a candidate to be able to subscribe for MWI
*
* Currently, this just makes sure that the endpoint is not already receiving unsolicted
* MWI for any of an AOR's configured mailboxes.
*
* \param obj The AOR to which the endpoint is subscribing.
* \param arg The endpoint that is attempting to subscribe.
* \param flags Unused.
* \retval 0 Endpoint is a candidate to subscribe to MWI on the AOR.
* \retval -1 The endpoint cannot subscribe to MWI on the AOR.
*/
static int mwi_validate_for_aor(void *obj, void *arg, int flags)
{
struct ast_sip_aor *aor = obj;
struct ast_sip_endpoint *endpoint = arg;
char *mailboxes;
char *mailbox;
struct ao2_container *unsolicited_mwi;
if (ast_strlen_zero(aor->mailboxes)) {
return 0;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/* A reload could be taking place so lock while checking if allowed */
unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
if (unsolicited_mwi) {
ao2_lock(unsolicited_mwi);
}
mailboxes = ast_strdupa(aor->mailboxes);
while ((mailbox = ast_strip(strsep(&mailboxes, ",")))) {
if (ast_strlen_zero(mailbox)) {
continue;
}
if (!allow_and_or_replace_unsolicited(endpoint, mailbox, unsolicited_mwi)) {
ast_debug(1, "Endpoint '%s' already configured for unsolicited MWI for mailbox '%s'. "
"Denying MWI subscription to %s\n", ast_sorcery_object_get_id(endpoint), mailbox,
ast_sorcery_object_get_id(aor));
if (unsolicited_mwi) {
ao2_unlock(unsolicited_mwi);
ao2_ref(unsolicited_mwi, -1);
}
return -1;
}
}
if (unsolicited_mwi) {
ao2_unlock(unsolicited_mwi);
ao2_ref(unsolicited_mwi, -1);
}
return 0;
}
static int mwi_on_aor(void *obj, void *arg, int flags)
{
struct ast_sip_aor *aor = obj;
struct mwi_subscription *sub = arg;
char *mailboxes;
char *mailbox;
if (ast_strlen_zero(aor->mailboxes)) {
return 0;
}
mailboxes = ast_strdupa(aor->mailboxes);
while ((mailbox = ast_strip(strsep(&mailboxes, ",")))) {
struct mwi_stasis_subscription *mwi_stasis_sub;
if (ast_strlen_zero(mailbox)) {
continue;
}
mwi_stasis_sub = mwi_stasis_subscription_alloc(mailbox, sub);
if (!mwi_stasis_sub) {
continue;
}
ao2_link(sub->stasis_subs, mwi_stasis_sub);
ao2_ref(mwi_stasis_sub, -1);
}
return 0;
}
static struct mwi_subscription *mwi_create_subscription(
struct ast_sip_endpoint *endpoint, struct ast_sip_subscription *sip_sub)
{
struct mwi_subscription *sub = mwi_subscription_alloc(endpoint, 1, sip_sub);
if (!sub) {
return NULL;
}
if (add_mwi_datastore(sub)) {
ast_log(LOG_WARNING, "Unable to add datastore for MWI subscription to %s\n",
sub->id);
ao2_ref(sub, -1);
return NULL;
}
return sub;
}
static struct mwi_subscription *mwi_subscribe_single(
struct ast_sip_endpoint *endpoint, struct ast_sip_subscription *sip_sub, const char *name)
{
struct ast_sip_aor *aor;
struct mwi_subscription *sub;
aor = find_aor_for_resource(endpoint, name);
if (!aor) {
ast_log(LOG_WARNING, "Unable to locate aor %s. MWI subscription failed.\n", name);
return NULL;
}
sub = mwi_create_subscription(endpoint, sip_sub);
if (sub) {
mwi_on_aor(aor, sub, 0);
}
ao2_ref(aor, -1);
return sub;
}
static struct mwi_subscription *mwi_subscribe_all(
struct ast_sip_endpoint *endpoint, struct ast_sip_subscription *sip_sub)
{
struct mwi_subscription *sub;
sub = mwi_create_subscription(endpoint, sip_sub);
if (!sub) {
return NULL;
}
ast_sip_for_each_aor(endpoint->aors, mwi_on_aor, sub);
return sub;
}
static int mwi_new_subscribe(struct ast_sip_endpoint *endpoint,
const char *resource)
{
RAII_VAR(struct ast_sip_aor *, aor, NULL, ao2_cleanup);
if (ast_strlen_zero(resource)) {
if (ast_sip_for_each_aor(endpoint->aors, mwi_validate_for_aor, endpoint)) {
return 500;
}
return 200;
}
aor = find_aor_for_resource(endpoint, resource);
if (!aor) {
ast_debug(1, "Unable to locate aor %s. MWI subscription failed.\n", resource);
return 404;
}
if (ast_strlen_zero(aor->mailboxes)) {
ast_debug(1, "AOR %s has no configured mailboxes. MWI subscription failed.\n",
resource);
return 404;
}
if (mwi_validate_for_aor(aor, endpoint, 0)) {
return 500;
}
return 200;
}
static int mwi_subscription_established(struct ast_sip_subscription *sip_sub)
{
const char *resource = ast_sip_subscription_get_resource_name(sip_sub);
struct mwi_subscription *sub;
struct ast_sip_endpoint *endpoint = ast_sip_subscription_get_endpoint(sip_sub);
struct ao2_container *solicited_mwi;
/* no aor in uri? subscribe to all on endpoint */
if (ast_strlen_zero(resource)) {
sub = mwi_subscribe_all(endpoint, sip_sub);
} else {
sub = mwi_subscribe_single(endpoint, sip_sub, resource);
}
if (!sub) {
ao2_cleanup(endpoint);
return -1;
}
if (!ao2_container_count(sub->stasis_subs)) {
/*
* We setup no MWI subscriptions so remove the MWI datastore
* to break the ref loop.
*/
ast_sip_subscription_remove_datastore(sip_sub, MWI_DATASTORE);
}
solicited_mwi = ao2_global_obj_ref(mwi_solicited);
if (solicited_mwi) {
ao2_link(solicited_mwi, sub);
ao2_ref(solicited_mwi, -1);
}
ao2_cleanup(sub);
ao2_cleanup(endpoint);
return 0;
}
static void *mwi_get_notify_data(struct ast_sip_subscription *sub)
{
struct ast_sip_message_accumulator *counter;
struct mwi_subscription *mwi_sub;
struct ast_datastore *mwi_datastore;
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
struct ast_sip_aor *aor;
struct ast_sip_endpoint *endpoint = ast_sip_subscription_get_endpoint(sub);
mwi_datastore = ast_sip_subscription_get_datastore(sub, MWI_DATASTORE);
if (!mwi_datastore) {
return NULL;
}
mwi_sub = mwi_datastore->data;
counter = ao2_alloc(sizeof(*counter), NULL);
if (!counter) {
ao2_cleanup(mwi_datastore);
return NULL;
}
if ((aor = find_aor_for_resource(endpoint, ast_sip_subscription_get_resource_name(sub)))) {
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
pjsip_dialog *dlg = ast_sip_subscription_get_dialog(sub);
pjsip_sip_uri *sip_uri = ast_sip_subscription_get_sip_uri(sub);
if (dlg && sip_uri) {
set_voicemail_extension(dlg->pool, sip_uri, counter, aor->voicemail_extension);
}
ao2_ref(aor, -1);
}
ao2_cleanup(endpoint);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
ao2_callback(mwi_sub->stasis_subs, OBJ_NODATA, get_message_count, counter);
ao2_cleanup(mwi_datastore);
return counter;
}
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
static void mwi_subscription_mailboxes_str(struct ao2_container *stasis_subs,
struct ast_str **str)
{
int is_first = 1;
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
struct mwi_stasis_subscription *node;
struct ao2_iterator i = ao2_iterator_init(stasis_subs, 0);
while ((node = ao2_iterator_next(&i))) {
if (is_first) {
is_first = 0;
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
ast_str_append(str, 0, "%s", node->mailbox);
} else {
ast_str_append(str, 0, ",%s", node->mailbox);
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
}
ao2_ref(node, -1);
}
ao2_iterator_destroy(&i);
}
static void mwi_to_ami(struct ast_sip_subscription *sub,
struct ast_str **buf)
{
struct mwi_subscription *mwi_sub;
struct ast_datastore *mwi_datastore;
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
mwi_datastore = ast_sip_subscription_get_datastore(sub, MWI_DATASTORE);
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
if (!mwi_datastore) {
return;
}
mwi_sub = mwi_datastore->data;
ast_str_append(buf, 0, "SubscriptionType: mwi\r\n");
ast_str_append(buf, 0, "Mailboxes: ");
mwi_subscription_mailboxes_str(mwi_sub->stasis_subs, buf);
ast_str_append(buf, 0, "\r\n");
ao2_ref(mwi_datastore, -1);
res_pjsip: AMI commands and events. Created the following AMI commands and corresponding events for res_pjsip: PJSIPShowEndpoints - Provides a listing of all pjsip endpoints and a few select attributes on each. Events: EndpointList - for each endpoint a few attributes. EndpointlistComplete - after all endpoints have been listed. PJSIPShowEndpoint - Provides a detail list of attributes for a specified endpoint. Events: EndpointDetail - attributes on an endpoint. AorDetail - raised for each AOR on an endpoint. AuthDetail - raised for each associated inbound and outbound auth TransportDetail - transport attributes. IdentifyDetail - attributes for the identify object associated with the endpoint. EndpointDetailComplete - last event raised after all detail events. PJSIPShowRegistrationsInbound - Provides a detail listing of all inbound registrations. Events: InboundRegistrationDetail - inbound registration attributes for each registration. InboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowRegistrationsOutbound - Provides a detail listing of all outbound registrations. Events: OutboundRegistrationDetail - outbound registration attributes for each registration. OutboundRegistrationDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsInbound - A detail listing of all inbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. PJSIPShowSubscriptionsOutbound - A detail listing of all outboundbound subscriptions and their attributes. Events: SubscriptionDetail - on each subscription detailed attributes SubscriptionDetailComplete - raised after all detail records have been listed. (issue ASTERISK-22609) Reported by: Matt Jordan Review: https://reviewboard.asterisk.org/r/2959/ ........ Merged revisions 403131 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403133 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-11-23 17:26:57 +00:00
}
static int serialized_notify(void *userdata)
{
struct mwi_subscription *mwi_sub = userdata;
send_mwi_notify(mwi_sub);
ao2_ref(mwi_sub, -1);
return 0;
}
static int serialized_cleanup(void *userdata)
{
struct mwi_subscription *mwi_sub = userdata;
/* This is getting rid of the reference that was added
* just before this serialized task was pushed.
*/
ao2_cleanup(mwi_sub);
/* This is getting rid of the reference held by the
* stasis subscription
*/
ao2_cleanup(mwi_sub);
return 0;
}
static int send_notify(void *obj, void *arg, int flags)
{
struct mwi_subscription *mwi_sub = obj;
struct ast_taskprocessor *serializer = mwi_sub->is_solicited
? ast_sip_subscription_get_serializer(mwi_sub->sip_sub)
: ast_serializer_pool_get(mwi_serializer_pool);
if (ast_sip_push_task(serializer, serialized_notify, ao2_bump(mwi_sub))) {
ao2_ref(mwi_sub, -1);
}
return 0;
}
static void mwi_stasis_cb(void *userdata, struct stasis_subscription *sub,
Multiple revisions 399887,400138,400178,400180-400181 ........ r399887 | dlee | 2013-09-26 10:41:47 -0500 (Thu, 26 Sep 2013) | 1 line Minor performance bump by not allocate manager variable struct if we don't need it ........ r400138 | dlee | 2013-09-30 10:24:00 -0500 (Mon, 30 Sep 2013) | 23 lines Stasis performance improvements This patch addresses several performance problems that were found in the initial performance testing of Asterisk 12. The Stasis dispatch object was allocated as an AO2 object, even though it has a very confined lifecycle. This was replaced with a straight ast_malloc(). The Stasis message router was spending an inordinate amount of time searching hash tables. In this case, most of our routers had 6 or fewer routes in them to begin with. This was replaced with an array that's searched linearly for the route. We more heavily rely on AO2 objects in Asterisk 12, and the memset() in ao2_ref() actually became noticeable on the profile. This was #ifdef'ed to only run when AO2_DEBUG was enabled. After being misled by an erroneous comment in taskprocessor.c during profiling, the wrong comment was removed. Review: https://reviewboard.asterisk.org/r/2873/ ........ r400178 | dlee | 2013-09-30 13:26:27 -0500 (Mon, 30 Sep 2013) | 24 lines Taskprocessor optimization; switch Stasis to use taskprocessors This patch optimizes taskprocessor to use a semaphore for signaling, which the OS can do a better job at managing contention and waiting that we can with a mutex and condition. The taskprocessor execution was also slightly optimized to reduce the number of locks taken. The only observable difference in the taskprocessor implementation is that when the final reference to the taskprocessor goes away, it will execute all tasks to completion instead of discarding the unexecuted tasks. For systems where unnamed semaphores are not supported, a really simple semaphore implementation is provided. (Which gives identical performance as the original taskprocessor implementation). The way we ended up implementing Stasis caused the threadpool to be a burden instead of a boost to performance. This was switched to just use taskprocessors directly for subscriptions. Review: https://reviewboard.asterisk.org/r/2881/ ........ r400180 | dlee | 2013-09-30 13:39:34 -0500 (Mon, 30 Sep 2013) | 28 lines Optimize how Stasis forwards are dispatched This patch optimizes how forwards are dispatched in Stasis. Originally, forwards were dispatched as subscriptions that are invoked on the publishing thread. This did not account for the vast number of forwards we would end up having in the system, and the amount of work it would take to walk though the forward subscriptions. This patch modifies Stasis so that rather than walking the tree of forwards on every dispatch, when forwards and subscriptions are changed, the subscriber list for every topic in the tree is changed. This has a couple of benefits. First, this reduces the workload of dispatching messages. It also reduces contention when dispatching to different topics that happen to forward to the same aggregation topic (as happens with all of the channel, bridge and endpoint topics). Since forwards are no longer subscriptions, the bulk of this patch is simply changing stasis_subscription objects to stasis_forward objects (which, admittedly, I should have done in the first place.) Since this required me to yet again put in a growing array, I finally abstracted that out into a set of ast_vector macros in asterisk/vector.h. Review: https://reviewboard.asterisk.org/r/2883/ ........ r400181 | dlee | 2013-09-30 13:48:57 -0500 (Mon, 30 Sep 2013) | 28 lines Remove dispatch object allocation from Stasis publishing While looking for areas for performance improvement, I realized that an unused feature in Stasis was negatively impacting performance. When a message is sent to a subscriber, a dispatch object is allocated for the dispatch, containing the topic the message was published to, the subscriber the message is being sent to, and the message itself. The topic is actually unused by any subscriber in Asterisk today. And the subscriber is associated with the taskprocessor the message is being dispatched to. First, this patch removes the unused topic parameter from Stasis subscription callbacks. Second, this patch introduces the concept of taskprocessor local data, data that may be set on a taskprocessor and provided along with the data pointer when a task is pushed using the ast_taskprocessor_push_local() call. This allows the task to have both data specific to that taskprocessor, in addition to data specific to that invocation. With those two changes, the dispatch object can be removed completely, and the message is simply refcounted and sent directly to the taskprocessor. Review: https://reviewboard.asterisk.org/r/2884/ ........ Merged revisions 399887,400138,400178,400180-400181 from http://svn.asterisk.org/svn/asterisk/branches/12 git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400186 65c4cc65-6c06-0410-ace0-fbb531ad65f3
2013-09-30 18:55:27 +00:00
struct stasis_message *msg)
{
struct mwi_subscription *mwi_sub = userdata;
if (stasis_subscription_final_message(sub, msg)) {
if (ast_sip_push_task(ast_serializer_pool_get(mwi_serializer_pool),
serialized_cleanup, ao2_bump(mwi_sub))) {
ao2_ref(mwi_sub, -1);
}
return;
}
if (ast_mwi_state_type() == stasis_message_type(msg)) {
send_notify(mwi_sub, NULL, 0);
}
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/*!
* \internal
* \brief Create unsolicited MWI subscriptions for an endpoint
*
* \note Call with the unsolicited_mwi container lock held.
*
* \param endpoint An endpoint object
* \param recreate Whether or not unsolicited subscriptions are potentially being recreated
* \param send_now Whether or not to send a notify once the subscription is created
* \param unsolicited_mwi A container of unsolicited mwi objects
* \param solicited_mwi A container of solicited mwi objects
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
*
* \retval 0
*/
static int create_unsolicited_mwi_subscriptions(struct ast_sip_endpoint *endpoint,
int recreate, int send_now, struct ao2_container *unsolicited_mwi, struct ao2_container *solicited_mwi)
{
RAII_VAR(struct mwi_subscription *, aggregate_sub, NULL, ao2_cleanup);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
char *mailboxes;
char *mailbox;
int sub_added = 0;
if (ast_strlen_zero(endpoint->subscription.mwi.mailboxes)) {
return 0;
}
if (endpoint->subscription.mwi.aggregate) {
const char *endpoint_id = ast_sorcery_object_get_id(endpoint);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/* Check if aggregate subscription exists */
aggregate_sub = ao2_find(unsolicited_mwi, endpoint_id, OBJ_SEARCH_KEY | OBJ_NOLOCK);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/*
* If enabled there should only ever exist a single aggregate subscription object
* for an endpoint. So if it exists just return unless subscriptions are potentially
* being added back in. If that's the case then continue.
*/
if (aggregate_sub && !recreate) {
return 0;
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (!aggregate_sub) {
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
aggregate_sub = mwi_subscription_alloc(endpoint, 0, NULL);
if (!aggregate_sub) {
return 0; /* No MWI aggregation for you */
}
/*
* Just in case we somehow get in the position of recreating with no previous
* aggregate object, set recreate to false here in order to allow the new
* object to be linked into the container below
*/
recreate = 0;
}
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
/* Lock solicited so we don't potentially add to both containers */
if (solicited_mwi) {
ao2_lock(solicited_mwi);
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
mailboxes = ast_strdupa(endpoint->subscription.mwi.mailboxes);
while ((mailbox = ast_strip(strsep(&mailboxes, ",")))) {
struct mwi_subscription *sub;
struct mwi_stasis_subscription *mwi_stasis_sub;
if (!is_unsolicited_allowed(endpoint, mailbox, unsolicited_mwi, solicited_mwi)) {
continue;
}
sub = aggregate_sub ?: mwi_subscription_alloc(endpoint, 0, NULL);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (!sub) {
continue;
}
mwi_stasis_sub = mwi_stasis_subscription_alloc(mailbox, sub);
if (mwi_stasis_sub) {
ao2_link(sub->stasis_subs, mwi_stasis_sub);
ao2_ref(mwi_stasis_sub, -1);
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (!aggregate_sub) {
ao2_link_flags(unsolicited_mwi, sub, OBJ_NOLOCK);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (send_now) {
send_notify(sub, NULL, 0);
}
ao2_ref(sub, -1);
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (aggregate_sub && !sub_added) {
/* If aggregation track if at least one subscription has been added */
sub_added = 1;
}
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (aggregate_sub) {
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (ao2_container_count(aggregate_sub->stasis_subs)) {
/* Only link if we're dealing with a new aggregate object */
if (!recreate) {
ao2_link_flags(unsolicited_mwi, aggregate_sub, OBJ_NOLOCK);
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (send_now && sub_added) {
send_notify(aggregate_sub, NULL, 0);
}
}
}
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
if (solicited_mwi) {
ao2_unlock(solicited_mwi);
}
return 0;
}
static int create_mwi_subscriptions_for_endpoint(void *obj, void *arg, void *data, int flags)
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
{
return create_unsolicited_mwi_subscriptions(obj, 0, 0, arg, data);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
}
static int unsubscribe(void *obj, void *arg, int flags)
{
struct mwi_subscription *mwi_sub = obj;
ao2_callback(mwi_sub->stasis_subs, OBJ_UNLINK | OBJ_NODATA | OBJ_MULTIPLE, unsubscribe_stasis, NULL);
return CMP_MATCH;
}
static void create_mwi_subscriptions(void)
{
struct ao2_container *unsolicited_mwi;
struct ao2_container *solicited_mwi;
struct ao2_container *endpoints;
sorcery/res_pjsip: Refactor for realtime performance There were a number of places in the res_pjsip stack that were getting all endpoints or all aors, and then filtering them locally. A good example is pjsip_options which, on startup, retrieves all endpoints, then the aors for those endpoints, then tests the aors to see if the qualify_frequency is > 0. One issue was that it never did anything with the endpoints other than retrieve the aors so we probably could have skipped a step and just retrieved all aors. But nevermind. This worked reasonably well with local config files but with a realtime backend and thousands of objects, this was a nightmare. The issue really boiled down to the fact that while realtime supports predicates that are passed to the database engine, the non-realtime sorcery backends didn't. They do now. The realtime engines have a scheme for doing simple comparisons. They take in an ast_variable (or list) for matching, and the name of each variable can contain an operator. For instance, a name of "qualify_frequency >" and a value of "0" would create a SQL predicate that looks like "where qualify_frequency > '0'". If there's no operator after the name, the engines add an '=' so a simple name of "qualify_frequency" and a value of "10" would return exact matches. The non-realtime backends decide whether to include an object in a result set by calling ast_sorcery_changeset_create on every object in the internal container. However, ast_sorcery_changeset_create only does exact string matches though so a name of "qualify_frequency >" and a value of "0" returns nothing because the literal "qualify_frequency >" doesn't match any name in the objset set. So, the real task was to create a generic string matcher that can take a left value, operator and a right value and perform the match. To that end, strings.c has a new ast_strings_match(left, operator, right) function. Left and right are the strings to operate on and the operator can be a string containing any of the following: = (or NULL or ""), !=, >, >=, <, <=, like or regex. If the operator is like or regex, the right string should be a %-pattern or a regex expression. If both left and right can be converted to float, then a numeric comparison is performed, otherwise a string comparison is performed. To use this new function on ast_variables, 2 new functions were added to config.c. One that compares 2 ast_variables, and one that compares 2 ast_variable lists. The former is useful when you want to compare 2 ast_variables that happen to be in a list but don't want to traverse the list. The latter will traverse the right list and return true if all the variables in it match the left list. Now, the backends' fields_cmp functions call ast_variable_lists_match instead of ast_sorcery_changeset_create and they can now process the same syntax as the realtime engines. The realtime backend just passes the variable list unaltered to the engine. The only gotcha is that there's no common realtime engine support for regex so that's been noted in the api docs for ast_sorcery_retrieve_by_fields. Only one more change to sorcery was done... A new config flag "allow_unqualified_fetch" was added to reg_sorcery_realtime. "no": ignore fetches if no predicate fields were supplied. "error": same as no but emit an error. (good for testing) "yes": allow (the default); "warn": allow but emit a warning. (good for testing) Now on to res_pjsip... pjsip_options was modified to retrieve aors with qualify_frequency > 0 rather than all endpoints then all aors. Not only was this a big improvement in realtime retrieval but even for config files there's an improvement because we're not going through endpoints anymore. res_pjsip_mwi was modified to retieve only endpoints with something in the mailboxes field instead of all endpoints then testing mailboxes. res_pjsip_registrar_expire was completely refactored. It was retrieving all contacts then setting up scheduler entries to check for expiration. Now, it's a single thread (like keepalive) that periodically retrieves only contacts whose expiration time is < now and deletes them. A new contact_expiration_check_interval was added to global with a default of 30 seconds. Ross Beer reports that with this patch, his Asterisk startup time dropped from around an hour to under 30 seconds. There are still objects that can't be filtered at the database like identifies, transports, and registrations. These are not going to be anywhere near as numerous as endpoints, aors, auths, contacts however. Back to allow_unqualified_fetch. If this is set to yes and you have a very large number of objects in the database, the pjsip CLI commands will attempt to retrive ALL of them if not qualified with a LIKE. Worse, if you type "pjsip show endpoint <tab>" guess what's going to happen? :) Having a cache helps but all the objects will have to be retrieved at least once to fill the cache. Setting allow_unqualified_fetch=no prevents the mass retrieve and should be used on endpoints, auths, aors, and contacts. It should NOT be used for identifies, registrations and transports since these MUST be retrieved in bulk. Example sorcery.conf: [res_pjsip] endpoint=config,pjsip.conf,criteria=type=endpoint endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error ASTERISK-25826 #close Reported-by: Ross Beer Tested-by: Ross Beer Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
2016-03-08 21:55:30 +00:00
struct ast_variable *var;
unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
if (!unsolicited_mwi) {
return;
}
sorcery/res_pjsip: Refactor for realtime performance There were a number of places in the res_pjsip stack that were getting all endpoints or all aors, and then filtering them locally. A good example is pjsip_options which, on startup, retrieves all endpoints, then the aors for those endpoints, then tests the aors to see if the qualify_frequency is > 0. One issue was that it never did anything with the endpoints other than retrieve the aors so we probably could have skipped a step and just retrieved all aors. But nevermind. This worked reasonably well with local config files but with a realtime backend and thousands of objects, this was a nightmare. The issue really boiled down to the fact that while realtime supports predicates that are passed to the database engine, the non-realtime sorcery backends didn't. They do now. The realtime engines have a scheme for doing simple comparisons. They take in an ast_variable (or list) for matching, and the name of each variable can contain an operator. For instance, a name of "qualify_frequency >" and a value of "0" would create a SQL predicate that looks like "where qualify_frequency > '0'". If there's no operator after the name, the engines add an '=' so a simple name of "qualify_frequency" and a value of "10" would return exact matches. The non-realtime backends decide whether to include an object in a result set by calling ast_sorcery_changeset_create on every object in the internal container. However, ast_sorcery_changeset_create only does exact string matches though so a name of "qualify_frequency >" and a value of "0" returns nothing because the literal "qualify_frequency >" doesn't match any name in the objset set. So, the real task was to create a generic string matcher that can take a left value, operator and a right value and perform the match. To that end, strings.c has a new ast_strings_match(left, operator, right) function. Left and right are the strings to operate on and the operator can be a string containing any of the following: = (or NULL or ""), !=, >, >=, <, <=, like or regex. If the operator is like or regex, the right string should be a %-pattern or a regex expression. If both left and right can be converted to float, then a numeric comparison is performed, otherwise a string comparison is performed. To use this new function on ast_variables, 2 new functions were added to config.c. One that compares 2 ast_variables, and one that compares 2 ast_variable lists. The former is useful when you want to compare 2 ast_variables that happen to be in a list but don't want to traverse the list. The latter will traverse the right list and return true if all the variables in it match the left list. Now, the backends' fields_cmp functions call ast_variable_lists_match instead of ast_sorcery_changeset_create and they can now process the same syntax as the realtime engines. The realtime backend just passes the variable list unaltered to the engine. The only gotcha is that there's no common realtime engine support for regex so that's been noted in the api docs for ast_sorcery_retrieve_by_fields. Only one more change to sorcery was done... A new config flag "allow_unqualified_fetch" was added to reg_sorcery_realtime. "no": ignore fetches if no predicate fields were supplied. "error": same as no but emit an error. (good for testing) "yes": allow (the default); "warn": allow but emit a warning. (good for testing) Now on to res_pjsip... pjsip_options was modified to retrieve aors with qualify_frequency > 0 rather than all endpoints then all aors. Not only was this a big improvement in realtime retrieval but even for config files there's an improvement because we're not going through endpoints anymore. res_pjsip_mwi was modified to retieve only endpoints with something in the mailboxes field instead of all endpoints then testing mailboxes. res_pjsip_registrar_expire was completely refactored. It was retrieving all contacts then setting up scheduler entries to check for expiration. Now, it's a single thread (like keepalive) that periodically retrieves only contacts whose expiration time is < now and deletes them. A new contact_expiration_check_interval was added to global with a default of 30 seconds. Ross Beer reports that with this patch, his Asterisk startup time dropped from around an hour to under 30 seconds. There are still objects that can't be filtered at the database like identifies, transports, and registrations. These are not going to be anywhere near as numerous as endpoints, aors, auths, contacts however. Back to allow_unqualified_fetch. If this is set to yes and you have a very large number of objects in the database, the pjsip CLI commands will attempt to retrive ALL of them if not qualified with a LIKE. Worse, if you type "pjsip show endpoint <tab>" guess what's going to happen? :) Having a cache helps but all the objects will have to be retrieved at least once to fill the cache. Setting allow_unqualified_fetch=no prevents the mass retrieve and should be used on endpoints, auths, aors, and contacts. It should NOT be used for identifies, registrations and transports since these MUST be retrieved in bulk. Example sorcery.conf: [res_pjsip] endpoint=config,pjsip.conf,criteria=type=endpoint endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error ASTERISK-25826 #close Reported-by: Ross Beer Tested-by: Ross Beer Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
2016-03-08 21:55:30 +00:00
var = ast_variable_new("mailboxes !=", "", "");
endpoints = ast_sorcery_retrieve_by_fields(ast_sip_get_sorcery(), "endpoint",
sorcery/res_pjsip: Refactor for realtime performance There were a number of places in the res_pjsip stack that were getting all endpoints or all aors, and then filtering them locally. A good example is pjsip_options which, on startup, retrieves all endpoints, then the aors for those endpoints, then tests the aors to see if the qualify_frequency is > 0. One issue was that it never did anything with the endpoints other than retrieve the aors so we probably could have skipped a step and just retrieved all aors. But nevermind. This worked reasonably well with local config files but with a realtime backend and thousands of objects, this was a nightmare. The issue really boiled down to the fact that while realtime supports predicates that are passed to the database engine, the non-realtime sorcery backends didn't. They do now. The realtime engines have a scheme for doing simple comparisons. They take in an ast_variable (or list) for matching, and the name of each variable can contain an operator. For instance, a name of "qualify_frequency >" and a value of "0" would create a SQL predicate that looks like "where qualify_frequency > '0'". If there's no operator after the name, the engines add an '=' so a simple name of "qualify_frequency" and a value of "10" would return exact matches. The non-realtime backends decide whether to include an object in a result set by calling ast_sorcery_changeset_create on every object in the internal container. However, ast_sorcery_changeset_create only does exact string matches though so a name of "qualify_frequency >" and a value of "0" returns nothing because the literal "qualify_frequency >" doesn't match any name in the objset set. So, the real task was to create a generic string matcher that can take a left value, operator and a right value and perform the match. To that end, strings.c has a new ast_strings_match(left, operator, right) function. Left and right are the strings to operate on and the operator can be a string containing any of the following: = (or NULL or ""), !=, >, >=, <, <=, like or regex. If the operator is like or regex, the right string should be a %-pattern or a regex expression. If both left and right can be converted to float, then a numeric comparison is performed, otherwise a string comparison is performed. To use this new function on ast_variables, 2 new functions were added to config.c. One that compares 2 ast_variables, and one that compares 2 ast_variable lists. The former is useful when you want to compare 2 ast_variables that happen to be in a list but don't want to traverse the list. The latter will traverse the right list and return true if all the variables in it match the left list. Now, the backends' fields_cmp functions call ast_variable_lists_match instead of ast_sorcery_changeset_create and they can now process the same syntax as the realtime engines. The realtime backend just passes the variable list unaltered to the engine. The only gotcha is that there's no common realtime engine support for regex so that's been noted in the api docs for ast_sorcery_retrieve_by_fields. Only one more change to sorcery was done... A new config flag "allow_unqualified_fetch" was added to reg_sorcery_realtime. "no": ignore fetches if no predicate fields were supplied. "error": same as no but emit an error. (good for testing) "yes": allow (the default); "warn": allow but emit a warning. (good for testing) Now on to res_pjsip... pjsip_options was modified to retrieve aors with qualify_frequency > 0 rather than all endpoints then all aors. Not only was this a big improvement in realtime retrieval but even for config files there's an improvement because we're not going through endpoints anymore. res_pjsip_mwi was modified to retieve only endpoints with something in the mailboxes field instead of all endpoints then testing mailboxes. res_pjsip_registrar_expire was completely refactored. It was retrieving all contacts then setting up scheduler entries to check for expiration. Now, it's a single thread (like keepalive) that periodically retrieves only contacts whose expiration time is < now and deletes them. A new contact_expiration_check_interval was added to global with a default of 30 seconds. Ross Beer reports that with this patch, his Asterisk startup time dropped from around an hour to under 30 seconds. There are still objects that can't be filtered at the database like identifies, transports, and registrations. These are not going to be anywhere near as numerous as endpoints, aors, auths, contacts however. Back to allow_unqualified_fetch. If this is set to yes and you have a very large number of objects in the database, the pjsip CLI commands will attempt to retrive ALL of them if not qualified with a LIKE. Worse, if you type "pjsip show endpoint <tab>" guess what's going to happen? :) Having a cache helps but all the objects will have to be retrieved at least once to fill the cache. Setting allow_unqualified_fetch=no prevents the mass retrieve and should be used on endpoints, auths, aors, and contacts. It should NOT be used for identifies, registrations and transports since these MUST be retrieved in bulk. Example sorcery.conf: [res_pjsip] endpoint=config,pjsip.conf,criteria=type=endpoint endpoint=realtime,ps_endpoints,allow_unqualified_fetch=error ASTERISK-25826 #close Reported-by: Ross Beer Tested-by: Ross Beer Change-Id: Id2691e447db90892890036e663aaf907b2dc1c67
2016-03-08 21:55:30 +00:00
AST_RETRIEVE_FLAG_MULTIPLE, var);
ast_variables_destroy(var);
if (!endpoints) {
ao2_ref(unsolicited_mwi, -1);
return;
}
solicited_mwi = ao2_global_obj_ref(mwi_solicited);
/* We remove all the old stasis subscriptions first before applying the new configuration. This
* prevents a situation where there might be multiple overlapping stasis subscriptions for an
* endpoint for mailboxes. Though there may be mailbox changes during the gap between unsubscribing
* and resubscribing, up-to-date mailbox state will be sent out to the endpoint when the
* new stasis subscription is established
*/
ao2_lock(unsolicited_mwi);
ao2_callback(unsolicited_mwi, OBJ_NOLOCK | OBJ_UNLINK | OBJ_NODATA | OBJ_MULTIPLE, unsubscribe, NULL);
ao2_callback_data(endpoints, OBJ_NODATA, create_mwi_subscriptions_for_endpoint, unsolicited_mwi, solicited_mwi);
ao2_unlock(unsolicited_mwi);
ao2_ref(endpoints, -1);
ao2_cleanup(solicited_mwi);
ao2_ref(unsolicited_mwi, -1);
}
/*! \brief Function called to send MWI NOTIFY on any unsolicited mailboxes relating to this AOR */
static int send_contact_notify(void *obj, void *arg, int flags)
{
struct mwi_subscription *mwi_sub = obj;
const char *aor = arg;
if (!mwi_sub->aors || !strstr(mwi_sub->aors, aor)) {
return 0;
}
if (ast_sip_push_task(ast_serializer_pool_get(mwi_serializer_pool),
serialized_notify, ao2_bump(mwi_sub))) {
ao2_ref(mwi_sub, -1);
}
return 0;
}
/*! \brief Create mwi subscriptions and notify */
static void mwi_contact_changed(const struct ast_sip_contact *contact)
{
char *id = ast_strdupa(ast_sorcery_object_get_id(contact));
char *aor = NULL;
struct ast_sip_endpoint *endpoint = NULL;
struct ao2_container *unsolicited_mwi;
struct ao2_container *solicited_mwi;
if (contact->endpoint) {
endpoint = ao2_bump(contact->endpoint);
} else {
if (!ast_strlen_zero(contact->endpoint_name)) {
endpoint = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", contact->endpoint_name);
}
}
if (!endpoint || ast_strlen_zero(endpoint->subscription.mwi.mailboxes)) {
ao2_cleanup(endpoint);
return;
}
unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
if (!unsolicited_mwi) {
ao2_cleanup(endpoint);
return;
}
solicited_mwi = ao2_global_obj_ref(mwi_solicited);
ao2_lock(unsolicited_mwi);
create_unsolicited_mwi_subscriptions(endpoint, 0, 0, unsolicited_mwi, solicited_mwi);
ao2_unlock(unsolicited_mwi);
ao2_cleanup(endpoint);
ao2_cleanup(solicited_mwi);
ao2_ref(unsolicited_mwi, -1);
aor = strsep(&id, ";@");
ao2_callback(unsolicited_mwi, OBJ_NODATA, send_contact_notify, aor);
}
/*! \brief Function called when a contact is updated */
static void mwi_contact_updated(const void *object)
{
mwi_contact_changed(object);
}
/*! \brief Function called when a contact is added */
static void mwi_contact_added(const void *object)
{
mwi_contact_changed(object);
}
/*! \brief Function called when a contact is deleted */
static void mwi_contact_deleted(const void *object)
{
const struct ast_sip_contact *contact = object;
struct ao2_iterator *mwi_subs;
struct mwi_subscription *mwi_sub;
struct ast_sip_endpoint *endpoint = NULL;
struct ast_sip_contact *found_contact;
struct ao2_container *unsolicited_mwi;
if (contact->endpoint) {
endpoint = ao2_bump(contact->endpoint);
} else {
if (!ast_strlen_zero(contact->endpoint_name)) {
endpoint = ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", contact->endpoint_name);
}
}
if (!endpoint || ast_strlen_zero(endpoint->subscription.mwi.mailboxes)) {
ao2_cleanup(endpoint);
return;
}
/* Check if there is another contact */
found_contact = ast_sip_location_retrieve_contact_from_aor_list(endpoint->aors);
ao2_cleanup(endpoint);
if (found_contact) {
ao2_cleanup(found_contact);
return;
}
unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
if (!unsolicited_mwi) {
return;
}
ao2_lock(unsolicited_mwi);
mwi_subs = ao2_find(unsolicited_mwi, contact->endpoint_name,
OBJ_SEARCH_KEY | OBJ_MULTIPLE | OBJ_NOLOCK | OBJ_UNLINK);
if (mwi_subs) {
for (; (mwi_sub = ao2_iterator_next(mwi_subs)); ao2_cleanup(mwi_sub)) {
unsubscribe(mwi_sub, NULL, 0);
}
ao2_iterator_destroy(mwi_subs);
}
ao2_unlock(unsolicited_mwi);
ao2_ref(unsolicited_mwi, -1);
}
/*! \brief Observer for contacts so unsolicited MWI is sent when a contact changes */
static const struct ast_sorcery_observer mwi_contact_observer = {
.created = mwi_contact_added,
.updated = mwi_contact_updated,
.deleted = mwi_contact_deleted,
};
/*! \brief Task invoked to send initial MWI NOTIFY for unsolicited */
static int send_initial_notify_all(void *obj)
{
struct ao2_container *unsolicited_mwi = ao2_global_obj_ref(mwi_unsolicited);
if (unsolicited_mwi) {
ao2_callback(unsolicited_mwi, OBJ_NODATA, send_notify, NULL);
ao2_ref(unsolicited_mwi, -1);
}
return 0;
}
/*! \brief Event callback which fires initial unsolicited MWI NOTIFY messages when we're fully booted */
static void mwi_startup_event_cb(void *data, struct stasis_subscription *sub, struct stasis_message *message)
{
struct ast_json_payload *payload;
const char *type;
if (stasis_message_type(message) != ast_manager_get_generic_type()) {
return;
}
payload = stasis_message_data(message);
type = ast_json_string_get(ast_json_object_get(payload->json, "type"));
if (strcmp(type, "FullyBooted")) {
return;
}
ast_sip_push_task(ast_serializer_pool_get(mwi_serializer_pool),
send_initial_notify_all, NULL);
stasis_unsubscribe(sub);
}
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
static void global_loaded(const char *object_type)
{
ast_free(default_voicemail_extension);
default_voicemail_extension = ast_sip_get_default_voicemail_extension();
ast_serializer_pool_set_alerts(mwi_serializer_pool,
ast_sip_get_mwi_tps_queue_high(), ast_sip_get_mwi_tps_queue_low());
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
}
static struct ast_sorcery_observer global_observer = {
.loaded = global_loaded,
};
static int reload(void)
{
if (!ast_sip_get_mwi_disable_initial_unsolicited()) {
create_mwi_subscriptions();
}
return 0;
}
static int unload_module(void)
{
/*
* pjsip_evsub_register_pkg is called by ast_sip_register_subscription_handler
* but there is no corresponding unregister function, so unloading
* a module does not remove the event package. If this module is ever
* loaded again, then pjproject will assert and cause a crash.
* For that reason, we must only be allowed to unload when
* asterisk is shutting down. If a pjsip_evsub_unregister_pkg
* API is added in the future then we should go back to unloading
* the module as intended.
*/
if (ast_shutdown_final()) {
struct ao2_container *unsolicited_mwi;
ast_sorcery_observer_remove(ast_sip_get_sorcery(), "global", &global_observer);
ast_sorcery_observer_remove(ast_sip_get_sorcery(), "contact", &mwi_contact_observer);
unsolicited_mwi = ao2_global_obj_replace(mwi_unsolicited, NULL);
if (unsolicited_mwi) {
ao2_callback(unsolicited_mwi, OBJ_UNLINK | OBJ_NODATA | OBJ_MULTIPLE, unsubscribe, NULL);
ao2_ref(unsolicited_mwi, -1);
}
ao2_global_obj_release(mwi_solicited);
if (ast_serializer_pool_destroy(mwi_serializer_pool)) {
ast_log(LOG_WARNING, "Unload incomplete. Try again later\n");
return -1;
}
mwi_serializer_pool = NULL;
ast_sip_unregister_subscription_handler(&mwi_handler);
ast_free(default_voicemail_extension);
default_voicemail_extension = NULL;
return 0;
} else {
return -1;
}
}
static int load_module(void)
{
struct ao2_container *mwi_container;
if (ast_sip_register_subscription_handler(&mwi_handler)) {
return AST_MODULE_LOAD_DECLINE;
}
mwi_serializer_pool = ast_serializer_pool_create("pjsip/mwi",
MWI_SERIALIZER_POOL_SIZE, ast_sip_threadpool(), MAX_UNLOAD_TIMEOUT_TIME);
if (!mwi_serializer_pool) {
ast_log(AST_LOG_WARNING, "Failed to create MWI serializer pool. The default SIP pool will be used for MWI\n");
}
mwi_container = ao2_container_alloc_hash(AO2_ALLOC_OPT_LOCK_MUTEX, 0, MWI_BUCKETS,
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
mwi_sub_hash, NULL, mwi_sub_cmp);
if (!mwi_container) {
unload_module();
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
return AST_MODULE_LOAD_DECLINE;
}
ao2_global_obj_replace_unref(mwi_solicited, mwi_container);
ao2_ref(mwi_container, -1);
res_pjsip_mwi: add better handling of solicited vs unsolicited subscriptions res_pjsip_mwi allows both solicited and unsolicited MWI subscription types. While both can be set in the configuration for a given endpoint/aor, only one is allowed. Precedence is given to unsolicited. Meaning if an endpoint/aor is configured to allow both types then the solicited subscription is rejected when it comes in. However, there is a configuration option to override that behavior: mwi_subscribe_replaces_unsolicited When set to "yes" then when a solicited subscription comes in instead of rejecting it Asterisk is suppose to replace the unsolicited one if it exists. Prior to this patch there was a bug in Asterisk that allowed the solicted one to be added, but did not remove the unsolicited. As a matter of fact a new unsolicited subscription got added everytime a SIP register was received. Over time this eventually could "flood" a phone with SIP notifies. This patch fixes that behavior to now make it work as expected. If configured to do so a solicited subscription now properly replaces the unsolicited one. As well when an unsubscribe is received the unsolicited subscription is restored. Logic was also put in to handle reloads, and any configuration changes that might result from that. For instance, if a solicited subscription had previously replaced an unsolicited one, but after reload it was configured to not allow that then the solicited one needs to be shutdown, and the unsolicited one added. ASTERISK-28488 Change-Id: Iec2ec12d9431097e97ed5f37119963aee41af7b1
2019-08-23 22:03:07 +00:00
mwi_container = ao2_container_alloc_hash(AO2_ALLOC_OPT_LOCK_MUTEX, 0, MWI_BUCKETS,
mwi_sub_hash, NULL, mwi_sub_cmp);
if (!mwi_container) {
unload_module();
return AST_MODULE_LOAD_DECLINE;
}
ao2_global_obj_replace_unref(mwi_unsolicited, mwi_container);
ao2_ref(mwi_container, -1);
ast_sorcery_observer_add(ast_sip_get_sorcery(), "contact", &mwi_contact_observer);
res_pjsip_mwi: Add voicemail extension and mwi_subscribe_replaces_unsolicited res_pjsip_mwi was missing the chan_sip "vmexten" functionality which adds the Message-Account header to the MWI NOTIFY. Also, specifying mailboxes on endpoints for unsolicited mwi and on aors for subscriptions required that the admin know in advance which the client wanted. If you specified mailboxes on the endpoint, subscriptions were rejected even if you also specified mailboxes on the aor. Voicemail extension: * Added a global default_voicemail_extension which defaults to "". * Added voicemail_extension to both endpoint and aor. * Added ast_sip_subscription_get_dialog for support. * Added ast_sip_subscription_get_sip_uri for support. When an unsolicited NOTIFY is constructed, the From header is parsed, the voicemail extension from the endpoint is substituted for the user, and the result placed in the Message-Account field in the body. When a subscribed NOTIFY is constructed, the subscription dialog local uri is parsed, the voicemail_extension from the aor (looked up from the subscription resource name) is substituted for the user, and the result placed in the Message-Account field in the body. If no voicemail extension was defined, the Message-Account field is not added to the NOTIFY body. mwi_subscribe_replaces_unsolicited: * Added mwi_subscribe_replaces_unsolicited to endpoint. The previous behavior was to reject a subscribe if a previous internal subscription for unsolicited MWI was found for the mailbox. That remains the default. However, if there are mailboxes also set on the aor and the client subscribes and mwi_subscribe_replaces_unsolicited is set, the existing internal subscription is removed and replaced with the external subscription. This allows an admin to configure mailboxes on both the endpoint and aor and allows the client to select which to use. ASTERISK-25865 #close Reported-by: Ross Beer Change-Id: Ic15a9415091760539c7134a5ba3dc4a6a1217cea
2016-03-25 03:55:03 +00:00
ast_sorcery_observer_add(ast_sip_get_sorcery(), "global", &global_observer);
ast_sorcery_reload_object(ast_sip_get_sorcery(), "global");
if (!ast_sip_get_mwi_disable_initial_unsolicited()) {
create_mwi_subscriptions();
if (ast_test_flag(&ast_options, AST_OPT_FLAG_FULLY_BOOTED)) {
ast_sip_push_task(ast_serializer_pool_get(mwi_serializer_pool),
send_initial_notify_all, NULL);
} else {
struct stasis_subscription *sub;
sub = stasis_subscribe_pool(ast_manager_get_topic(), mwi_startup_event_cb, NULL);
stasis_subscription_accept_message_type(sub, ast_manager_get_generic_type());
stasis_subscription_set_filter(sub, STASIS_SUBSCRIPTION_FILTER_SELECTIVE);
}
}
if (!mwi_serializer_pool) {
/*
* If the mwi serializer pool was unable to be established then the module will
* use the default serializer pool. If this happens prevent manual unloading
* since there would now exist the potential for a crash on unload.
*/
ast_module_shutdown_ref(ast_module_info->self);
}
return AST_MODULE_LOAD_SUCCESS;
}
AST_MODULE_INFO(ASTERISK_GPL_KEY, AST_MODFLAG_LOAD_ORDER, "PJSIP MWI resource",
.support_level = AST_MODULE_SUPPORT_CORE,
.load = load_module,
.unload = unload_module,
.reload = reload,
.load_pri = AST_MODPRI_CHANNEL_DEPEND + 5,
.requires = "res_pjsip,res_pjsip_pubsub",
);