From the gdb information, ast_websocket_read reads a message successfully,
then transport_read is called in the serializer. During execution of pjsip_transport_down,
ws_session->stream->fd is closed; ast_websocket_read encounters an error and exits the while loop.
After executing transport_shutdown, the transport's reference count becomes 0, causing a crash when sending SIP messages.
This was due to pjsip_transport_dec_ref executing earlier than pjsip_rx_data_clone, leading to this issue.
In websocket_cb executeing pjsip_transport_add_ref, this we now ensure the transport is not destroyed while in the loop.
Resolves: asterisk#299
(cherry picked from commit edc674a6ca)
When Asterisk receives a new websocket conenction, it creates a new
pjsip transport for it and copies connection data into it. The
transport manager then uses the remote IP address and port on the
transport to create a monitor for each connection. However, the
remote port wasn't being copied, only the IP address which meant
that the transport manager was creating only 1 monitoring entry for
all websocket connections from the same IP address. Therefore, if
one of those connections failed, it deleted the transport taking
all the the connections from that same IP address with it.
* We now copy the remote port into the created transport and the
transport manager behaves correctly.
ASTERISK-30369
Change-Id: Ib506d40897ea6286455ac0be4dfbb0ed43b727e1
As part of PJSIP 2.11 a behavior change was done to require
a matching remote hostname on an established transport for
secure transports. Since the Websocket transport is considered
a secure transport this caused the existing connection to not
be found and used.
We now set the remote hostname and the transport can be found.
ASTERISK-30065
Change-Id: Ia1cdef33e1411f927985b4b852c95e163c080e94
This is needed to be able to restore it in REGISTER responses,
otherwise the client won't be able to find the contact it created.
ASTERISK-30042
Change-Id: I0c5823918199acf09246b3b206fbde66773688f6
In rewrite_uri asterisk was not making deep copies of strings when
changing the uri. This was in some cases causing garbage in the route
header and in other cases even crashing asterisk when receiving a
message with a record-route header set. Thanks to Ralf Kubis for
pointing out why this happens. A similar problem was found in
res_pjsip_transport_websocket.c. Pjproject needs as well to be patched
to avoid garbage in CANCEL messages.
ASTERISK-29024 #close
Change-Id: Ic5acd7fa2fbda3080f5f36ef12e46804939b198b
When TLS is in use, checking the readiness of the underlying FD is insufficient
for determining if there is data available to be read. So before polling the
FD, check if there is any buffered data in the TLS layer and use that first.
ASTERISK-28562 #close
Reported by: Robert Sutton
Change-Id: I95fcb3e2004700d5cf8e5ee04943f0115b15e10d
The transport management code that checks for idle connections keeps a
reference to PJSIP's transport for IDLE_TIMEOUT milliseconds (32000 by
default). Because of this, if the transport is closed before this
timeout, the idle checking code will keep the transport from actually
being shutdown until the timeout expires.
Rather than passing the AO2 object to the scheduler task, we just pass
its key and look it up when it is time to potentially close the idle
connection. The other transport management code handles cleaning up
everything else for us.
Additionally, because we use the address of the transport when
generating its name, we concatenate an incrementing ID to the end of the
name to guarantee uniqueness.
Related to ASTERISK~28231
Change-Id: I02ee9f4073b6abca9169d30c47aa69b5e8ae9afb
When --enable-dev-mode is used, pjsip_tpmgr_receive_packet() will assert
if passed a payload length of 0, so treat empty frames as if we didn't
receive them.
Change-Id: I9c5fdccd89cc8d2f3ed7e3ee405ef0fc78178f48
Both pjsip_tx_data.tp_info.dst_name and pjsip_rx_data.pkt_info.src_name
store IPv6 addresses without enclosing brackets. This causes some log
output to be confusing because it is difficult to separate the IPv6
address from a port specification.
* Use pj_sockaddr_print() along with pjsip_tx_data.tp_info.dst_addr and
pjsip_rx_data.pkt_info.src_addr where possible for consistent IPv6
output.
* When a pj_sockaddr is not available, explicitly wrap IPv6 addresses
in brackets.
* When assigning pjsip_rx_data.pkt_info.src_name ourselves, make sure
to also set pjsip_rx_data.pkt_info.src_addr.
Change-Id: I5cfe997ced7883862a12b9c7d8551d76ae02fcf8
SIP responses over WebSockets when the client is using IPv6 have invalid
Via headers according to RFC 3261. The 'received' header parameter
should not be wrapped in brackets if it is an IPv6 address.
When src_name is populated by the built-in PJSIP transports, the code
uses pj_sockaddr_print() with 'flags' set to 0, meaning that the
brackets are not rendered around IPv6 addresses.
This may be related to ASTERISK~27101.
See also: https://github.com/onsip/SIP.js/pull/594
ASTERISK-28020 #close
Change-Id: I8ea9d289901b837512bee2ca2535e3dc14f04d77
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
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
We were not \0 terminating this string, so any attempt to print it would
in the best case show an empty string and in the worst case potentially
crash.
Change-Id: I63d96ef8f7516ac02a0f91e22dfa8acdc615042c
Previously for PJSIP the local address of WebSocket connections
was set to the remote address. For logging purposes this is
not particularly useful.
The WebSocket API has been extended to allow the local
address to be queried and this is used in PJSIP to set the
local address to the correct value.
The PJSIP HEP support has also been tweaked so that reliable
transports always use the local address on the transport
and do not try to (wrongly) guess. As they are connection
based it is impossible for the source to be anything else.
ASTERISK-26758
ASTERISK-27363
Change-Id: Icd305fd038ad755e2682ab2786e381f6bf29e8ca
The fix for the issue is broken up into three parts.
This is part two which handles the server side of REGISTER requests when
rewrite_contact is enabled. Any registered reliable transport contact
becomes invalid when the transport connection becomes disconnected.
* Monitor the rewrite_contact's reliable transport REGISTER contact for
shutdown. If it is shutdown then the contact must be removed because it
is no longer valid. Otherwise, when the client attempts to re-REGISTER it
may be blocked because the invalid contact is there. Also if we try to
send a call to the endpoint using the invalid contact then the endpoint is
not likely to see the request. The endpoint either won't be listening on
that port for new connections or a NAT/firewall will block it.
* Prune any rewrite_contact's registered reliable transport contacts on
boot. The reliable transport no longer exists so the contact is invalid.
* Websockets always rewrite the REGISTER contact address and the transport
needs to be monitored for shutdown.
* Made the websocket transport set a unique name since that is what we use
as the ao2 container key. Otherwise, we would not know which transport we
find when one of them shuts down. The names are also used for PJPROJECT
debug logging.
* Made the websocket transport post the PJSIP_TP_STATE_CONNECTED state
event. Now the global keep_alive_interval option, initially idle shutdown
timer, and the server REGISTER contact monitor can work on wetsocket
transports.
* Made the websocket transport set the PJSIP_TP_DIR_INCOMING direction.
Now initially idle websockets will automatically shutdown.
ASTERISK-27147
Change-Id: I397a5e7d18476830f7ffe1726adf9ee6c15964f4
Added check for NULL return value when calling
ast_sorcery_retrieve_by_id in function get_write_timeout
ASTERISK-27046
Change-Id: I9357717278da631c3a1cb502c412693929b0cb41
This change adds a PJSIP patch (which has been contributed upstream)
to allow the registration of IPv6 transport types.
Using this the res_pjsip_transport_websocket module now registers
an IPv6 Websocket transport and uses it for the corresponding
traffic.
ASTERISK-26685
Change-Id: Id1f9126f995b31dc38db8fdb58afd289b4ad1647
According to the RFC[1] WSS should only be used in the Via header
for secure Websockets.
* Use WSS in Via for secure transport.
* Only register one transport with the WS name because it would be
ambiguous. Outgoing requests may try to find the transport by name and
pjproject only finds the first one registered. This may mess up unsecure
websockets but the impact should be minimal. Firefox and Chrome do not
support anything other than secure websockets anymore.
* Added and updated some debug messages concerning websockets.
* security_events.c: Relax case restriction when determining security
transport type.
* The res_pjsip_nat module has been updated to not touch the transport
on Websocket originating messages.
[1] https://tools.ietf.org/html/rfc7118
ASTERISK-26796 #close
Change-Id: Ie3a0fb1a41101a4c1e49d875a8aa87b189e7ab12
Per RFC 7118 5.2, the SIP URI 'transport' parameter should advertise
'ws' when WebSockets are to be used as the transport. This applies to
both secure and insecure WebSockets.
There were two bugs in Asterisk with respect to this:
(1) The most egregious occurs in res_pjsip. There, we advertise 'ws' for
insecure websockets and 'wss' for secure websockets. While this
would seem to make sense - since 'WS' and 'WSS' are used for the Via
Transport parameter - this is not the case for the SIP URI. This
patch corrects that by registering the secure websockets with
pjproject using the shorthand 'WS', and by returning 'ws' when asked
for the transport parameter. Note that in pjproject, it is perfectly
valid to have multiple transports use the same shorthand.
(2) In chan_sip, we return an upper-case version of the transport 'WS'
instead of 'ws'. Since we should be strict in what we send and
liberal in what we accept (within reason), this patch lower-cases
the transport before appending it to the parameter.
ASTERISK-24330 #close
Reported by: cervajs, Inaki Baz Castillo
Change-Id: Iff77b645f8cc3b7cd35168a6676c26b147f22f42
Attempting to load a transport from realtime was forcing asterisk into an
infinite recursion loop. The first thing transport_apply did was to do a
sorcery retrieve by id for an existing transport of the same name. For files,
this just returns the previous object from res_sorcery_config's internal
container, if any. For realtime, the res_sourcery_realtime driver looks in the
database and finds the existing row but now it has to rehydrate it into a
sorcery object which means calling... transport_apply. And so it goes.
The main issue with loading from realtime (apart from the loop) was that
transport stores structures and pointers directly in the ast_sip_transport
structure instead of the separate ast_transport_state structure. This patch
separates those items into the ast_sip_transport_state structure. The pattern
is roughly the same as res_pjsip_outbound_registration.
Although all current usages of ast_sip_transport and ast_sip_transport_state
were modified to use the new ast_sip_get_transport_state API, the original
items are left in ast_sip_transport and kept updated to maintain ABI
compatability for third-party modules. They are marked as deprecated and
noted that they're now in ast_sip_transport_state.
ASTERISK-25606 #close
Reported-by: Martin Moučka
Change-Id: Ic7a836ea8e786e8def51fe3f8cce855ea54f5f19
Pjsip is refusing to use unsecure transport with "sips" in url.
WSS should be considered as secure transport.
ASTERISK-24602 #comment Partially fixed by setting WSS as secure
Change-Id: Iddac406c6deba6240c41a603b8859dfefe1a5353
We have seen a rash of test failures on a 32-bit build agent. Commit
48698a5e21 solved an obvious problem where
we were not encoding a 64-bit value correctly over the wire. This
commit, however, did not solve the test failures.
In the failing tests, ARI is attempting to send a 537 byte text frame
over a websocket. When sending a frame this small, 16 bits are all that
is required in order to encode the payload length on the websocket
frame. However, ast_websocket_write() thinks that the payload length is
greater than 65535 and therefore writes out a 64 bit payload length.
Inspecting this payload length, the lower 32 bits are exactly what we
would expect it to be, 537 in hex. The upper 32 bits, are junk values
that are not expected to be there.
In the failure, we are passing the result of strlen() to a function that
expects a uint64_t parameter to be passed in. strlen() returns a size_t,
which on this 32-bit machine is 32 bits wide. Normally, passing a 32-bit
unsigned value to somewhere where a 64-bit unsigned value is expected
would cause no problems. In fact, in manual runs of failing tests, this
works just fine. However, ast_websocket_write() uses the Asterisk
optional API, which means that rather than a simple function call, there
are a series of macros that are used for its declaration and
implementation. These macros may be causing some sort of error to occur
when converting from a 32 bit quantity to a 64 bit quantity.
This commit changes the logic by making existing ast_websocket_write()
calls use ast_websocket_write_string() instead. Within
ast_websocket_write_string(), the 64-bit converted strlen is saved in a
local variable, and that variable is passed to ast_websocket_write()
instead.
Note that this commit message is full of speculation rather than
certainty. This is because the observed test failures, while always
present in automated test runs, never occur when tests are manually
attempted on the same test agent. The idea behind this commit is to fix
a theoretical issue by performing changes that should, at the least,
cause no harm. If it turns out that this change does not fix the failing
tests, then this commit should be reverted.
Change-Id: I4458dd87d785ca322b89c152b223a540a3d23e67
This patch fixes use-after-free bugs caught by AddressSanitizer.
1. PJSIP transport manager may decide to destroy transport on its own.
For example, when the contact registered via websocket has not renewed
its registration in time. The transport was destoyed, but the websocket
listener thread was still active until the socket closes, and then tried
to call transport_shutdown on transport that has been freed.
Also, the transport destructor accessed wstransport->rdata.tp_info.pool
right after freeing memory that contained wstransport itself.
This patch converts transport to an ao2 object, allowing it to be
refcounted, so that it is available until both websocket listener and
pjsip transport manager are finished with it.
2. The websocket listener deletes the last reference on websocket session
when the tcp connection is closed, and it gets destroyed, but
the transport manager may still use it, for example when disconnect
happens in the middle of a SIP transaction.
A new reference to websocket session has been added that is released
with the transport to prevent this.
ASTERISK-25096 #close
Reported by: Josh Kitchens
ASTERISK-24963 #close
Reported by: Badalian Vyacheslav
Change-Id: Idc0b63eb6e459c1ddfb2430127d34b3c4d8d373b
Incoming SIP packets larger than PJSIP_MAX_PKT_LEN were themselves
truncated before passing to pjsip_tpmgr_receive_packet, but the length
was passed unaltered, thus causing memory corruption and segfault.
ASTERISK-25122 #close
Change-Id: I608a6b6b7f229eacc33a0a7d771d18e27e5b08ab
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In order to alter the Contact header on in-dialog requests and responses the
Websocket module must be attached on outgoing INVITEs. The Contact header is
modified so that the PJSIP transport layer can find and use the existing
Websocket connection based on the source IP address, port, and transport.
ASTERISK-24143 #close
Reported by: Aleksei Kulakov
........
Merged revisions 421955 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421956 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The packet structure used to receive messages was using the transport
pool. This meant that for each parsing the pool would grow accordingly.
Since memory can not be reclaimed without resetting it this would
cause the memory pool to grow and grow.
This change uses a specific memory pool for the packet structure and
resets it to a fresh state after the message has been received and
handled.
........
Merged revisions 421939 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421945 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421950 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
Transport type determination for security events has been simplified to use
the type present on the message itself instead of searching through configured
transports to find the transport used.
The actual WebSocket transport has also been simplified. It now leverages the
existing PJSIP transport manager for finding the active WebSocket transport
for outgoing messages. This removes the need for res_pjsip_transport_websocket
to store a mapping itself.
(closes issue ASTERISK-22897)
Reported by: Max E. Reyes Vera J.
Review: https://reviewboard.asterisk.org/r/3036/
........
Merged revisions 403256 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403257 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
Tinet-mucw
George Joseph
Joshua C. Colp
Thomas Guebels
Pirmin Walthert
Sean Bright
Richard Mudgett
Corey Farrell
Joshua Colp
Jørgen H
Matt Jordan
George Joseph
Martin Tomec
Mark Michelson
Ivan Poddubny
Rodrigo Ramírez Norambuena
Kinsey Moore