This change updates the documentation for the outbound_proxy option
to ensure it is consistently stated that a full SIP URI must be
provided for the option.
The res_pjsip_outbound_registration module has also been changed so
that the provided outbound_proxy value is checked to ensure it is a
URI and if not an error is output stating so.
ASTERISK-26782
Change-Id: I6c239a32274846fd44e65b44ad9bf6373479b593
Using the same auth section for inbound and outbound authentication is not
recommended. There is a difference in meaning for an empty realm setting
between inbound and outbound authentication uses.
An empty inbound auth realm represents the global section's default_realm
value when the authentication object is used to challenge an incoming
request. An empty outgoing auth realm is treated as a don't care wildcard
when the authentication object is used to respond to an incoming
authentication challenge.
ASTERISK-26799
Change-Id: Id3952f7cfa1b6683b9954f2c5d2352d2f11059ce
While publishing device state between multiple instances of Asterisk,
a crash will sporadically occur under high CPS which looks to be a
race condition operating on the publisher queue.
ASTERISK-26506
Change-Id: I28da25d346deb358eff1d563485cabc433ce1ed6
This change replaces the custom unload process for the outbound
publish module with the common serializer shutdown group.
ASTERISK-25217 #close
Change-Id: I280a0384d860c486202d87d2d674394cca77ffb6
Recent changes to res_pjsip_outbound_publish have introduced a
race condition at shutdown where an outbound publish may be shutdown
twice. In this case the first succeeds as a result of the unpublish.
In the second invocation since it's been unpublished a task is
queued to just destroy the client. This task holds no ref to the
publish and as a result the publish may be destroyed before the
task is run, causing a crash.
This explicit destruction task now holds a reference to the publish
to ensure it remains valid.
ASTERISK-26053 #close
Change-Id: I10789b98add3e50292ee3b33a55a1d9061cec94b
This change uses the newly added multi-user support for
outbound publish to publish to the specific user that an
extension state change is for.
This also extends the res_pjsip_outbound_publish support
to include the user specific From and To URI information in
the outbound publishing of extension state. Since the URI
is used when constructing the body it is important to ensure
that the correct local and remote URIs are used.
Finally the max string growths for the dialog-info+xml
body generator has been increased as through testing it has
proven to be too conservative.
ASTERISK-25965
Change-Id: I668fdf697b1e171d4c7e6f282b2e1590f8356ca1
Added a new multi_user option that when specified allows a particular
configuration to be used for multiple users. It does this by replacing
the user portion of the server uri with a dynamically created one.
Two new API calls have been added in order to make use of the new
functionality:
ast_sip_publish_user_send - Sends an outgoing publish message based on the
given user. If state for the user already exists it uses that, otherwise
it dynamically creates new outbound publishing state for the user at that
time.
ast_sip_publish_user_remove - Removes all outbound publish state objects
associated with the user. This essentially stops outbound publishing for
the user.
ASTERISK-25965 #close
Change-Id: Ib88dde024cc83c916424645d4f5bb84a0fa936cc
When reloading, or fetching realtime data, if the "apply" failed for any
numerous reasons the current state object would not be maintained. This
potentially resulted in publishes being stopped for some states/clients when
they should not have been.
This patch makes it so the current state object is kept upon any type of reload/
fetch failures.
Change-Id: Iab6020c116d628ed2ae81183e987e2eaa3c90b30
The same thing was happening in res_pjsip_publish_asterisk. When the library
was unloaded it did not unregister the object type from sorcery. Subsequent
loads resulted in a failed load due to the sorcery type already existing.
Change-Id: Ifdc25e94e4cd40bc5a19eb4d0a00b86c2e9fedc9
When res_pjsip_outbound_publish unloads it has to wait for all current
publishing objects to get done. However if the wait condition times out
then it does not fail the unload. This sometimes results in an infinite
loop check while unloading. This patch now fails the unload operation if
the condition times out.
Change-Id: Id57b8cbed9d61222690fcba1e4f18e259df4c7ec
There were a few spots where the client object's reference was being leaked in
sip_outbound_publish_callback. This patch cleans up those leaks.
Change-Id: I485d0bc9335090f373026f77c548042e258461df
It was possible for the explicit publish destroy function to be called without
the pjsip client ever being initialized. This fix checks to make sure there is
a client to destroy before attempting.
Change-Id: I8eea1bfa3bd472149bfc255310be2a6248688f5c
Create PUBLISH messages to update a third party when an extension state
changes because of either a device or presence state change.
A configuration example:
[exten-state-publisher]
type=outbound-publish
server_uri=sip:instance1@172.16.10.2
event=presence
; Optional regex for context filtering, if specified only extension state
; for contexts matching the regex will cause a PUBLISH to be sent.
@context=^users
; Optional regex for extension filtering, if specified only extension
; state for extensions matching the regex will cause a PUBLISH to be sent.
@exten=^[0-9]*
; Required body type for the PUBLISH message.
;
; Supported values are:
; application/pidf+xml
; application/xpidf+xml
; application/cpim-pidf+xml
; application/dialog-info+xml (Planned support but not yet)
@body=application/pidf+xml
The '@' extended variables are used because the implementation can't
extend the outbound publish type as it is provided by the outbound publish
module. That means you either have to use extended variables, or
implement some sort of custom extended variable thing in the outbound
publish module. Another option would be to refactor that stuff to have an
option which specifies the use of an alternate implementation's
configuration and then have that passed to the implementation. JColp
opted for the extended variables method originally.
ASTERISK-25972 #close
Change-Id: Ic0dab4022f5cf59302129483ed38398764ee3cca
The first available transport of the appropriate type is used now.
This patch adds new config option 'transport' for outbound-publish.
If transport is set then outbound PUBLISH requests will use this transport.
ASTERISK-25901 #close
Change-Id: Ib389130489b70e36795b0003fa5fd386e2680151
When Asterisk receives a 412 (Conditional Request Failed) response
it has to recreate publish session.
There is bug in res_pjsip_outbound_publish.c
The function sip_outbound_publish_client_alloc is called with wrong object
while processing 412 (Conditional Request Failed) response.
This patch fixes it.
ASTERISK-25229 #close
Change-Id: I3b62f2debf6bb1e5817cde7b13ea39ef2bf14359
Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.
Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.
To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.
ASTERISK-25020
Reported by Mark Michelson
Change-Id: I756c19ab05ada5d0503175db9676acf87c686d0a
When Asterisk attempts to send SIP outbound publish information and no response
is ever received (no 200 okay, 412, 423) the system eventually crashes. A
response is never received because the system Asterisk is attempting to send
publish information to is not available. The underlying pjsip framework attempts
to send publish information. After several attempts it calls back into the
Asterisk outbound publish code. At this point if the "client->queue" is empty
Asterisk attempts to schedule a refresh which utilizes "rdata" and since no
response was received the given "rdata" struture is NULL. Attempting to
dereference a NULL object of course results in a crash.
The fix here removes the dependency on rdata for schedule_publish_refresh.
Instead param->expiration is now passed to it as this is set to -1 if no
response is received. Also added a notification when no response is received.
ASTERISK-24635 #close
Reported by: Marco Paland
Review: https://reviewboard.asterisk.org/r/4384/
........
Merged revisions 431490 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431491 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code was missing the case for explicitly destroying an outbound publication
when Asterisk had never actually published anything. The result was that Asterisk
would hang for a while on a graceful shutdown.
With this change, the case is taken into account, and on a graceful shutdown, these
publications are destroyed without the need to actually send a PUBLISH request.
ASTERISK-24655 #close
Reported by Kevin Harwell
Review: https://reviewboard.asterisk.org/r/4325
........
Merged revisions 430608 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430609 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When using a non-default sorcery wizard (in this instance realtime) for outbound
publishes Asterisk will crash after a stack overflow occurs due to the code
infinitely recursing. The fix entails removing the outbound publish state
dependency from the outbound publish sorcery object and instead keeping an in
memory container that can be used to lookup the state when needed.
ASTERISK-24514 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4178/
........
Merged revisions 429175 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429176 65c4cc65-6c06-0410-ace0-fbb531ad65f3
