Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@415841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk started counting the session timer at INVITE while the other
end correctly started at 200. This meant that for short session-expiries
(90 seconds) combined with long ringing times (e.g. 30 seconds), asterisk
would wrongly assume that the timer was hit before the other end thought
it was time to send a session refresh. This resulted in prematurely
ended calls.
This changes the session timer to start counting first at 200 like RFC
says it should.
(Also removed a few excess NULL checks that would never hit, because if
they did, asterisk would have crashed already.)
ASTERISK-22551 #close
Reported by: i2045
Review: https://reviewboard.asterisk.org/r/3562/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@414620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves a large number of compiler warnings from GCC 4.10 which
cause the build to fail under dev mode. The vast majority are
signed/unsigned mismatches in printf-style format strings.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@413586 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r411189, some behavior was changed which made sendrpid behavior
act in a more trusting manner by sending full user data for peers
set with private caller presence in P-Asserted-Identity headers.
Since this changed long time expected behaviors, we decided to pull
that patch when that was pointed out by the community. Instead, this
patch provides a trust_id_outbound setting which will expose the data
per RFC-3325 if set to 'yes' and simply not send the PAI/RPID headers
at all if set to 'no'. By default trust_id_outbound will be set to
'legacy' which will preserve the behavior prior to these patches.
Extra special thanks to Walter Doekes for providing advice and
feedback.
(closes issue AST-1301)
(closes issue ASTERISK-19465)
Reported by: Krzysztof Chmielewski
Review: https://reviewboard.asterisk.org/r/3447/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@412744 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---
r411189 | jrose | 2014-03-26 10:50:48 -0500 (Wed, 26 Mar 2014) | 12 lines
chan_sip: Send real CallerID information with P-Assserted-Identity (RFC-3325)
Prior to this patch, the P-Asserted-Identity header would include anonymous
caller id information which seems to go against the point of the
P-Asserted-Identity header. Now the real caller ID information will be
included in this header. Also, no privacy header would be included.
This patch adds 'Privacy: id' to outgoing SIP messages that include the
P-Asserted-Identity header.
(closes issue AST-1301)
---
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@412328 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
Every run will now blow away the previous run (as large ref files
sometimes caused issues). We now also no longer open/close the file
on each write, instead relying on fflush to make sure data gets written
to the file (in case the ao2 call being performed is about to cause a
crash)
(3) It goes with a comma delineated format for the ref debug file. This
makes parsing much easier. This also now includes the thread ID of the
thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
contrib/scripts folder.
Review: https://reviewboard.asterisk.org/r/3377/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@412114 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross. Local channel optimization requires frames
flowing to trigger when optimization can happen. When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing. If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received. With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.
* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed. Asterisk now always uses internal
timing when needed if any timing module is loaded. The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used. The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.
* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().
ASTERISK-22846 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3414/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior too this patch, the P-Asserted-Identity header would include anonymous
caller id information which seems to go against the point of the
P-Asserted-Identity header. Now the real caller ID information will be
included in this header. Also, no privacy header would be included.
This patch adds 'Privacy: id' to outgoing SIP messages that include the
P-Asserted-Identity header.
(closes issue AST-1301)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411189 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If update_provisional_keepalive() is called while
send_provisional_keepalive_full() is waiting on the PVT lock, then
pvt->provisional_keepalive_sched_id will be changed to a new sched_id
value by update_provisional_keepalive(), but that new sched_id then may
be overwritten with -1 by send_provisional_keepalive_full(), killing
the pvt's reference to a schedule and "leaking" the reference.
(closes issue ASTERISK-22079)
Review: https://reviewboard.asterisk.org/r/3368/
Reported by: Jamuel Starkey, Matteo, Leif Madsen, Steve Davies
Patches:
provisional_keepalive_fix.diff uploaded by Steve Davies (license 5012)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@411088 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to avoid creation of the channel and
consumption of associated file descriptors altogether if the inbound
request is going to be rejected anyway.
(closes issue ASTERISK-23373)
Reported by: Corey Farrell
Patches:
chan_sip-earlier-st-1.8.patch uploaded by Corey Farrell (license 5909)
chan_sip-earlier-st-11.patch uploaded by Corey Farrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@410308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a static realtime peer with qualify=yes is loaded, Asterisk will fail to
send an OPTIONS request due to the lastms being equal to 0. This results in
the peer being unable to receive calls from Asterisk because the status is
permanently UNKNOWN.
This patch allows an OPTIONS request to be sent during module load by
ignoring the lastms value on startup only.
Review: https://reviewboard.asterisk.org/r/3294/
(closes issue ASTERISK-17523)
Reported by: Maciej Krajewski
Tested by: wushumasters
patches:
realtime_fix_11.7.0.txt uploaded by Trevor Peirce (license 6112)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@410105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix crash in ast_channel_hangupcause_set() because p->owner not checked
before calling. Regression introduced by the fix for ASTERISK-22621.
(closes issue ASTERISK-23135)
Reported by: OK
(issue ASTERISK-23323)
Reported by: Walter Doekes
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@409156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Updated the code to check to see if MOH is playing on the transferor and if
so then start it on the channel that replaces it during a masquerade.
Example scenario of the problem:
Alice calls Bob and then Bob begins the attended transfer process into a queue.
Upon going on hold Alice hears music and so does Bob once he is in the queue.
Bob then transfers Alice into the queue and then music for Alice stops even
though she should be hearing it since has now replaced Bob in the queue.
The problem that was occurring is that once the channel was masqueraded the app
(queues, confbridge, etc...) had no way of knowing that the channel had just
been swapped out thus it did not start music for the present channel.
Credit to Olle Johansson for pointing me in the right direction on this issue.
(closes issue ASTERISK-19499)
Reported by: Timo Teräs
Review: https://reviewboard.asterisk.org/r/3226/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@408642 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to decline individual image streams over
unsupported transports in the SDP of the 200 response. Previously,
an image stream offer with RTP/AVP as the transport would cause
chan_sip to respond with a 488.
(closes issue ASTERISK-22988)
Reported by: adomjan
Original patch by: adomjan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406170 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@405791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-12117, an improvement to insure consistant local from tags
on outbound registrations resulted in an undesirable behavior - caused
by leftover unexpired sip_pvt dialogs (with the previous cseq number),
resulting in many uncessary REGISTER requests. Instead of significant
rework of transmit_register(), this change deletes the dialogs after a
200 OK response indiciating a successful registration, keeping the old
dialogs from interfering with normal operation.
(closes issue ASTERISK-22946)
Reported by: Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/3109/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@405433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When performing a SIP transfer to a Park extension, if the Park fails, chan_sip
will currently not hang up either the transferer or the transfer target. This
results in the channels being orphaned with no thread to service frames,
resulting in stuck channels.
This patch immediately hangs up the two channels if a Park fails.
(closes issue ASTERISK-22834)
Reported by: rsw686
(closes issue ASTERISK-23047)
Reported by: Tommy Thompson
Review: https://reviewboard.asterisk.org/r/3107
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@405379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outbound register requests the tag on the From line was
updated every 20 seconds prior to a successful registration
and also once for each registration renewal. That behavior
can possibly cause the registration to be denied because of
the different tag, and is not aligned with the intention of
RFC 3261 8.1.3.5 "... request constitutes a new transaction
and SHOULD have the same value of the Call-ID, To, and From
of the previous request...". This updates chan_sip to have
a field to keep the local tag in the registration structure
and use that tag for registration requests where the callid
is also unchanged.
(closes issue ASTERISK-12117)
Reported by: Pawel Pierscionek
Review: https://reviewboard.asterisk.org/r/2988/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@402604 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The presentation indicator in a callerid (e.g. set by dialplan function
Set(CALLERID(name-pres)= ...)) is not checked when SIP Dialog Info Notifies
are generated during extension monitoring. Added a check to make sure the
name and/or number presentations on the callee (remote identity) are set to
allow. If they are restricted then "anonymous" is used instead.
(closes issue AST-1175)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2976/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@402468 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If preferred codecs included any non-audio format the code would
mistakenly add the audio format, even if it was not a joint capability
with the remote side.
(closes issue ASTERISK-21131)
Reported by: nbougues
Patches:
patch_unsupported_codec_1.8.patch uploaded by nbougues (license 6470)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401497 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400970 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Bumping the SDP version number can cause interoperability problems
since receivers of the responses will expect that a 200 SDP will
be identical to a previous 183 SDP.
(closes issue ASTERISK-21204)
reported by NITESH BANSAL
Patches:
dont-increment-session-version-in-2xx-after-183.patch uploaded by NITESH BANSAL (License #6418)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a global option in chan_sip to allow it to continue
attempting registration if a 403 is received, clearing the cached nonce
and treating it as a non-fatal response. Normally, this would cause
registration attempts to that endpoint to stop.
(closes issue ASTERISK-17138)
Review: https://reviewboard.asterisk.org/r/2874/
Reported by: Rudi
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399794 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, Asterisk would incorrectly use the previous endpoint
addresses in SDP in spite of providing its own port. T38 is never meant to
be done through directmedia and Asterisk should always be in the media path
for these streams.
(closes issue ASTERISK-17273)
Reported by: Kevin Stewart
(closes issue ASTERISK-18706)
Reported by: Jeremy Kister
Review: https://reviewboard.asterisk.org/r/2853/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive a 200 OK without SDP, we will now check to see if
the remote address has been established for that channel's RTP
session and if the to tag for that channel has changed from
the most recent to tag in a response less than 200.
If either a change has been made since the last to-tag was
received or the remote address is unset, then we will drop
the call.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/diff/#index_header
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398835 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397756 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397710 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397204 65c4cc65-6c06-0410-ace0-fbb531ad65f3
