ast_sip_push_task_synchronous() did not necessarily execute the passed in
task under the specified serializer. If the current thread is any
registered pjsip thread then it would execute the task immediately instead
of under the specified serializer. Reentrancy issues could result if the
task does not execute with the right serializer.
The original reason ast_sip_push_task_synchronous() checked to see if the
current thread was a registered pjsip thread was because of a deadlock
with masquerades and the channel technology's fixup callback
(ASTERISK_22936). A subsequent masquerade deadlock fix (ASTERISK_24356)
involving call pickups avoided the original deadlock situation entirely.
The PJSIP channel technology's fixup callback no longer needed to call
ast_sip_push_task_synchronous().
However, there are a few places where this unexpected behavior is still
required to avoid deadlocks. The pjsip monitor thread executes callbacks
that do calls to ast_sip_push_task_synchronous() that would deadlock if
the task were actually pushed to the specified serializer. I ran into one
dealing with the pubsub subscriptions where an ao2 destructor called
ast_sip_push_task_synchronous().
* Split ast_sip_push_task_synchronous() into
ast_sip_push_task_wait_servant() and ast_sip_push_task_wait_serializer().
ast_sip_push_task_wait_servant() has the old behavior of
ast_sip_push_task_synchronous(). ast_sip_push_task_wait_serializer() has
the new behavior where the task is always executed by the specified
serializer or a picked serializer if one is not passed in. Both functions
behave the same if the current thread is not a SIP servant.
* Redirected ast_sip_push_task_synchronous() to
ast_sip_push_task_wait_servant() to preserve API for released branches.
ASTERISK_26806
Change-Id: Id040fa42c0e5972f4c8deef380921461d213b9f3
* Prefer strcasecmp() over stricmp()
* Use a list with no lock since we never actually lock
* Minor cleanups to error messages
Change-Id: I8446f44795ee8f3072e1c1f9193c6912dfc0c42b
This removes references that are no longer needed due to automatic
references created by module dependencies.
In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.
Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.
Still need to investigate dependencies among modules I cannot compile.
Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf
Added notes about when you can read or write headers. Specifically
about being able to read on the inbound channel and write on an
outbound channel.
ASTERISK-26063 #close
Reported by: Private Name
Tested by: Rusty Newton
Change-Id: Ibeb64af17d1f6451028b3c29855a3f151a01d8c5
When using PJSIP_HEADER() to add custom headers to outgoing INVITE requests, certain
situations could result in the headers being duplicated. For instance, if the request
were retransmitted, or if the INVITE were re-sent with authentication credentials,
the custom headers would be re-added to the request.
The fix here is to, after adding the custom headers to the outbound INVITE, remove
the datastore that holds the custom headers to add. This way, there is no risk in
accidentally adding them if the session supplement is called into a second or third
time.
........
Merged revisions 415579 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415580 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the ability for transferring directly to voicemail on digium phones.
Added a new module that checks for the presence of a custom header and/or
diversion header within a sip REFER. If either is found and they specify
a sending to voicemail action then variables are added to the channel
allowing the user access to them in the dialplan. Dialplan can then be
written that branches based upon these values allowing, for instace, for
a single number to be used for dialing and/or accessing voicemail directly.
Also fixed a problem where the PJSIP_HEADER function was allowing non pjsip
channels through (checked to make sure it has the correct channel type before
proceeding).
Review: https://reviewboard.asterisk.org/r/3245/
........
Merged revisions 408880 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408881 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
When sending a re-INVITE to an endpoint it was possible for received
headers to be added as well (since they are stored for retrieval using
the PJSIP_HEADER dialplan function). This caused a broken (and
potentially large) SIP INVITE to be produced and sent.
This changes the module so it will no longer add headers to
re-INVITEs.
(closes issue ASTERISK-22882)
Reported by: David M. Lee
........
Merged revisions 403221 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403222 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Both res_pjsip_messaging and res_pjsip_header_funcs were causing asterisk to
crash because they were trying to dereference a NULL pointer.
In the case of res_pjsip_messaging it was attempting to "print" a contact
header that did not exist. In fact contact headers should not be part of
a SIP MESSAGE, so the offending code was simply removed.
In the case of res_pjsip_header_funcs a null private channel tech was being
passed to the function and then later dereferenced. Added null checks (and
error logging) to the read/write function handlers to guard against crashing.
(closes issue ASTERISK-22821)
Reported by: Anthony Messina
........
Merged revisions 402757 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@402758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support to the PJSIP stack in Asterisk for SIP header
manipulation. Note that this is analagous to SIPAddHeader/SIPRemoveHeader.
For PJSIP_HEADER, an incoming supplemental session callback is registered that
takes the pjsip_hdrs from the incoming session and stores them in a linked
list in the session datastore. Calls to PJSIP_HEADER traverse over the list
and return the nth matching header where 'n' is the 'number' argument to the
function.
When adding a header, the first call creates a datastore and linked list and
adds the datastore to the session. The header is then created as a pjsip_hdr
and added to the list. An outgoing supplemental session callback then
traverses the list and adds the headers to the outgoing pjsip_msg.
When removing a header, the list created with PJSIP_HEADER(add,...) is
traversed and all matching entries are removed.
(closes issue ASTERISK-22498)
Reported by: George Joseph
patch:
res_pjsip_header_funcs_v1.patch uploaded by george.joseph (License 6322)
........
Merged revisions 400771 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@400772 65c4cc65-6c06-0410-ace0-fbb531ad65f3