RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in res_pjsip/chan_pjsip.c
Review: https://reviewboard.asterisk.org/r/4345
........
Merged revisions 431426 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a CLI "module reload" command when there are new pjsip.conf
registration objects defined frequently failed to load them correctly.
What happens is a race condition between res_pjsip pushing its reload into
an asynchronous task processor task and the thread that does the rest of
the reloads when it gets to reloading the res_pjsip_outbound_registration
module. A similar race condition happens between a reload and the CLI/AMI
show registrations commands. The reload updates the current_states
container and the CLI/AMI commands call get_registrations() which builds a
new current_states container.
* Made res_pjsip.c reload_module() use ast_sip_push_task_synchronous()
instead of ast_sip_push_task() to eliminate two threads processing config
reloads at the same time.
* Made get_registrations() not replace the global current_states container
so the CLI/AMI show registrations command cannot interfere with reloading.
You could never add/remove objects in the container without the
possibility of the container being replaced out from under you by
get_registrations().
* Added a registration loaded sorcery instance observer to purge any dead
registration objects since get_registrations() cannot do this job anymore.
The struct ast_sorcery_instance_observer callbacks must be used because
the callback happens inline with the load process. The struct
ast_sorcery_observer callbacks are pushed to a different thread.
* Added some global current_states NULL pointer checks in case the
container disappears because of unload_module().
* Made sorcery's struct ast_sorcery_instance_observer.object_type_loaded
callbacks guaranteed to be called before any struct
ast_sorcery_observer.loaded callbacks will be called.
* Moved the check for non-reloadable objects to before the sorcery
instance loading callbacks happen to short circuit unnecessary work.
Previously with non-reloadable objects, the sorcery instance
loading/loaded callbacks would always happen, the individual wizard
loading/loaded would be prevented, and the non-reloadable type logging
message would be logged for each associated wizard.
ASTERISK-24729 #close
Review: https://reviewboard.asterisk.org/r/4381/
........
Merged revisions 431243 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431251 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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 first thing this patch fixes is UAS dialogs. Previously if a transport was
configured on an endpoint and an inbound session was created there was no guarantee
that requests sent on the dialog would use the correct transport and address
information. This has now been fixed so an explicitly configured transport
is taken into account.
The second thing this patch fixes is res_pjsip_multihomed. The res_pjsip_multihomed
module attempts to determine what transport a message should go out on and what
addressing information should go into the message itself. In a scenario where
multiple transports exist bound to the same IP address but a different port the
code would incorrectly alter the transport and change the message to the wrong
transport. This change makes the res_pjsip_multihomed module smarter so it will
only change the transport and address information in the message when it is
possible and makes sense.
ASTERISK-24615 #close
Reported by: David Justl
Review: https://reviewboard.asterisk.org/r/4331/
........
Merged revisions 430755 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430756 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
Testing has shown repeatedly that PJSIP's default behavior of switching
automatically to TCP for large messages can cause issues. The most common
issues are that devices that we are communicating with do not handle the
switch to TCP gracefully, thus causing situations such as broken calls or
broken subscriptions. Now, in order to have this behavior happen, you must
opt into it. The sample file has been updated to warn that enabling the
TCP switch behavior may cause issues for you, so use at your own risk.
........
Merged revisions 427334 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a packet exceeds the MTU, pjproject will switch from UDP to TCP. In
some circumstances (on some networks), this can cause some issues with
messages not getting sent to the correct destination - and can also cause
connections to get dropped due to quirks in pjproject deciding to
terminate TCP connections with no messages.
While fixing the routing/messaging issues is important, having a
configuration option in Asterisk that tells pjproject to not switch over
to TCP would be useful. That way, if some glitch is discovered on some
other network/site, we can at least disable the behavior until a fix is
put into place.
AFS-197 #close
Review: https://reviewboard.asterisk.org/r/4137/
........
Merged revisions 427129 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427130 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an option, moh_passthrough, that when enabled will pass
hold and unhold requests through using a SIP re-invite. When placing on
hold a re-invite with sendonly will be sent and when taking off hold a
re-invite with sendrecv will be sent. This allows remote servers to handle
the musiconhold instead of the local Asterisk instance being responsible.
Review: https://reviewboard.asterisk.org/r/4103/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When an inbound SDP offer is received, Asterisk currently makes a few
incorrection assumptions:
(1) If the offer contains more than a single audio/video stream, Asterisk will
reject the entire stream with a 488. This is an overly strict response;
generally, Asterisk should accept the media streams that it can accept and
decline the others.
(2) If the offer contains a declined media stream, Asterisk will attempt to
process it anyway. This can result in attempting to match format
capabilities on a declined media stream, leading to a 488. Asterisk should
simply ignore declined media streams.
(3) Asterisk will currently attempt to handle offers with AVPF with
use_avpf=No/AVP with use_avpf=Yes. This mismatch results in invalid SDP
answers being sent in response. If there is a mismatch between the media
type being offered and the configuration, Asterisk must reject the offer
with a 488.
This patch does the following:
* Asterisk will accept SDP offers with at least one media stream that it can
use. Some WARNING messages have been dropped to NOTICEs as a result.
* Asterisk will not accept an offer with a media type that doesn't match its
configuration.
* Asterisk will ignore declined media streams properly.
#SIPit31
Review: https://reviewboard.asterisk.org/r/4063/
ASTERISK-24122 #close
Reported by: James Van Vleet
ASTERISK-24381 #close
Reported by: Matt Jordan
........
Merged revisions 425868 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 425879 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425881 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds a module which is configurable using the keep_alive_interval setting in the
global section that will send a CRLF keep alive to all active connection-oriented transports at
the provided interval. This is useful because it can help keep connections open through NATs.
This functionality also exists within PJSIP but can not be controlled at runtime and requires
recompiling it.
Review: https://reviewboard.asterisk.org/r/4084/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@425825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Improvements to the res_pjsip transport cipher option.
* Made the cipher option accept a comma separated list of OpenSSL cipher
names. Users of realtime will be glad if they have more than one name to
list.
* Added the CLI command 'pjsip list ciphers' so a user can know what
OpenSSL names are available for the cipher option.
* Updated the cipher option online XML documentation to specify what is
expected for the value.
* Updated pjsip.conf.sample to not indicate that ALL is acceptable since
ALL does not imply a preference order for the ciphers and PJSIP does not
simply pass the string to OpenSSL for interpretation.
ASTERISK-24199 #close
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/4018/
........
Merged revisions 424393 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424394 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424395 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During the latest update to DTLS-SRTP support the ability to configure
the hash used for fingerprints was added. This gave us two supported ones:
SHA-1 and SHA-256. The default was accordingly updated to SHA-256.
Unfortunately this configuration ability was not exposed within res_pjsip.
This change adds a dtls_fingerprint option that controls it.
#SIPit31
........
Merged revisions 424290 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424291 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424292 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The crash on the issues is a result of an invalid transport configuration
change when asterisk is restarted. The attempt to send the qualify
request fails and we cleaned up. However, the callback is also called
which results in a double unref of the objects involved.
* Put a wrapper around pjsip_endpt_send_request() to detect when the
passed in callback is called because of an error so callers can know to
not cleanup.
* Made send_request_cb() able to handle repeated challenges (Up to 10).
* Fix periodic endpoint qualify OPTIONS sched deletion race by avoiding
it. The sched entry will no longer self stop and must be externally
stopped.
* Added REF_DEBUG description tags to struct sched_data in
pjsip_options.c.
* Fix some off-nominal ref leaks in schedule_qualify(),
qualify_and_schedule().
* Reordered pjsip_options.c module start/stop code to cleanup better on
error.
ASTERISK-24295 #close
Reported by: Rogger Padilla
Review: https://reviewboard.asterisk.org/r/3954/
........
Merged revisions 423866 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 423867 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a large swath of response documentation for PJSIPShowEndpoint
and PJSIPShowEndpoints AMI commands. It relies heavily on the existing
text in the configInfo documentation via xi:include tags to avoid
documentation duplication.
Review: https://reviewboard.asterisk.org/r/3888/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most channel drivers let you specify a default accountcode to be set on
channels associated with a particular peer/endpoint/object. Prior to this
patch, chan_pjsip/res_pjsip did not support such a setting.
This patch adds a new setting to the res_pjsip endpoint object, 'accountcode'.
When a channel is created that is associated with an endpoint with this value
set, the channel will automatically have its accountcode property set to the
value configured for the endpoint.
Review: https://reviewboard.asterisk.org/r/3724/
ASTERISK-24000 #close
Reported by: Matt Jordan
........
Merged revisions 418756 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip and chan_pjsip have also been added to
allow behavior to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SIP transaction timeouts are handled in the PJSIP monitor thread. When
this happens on a subscription, and the subscription is destroyed, the
subscription destruction is dispatched synchronously to the threadpool.
The issue is that the PJSIP dialog is locked by the monitor thread,
and then the dispatched task attempts to lock the dialog. This leads
to a deadlock that causes SIP traffic to no longer be accepted on the
Asterisk server.
The fix here is to treat the monitor thread as if it were a threadpool
thread when it attempts to dispatch synchronous tasks. This way, the
dispatched task turns into a simple function call within the same thread,
and the locking issue is averted.
AST-2014-008
ASTERISK-23802 #close
........
Merged revisions 415794 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415795 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes res_pjsip_pubsub persist inbound subscriptions in sorcery. By default
this uses the local astdb but it can also be configured to store within an outside
database. When Asterisk is started these subscriptions are recreated if they have not
expired. Notifications are sent to the devices which have subscribed and they are none
the wiser that the system has restarted.
Review: https://reviewboard.asterisk.org/r/3598/
........
Merged revisions 415766 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change fixes a problem where permanent contacts being qualified were not
being updated. This was caused by the permanent contacts getting a uuid and not a
known identifier, causing an inability to look them up when updating in the
qualify code. A bug also existed where the new configuration may not be available
immediately when updating qualifies.
(closes issue ASTERISK-23514)
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/3448/
........
Merged revisions 412551 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes it so if a transport is configured on an endpoint that is a WebSocket
type the option will be ignored. In practice this is fine because the WebSocket
transport can not create outgoing connections, it can only reuse existing ones. By
ignoring the option the existing PJSIP logic for using the existing connection will
be invoked and stuff will proceed.
(closes issue ASTERISK-23584)
Reported by: Rusty Newton
........
Merged revisions 411927 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed bad use of ao2_find() in on_endpoint().
* Replaced use of find_endpoints() with find_an_endpoint() since only the
first found endpoint is ever needed.
* Fixed qualify_contact_cb() to update the contact with the aor
authenticate_qualify setting. Otherwise, permanent contacts in the aor
type sections would have a config line order dependancy.
* Fixed off nominal path contact ref leak in qualify_contact(). The
comment saying the unref is not needed was wrong.
* Fixed off nominal path use of the endpoint parameter if it is NULL in
send_out_of_dialog_request().
* Added missing off nominal path unref of pjsip tdata in
send_out_of_dialog_request().
* Fixed off nominal path failing to call the callback in send_request_cb()
when the request is challenged for authentication.
* Eliminated silly RAII_VAR() use in qualify_contact_cb().
* Updated ast_sip_send_request() doxygen to better reflect reality.
(closes issue ASTERISK-23254)
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/3381/
........
Merged revisions 411141 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411142 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enables DNS client support within PJSIP. System
nameservers are automatically discovered using res_init or
res_ninit. If this fails then PJSIP will resort to using
gethostbyname for resolution.
By enabling this support we gain SRV support, failover, and
weight support.
(closes issue ASTERISK-23435)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3343/
........
Merged revisions 410795 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The one touch recording options have several see-also links between the
various configuration options. These were 'broken' by the snake casing
of those options. This patch corrects the see-also links such that they
reference the correct option names.
........
Merged revisions 410194 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to retrieve an arbitrary sorcery instance from a dialplan function
(or any place else) there needs to be a registry of sorcery instances.
ast_sorcery_init now creates a hashtab as a registry.
ast_sorcery_open now checks the hashtab for an existing sorcery instance
matching the caller's module name. If it finds one, it bumps the
refcount and returns it. If not, it creates a new sorcery instance,
adds it to the hashtab, then returns it.
ast_sorcery_retrieve_by_module_name is a new function that does a hashtab
lookup by module name. It can be called by the future dialplan function.
res_pjsip/config_system needed a small change to share the main res_pjsip
sorcery instance.
tests/test_sorcery was updated to include a test for the registry.
(closes issue ASTERISK-22537)
Review: http://reviewboard.asterisk.org/r/3184/
........
Merged revisions 408518 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When 'use_avpf' is set to True, inbound offers must use the AVPF/SAVPF RTP
profile. However, when 'use_avpf' is set to False, Asterisk will accept
both AVP/SAVP or AVPF/SAVPF RTP profiles in inbound offers. The documentation
previously implied that Asterisk would reject AVPF/SAVPF if 'use_avpf' was
set to False and a UA offered said profile in an INVITE request.
........
Merged revisions 408502 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408503 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Making the help text for both more explicit regarding the format of mailbox identifiers. i.e. clarifying the format for app_voicemail mailboxes vs mailboxes from external MWI sources through modules such as res_external_mwi.
........
Merged revisions 406133 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406134 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The PJSIP header parsing function (pjsip_parse_hdr) can generate more
than one header instance from a single header field. These header
instances exist as a list attached to the returned header and must be
handled appropriately when they are added to a message or else only the
first header instance will be used. This changes the linked list
functions used in outbound proxy code to merge the lists properly.
........
Merged revisions 406020 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@406022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
