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
SIP transaction group lock support has been backported into our pjproject. Since the code
now internally uses a group lock the code is now changed to unlock it if present. Note
that the act of finding the transaction is what actually returns it locked.
For further information about group locks check out the wiki page at:
http://trac.pjsip.org/repos/wiki/Group_Lock
(issue ASTERISK-22818)
Reported by: Matt Jordan
........
Merged revisions 402864 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402865 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes two issues when setting an outbound proxy:
1. The outbound proxy URI was not parsed and validated during configuration.
2. If an outgoing dialog was created and the outbound proxy could not be set an assertion would
occur because the usage count on the dialog was not decremented.
The documentation has also been updated to specify that a full URI must be specified for
the outbound proxy.
(closes issue ASTERISK-22672)
Reported by: Antti Yrjola
........
Merged revisions 400824 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
pjsip_strerror is only aware of PJSIP-specific error
codes. pj_strerror() is aware of all PJProject error
codes and OS-specific error codes.
This specifically fixes an oft-seen error in transport
configuration code where EADDRINUSE would result in
"Unknown PJSIP error 120098" instead of a useful
message.
........
Merged revisions 400749 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400750 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If you run Asterisk in the background and then connect to
it through a separate console, the thread that runs CLI commands
is not registered with PJLIB. Thus PJLIB does not like it when
you attempt to send OPTIONS requests from that thread. So now
we push the task into the threadpool, which we know to be registered
with PJLIB.
Thanks to Antti Yrjola for reporting this.
........
Merged revisions 400680 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
........
Merged revisions 400356 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400363 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
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
While handling a registration request a race condition could occur if/when two+
clients registered at the same time. This happened when one request obtained a
copy of the current contacts for an AOR and another request did the same before
the first request updated. Thus the second would update and overwrite the first
(or vice-versa depending on which actually updated first). In the case of it
being the same contact two "add" events would be raised.
pjsip registration handling is now serialized to alleviate this issue.
(closes issue AST-1213)
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/2860/
........
Merged revisions 399897 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399898 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The endpoint option does not apply to communication with external entities. Rather,
the option is applied to all communications with the endpoint. The external_media_address
transport configuration option may override the endpoint option if it turns out that
we are going to be communicating with an external entity.
Two things of note:
1) I have not updated the XML documentation. This is being taken care of by Rusty as part
of his work on issue ASTERISK-22405
2) This commit is likely to cause testsuite failures since there are tests that use the
external_media_address endpoint option, and they will need to be changed over. Well, I'm
planning to get that updated ASAP after this commit.
(closes issue ASTERISK-22528)
reported by Rusty Newton
........
Merged revisions 399283 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With this change, if no realm is specified in an outbound auth
section, then we will simply match the realm that was present
in the 401/407 challenge.
(closes issue ASTERISK-22471)
Reported by George Joseph
(closes issue ASTERISK-22386)
Reported by Rusty Newton
Patches:
outbound_auth_realm_v4.patch uploaded by George Joseph (License #6322)
........
Merged revisions 399059 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@399082 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some configuration objects currently won't place nice if reloaded.
Specifically, in this case the pjsip transport objects. Now when
registering an object in sorcery one may specify that the object is
allowed to be reloaded or not. If the object is set to not reload
then upon reloading of the configuration the objects of that type
will not be reloaded. The initially loaded objects of that type
however will remain.
While the transport objects will not longer be reloaded it is still
possible for a user to configure an endpoint to an invalid transport.
A couple of log messages were added to help diagnose this problem if
it occurs.
(closes issue ASTERISK-22382)
Reported by: Rusty Newton
(closes issue ASTERISK-22384)
Reported by: Rusty Newton
Review: https://reviewboard.asterisk.org/r/2807/
........
Merged revisions 398139 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@398140 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Dialog matching is performed in the distributor for the sole
purpose of retrieving an associated serializer so the request
may be serialized.
This patch fixes two problems.
First, incoming CANCEL requests that had no to-tag (which really
should be *all* CANCEL requests) would not match with a dialog.
An earlier bug fix to deal with early CANCEL requests would result
in the CANCEL being replied to with a 481. The fix for this is to
find the matching INVITE transaction and get the dialog from that
transaction.
Second, no SIP responses were matching dialogs. This is because we
were inverting the tags that we were passing into PJSIP's dialog
finding function. This logic has been corrected by setting local
and remote tag variables based on whether the incoming message is
a request or response.
........
Merged revisions 397854 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397855 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The rtpengine configuration parameter was documented in the XML documentation,
but it was not actually registered with the sorcery object. This adds the
parameter with a default of "asterisk", such that res_rtp_asterisk is chosen as
the default RTP implementation.
(closes issue ASTERISK-22380)
Reported by: Rusty Newton
Tested by: Rusty Newton
........
Merged revisions 397621 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are times when a configuration option should not have documentation.
1. Some options are registered with a particular object merely as a warning to
users. These options aren't even really 'deprecated' - which has its own
separate API call - they are actually provided by a different configuration
file. The options are merely registered so that the user gets a warning that
a different configuration file provides the item.
2. Some object types - most notably some used by modules that use sorcery - are
completely internal and should never be shown to the user.
3. Sorcery itself has several 'hidden' fields that should never be shown to a
user.
This patch updates the configuration framework and sorcery with additional API
calls that allow a module to register types as internal and options as not
requiring documentation. This bypasses the XML documentation checking.
This patch also re-enables the strict XML documentation checking in trunk, as
well as updates some documentation that was missing.
Review: https://reviewboard.asterisk.org/r/2785/
(closes issue ASTERISK-22359)
Reported by: Matt Jordan
(closes issue ASTERISK-22112)
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is more-or-less a reversion of previous ACL behavior so that
it is more self-contained. ACL sections are now only parsed if res_pjsip_acl.so
is loaded. Moreover, the configuration section is now "type=acl" instead of
"type=security".
The original reason for having ACLs configured in a "type=security" section
was to lump ACLs and other security-related items into the same section. The
problem is that ACLs really should be in their own sections and there are
no other security-related options implemented anyways.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@397193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For chan_pjsip, this introduces CLI/AMI remote unregistration commands,
reworks CLI syntax for sending NOTIFYs, adds AMI qualification support,
and adds documentation for PJSIPNotify.
This also fixes two refcounting bugs in the outbound registration code.
Review: https://reviewboard.asterisk.org/r/2695/
(closes issue ASTERISK-21939)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@396087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The general gist is to have a clear boundary between old SIP stuff
and new SIP stuff by having the word "SIP" for old stuff and "PJSIP"
for new stuff. Here's a brief rundown of the changes:
* The word "Gulp" in dialstrings, functions, and CLI commands is now
"PJSIP"
* chan_gulp.c is now chan_pjsip.c
* Function names in chan_gulp.c that were "gulp_*" are now "chan_pjsip_*"
* All files that were "res_sip*" are now "res_pjsip*"
* The "res_sip" directory is now "res_pjsip"
* Files in the "res_pjsip" directory that began with "sip_*" are now "pjsip_*"
* The configuration file is now "pjsip.conf" instead of "res_sip.conf"
* The module info for all PJSIP-related files now uses "PJSIP" instead of "SIP"
* CLI and AMI commands created by Asterisk's PJSIP modules now have "pjsip" as
the starting word instead of "sip"
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@395764 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Kevin Harwell
Joshua Colp
David M. Lee
Jonathan Rose
Mark Michelson
Richard Mudgett
Matthew Jordan
Kinsey Moore