bridge_native_rtp can call into an RTP-capable channel driver in order
for the driver to update information about who the channel is
communicating with. For SIP channel drivers, this means deactivating
RTCP and sending a reinvite so that the endpoints can communicate
directly.
bridge_native_rtp does the right thing and has the channel locked when
calling into the channel driver. chan_pjsip can't alter session
properties in this thread, though. chan_pjsip queues a task on the
session serializer in order to update properties there.
The problem is that this queued task was not locking the channel. This
meant that the queued task could attempt to deactivate RTCP at the same
time that the channel thread was attempting to process an incoming RTCP
packet. This could lead to a crash.
This patch fixes the issue by locking the channel in the queued task
when altering RTP properties.
ASTERISK-26092 #close
Reported by Niklas Larsson
Change-Id: I3464e226a3c41f6b915f97891e07fa1599e2a159
A change to glibc 2.22 changed the order of the sockadddr_storage
members which caused the places where we do an initialization of
ast_sockaddr with '{ { 0, 0, } }' to fail compilation. Those
initializers (which we shouldn't have been using anyway) have been
replaced with memsets.
Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4
When chan_sip does a re-INVITE to refresh a session and authentication
is required, the INVITE with the Authorization header containes a
second Session-Expires header without the ";refersher=" parameter.
This is causing some proxies to return a 400. Also, when Asterisk is
the uas and the refresher, it is including the Session-Expires and
Min-SE headers in OPTIONS messages which is not allowed per RFC4028.
This patch (based on the reporter's) Checks to see if a Session-Expires
header is already in the message before adding another one. It also
checks that the method is INVITE or UPDATE.
ASTERISK-26030 #close
Change-Id: I58a7b07bab5a3177748d8a7034fb8ad8e11ce1d9
The unload process currently tells each TCP/TLS to terminate but
does not wait for them to do so. This introduces a race condition
where the container holding the threads may be destroyed before
the threads are able to remove themselves from it. When they
finally do the container is invalid and can't be used causing a
crash.
A previous change existed which waited a bit to wait for any
stranglers to finish. This change extends this and waits longer.
ASTERISK-25961 #close
Change-Id: Idc6262b670ca49ede32061159e323b7b63c6f3c6
Since Stasis has been introduced, an attempt to send AMI messages by an
autocreated peer caused a crash, and all events from autocreated peers were
semi-inadvertently disabled altogether in 0b83761. This change restores the
disabled functionality.
ASTERISK-25950
Change-Id: Iecc350f23db603fadb2f302064643ebe9664e974
Added the ability to show channel statistics to chan_pjsip (cli_functions.c)
Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c. The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.
Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots. Much more efficient.
Change-Id: I03b114522126d27434030b285bf6d531ddd79869
Asterisk 13.7.0 included a fix for ASTERISK-24543, not to send all those
codecs, which the caller did not request/support. That fix was not complete
because on the second Session Timer all codecs were sent again. Some VoIP/SIP
clients interpreted that complete codec-list as a change in the SIP session.
Because of that, Asterisk did not send the RTP audio via NAT anymore which
created a non-audio scenario after the second Session Timer fired.
ASTERISK-24543 #close
Change-Id: I1881827816ab7fd47eb4287a95961179b34a0b66
check_via() already skips leading blanks where the sent-by address (with the
optional port) should be placed.
Since RFC 3261 allows for blanks between the port ant the Via parameters:
> https://tools.ietf.org/html/rfc3261#section-20.42
(actually it allows a lot of blanks more ;-)). I just switched from
ast_skip_blanks() to ast_strip() on the local copy of the string.
ASTERISK-21301 #close
Change-Id: Ie5b8fe5a07067b7c0dc9bcdd1707e99b23b02b06
During a transfer involving direct media a race occurs between when the
transferer channel is swapped out, initiating rtp changes/updates, and the
subsequent reinvites.
When Alice, after speaking with Charlie (Bob is on hold), connects Bob and
Charlie invites are sent to each in order to establish the call between them.
Bob is taken off hold and Charlie is told to have his media flow through
Asterisk. However, if before those invites go out the bridge updates Bob's
and/or Charlie's rtp information with direct media data (i.e. address, port)
then the invite(s) will contain the remote data in the SDP instead of the
Asterisk data.
The race occurs in the native bridge glue code when updating the peer. The
direct_media_address can get set twice before sending out the first invite
during call connection. This can happen because the checking/setting of the
direct_media_address happened in one thread while the sending of the invite(s)
happened in another thread.
This fix removes the race condition by moving the checking/setting of the
direct_media_address to be in the same thread as the sending of the invites(s).
This serializes the checking/setting and sending so they can no longer happen
out of order.
ASTERISK-25849 #close
Change-Id: Idfea590175e74f401929a601dba0c91ca1a7f873
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023 #close
Change-Id: I96d429c57a48861fd8bde63dd93db4e92dc3adb6
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I2e40de89efc8ae6e8850771d089ca44bc604b508
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: If595e4456cd059d7171880c7f354e844c21b5f5f
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I9c11b9d597468f63916c99e1dabff9f4a46f84c1
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Fix retrans_pkt() to call check_pendings() with both the owner channel
and the private objects locked as required.
* Refactor dialog retransmission packet list to safely remove packet
nodes. The list nodes are now ao2 objects. The list has a ref and the
scheduled entry has a ref.
ASTERISK-25023
Change-Id: I50926d81be53f4cd3d572a3292cd25f563f59641
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Made always run check_pendings() under the scheduler thread so scheduler
ids can be checked safely.
ASTERISK-25023
Change-Id: Ia834d6edd5bdb47c163e4ecf884428a4a8b17d52
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I6d65269151ba95e0d8fe4e9e611881cde2ab4900
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Fix clearing autokillid in __sip_autodestruct() even though we could
reschedule.
ASTERISK-25023
Change-Id: I450580dbf26e2e3952ee6628c735b001565c368f
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I98a694fd42bc81436c83aa92de03226e6e4e3f48
This patch is part of a series to resolve deadlocks in chan_sip.c.
* Make dialog_unlink_all() unschedule all items at once in the sched
thread.
ASTERISK-25023
Change-Id: I7743072fb228836e8228b72f6dc46c8cc50b3fb4
This patch is part of a series to resolve deadlocks in chan_sip.c.
The reordering of chan_sip's shutdown is to handle any immediate events
that get put onto the scheduler so resources aren't leaked. The typical
immediate events at this time are going to be concerned with stopping
other scheduled events.
ASTERISK-25023
Change-Id: I3f6540717634f6f2e84d8531a054976f2bbb9d20
This patch is part of a series to resolve deadlocks in chan_sip.c.
Delaying destruction of the chan_sip sip_pvt structures caused the
/channels/chan_sip/test_sip_rtpqos unit test to crash. That test
registers a special test ast_rtp_engine with the rtp engine module. When
the unit test completes it cleans up by unregistering the test
ast_rtp_engine and exits. Since the delayed destruction of the sip_pvt
happens after the unit test returns, the destructor tries to call the rtp
engine destroy callback of the test ast_rtp_engine auto variable which no
longer exists on the stack.
* Change the test ast_rtp_engine auto variable to a static variable. Now
the variable can still exist after the unit test exits so the delayed
sip_pvt destruction can complete successfully.
ASTERISK-25023
Change-Id: I61e34a12d425189ef7e96fc69ae14993f82f3f13
Remove destructor calling destroy_it calling really_destroy_it
for no benefit. Just make the destructor the really_destroy_it
function.
Change-Id: Idea0d47b27dd74f2488db75bcc7f353d8fdc614a
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
chan_sip could not handle AST_T38_TERMINATED frames being sent to it when
the channel left the bridge. The action resulted in overlapping outgoing
reINVITEs. The testsuite tests/fax/sip/directmedia_reinvite_t38 was not
happy.
* Force T.38 to be remembered as locally bridged. Now when the channel
leaves the native RTP bridge after T.38, the channel remembers that it has
already reINVITEed the media back to Asterisk. It just needs to terminate
T.38 when the AST_T38_TERMINATED arrives.
* Prevent redundant AST_T38_TERMINATED from causing problems. Redundant
AST_T38_TERMINATED frames could cause overlapping outgoing reINVITEs if
they happen before the T.38 state changes to disabled. Now the T.38 state
is set to disabled before the reINVITE is sent.
ASTERISK-25582 #close
Change-Id: I53f5c6ce7d90b3f322a942af1a9bcab6d967b7ce
Use the correct comparison function since we only care if the address
without the port is the same.
Change-Id: Ibf6c485f843a1be6dee58a47b33d81a7a8cbe3b0
Setting the sip.conf timert1 value to a value higher than 1245 can cause
an integer overflow and result in large retransmit timeout times. These
large timeout times hold system file descriptors hostage and can cause the
system to run out of file descriptors.
NOTE: The default sip.conf timert1 value is 500 which does not expose the
vulnerability.
* The overflow is now detected and the previous timeout time is
calculated.
ASTERISK-25397 #close
Reported by: Alexander Traud
Change-Id: Ia7231f2f415af1cbf90b923e001b9219cff46290
When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
asterisk to include the same value for its own ip in both cases a) and b),
but it seems a) produces a contact header like Contact:
<sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
<sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf
My guess is that manager_sipnotify should call
ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
because after applying this patch, both cases a) and b) produce
the contact header that I expect: <sip:asterisk@192.168.1.227:8060>
Reported by: Stefan Engström
Tested by: Stefan Engström
Change-Id: I86af5e209db64aab82c25417de6c768fb645f476
sip_sipredirect uses sscanf to copy up to 256 characters to a stacked buffer
of 256 characters. This patch reduces the copy to 255 characters to leave
room for the string null terminator.
ASTERISK-25722 #close
Change-Id: Id6c3a629a609e94153287512c59aa1923e8a03ab
websocket_write_timeout was not being set to its default value
during sip config reload, which meant that prior to this commit,
1) the default value of 100 was not used, unless an invalid value
(or 1) was specified in sip.conf for websocket_write_timeout, and
2) if the websocket_write_timeout directive was removed from sip.conf
without a full restart of asterisk, then the previous value would
continue to be used indefinitely.
This essentially lead to a 0ms write timeout (the first write attempt
in ast_careful_fwrite must have succeeded) in websocket write requests
from chan_sip, unless websocket_write_timeout was explicitely set in sip.conf.
Changes to websocket_write_timeout still only apply to new websocket
sessions, after the sip reload -- timeouts on existing sessions are
not adjusted during sip reload.
Change-Id: Ibed3816ed29cc354af6564c5ab3e75eab72cb953
Per the documentation the WebSocket support in chan_sip is
supposed to be enabled by default but is not. This change
corrects that.
Change-Id: Icb02bbcad47b11a795c14ce20a9bf29649a54423
Adds the TCP Keep Alive option to TCP and TLS server sockets. Previously
this option was only being set on session sockets.
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
According to the link above, the SO_KEEPALIVE option is useful for knowing
when a TCP connected endpoint has severed communication without indicating
it or has become unreachable for some reason. Without this patch, keep
alive is not set on the socket listening for incoming TCP sessions and
in Komatsu's report this resulted in the thread listening for TCP becoming
stuck in a waiting state.
ASTERISK-25364 #close
Reported by: Hiroaki Komatsu
Change-Id: I7ed7bcfa982b367dc64b4b73fbd962da49b9af36
Asterisk may crash when calling ast_channel_get_t38_state(c)
on a locked channel which is being hung up.
ASTERISK-25609 #close
Change-Id: Ifaa707c04b865a290ffab719bd2e5c48ff667c7b
The current logic for ICE negotiation starts it
when receiving an SDP with ICE candidates. This is
incorrect as ICE negotiation can only start when each
call party have at least one pair of local and remote
candidate. Starting ICE negotiation early would result
in negotiation failure and ultimately no audio.
This change makes it so ICE negotiation is only started
when a response with SDP is received or when a response
with SDP is sent.
ASTERISK-24146
Change-Id: I55a632bde9e9827871b09141d82747e08379a8ca
A crash happens sometimes when performing a CLI "sip reload". The bogus
peer gets refreshed while it is in use by a new call which can cause the
crash.
* Protected the global bogus peer object with an ao2 global object
container.
ASTERISK-25610 #close
Change-Id: I5b528c742195681abcf713c6e1011ea65354eeed
chan_sip.c:
* Initialize mwi subscription scheduler ids earlier because of ASTOBJ to
ao2 conversion.
* Initialize register scheduler ids earlier because of ASTOBJ to ao2
conversion.
chan_skinny.c:
* Fix more scheduler usage for the valid 0 id value.
ASTERISK-25476
Change-Id: If9f0e5d99638b2f9d102d1ebc9c5a14b2d706e95
channels/chan_iax2.c:
* Initialize struct chan_iax2_pvt scheduler ids earlier because of
iax2_destroy_helper().
channels/chan_sip.c:
channels/sip/config_parser.c:
* Fix initialization of scheduler id struct members. Some off nominal
paths had 0 as a scheduler id to be destroyed when it was never started.
chan_skinny.c:
* Fix some scheduler id comparisons that excluded the valid 0 id.
channel.c:
* Fix channel initialization of the video stream scheduler id.
pbx_dundi.c:
* Fix channel initialization of the packet retransmission scheduler id.
ASTERISK-25476
Change-Id: I07a3449f728f671d326a22fcbd071f150ba2e8c8
When a channel is in a direct media bridge, a re-INVITE may arrive that forces
Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge
must change its technology to a simple bridge, and re-INVITE the media back
to Asterisk.
Generally, this logic mostly already exists in Asterisk. However, prior to this
patch, there were a few bugs:
(1) The T.38 framehook currently prevents a channel capable of T.38 faxes from
ever entering into a direct media bridge. This applies even when the only
media being passed over the channel is audio. This patch fixes this bug
by having the framehook specify that it defers caring about any frame type.
This allows the channels to enter into a direct media bridge, which will
be broken when a re-INVITE is received.
(2) When a re-INVITE is received, nothing instructed the bridging layer to
re-inspect the allowed bridging technology. This now occurs when either
a re-INVITE is received from a peer, or when a response is received from
the far end (that is, when the T.38 state changes to either
T38_PEER_REINVITE or T38_LOCAL_REINVITE).
(3) chan_pjsip needs to do a small amount of work to prevent a direct media
bridge from being chosen when a T.38 session is in progress. When a T.38
session supplement has a t38 datastore - which is added when we detect
we should start thinking about T.38 on a channel - we now refuse a native
RTP bridge.
(4) When a BYE request is received, we don't terminate the T.38 session. If
the other side of a T.38 fax survives the hangup (due to the 'g' flag
in Dial, for example), we don't currently re-INVITE the media on the
other channel back to audio. This patch now has res_pjsip_t38 intercept
BYE requests and inform the far side that the T.38 session is terminated.
This naturally causes the correct re-INVITEs to be sent.
ASTERISK-25582
Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
When ASTERISK-25449 was closed, a number of scheduler issues mentioned in
the comments were missed. These have since beed raised in ASTERISK-25476
and elsewhere.
This patch attempts to collect all of the scheduler issues discovered so
far and address them sensibly.
ASTERISK-25476 #close
Change-Id: I87a77d581e2e0d91d33b4b2fbff80f64a566d05b
This patch adds a new setting "websockets_enabled" to sip.conf.
Setting this to false allows chan_sip to be used without causing
conflicts with res_pjsip_transport_websocket.
ASTERISK-24106 #close
Reported by: Andrew Nagy
Change-Id: I04fe8c4f2d57b2d7375e0e25826c91a72e93bea7
