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
When a DAHDI device is removed at run-time it sends the event
DAHDI_EVENT_REMOVED on each channel. This is intended to signal the
userspace program to close the respective file handle, as the driver of
the device will need all of them closed to properly clean-up.
This event has long since been handled in chan_dahdi (chan_zap at the
time). However the event that is sent on a D-Channel of a "PRI" (ISDN)
span simply gets ignored.
This commit adds handling for closing the file descriptor (and shutting
down the span, while we're at it).
It also adds a CLI command 'pri destroy span <N>' to destroy the span
and its DAHDI channels.
Backported from trunk/12.
Review: https://reviewboard.asterisk.org/r/726/
........
Merged revisions 394552 394567 from http://svn.asterisk.org/svn/asterisk/trunk
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@407817 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@407678 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
This restricts direct usage of global oseq so that all accesses are
locked and threads are not racing to get oseq values that they did not
claim.
This also fixes a build error in res_pktccops under dev mode.
(closes issue ASTERISK-23100)
Reported by: adomjan
Patch by: adomjan
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@406037 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
dahdi show channels output slices the callerid (which is dnid copied over on
PRI channels). If the channel naming structures look like:
'DAHDI/i1/1408409XXXX-6'
then the output slices 1408409XXXX down to 1408409XXX. This patch just opens
it up to 15 chars so you can see the whole thing.
(closes issue ASTERISK-22918)
Reported by: outtolunc
Patches:
svn_chan_dahdi.c.format12_15.diff.txt uploaded by outtolunc (license 5198)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@404784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk will sometimes core dump during caller id read on analog
channels due to a negative return value from the read() in
my_get_callerid that slips through as a negative length argument to
callerid_feed() if the errno returned by DAHDI is ELAST. This change
ensures that the negative return is treated properly even when it is
ELAST.
(closes issue ASTERISK-22746)
Reported by: Michael Walton
Patches:
chan_dahdi_cid_crash_fix.r401410.patch uploaded by Michael Walton (License 6502)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@402708 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
Also covers ast_app_parse_timelen-fail-zero-length.patch, but the patch was
replaced with one of my own.
(issue ASTERISK-22467)
Reported by: Corey Farrell
Patches:
chan_dahdi-cleanup_push.patch uploaded by coreyfarrell (license 5909)
clicompat-r2.patch uploaded by coreyfarrell (license 5909)
codecs-ilbc-doCPLC.patch uploaded by coreyfarrell (license 5909)
data-cleanup-test-registration.patch uploaded by coreyfarrell (license 5909)
main-asterisk-kill-listener.patch uploaded by coreyfarrell (license 5909)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401704 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects a situation in which a media line was not parsed properly
and resulted in a crash.
(closes issue ASTERISK-21190)
Reported by: adomjan
Patches:
chan_mgcp.c-sscnaf_fix uploaded by adomjan (License 5448)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401537 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
Transferring an analog call using flashhooks generated an unable to get
index WARNING message when the transfer is completed.
* Removed unnecessary analog subchannel shell games when transferring a
call using flashhooks.
Thanks to Tzafrir Cohen for mentioning this in a comment on issue
ASTERISK-22720.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@401378 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
* Remember the swgain setting from CLI "dahdi set swgain" command so the
CLI "dahdi show channel" output will reflect the current setting.
* Updated CLI "dahdi set hwgain" and "dahdi set swgain" documentation.
(issue ASTERISK-22429)
Reported by: Jaco Kroon
Patches:
jira_asterisk_22429_v1.8_v2.patch (license #5621) patch uploaded by rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400907 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
The member reg in the peercnt structure is an unsigned char and peercnt_modify()
is expecting an unsigned char argument which gets assigned to peercnt->reg.
This patch fixes that by casting the integer argument being passed to
peercnt_modify to unsigned char.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@400314 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
The PRI and SS7 link control threads are not stopped correctly when the
chan_dahdi.so module is unloaded. The link control threads pri_dchannel()
and ss7_linkset() are not awakened from a poll() to cancel the thread.
* Added a SIGURG signal after requesting the thread cancel to break the
link control thread poll() immediately.
For SS7 it was slightly worse, the link poll() timeout would always be
whatever was the last libss7 scheduled event time used. If no libss7
scheduled event was pending, the thread could run more often than
necessary.
* Set nextms to 60 seconds for the ss7_linkset() poll() if there is no
other libss7 scheduled event.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399818 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
* Clean up some twisted code in the iax2_bridge() loop.
* Add AST_CONTROL_VIDUPDATE and AST_CONTROL_SRCCHANGE to a list of frames
to prevent the native bridge loop from breaking.
* Passing the AST_CONTROL_T38_PARAMETERS frame should also allow FAX over
a native IAX2 bridge.
(issue ABE-2912)
Review: https://reviewboard.asterisk.org/r/2870/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399697 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
When a new IAX2 client registers, the astdb database is updated with the
value of minregexpire defined in iax.conf instead of using the expiry time
that is provided by the client. The provided expiry time of the client is
updated after inserting the astdb entry. As a consequence, restarting or
reloading asterisk creates clients whose registration may expire before
they reregister. The clients are therefore unavailable after minregexpire
seconds until they reregister.
* Move updating of the expiry time to before inserting into the astdb.
(closes issue ASTERISK-22504)
Reported by: Stefan Wachtler
Patches:
chan_iax2.c.patch (license #6533) patch uploaded by Stefan Wachtler
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@399158 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
* Reduce indentation in __attempt_transmit().
* Don't update the static last error time variable every time in
__schedule_action() and socket_read().
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix stray reference to idle_list in cleanup_thread_list(). This may be
the reason for the note in iax2_process_thread() about threads not being
removed from the task lists.
* Move cleanup_thread_list(&idle_list) to after the other lists are
cleaned up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix bridgecallno deadlock avoidance. When doing deadlock avoidance, you
need to retest the status of values for each loop to see if you still need
the lock for bridgecallno.
* As a safety check, after acquiring the bridgecallno lock you should
check if iaxs[bridgecallno] is NULL just like the current callno checks.
* Move setting thread->iostate to IAX_IOSTATE_IDLE to after processing any
deferred frames to ensure that the iostate is IDLE when it is placed back
into the idle list. defer_full_frame() tries to ensure
iax2_process_thread() wakes up to process the frame.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398379 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the misdn debug output to remote consoles. chan_misdn uses
ast_console_puts() which doesn't know about verbose levels. Better to use
ast_verbose() instead. Without this patch the misdn debug messages are
appended to the verbose level which ever was set by the message sent to
the console before, i.e. any undefined level.
(closes issue AST-1218)
Reported by: Guenther Kelleter
Patches:
misdnlog.patch (license #6372) patch uploaded by Guenther Kelleter
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@398235 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
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@397525 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
