Due to the original patch causing memory corruptions it was removed until the
problem could be resolved. This patch is the original patch plus some added
locking around stasis router subcription that was needed to avoid the memory
corruption.
Description of the original problem and patch (still applicable):
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4363/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 431179 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4311/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling incoming messages we determine if it is associated with
a dialog. If so we use that to determine what serializer and endpoint
to use for the message. Previously this would pass the endpoint to the
endpoint lookup module to actually place the endpoint completely on the
message. For in-dialog responses, however, this did not occur as
dialog processing took over and the endpoint lookup did not occur.
This change just places the endpoint in the expected spot immediately
instead of relying on the endpoint lookup module. In-dialog responses
thus have the expected endpoint.
AST-1459 #close
Review: https://reviewboard.asterisk.org/r/4146/
........
Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427491 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a message that exceeds the PJ_MAX_PKT_SIZE is sent over a reliable
transport, it is possible (although it shouldn't occur) for pjproject to pass
up an rdata object with a NULL msg in the msg_info. Needless to say, things
that attempt to dereference this are in for a rough ride.
In particular, this caused crashes in three different locations, all of which
are 'low level' enough to intercept an rdata object early in processing:
(1) res_pjsip_logger
(2) res_hep_pjsip
(3) res_pjsip/distributor
Anything that can intercept an rdata object before res_pjsip/distributor should
be defensive when looking at the received packet.
#SIPit31
ASTERISK-24369 #close
Reported by: Matt Jordan
........
Merged revisions 424618 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424619 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds Path support to chan_pjsip in res_pjsip_path.c with minimal
additions in res_pjsip_registrar.c to store the path and additions in
res_pjsip_outbound_registration.c to enable advertisement of path
support to registrars and intervening proxies.
Path information is stored on contacts and is enabled via Address of
Record (AoRs) and Registration configuration sections.
While adding path support, it became necessary to be able to add SIP
supplements that handled messages outside of sessions, so a framework
for handling these types of hooks was added in parallel to the
already-existing session supplements and several senders of
out-of-dialog requests were refactored as a result.
(closes issue ASTERISK-21084)
Review: https://reviewboard.asterisk.org/r/3050/
........
Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We were not including an authentication challenge when sending a 401 response
to unmatched endpoints. This was due to the conversion to use a vector for
authentication section names on an endpoint. The vector for artificial endpoints
was empty, resulting in the challenge being sent back containing no challenges.
This is worked around by placing a bogus value in the artificial endpoint's auth
vector. This value is never looked up by anything, since they instead will directly
call ast_sip_get_artificial_auth().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405420 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
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 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
