https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r324237 | twilson | 2011-06-20 12:33:07 -0500 (Mon, 20 Jun 2011) | 12 lines
Ignore media offers with a port of 0
Section 5.1 of RFC3264 states:
A port number of zero in the offer indicates that the stream is offered
but MUST NOT be used.
(closes issue ASTERISK-17845)
Reported by: jacco
Patches:
issue19281_2.patch uploaded by jacco (license 1277)
Tested by: jacco, twilson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@324238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r323371 | jrose | 2011-06-14 11:38:43 -0500 (Tue, 14 Jun 2011) | 12 lines
Changes contact use in build_peer to use the FORCE_RPORT flag instead of RPORT_PRESENT
It turned out that this was causing NAT=Yes to always use rport when present which was
against 1.6.2 behavior and the check itself was redundant since the only way this
segment of code could be reached was if RPORT_PRESENT was already evaluated as true
earlier.
(closes issue ASTERISK-17789)
Reported by: byronclark
Patches:
use_sip_nat_force_rport.patch uploaded by byronclark (license 1200)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@323372 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Autoanswer added to skinny based on incoming chan var SKINNY_AUTOANSWER.
Initial value must be the time to autoanswer in ms, then optionally :BEEP
to play a tone when answered and :MUTE to mute the mic when answering.
eg 3000:MUTE:BEEP will ring for 3 secs, then answer, mute the mic, and
play a beep. just 3000 would answer afer 3 secs of ringing with no
beep and full two way audio.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@322544 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The do_monitor seemed to be there for task scheduling and network monitoring. However, the network monitoring has a dedicated thread so the ast_io_wait was basically just a usleep as it didn't actually seem to be monitoring anything.
Review: https://reviewboard.asterisk.org/r/1256/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@322381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r322322 | irroot | 2011-06-08 08:18:38 +0200 (Wed, 08 Jun 2011) | 18 lines
Make handle_request_publish do dialog expiration and destruction.
This patch fixes handle_request_publish so that it does dialog expiration and destruction.
Without this patch the incoming PUBLISH requests will get stuck in the dialog list.
Restarting asterisk is the only way to remove them.
Personal observation on one system the server hung up while looping through the channels
rendering asterisk unusable and all sip phones unregisterd when they try reregister
more requests are added.
(closes issue #18898)
Reported by: gareth
Tested by: loloski, Chainsaw, wimpy, se, kuj, irroot
Jira: https://issues.asterisk.org/jira/browse/ASTERISK-17915
Review: https://reviewboard.asterisk.org/r/1253
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@322323 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Don't send all messages to 's'. Get the destination from the request URI.
(Found using automated test cases).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321617 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk now has protocol independent support for processing text messages
outside of a call. Messages are routed through the Asterisk dialplan.
SIP MESSAGE and XMPP are currently supported. There are options in sip.conf
and jabber.conf that enable these features.
There is a new application, MessageSend(). There are two new functions,
MESSAGE() and MESSAGE_DATA(). Documentation will be available on
the project wiki, wiki.asterisk.org.
Thanks to Terry Wilson for the assistance with development and to David Vossel
for helping with some additional testing.
Review: https://reviewboard.asterisk.org/r/1042/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321546 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r321155 | markm | 2011-05-26 17:48:45 -0400 (Thu, 26 May 2011) | 10 lines
Fixed build problem with dev mode enabled, which was caused by commit 321100. Reformulated patch to be more generic.
Moved the sip uri parse variable initalization to parse_uri_full in reqresp_parser.c. This will ensure that any use of parse uri will have null output variables if the parse fails.
(closes issue #19346)
Reported by: kobaz
Tested by: kobaz,JonathanRose
Review: [full review board URL with trailing slash]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r321100 | markm | 2011-05-26 16:09:35 -0400 (Thu, 26 May 2011) | 11 lines
ast_sockaddr_resolve() in netsock2.c may deref a null pointer
Added a null check in netsock2 ast_sockaddr_resolve() as well as added default initalizers in chan_sip parse_uri_legacy_check() to make sure that invalid uris will make null (and not undefined) user,pass,domain,transport variables
(closes issue #19346)
Reported by: kobaz
Patches:
netsock2.patch uploaded by kobaz (license 834)
Tested by: kobaz, Marquis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@321101 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320883 | rmudgett | 2011-05-25 17:25:18 -0500 (Wed, 25 May 2011) | 17 lines
Native SIP CCSS sends bad CC cancel SUBSCRIBE message.
The SUBSCRIBE message used to cancel a CC request has incorrect To/From
SIP headers. They are reversed and the dialog tags are the same when they
should not be. If pedantic mode was disabled, then the cancel would have
succeeded despite the incorrect message.
* The SIP_OUTGOING flag was not set correctly for the dialog and I had to
move some CC subscribe handling code as a result.
* Initialized the dialog subscribed type to CALL_COMPLETION earlier. If a
CC request SUBSCRIBE message comes in and the CC instance is not found,
the 404 response was duplicated.
JIRA AST-568
JIRA SWP-3493
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320884 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r320180 | mnicholson | 2011-05-20 13:48:46 -0500 (Fri, 20 May 2011) | 16 lines
This commit modifies the way polling is done on TLS sockets.
Because of the buffering the TLS layer does, polling is unreliable. If poll is
called while there is data waiting to be read in the TLS layer but not at the
network layer, the messaging processing engine will not proceed until something
else writes data to the socket, which may not occur. This change modifies the
logic around TLS sockets to only poll after a failed read on a non-blocking
socket. This way we know that there is no data waiting to be read from the
buffering layer.
(closes issue #19182)
Reported by: st
Patches:
ssl-poll-fix3.diff uploaded by mnicholson (license 96)
Tested by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@320181 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r319938 | jrose | 2011-05-20 08:28:24 -0500 (Fri, 20 May 2011) | 12 lines
Adds legacy_useroption_parsing to address interoperability concerns.
With the new option engaged, Asterisk should interpret user fields with useroptions
contained within the userfield of the uri by stripping them out of the original message
whenever a semicolon is encountered in the userfield string.
(closes issue #18344)
Reported by: danimal
Tested by: jrose
Review: https://reviewboard.asterisk.org/r/1223/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r319654 | twilson | 2011-05-18 16:15:58 -0700 (Wed, 18 May 2011) | 22 lines
Merged revisions 319653 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r319653 | twilson | 2011-05-18 16:11:57 -0700 (Wed, 18 May 2011) | 15 lines
Merged revisions 319652 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r319652 | twilson | 2011-05-18 16:04:35 -0700 (Wed, 18 May 2011) | 8 lines
Make sure everyone gets an unhold when a transfer succeeds
Some phones, like the Snom phones, send a hold to the transfer target after
before sending the REFER. We need to make sure that we unhold the parties
that are being connected after the masquerade. If Local channels with the /nm
option are used when dialing the parties, hold music would still be playing on
the transfer target, even after being connected with the transferee.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319661 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r319552 | twilson | 2011-05-18 13:22:36 -0700 (Wed, 18 May 2011) | 11 lines
Unbreak the storing of registrations for restart
The fix for issue 18882 broke retrieving non-realtime peers from the ast_db
on restart/reload. This patch tries to unbreak things while leaving the intent
of the original fix intact.
(closes issue #19318)
Reported by: remiq
Patches:
diff.txt uploaded by twilson (license 396)
Tested by: lmadsen, remiq
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319564 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r319469 | rmudgett | 2011-05-17 16:57:56 -0500 (Tue, 17 May 2011) | 22 lines
Merged revision 319468 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r319468 | rmudgett | 2011-05-17 16:49:31 -0500 (Tue, 17 May 2011) | 15 lines
The mISDN HDLC mode is prevented on dialed channels.
The use of mISDN HDLC mode is prevented if the mISDN dial technology
option 'h1' is used when config option astdtmf=yes.
There is a bug in channels/misdn/isdn_lib.c which prevents the use of HDLC
mode. Instead of setting the channel to HDLC mode it is set to
transparent(no dsp, no hdlc), although hdlc is not "no hdlc". I.e the
logging message is correct, but the if condition is not.
Make check the nodsp and hdlc flags.
JIRA ABE-2787
JIRA SWP-3437
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The NEC SV8300 rejects the Q931_IE_TIME_DATE for Q.SIG.
Add option to specify if and how much of the current time is put in
Q931_IE_TIME_DATE.
* Send date/time ie never.
* Send date/time ie date only.
* Send date/time ie date and hour.
* Send date/time ie date, hour, and minute.
* Send date/time ie date, hour, minute, and second.
* Send date/time ie default: Libpri will send date and hhmm only when in
NT PTMP mode to support ISDN phones.
(closes issue #19221)
Reported by: kenner
JIRA SWP-3396
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Probably haven't been working for a couple of years. May still need
some more love, but they are now working, both as a hint device and
monitoring a hint. Changes centre around the long ago change
to remove the requirement for a device name in a skinny line, and
changes to the transmit_* functions.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319316 65c4cc65-6c06-0410-ace0-fbb531ad65f3
state of the channel reverts to unknown this should be rejected.
this is important for negotiating T.38 gateway see #13405
This patch adds a option T38_REJECTED that behaves as T38_DISABLED except it reports state rejected.
Trivial Change to res_fax to honnor UNAVAILABLE and REJECTED states.
(closes issue #18889)
Reported by: irroot
Tested by: irroot, darkbasic, mnicholson
Review: https://reviewboard.asterisk.org/r/1115
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When called, activatesub first cleans up the active sub and then
handles the sub passed. dialandactivatesub first sets sub->exten
and then calls activatesub. Revise handle_offhook to utilise the
callid sent to chan_skinny. Some other minor fixes especially around
d->hookstate (which still needs some more work).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@319024 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There were some issues where if a simple switch was cancelled and a
new switch started before the first had timed out where the d->exten
would be used for both subchannels. This was bad leading to possible
invalid extensions if some digits had been entered in the abandoned
simple switch and the second one was completed before the first timed
out, or the second would be cancelled because d->exten would be set to
nothing on the time out of the first.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318833 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318783 | rmudgett | 2011-05-12 20:47:05 -0500 (Thu, 12 May 2011) | 14 lines
PRI early media won't ring.
And another way to pass early media. Don't indicate that there is inband
information present, just assume that the B channel is connected.
* Restore clearing the dialing flag Rx squelch unconditionally when a
PROCEEDING message comes in.
(closes issue #19268)
Reported by: tbsky
Patches:
issue19268_v1.8.patch uploaded by rmudgett (license 664)
Tested by: tbsky
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318671 | alecdavis | 2011-05-13 10:52:08 +1200 (Fri, 13 May 2011) | 30 lines
Fix directed group pickup feature code *8 with pickupsounds enabled
Since 1.6.2, the new pickupsound and pickupfailsound in features.conf cause many issues.
1). chan_sip:handle_request_invite() shouldn't be playing out the fail/success audio, as it has 'netlock' locked.
2). dialplan applications for directed_pickups shouldn't beep.
3). feature code for directed pickup should beep on success/failure if configured.
Created a sip_pickup() thread to handle the pickup and playout the audio, spawned from handle_request_invite.
Moved app_directed:pickup_do() to features:ast_do_pickup().
Functions below, all now use the new ast_do_pickup()
app_directed_pickup.c:
pickup_by_channel()
pickup_by_exten()
pickup_by_mark()
pickup_by_part()
features.c:
ast_pickup_call()
(closes issue #18654)
Reported by: Docent
Patches:
ast_do_pickup_1.8_trunk.diff.txt uploaded by alecdavis (license 585)
Tested by: lmadsen, francesco_r, amilcar, isis242, alecdavis, irroot, rymkus, loloski, rmudgett
Review: https://reviewboard.asterisk.org/r/1185/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consolidate the functions and add some debugging info. Allows to be
able to set a substate without explicitly knowing what the state is.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318635 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Add the setsubstate_onhook to complete the initial substate handling
procedures. Added dumpsub(sub, forcehangup) which is the common way of
calling setsubstate_onhook. Dumpsub attempts to activate another sub
after setting the current one onhook.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318600 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r318549 | twilson | 2011-05-11 13:39:48 -0500 (Wed, 11 May 2011) | 27 lines
Merged revisions 318548 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r318548 | twilson | 2011-05-11 12:15:39 -0500 (Wed, 11 May 2011) | 19 lines
Clean up several chan_sip reference leaks
Several situations in the code could lead to peers or sip_pvt references
being leaked. This would cause RTP ports to never be destroyed (leading
to exhaustion of all available RTP ports) and memory leaks.
The original patch for this issue from rgagnon was the result of an
obscene amount of testing and hard work, for which I am very grateful. I
did some cleanup and added a few additional refcount fixes that I found.
(closes issue #17255)
Reported by: kvveltho
Patches:
tag-1.6.2.17-r309252-sip-dos-mem-leak-fix.diff uploaded by rgagnon (license 1202)
Tested by: rgagnon, twilson, wdoekes, loloski
Review: https://reviewboard.asterisk.org/r/1101/
Review: https://reviewboard.asterisk.org/r/1207/
Review: https://reviewboard.asterisk.org/r/1210/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r318499 | rmudgett | 2011-05-10 18:41:08 -0500 (Tue, 10 May 2011) | 15 lines
Unable to pickup DAHDI/PRI call because call state is reported as DIALING.
The channel state is not updated to RINGING when an ALERTING message is
received. Regression caused when sig_pri.c (also sig_ss7.c) extracted
from chan_dahdi.c.
* Added missing channel state update to RINGING when the
AST_CONTROL_RINGING frame is queued for ISDN and SS7.
(closes issue #19257)
Reported by: alecdavis
Patches:
issue19257_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r318337 | twilson | 2011-05-09 15:23:15 -0500 (Mon, 09 May 2011) | 18 lines
Merged revisions 318331 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r318331 | twilson | 2011-05-09 15:04:41 -0500 (Mon, 09 May 2011) | 12 lines
Don't offer video to directmedia callee unless caller offered it as well
Make sure that when directmedia is enabled, that video is not offered to the
callee even if it supports it. p->vrtp will not exist since the caller didn't
offer video.
(closes issue #19195)
Reported by: one47
Patches:
sip_cant_add_video_rtp uploaded by one47 (license 23)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r318231 | rmudgett | 2011-05-09 11:57:18 -0500 (Mon, 09 May 2011) | 41 lines
Don't get early media for ISDN on outgoing calls.
It looks to be a long-standing misinterpretation of the progress indicator
ie values:
1 - Call is not end-to-end ISDN; further call progress information may be
available in-band.
8 - In-band information or an appropriate pattern is now available.
Only value 8 is handled by chan_dahdi/sig_pri. The 1 value is not handled
as early media probably because the meaning of the second half of it's
description was overlooked.
* Test to see if either PRI_PROG_CALL_NOT_E2E_ISDN(1) or
PRI_PROG_INBAND_AVAILABLE(8) bits are set to open the media path.
(closes issue #18868)
Reported by: isrl
Patches:
issue18868_19246_v1.8.patch uploaded by rmudgett (license 664)
Tested by: satish_lx
..........
No inband progress on PRI_EVENT_RINGING even if inband flag set.
My ISDN-PRI provider sends an ALERTING with "Inband information or
appropriate pattern now available", but Asterisk only generates and passes
the RING to the SIP extension, not the inband message. Unfortunately, the
inband message is not a ringback tone but a prompt that says the number is
not in service. The SIP extension then hears two rings and the call is
hungup which confuses the caller.
* Post an AST_CONTROL_PROGRESS as well as opening the media path if inband
audio is indicated with an ALERTING message.
(closes issue #19246)
Reported by: cristiandimache
Patches:
issue19246_v1.8.patch uploaded by rmudgett (license 664)
Tested by: cristiandimache
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318232 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a call is made to a line that already has a call and the device is
offhook (ie activeish call), the call is set to CALLWAIT rather than RINGIN.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@318106 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Long time coming, finally moving the hookstate from line to device.
This may fix some issues where a device has multiple lines. Previously
we had to run through all lines on a device to see if it was actually
onhook or not.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317996 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317867 | russell | 2011-05-06 15:01:16 -0500 (Fri, 06 May 2011) | 10 lines
chan_sip: Destroy variables on a sip_pvt before copying vars from the sip_peer.
Don't duplicate variables on the sip_pvt. Just reset the variable list each
time.
(closes issue #19202)
Reported by: wdoekes
Patches:
issue19202_destroy_challenged_invite_chanvars.patch uploaded by wdoekes (license 717)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317865 | russell | 2011-05-06 14:46:49 -0500 (Fri, 06 May 2011) | 11 lines
chan_sip: fix a deadlock in check_rtp_timeout.
Don't block doing silly deadlock avoidance. Just return and try again later.
The funciton gets called often enough that it's fine. Also, this change was
already made in trunk.
(closes issue #18791)
Reported by: irroot
Patches:
chan_sip.rtptimeout.patch uploaded by irroot (license 52)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317670 | rmudgett | 2011-05-06 11:19:18 -0500 (Fri, 06 May 2011) | 22 lines
Fix SIP connected line updates.
This patch fixes a couple SIP connected line update problems:
1) The connected line needs to be updated when the initial INVITE is sent
if there is a peer callerid configured. Previously, the connected line
information did not get reported until the call was connected so SIP could
not report connected line information in ringing or progress messages.
2) The connected line should not be updated on initial connect if there is
no connected line information. Previously, all it did was wipe out any
default preset CONNECTEDLINE information set by the dialplan with empty
strings.
(closes issue #18367)
Reported by: GeorgeKonopacki
Patches:
issue18367_v1.8.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
Review: https://reviewboard.asterisk.org/r/1199/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317671 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317478 | russell | 2011-05-05 17:53:45 -0500 (Thu, 05 May 2011) | 12 lines
Fix some consistency issues with jitterbuffer config.
Store the defaults noted in the sample config files in the jitterbuffer config
data structure. This makes the CLI commands that output these settings show
the right thing. Also only show the settings that are relevant in the settings
CLI commands, based on which jitterbuffer is selected and whether it's enabled.
(closes issue #19083)
Reported by: rgagnon
Patches:
issue-19083-trunk-r313139.diff uploaded by rgagnon (license 1202)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
skinny_hold moved to setsubstate_hold and skinny_unhold integrated into
setsubstate_connected. Removed sub->onhold and replaced with
SUBSTATE_HOLD.
Also fixed inbound call answering by queueing an AST_CONTROL_ANSWER on
answering a SUBSTATE_RINGIN sub (was a typo).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317283 | jrose | 2011-05-05 14:09:13 -0500 (Thu, 05 May 2011) | 10 lines
Resolves a deadlock that occurs during sip_new
This is based on an uncommitted patch by jpeeler for the issue. Instead of
relocking and then unlocking the channel though, we keep the lock on the channel
until we are finished doing what we need to the channel.
(closes issue #18441)
Reported by: Alric
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r317281 | russell | 2011-05-05 13:39:44 -0500 (Thu, 05 May 2011) | 29 lines
Merged revisions 317255 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r317255 | russell | 2011-05-05 13:29:53 -0500 (Thu, 05 May 2011) | 22 lines
Merged revisions 317211 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r317211 | russell | 2011-05-05 13:20:29 -0500 (Thu, 05 May 2011) | 15 lines
chan_sip: fix broken realtime peer count, fix memory leak
This patch addresses two bugs in chan_sip:
1) The count of realtime peers and users was off. The increment checked the
value of the caching option, while the decrement did not.
2) Add a missing regfree() for a regex.
(closes issue #19108)
Reported by: vrban
Patches:
missing_regfree.patch uploaded by vrban (license 756)
sip_object_counter.patch uploaded by vrban (license 756)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r317196 | mnicholson | 2011-05-05 13:02:52 -0500 (Thu, 05 May 2011) | 8 lines
Set SO_KEEPALIVE on SIP TCP sockets so that they eventually go away when a peer
abruptly disappears. This mostly occurs after a successful registration.
(closes issue #17544)
Reported by: marcelloceschia
Patches:
(modified) tcptls.patch uploaded by st (license 907)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317198 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move handling of both state handling from skinny_indicate to it's own sub.
Also, modified behaviour to not hangup the sub and let the dialplan
have a chance in doing what it wants for congestion. Added various states to
substate2str and added these states where applicable for other set_substate_
procs.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@317026 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move handling of setting busy state from skinny_indicate to it's own sub.
Also, modified behaviour to not hangup the sub and let the dialplan
have a chance in doing what it wants (eg busy(10); hangup() in the dialplan
now gives a busy indication for 10 secs and then hangs up.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316994 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Renamed previous setsubstate_ringout to setsubstate_dialing for a state
when attempting to dial a number, substate ringout now for when core
has indicated that the channel is actually ringing on the other end.
Also added substate2str for debugging purposes.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r316617 | dvossel | 2011-05-04 08:44:41 -0500 (Wed, 04 May 2011) | 19 lines
Merged revisions 316616 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r316616 | dvossel | 2011-05-04 08:40:41 -0500 (Wed, 04 May 2011) | 12 lines
Fixes session-timers=refuse not being enforced for *caller*
During handle_request_invite, the session timer mode was retrieved from
a cached variable. This patch forces a peer lookup of the session timer
mode in the case of an incoming invite.
(closes issue #18804)
Reported by: wdoekes
Patches:
issue18804_session_timer_refuse_caller.patch uploaded by wdoekes (license 717)
issue_18804_v2.diff uploaded by dvossel (license 671)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316618 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added setsubstate_ringin. skinny_call now calls sss_ringin rather than inline.
Fixed previous issue so that setsubstate_connected now use SUBSTATE_RINGIN
to determine is an AST_CONTROL_ANSWER should be queued.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316584 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cosolidated the code so that skinny_answer now uses the setsubstate procedures
rather than doing the handling inline.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cosolidated the working out of the callinfo to be sent into
transmit_callinfo. Replaced ambiguous sub->outgoing with calldirection
which can be SKINNY_INCOMING or SKINNY_OUTGOING (same value as the
skinny protocol).
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The original implementation of this did the merging of all contexts with the
same name in the realtime layer, but that implementation severely breaks
drivers which use the same context name (e.g. iax.conf, type={peer,user}).
Therefore, the implementation needs to do the merging for particular entries
only, based upon what contexts would allow that in the channel driver itself.
This implementation is for chan_sip only, but others could be added in the
future.
(closes issue #17957)
Reported by: marcelloceschia
Patches:
chan-sip_parsing-general_branch162.patch uploaded by marcelloceschia (license 1079)
Tested by: tilghman
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r316224 | rmudgett | 2011-05-03 14:18:30 -0500 (Tue, 03 May 2011) | 16 lines
The dahdi_hangup() call does not clean up the channel fully.
After dahdi_hangup() has supposedly hungup an ISDN channel there is still
traffic on the S0-bus because the channel was not cleaned up fully.
Shuffled the hangup code to include some missing cleanup. Also fixed some
code formatting in the area. I think the primary missing clean up code
was the call to tone_zone_play_tone() to turn off any active tones on the
channel.
(closes issue #19188)
Reported by: jg1234
Patches:
issue19188_v1.8.patch uploaded by rmudgett (license 664)
Tested by: jg1234
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316240 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r316217 | dvossel | 2011-05-03 13:59:06 -0500 (Tue, 03 May 2011) | 9 lines
Never put the Require: timer header in an Invite.
This has already been discussed and should have been resolved earlier. View
revsion 285565's log for more information about why it is important to not
put timer in the Require header.
(closes issue #18704)
Reported by: mfrager
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@316218 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r315894 | mnicholson | 2011-04-27 14:14:27 -0500 (Wed, 27 Apr 2011) | 28 lines
Merged revisions 315893 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r315893 | mnicholson | 2011-04-27 14:03:05 -0500 (Wed, 27 Apr 2011) | 21 lines
Merged revisions 315891 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r315891 | mnicholson | 2011-04-27 13:57:56 -0500 (Wed, 27 Apr 2011) | 14 lines
Fix our compliance with RFC 3261 section 18.2.2.
This change optimizes the free_via() function and removes some redundant null
checking. It also fixes compliance with RFC 3261 section 18.2.2 by always using
the port specified in the Via header for routing responses (even when maddr is
not set). Also the htons() function is now used when setting the port.
Additional documentation comments have been added in various places to make the
logic in the code clearer.
(closes issue #18951)
Reported by: jmls
Patches:
issue18951_set_proper_port_from_via.patch uploaded by wdoekes (license 717) (modified)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r315446 | russell | 2011-04-26 12:40:23 -0500 (Tue, 26 Apr 2011) | 14 lines
chan_local: resolve a deadlock.
This patch resolves a fairly complex deadlock that can occur with the
combination of chan_local and a dialplan switch, such as dynamic realtime
extensions, which pulls autoservice into the picture when doing a dialplan
lookup.
(closes issue #18818)
Reported by: nic
Patches:
issue18818.patch uploaded by jthurman (license 614)
18818.v1.txt uploaded by russell (license 2)
Tested by: nic, jthurman, kterzi, steve-howes, sysreq, IshMalik
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@315447 65c4cc65-6c06-0410-ace0-fbb531ad65f3
PRIShowSpans works like the AMI action DAHDIShowChannels but for PRI
spans. It is similar to the CLI command "pri show spans".
(closes issue #15980)
Reported by: dwery
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r314628 | mnicholson | 2011-04-21 13:24:05 -0500 (Thu, 21 Apr 2011) | 27 lines
Merged revisions 314620 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r314620 | mnicholson | 2011-04-21 13:22:19 -0500 (Thu, 21 Apr 2011) | 20 lines
Merged revisions 314607 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r314607 | mnicholson | 2011-04-21 13:19:21 -0500 (Thu, 21 Apr 2011) | 14 lines
Added limits to the number of unauthenticated sessions TCP based protocols are allowed to have open simultaneously. Also added timeouts for unauthenticated sessions where it made sense to do so.
Unrelated, the manager interface now properly checks if the user has the "system" privilege before executing shell commands via the Originate action.
AST-2011-005
AST-2011-006
(closes issue #18787)
Reported by: kobaz
(related to issue #18996)
Reported by: tzafrir
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314666 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r314550 | twilson | 2011-04-20 17:23:04 -0700 (Wed, 20 Apr 2011) | 13 lines
Merged revisions 314549 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r314549 | twilson | 2011-04-20 17:17:34 -0700 (Wed, 20 Apr 2011) | 6 lines
Don't allocate more space than necessary for a sip_pkt
This extra allocation is a hold-over from when pkt->data was a
character array. Now that it is an allocated string, just allocate
enough for the sip_pkt.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "controlling user number" is always the number of the voice mail box
which is identical with the subscriber number itself. This number which
is listed in the ISDN phone MWI menu cannot be called back to contact the
voice mail box. The controlling user number should be made configurable.
JIRA ABE-2738
JIRA SWP-2846
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r314067 | dvossel | 2011-04-18 10:23:45 -0500 (Mon, 18 Apr 2011) | 22 lines
Remove the need for deadlock avoidance in chan_sip do_monitor.
Deadlock avoidance between the sip pvt and the pvt->owner is
very difficult. Now that channel's are ao2 objects, this complication
is no longer necessary. It turns out the pvt's msg queue only
exists because of deadlock avoidance (when deadlock avoidance fails
msgs were added to a queue to be processed later), so this goes away as well.
The technique used in the new sip_lock_pvt_full() function should
be used as a template for replacing all locations where deadlock
avoidance occurs between a channel tech_pvt and the pvt's owner.
My hope is that this will begin a reversal of the invalid channel
driver locking architecture we have been using for so long.
This patch also resolves an issue where the pvt->owner gets
unlocked during processing the msg queue.
(closes issue #18690)
Reported by: dvossel
Review: https://reviewboard.asterisk.org/r/1182/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r314017 | dvossel | 2011-04-18 08:41:06 -0500 (Mon, 18 Apr 2011) | 17 lines
sip codec negotiation of dynamic rtp payloads error fix
This patch fixes how chan_sip handles dynamic rtp payload types
it does not understand. At the moment if a dynamic payload's mime
type does not match one we understand, the payload does not get
removed from our payload table. As a result of this, the payload
is set to whatever dynamic codec we use internally for that payload
number on outgoing INVITES. This is incorrect.
This patch fixes this by properly checking the rtpmap set function's
return code to make sure it was found. The function can return both
-1 and -2 depending on the source of the mismatch. We were just
checking -1 explicitly.
Review: https://reviewboard.asterisk.org/r/1169/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@314018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r313780 | rmudgett | 2011-04-14 15:59:56 -0500 (Thu, 14 Apr 2011) | 20 lines
Leftover debug messages unconditionally sent to the console.
Executing Dial(DAHDI/1/18475551212,300,) with the echotraining config
option enabled outputs the following debug messages unconditionally:
Dialing T1847555121 on 1
Dialing www2w on 1
* Made debug messages in my_dial_digits() normal debug messages that do
not get output unless enabled.
* Reworded some debug messages in my_dial_digits() to be clearer.
* Replace strncpy() with ast_copy_string() in my_dial_digits() which does
the same job better.
(closes issue #18847)
Reported by: vmikhelson
Tested by: rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313781 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
also went ahead and fixed the problem it introduces before committing.
........
r313435 | jrose | 2011-04-12 13:44:44 -0500 (Tue, 12 Apr 2011) | 1 line
fixing stupid mistake with putting code before variable declaration
........
Merged revisions 313433 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r313432 | jrose | 2011-04-12 13:12:29 -0500 (Tue, 12 Apr 2011) | 14 lines
reload Chan_dahdi memory leak caused by variables
chan_dahdi reloading with variables set via setvar in chan_dahdi.conf would
stay in the dahdi_pvt structs for individual channels (causing them to just
continue adding the new ones to the list) and also there was a memory leak
causes by the conf objects. This patch resolves both of these by using
ast_variables_destroy during the loading process.
(closes issue #17450)
Reported by: nahuelgreco
Patches:
patch.diff uploaded by jrose (license 1225)
Tested by: tilghman, jrose
Review: https://reviewboard.asterisk.org/r/1170/
........
........
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313437 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r313190 | rmudgett | 2011-04-11 10:40:30 -0500 (Mon, 11 Apr 2011) | 39 lines
Merged revisions 313189 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r313189 | rmudgett | 2011-04-11 10:32:53 -0500 (Mon, 11 Apr 2011) | 32 lines
Merged revisions 313188 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r313188 | rmudgett | 2011-04-11 10:27:52 -0500 (Mon, 11 Apr 2011) | 25 lines
Stuck channel using FEATD_MF if caller hangs up at the right time.
The cause was actually a caller hanging up just at the end of the Feature
Group D DTMF tones that setup the call. The reason for this is a "guard
timer" that's implemented using ast_safe_sleep(100). If the caller
happens to hang up AFTER the final tone of the DTMF string but BEFORE the
end of that ast_safe_sleep(), then ast_safe_sleep() will return non-zero.
This causes the code to bounce to the end of ss_thread(), but it does NOT
tear down the call properly.
This should be a rare occurrence because the caller has to hang up at
EXACTLY the right time. Nonetheless, it was happening quite regularly on
the reporter's system. It's not easily reproducible, unless you purposely
increase the guard-time to 2000 or more. Once you do that, you can
reproduce it every time by watching the DTMF debug and hanging up just as
it ends.
Simply add an ast_hangup() before goto quit.
(closes issue #15671)
Reported by: jcromes
Patches:
issue15671.patch uploaded by pabelanger (license 224)
Tested by: jcromes
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313191 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r313001 | alecdavis | 2011-04-07 22:19:31 +1200 (Thu, 07 Apr 2011) | 13 lines
Fix ISDN calling subaddr User Specified Odd/Even Flag
Calculation of the Odd/Even flag was wrong.
Implement correct algo, and set odd/even=0 if data would be truncated.
Only allow automatic calculation of the O/E flag, don't let dialplan influence.
(closes issue #19062)
Reported by: festr
Patches:
bug19062.diff2.txt uploaded by alecdavis (license 585)
Tested by: festr, alecdavis, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@313005 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312949 | rmudgett | 2011-04-05 13:45:24 -0500 (Tue, 05 Apr 2011) | 6 lines
Crash if ISDN span layer 1 is down on initial load.
Regression from -r312575 B channel shifting during negotiation.
* Also combine updating the alarm flag with clearing the resetting flag.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312866 | rmudgett | 2011-04-05 10:38:14 -0500 (Tue, 05 Apr 2011) | 15 lines
Responding to OPTIONS packet with 404 because Asterisk not looking for "s" extension.
The get_destination() function was not using the "s" extension when the
request URI did not specify an extension. This is a regression caused
when the URI parsing code was extracted into parse_uri().
Made get_destination() substitute the "s" extension when the parsed URI
results in an empty string.
(closes issue #18348)
Reported by: shmaize
Patches:
issue18348_v1.8.patch uploaded by rmudgett (license 664)
Tested by: shmaize
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r312575 | rmudgett | 2011-04-04 11:10:50 -0500 (Mon, 04 Apr 2011) | 52 lines
Merged revisions 312574 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r312574 | rmudgett | 2011-04-04 11:00:02 -0500 (Mon, 04 Apr 2011) | 45 lines
Merged revisions 312573 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r312573 | rmudgett | 2011-04-04 10:49:30 -0500 (Mon, 04 Apr 2011) | 38 lines
Issues with ISDN calls changing B channels during call negotiations.
The handling of the PROCEEDING message was not using the correct call
structure if the B channel was changed. (The same for PROGRESS.) The call
was also not hungup if the new B channel is not provisioned or is busy.
* Made all call connection messages (SETUP_ACKNOWLEDGE, PROCEEDING,
PROGRESS, ALERTING, CONNECT, CONNECT_ACKNOWLEDGE) ensure that they are
using the correct structure and B channel. If there is any problem with
the operations then the call is now hungup with an appropriate cause code.
* Made miscellaneous messages (INFORMATION, FACILITY, NOTIFY) find the
correct structure by looking for the call and not using the channel ID.
NOTIFY is an exception with versions of libpri before v1.4.11 because a
call pointer is not available for Asterisk to use.
* Made all hangup messages (DISCONNECT, RELEASE, RELEASE_COMPLETE) find
the correct structure by looking for the call and not using the channel
ID.
(closes issue #18313)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2620
(closes issue #18231)
Reported by: destiny6628
Tested by: rmudgett
JIRA SWP-2924
(closes issue #18488)
Reported by: jpokorny
JIRA SWP-2929
JIRA AST-437 (The issues fixed here are most likely causing this JIRA issue.)
JIRA DAHDI-406
JIRA LIBPRI-33 (Stuck resetting flag likely fixed)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312579 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312509 | rmudgett | 2011-04-01 18:15:42 -0500 (Fri, 01 Apr 2011) | 22 lines
When a call going out an NT-PTMP port gets rejected, Asterisk crashes.
If a call is sent to an ISDN phone that rejects the call with
RELEASE_COMPLETE(cause: call reject(21), or busy(17)) Asterisk crashes.
I could not get my setup to crash. However, I could see the possibility
from a race condition between queuing an AST_CONTROL_BUSY to the core and
then queueing an AST_CONTROL_HANGUP. If the AST_CONTROL_BUSY is processed
before the AST_CONTROL_HANGUP is queued, the ast_channel could be
destroyed out from under chan_misdn.
Avoid this particular crash scenario by not queueing the
AST_CONTROL_HANGUP if the AST_CONTROL_BUSY was queued.
(closes issue #18408)
Reported by: wimpy
Patches:
issue18408_v1.8.patch uploaded by rmudgett (license 664)
Tested by: rmudgett, wimpy
JIRA SWP-2679
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In chan_dahdi.conf, the user can now use length 4 patterns in addition to the usual length 2 patterns. The s
ntax remains the same and the method used to track the pattern history will only change when using the length
4 patterns.
(closes issue SWP-3250)
Code:
jrose
rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312384 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r312022 | rmudgett | 2011-03-31 15:11:40 -0500 (Thu, 31 Mar 2011) | 14 lines
chan_misdn segfaults when DEBUG_THREADS is enabled.
The segfault happens because jb->mutexjb is uninitialized from the
ast_malloc(). The internals of ast_mutex_init() were assuming a nonzero
value meant mutex tracking initialization had already happened. Recent
changes to mutex tracking code to reduce excessive memory consumption
exposed this uninitialized value.
Converted misdn_jb_init() to use ast_calloc() instead of ast_malloc().
Also eliminated redundant zero initialization code in the routine.
(closes issue #18975)
Reported by: irroot
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@312023 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311612 | bbryant | 2011-03-23 17:45:46 -0400 (Wed, 23 Mar 2011) | 9 lines
Fix a possible crash in sip/reqresp_parser.c that is caused by a possible null
value.
(closes issue #18821)
Reported by: cmaj
Patches:
patch-reqresp_parser_sip_uri_domain_cmp_c_locale-crash-1.8.3-rc2.diff.tx
uploaded by cmaj (license 830)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311613 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311558 | twilson | 2011-03-22 19:24:53 -0700 (Tue, 22 Mar 2011) | 5 lines
Don't use static declared buf in parse_name_andor_addr
This function isn't used anywhere yet, but we definitely don't want
to keep the same value for buf between calls to the function.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311352 | jrose | 2011-03-18 11:19:05 -0500 (Fri, 18 Mar 2011) | 10 lines
Changes some print statements/events to use a blank string in place of NULL if the string in question is NULL.
This is supposed to improve Solaris compatibility since Solaris goes berserk when trying to output NULL strings.
(closes issue #18759)
Reported by: bklang
Patches:
null-strings.patch uploaded by bklang (license 919)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311373 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r311297 | rmudgett | 2011-03-17 21:59:05 -0500 (Thu, 17 Mar 2011) | 12 lines
Race condition when ISDN CallRerouting/CallDeflection invoked.
The queued AST_CONTROL_BUSY could sometimes be processed before the
call_forward dial string is recognized.
* Moved setting the call_forwarding dial string after sending a response
to the initiator and just queue an empty frame to wake up the media thread
instead of an AST_CONTROL_BUSY.
* Added check for empty rerouting/deflection number and respond with an
error.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@311298 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309808 | tilghman | 2011-03-06 18:54:42 -0600 (Sun, 06 Mar 2011) | 14 lines
Merged revisions 309251 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309251 | tilghman | 2011-03-01 19:06:02 -0600 (Tue, 01 Mar 2011) | 7 lines
Revert previous 2 commits, and instead conditionally redefine the same macro used in flex 2.5.35 that clashed with our workaround.
Not surprisingly, the workaround was exactly the same code as was provided by
the Flex maintainers, albeit in two different places, in different macros.
This should fix the FreeBSD builds, which have an older version of Flex.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r309445 | rmudgett | 2011-03-04 09:22:04 -0600 (Fri, 04 Mar 2011) | 46 lines
Get real channel of a DAHDI call.
Starting with Asterisk v1.8, the DAHDI channel name format was changed for
ISDN calls to: DAHDI/i<span>/<number>[:<subaddress>]-<sequence-number>
There were several reasons that the channel name had to change.
1) Call completion requires a device state for ISDN phones. The generic
device state uses the channel name.
2) Calls do not necessarily have B channels. Calls placed on hold by an
ISDN phone do not have B channels.
3) The B channel a call initially requests may not be the B channel the
call ultimately uses. Changes to the internal implementation of the
Asterisk master channel list caused deadlock problems for chan_dahdi if it
needed to change the channel name. Chan_dahdi no longer changes the
channel name.
4) DTMF attended transfers now work with ISDN phones because the channel
name is "dialable" like the chan_sip channel names.
For various reasons, some people need to know which B channel a DAHDI call
is using.
* Added CHANNEL(dahdi_span), CHANNEL(dahdi_channel), and
CHANNEL(dahdi_type) so the dialplan can determine the B channel currently
in use by the channel. Use CHANNEL(no_media_path) to determine if the
channel even has a B channel.
* Added AMI event DAHDIChannel to associate a DAHDI channel with an
Asterisk channel so AMI applications can passively determine the B channel
currently in use. Calls with "no-media" as the DAHDIChannel do not have
an associated B channel. No-media calls are either on hold or
call-waiting.
(closes issue #17683)
Reported by: mrwho
Tested by: rmudgett
(closes issue #18603)
Reported by: arjankroon
Patches:
issue17683_18603_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: stever28, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309446 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r309256 | qwell | 2011-03-02 13:54:20 -0600 (Wed, 02 Mar 2011) | 15 lines
Merged revisions 309255 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r309255 | qwell | 2011-03-02 13:53:47 -0600 (Wed, 02 Mar 2011) | 8 lines
Fix usage of "hasvoicemail=yes" and "mailbox=" in users.conf for SIP.
Since it's a duplicate, nothing is going to be done, so delme doesn't need to
be set at all. Strangely, when this was added, this was being set to 1 in 1.6,
and 0 in trunk.
(issue AST-439)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@309257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r308945 | alecdavis | 2011-02-26 07:52:53 +1300 (Sat, 26 Feb 2011) | 21 lines
Fix Deadlock with attended transfer of SIP call
Call path
sip_set_rtp_peer (locks chan then pvt)
transmit_reinvite_with_sdp
try_suggested_sip_codec
pbx_builtin_getvar_helper (locks p->owner)
But by the time p->owner lock was attempted, seems as though chan and p->owner were different.
So in sip_set_rtp_peer, lock pvt first then lock p->owner using deadlocking methods.
(closes issue #18837)
Reported by: alecdavis
Patches:
bug18837-trunk.diff3.txt uploaded by alecdavis (license 585)
Tested by: alecdavis, Irontec, ZX81, cmaj
Review: [https://reviewboard.asterisk.org/r/1126/]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308946 65c4cc65-6c06-0410-ace0-fbb531ad65f3
-Functional changes
1. Dynamic global format list build by codecs defined in codecs.conf
2. SILK 8khz, 12khz, 16khz, and 24khz with custom attributes defined in codecs.conf
3. Negotiation of SILK attributes in chan_sip.
4. SPEEX 32khz with translation
5. SLINEAR 8khz, 12khz, 24khz, 32khz, 44.1khz, 48khz, 96khz, 192khz with translation
using codec_resample.c
6. Various changes to RTP code required to properly handle the dynamic format list
and formats with attributes.
7. ConfBridge now dynamically jumps to the best possible sample rate. This allows
for conferences to take advantage of HD audio (Which sounds awesome)
8. Audiohooks are no longer limited to 8khz audio, and most effects have been
updated to take advantage of this such as Volume, DENOISE, PITCH_SHIFT.
9. codec_resample now uses its own code rather than depending on libresample.
-Organizational changes
Global format list is moved from frame.c to format.c
Various format specific functions moved from frame.c to format.c
Review: https://reviewboard.asterisk.org/r/1104/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@308582 65c4cc65-6c06-0410-ace0-fbb531ad65f3
List the current mapping of DAHDI B channels to Asterisk channel names and
which calls are on hold or call-waiting. Calls on hold or call-waiting
are not associated with any B channel.
JIRA LIBPRI-27
JIRA SWP-2547
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307964 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r307879 | rmudgett | 2011-02-15 10:13:55 -0600 (Tue, 15 Feb 2011) | 37 lines
No response sent for SIP CC subscribe/resubscribe request.
Asterisk does not send a response if we try to subscribe for call
completion after we have received a 180 Ringing. You can only subscribe
for call completion when the call has been cleared.
When we receive the 180 Ringing, for this call, its call-completion state
is 'CC_AVAILABLE'. If we then send a subscribe message to Asterisk, it
trys to change the call-completion state to 'CC_CALLER_REQUESTED'.
Because this is an invalid state change, it just ignores the message. The
only state Asterisk will accept our subscribe message is in the
'CC_CALLER_OFFERED' state.
Asterisk will go into the 'CC_CALLER_OFFERED' when the SIP client clears
the call by sending a CANCEL.
Asterisk should always send a response. Even if its a negative one.
The fix is to allow for the CCSS core to notify a CC agent that a failure
has occurred when CC is requested. The "ack" callback is replaced with a
"respond" callback. The "respond" callback has a parameter indicating
either a successful response or a specific type of failure that may need
to be communicated to the requester.
(closes issue #18336)
Reported by: GeorgeKonopacki
Tested by: mmichelson, rmudgett
JIRA SWP-2633
(closes issue #18337)
Reported by: GeorgeKonopacki
Tested by: mmichelson
JIRA SWP-2634
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307883 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The nativeformats field was being overwritten when it should have been
appended too. This caused some format capabilities to be lost briefly and
some log warnings to be output.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@307433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Pass a MCID request to the bridged channel so the bridged channel can send
it to the network.
The ability to send the MCID request on an ISDN span is enabled with the
new chan_dahdi.conf mcid_send option.
JIRA SWP-2845
JIRA ABE-2736
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306755 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r306619 | twilson | 2011-02-07 14:15:27 -0800 (Mon, 07 Feb 2011) | 24 lines
Merged revisions 306618 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r306618 | twilson | 2011-02-07 13:59:54 -0800 (Mon, 07 Feb 2011) | 17 lines
Merged revisions 306617 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r306617 | twilson | 2011-02-07 13:51:43 -0800 (Mon, 07 Feb 2011) | 10 lines
Don't allow a REFER w/replaces to replace its own dialog
Asterisk currently accepts a REFER with a Refer-To with an embedded Replaces
header that matches the dialog of the REFER. This would be a situation like A
calls B, A calls C, A transfers B to A, which is just silly. This patch makes
the transfer fail instead of making Asterisk freak out and forget to hang other
channels up.
Review: https://reviewboard.asterisk.org/r/1093/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306670 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The display ie handling can be controlled independently in the send and
receive directions with the following options:
* Block display text data.
* Use display text in SETUP/CONNECT messages for name.
* Use display text for COLP name updates (FACILITY/NOTIFY as appropriate).
* Pass arbitrary display text during a call. Sent in INFORMATION
messages. Received from any message that the display text was not used as
a name.
If the display options are not set then the options default to legacy
behavior.
The arbitrary display text is exchanged between bridged channels using the
AST_FRAME_TEXT frame type.
To send display text from the dialplan use the SendText() application when
the arbitrary display text option is enabled.
JIRA SWP-2688
JIRA ABE-2693
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306396 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r306215 | jpeeler | 2011-02-03 17:49:28 -0600 (Thu, 03 Feb 2011) | 20 lines
Fix SIP deadlock involving state changes.
Once again a call to pbx_builtin_getvar_helper (and pbx_builtin_setvar_helper)
has caused locking problems. Both of these functions lock the channel when
the channel argument is passed in!
In this case, the suspected problem (the backtrace makes it impossible to tell)
was the private being locked in sip_set_rtp_peer and then:
transmit_reinvite_with_sdp
try_suggested_sip_codec
pbx_builtin_getvar_helper
(Traced to verify that the fix was only required in 1.8 and later.)
(closes issue #18491)
Reported by: cmaj
Patches:
chan_sip_fix_deadlocks_bug_18491.txt uploaded by cmaj (license 830)
Tested by: cmaj
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306216 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r306127 | twilson | 2011-02-03 13:03:26 -0800 (Thu, 03 Feb 2011) | 23 lines
Merged revisions 306126 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r306126 | twilson | 2011-02-03 12:56:00 -0800 (Thu, 03 Feb 2011) | 16 lines
Merged revisions 306119 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r306119 | twilson | 2011-02-03 12:36:34 -0800 (Thu, 03 Feb 2011) | 9 lines
Set hangup cause in local_hangup
When a call involves a local channel (like SIP -> Local -> SIP), the hangup
cause was not being set. This resulted in SIP channels sometimes getting a
503 error instead of a 486 when the far side sent a busy. In Asterisk 1.8+
this also can cause issues with CCSS that involve a local channel. This patch
sets the hangupcause for one side of the local channel to the other in
local_hangup for outbound calls.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is the foundation of an entire new way of looking at media in Asterisk.
The code present in this patch is everything required to complete phase1 of my
Media Architecture proposal. For more information about this project visit the link below.
https://wiki.asterisk.org/wiki/display/AST/Media+Architecture+Proposal
The primary function of this patch is to convert all the usages of format
bitfields in Asterisk to use the new format and format_cap APIs. Functionally
no change in behavior should be present in this patch. Thanks to twilson
and russell for all the time they spent reviewing these changes.
Review: https://reviewboard.asterisk.org/r/1083/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@306010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r305923 | rmudgett | 2011-02-02 18:24:40 -0600 (Wed, 02 Feb 2011) | 24 lines
Merged revisions 305889 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r305889 | rmudgett | 2011-02-02 18:15:07 -0600 (Wed, 02 Feb 2011) | 17 lines
Merged revisions 305888 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r305888 | rmudgett | 2011-02-02 18:02:43 -0600 (Wed, 02 Feb 2011) | 8 lines
Minor AST_FRAME_TEXT related issues.
* Include the null terminator in the buffer length. When the frame is
queued it is copied. If the null terminator is not part of the frame
buffer length, the receiver could see garbage appended onto it.
* Add channel lock protection with ast_sendtext().
* Fixed AMI SendText action ast_sendtext() return value check.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@305939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r305343 | rmudgett | 2011-01-31 18:01:09 -0600 (Mon, 31 Jan 2011) | 21 lines
Merged revisions 305342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r305342 | rmudgett | 2011-01-31 17:50:10 -0600 (Mon, 31 Jan 2011) | 14 lines
Merged revisions 305341 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r305341 | rmudgett | 2011-01-31 17:45:58 -0600 (Mon, 31 Jan 2011) | 7 lines
Obtain the pri lock for PRI queue counters.
Need to obtain the pri lock when calling pri_dump_info_str() to avoid a
reentrancy problem when calculating the Q.921 Q count statistic.
JIRA AST-484
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@305344 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r305254 | qwell | 2011-01-31 17:07:00 -0600 (Mon, 31 Jan 2011) | 24 lines
Merged revisions 305253 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r305253 | qwell | 2011-01-31 16:59:34 -0600 (Mon, 31 Jan 2011) | 17 lines
Merged revisions 305252 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r305252 | qwell | 2011-01-31 16:56:54 -0600 (Mon, 31 Jan 2011) | 10 lines
Prevent a crash when dialing a technology with no destination (ex: Dial(SIP/))
chan_iax2 and other channel drivers already had code to prevent this. The
attempt that app_dial was making to prevent it was not correct, so I fixed that.
(closes issue #18371)
Reported by: gbour
Patches:
18371.patch uploaded by gbour (license 1162)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@305255 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303962 | twilson | 2011-01-25 16:09:01 -0600 (Tue, 25 Jan 2011) | 30 lines
Merged revisions 303960 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303960 | twilson | 2011-01-25 16:02:42 -0600 (Tue, 25 Jan 2011) | 23 lines
Merged revisions 303906 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303906 | twilson | 2011-01-25 14:50:59 -0600 (Tue, 25 Jan 2011) | 16 lines
Guard against retransmitting BYEs indefinitely
In the case of an attended transfer (A calls B, A atxfers to C) where
A becomes unreachable before replying to Asterisk's BYE, Asterisk can
sometimes retransmit the BYE indefinitely. This is because
__sip_autodestruct tests p->refer && !ast_test_flag(&p->flags[0],
SIP_ALREADYGONE and will then transmit a BYE. When this BYE times out,
it will not ever be marked as ALREADYGONE, so when __sip_autodestruct
is called again, we end up starting the cycle over.
This patch adds a call to sip_alreadygone(pkt->owner) in retrans_pkt
in the case of a BYE that has timed out. This should prevent Asterisk
from trying to transmit new BYE messages in the future.
Review: https://reviewboard.asterisk.org/r/1077/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303963 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r303771 | rmudgett | 2011-01-25 11:49:20 -0600 (Tue, 25 Jan 2011) | 54 lines
Merged revisions 303769 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r303769 | rmudgett | 2011-01-25 11:42:42 -0600 (Tue, 25 Jan 2011) | 47 lines
Merged revisions 303765 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r303765 | rmudgett | 2011-01-25 11:36:50 -0600 (Tue, 25 Jan 2011) | 40 lines
Sending out unnecessary PROCEEDING messages breaks overlap dialing.
Issue #16789 was a good idea. Unfortunately, it breaks overlap dialing
through Asterisk. There is not enough information available at this point
to know if dialing is complete. The ast_exists_extension(),
ast_matchmore_extension(), and ast_canmatch_extension() calls are not
adequate to detect a dial through extension pattern of "_9!".
Workaround is to use the dialplan Proceeding() application early in
non-dial through extensions.
* Effectively revert issue #16789.
* Allow outgoing overlap dialing to hear dialtone and other early media.
A PROGRESS "inband-information is now available" message is now sent after
the SETUP_ACKNOWLEDGE message for non-digital calls. An
AST_CONTROL_PROGRESS is now generated for incoming SETUP_ACKNOWLEDGE
messages for non-digital calls.
* Handling of the AST_CONTROL_CONGESTION in chan_dahdi/sig_pri was
inconsistent with the cause codes.
* Added better protection from sending out of sequence messages by
combining several flags into a single enum value representing call
progress level.
* Added diagnostic messages for deferred overlap digits handling corner
cases.
(closes issue #17085)
Reported by: shawkris
(closes issue #18509)
Reported by: wimpy
Patches:
issue18509_early_media_v1.8_v3.patch uploaded by rmudgett (license 664)
Expanded upon issue18509_early_media_v1.8_v3.patch to include analog
and SS7 because of backporting requirements.
Tested by: wimpy, rmudgett
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For each component, the set of valid BNF expansions defines exactly
which characters may appear unescaped. All other characters MUST be
escaped.
This patch modifies ast_uri_encode() to encode strings in line with this recommendation. This patch also adds an ast_escape_quoted() function which escapes '"' and '\' characters in quoted strings in accordance with section 25.1 of RFC 3261. The ast_uri_encode() function has also been modified to take an ast_flags struct describing the set of rules it should use when escaping characters to allow for it to escape SIP URIs in addition to HTTP URIs and other types of URIs or variations of those two URI types in the future.
The ast_uri_decode() function has also been modified to accept an ast_flags struct describing the set of rules to use when decoding to enable decoding '+' as ' ' in legacy http URLs.
The unit tests for these functions have also been updated.
ABE-2705
Review: https://reviewboard.asterisk.org/r/1081/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@303509 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r302412 | seanbright | 2011-01-19 10:31:39 -0500 (Wed, 19 Jan 2011) | 10 lines
Use appropriate type for requested format in chan_local.
We were passing and storing the requested format as an int instead of format_t
resulting in truncation.
(closes issue #18238)
Reported by: whizemen
Patches:
0018238_speex16.patch uploaded by whizemen (license 1143)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302413 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293493 | twilson | 2010-11-01 09:58:00 -0500 (Mon, 01 Nov 2010) | 14 lines
Only offer codecs both sides support for directmedia
When using directmedia, Asterisk needs to limit the codecs offered to just
the ones that both sides recognize, otherwise they may end up sending audio
that the other side doesn't understand.
(closes issue #17403)
Reported by: one47
Patches:
sip_codecs_simplified4 uploaded by one47 (license 23)
Tested by: one47, falves11
Review: https://reviewboard.asterisk.org/r/967/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@302048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301946 | rmudgett | 2011-01-14 15:09:57 -0600 (Fri, 14 Jan 2011) | 13 lines
Deadlock between dahdi_request() and pri_dchannel() processing an incomming call.
The sig_pri_new_ast_channel() is called with the channel private lock held
when pri_dchannel() calls it and no channel private lock held when
dahdi_request() calls it. The use of pri_grab() in
sig_pri_new_ast_channel() could leave the channel private lock held when
it returns if the lock was not held before calling it.
Make sig_pri_new_ast_channel() just lock the PRI span lock instead of
using pri_grab(). It is safe to do this because dahdi_request() does not
have the channel private lock and the deadlock potential with the PRI span
lock is only between pri_dchannel() and other threads.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301790 | jpeeler | 2011-01-14 11:32:52 -0600 (Fri, 14 Jan 2011) | 42 lines
Resolve deadlock involving REFER.
Two fixes:
1) One must always have the private unlocked before calling
pbx_builtin_setvar_helper to not invalidate locking order since it locks the
channel.
2) Unlock the channel before calling pbx_find_extension, which starts and stops
autoservice during the lookup. The problem scenario as illustrated by the
reporter:
Thread: do_monitor
-----------------------
handle_request_do
handle_incoming
handle_request_refer
ast_parking_ext_valid
pbx_find_extension
ast_autoservice_stop
while (chan_list_state == as_chan_list_state) { usleep(1000); }
Thread: autoservice_run
-----------------------
autoservice_run
chan = ast_waitfor_n
ast_waitfor_nandfds
ast_waitfor_nandfds_classic / simple / complex (depending on your system)
ast_channel_lock(c[x]);
handle_request_do and schedule_process_request_queue locks the owner
if it exists. The autoservice thread is waiting for the channel lock, which
wasn't ever released since the do_monitor thread was waiting for autoservice
operations to complete. Solved by unlocking the channel but keeping a reference
to guarantee safety.
(closes issue #18403)
Reported by: jthurman
Patches:
20110103-blind_deadlock.diff uploaded by jthurman (license 614)
issue18403.patch uploaded by jpeeler (license 325)
Tested by: jthurman
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301791 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r301134 | rmudgett | 2011-01-07 19:11:31 -0600 (Fri, 07 Jan 2011) | 7 lines
The DTMF attended transfer feature cannot callback a chan_dahdi BRI phone.
The DAHDI ISDN channel name is not dialable.
Make a channel name like DAHDI/i3/400-12 dialable when the sequence number
is stripped off of the name.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@301135 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r300714 | rmudgett | 2011-01-05 14:54:21 -0600 (Wed, 05 Jan 2011) | 21 lines
Merged revision 300711 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r300711 | rmudgett | 2011-01-05 13:43:55 -0600 (Wed, 05 Jan 2011) | 14 lines
A call retrieved from hold may wind up with no audio.
If the retrieved call is natively bridged then the call may not have any
audio path. The following warning message is given:
"Failed to add <dfd> to conference <chan>/<chan>: Invalid argument".
* Open the media on a B channel when pri_fixup_principle() moves the call
from a no_b_channel channel to a real channel.
* Added lock protection while pri_fixup_principle() moves a call from one
private structure to another.
* Made some pri_fixup_principle() messages more meaningful.
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300716 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r300301 | twilson | 2011-01-04 11:54:41 -0600 (Tue, 04 Jan 2011) | 29 lines
Merged revisions 300298 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r300298 | twilson | 2011-01-04 11:37:26 -0600 (Tue, 04 Jan 2011) | 22 lines
Merged revisions 300216 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r300216 | twilson | 2011-01-04 11:11:48 -0600 (Tue, 04 Jan 2011) | 15 lines
Don't authenticate SUBSCRIBE re-transmissions
This only skips authentication on retransmissions that are already
authenticated. A similar method is already used for INVITES. This
is the kind of thing we end up having to do when we don't have a
transaction layer...
(closes issue #18075)
Reported by: mdu113
Patches:
diff.txt uploaded by twilson (license 396)
Tested by: twilson, mdu113
Review: https://reviewboard.asterisk.org/r/1005/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300302 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Added the moh_signaling option to specify what to do when the channel's
bridged peer puts the ISDN channel on and off of hold.
Implemented as a FSM to control libpri ISDN signaling when the bridged
peer places the channel on and off of hold with the AST_CONTROL_HOLD and
AST_CONTROL_UNHOLD control frames.
JIRA SWP-2687
JIRA ABE-2691
Review: https://reviewboard.asterisk.org/r/1063/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@300212 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r299405 | rmudgett | 2010-12-21 20:10:39 -0600 (Tue, 21 Dec 2010) | 17 lines
Chan_dahdi sends an empty COLP on the bridged channel.
Chan_dahdi always inserts a connected party IE when you call from one
dahdi channel to another dahdi channel, even if no such information was
received on the 2nd channel. This clears the display of many phones.
* Removed leftover artifact from before the valid flag was added.
* Updated all of the channel's caller id information with the new
connected line information instead of just the string parts.
(closes issue #18508)
Reported by: wimpy
Patches:
issue18508_trunk.patch uploaded by rmudgett (license 664)
Tested by: wimpy, rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299406 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r299353 | mnicholson | 2010-12-21 09:25:03 -0600 (Tue, 21 Dec 2010) | 30 lines
Merged revisions 299242 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r299242 | mnicholson | 2010-12-20 15:25:35 -0600 (Mon, 20 Dec 2010) | 23 lines
Merged revisions 299194,299198,299220 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r299194 | mnicholson | 2010-12-20 14:45:38 -0600 (Mon, 20 Dec 2010) | 6 lines
Respond as soon as possible with a 202 Accepted to refer requests.
This change also plugs a few memory leaks that can occur when parking sip calls.
ABE-2656
........
r299198 | mnicholson | 2010-12-20 15:00:44 -0600 (Mon, 20 Dec 2010) | 2 lines
Remove changes to via processing that were not supposed to go into the last commit.
........
r299220 | mnicholson | 2010-12-20 15:21:39 -0600 (Mon, 20 Dec 2010) | 4 lines
Use ast_free() instead of free()
ABE-2656
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r299248 | mmichelson | 2010-12-20 15:38:30 -0600 (Mon, 20 Dec 2010) | 20 lines
Fix a couple of CCSS issues.
* Make sure to allocate a cc_params structure
when creating autopeers.
* Use sip_uri_cmp when retrieving SIP CC agents
and monitors in case parameters appear in the
URI.
(closes issue #18504)
Reported by: kkm
(closes issue #18338)
Reported by: GeorgeKonopacki
Patches:
18338.diff uploaded by mmichelson (license 60)
Tested by: GeorgeKonopacki
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299249 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, I had added the ast_sched_thread stuff that was a generic scheduler
thread implementation. However, if you used it, it required using different
functions for modifying scheduler contents. This patch reworks how this is
done and just allows you to optionally start a thread on the original scheduler
context structure that has always been there. This makes it trivial to switch
to the generic scheduler thread implementation without having to touch any of
the other code that adds or removes scheduler entries.
In passing, I made some naming tweaks to add ast_ prefixes where they were not
there before.
Review: https://reviewboard.asterisk.org/r/1007/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@299091 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r298539 | tilghman | 2010-12-16 03:28:17 -0600 (Thu, 16 Dec 2010) | 8 lines
Ensure the ipaddr field in realtime is large enough to handle IPv6 addresses.
(closes issue #18464)
Reported by: IgorG
Patches:
realtime_ipv6store.diff uploaded by IgorG (license 20)
(plus a few additional lines by tilghman)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298545 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r298195 | rmudgett | 2010-12-13 11:11:43 -0600 (Mon, 13 Dec 2010) | 33 lines
Merged revisions 298194 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r298194 | rmudgett | 2010-12-13 11:04:41 -0600 (Mon, 13 Dec 2010) | 26 lines
Merged revisions 298193 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r298193 | rmudgett | 2010-12-13 10:56:07 -0600 (Mon, 13 Dec 2010) | 19 lines
Outgoing PRI/BRI calls cannot do DTMF triggered transfers.
Outgoing PRI/BRI calls cannot do DTMF triggered transfers if a PROCEEDING
message is not received. The debug output shows that the DTMF begin event
is seen, but the DTMF end event is missing. When the DTMF begin happens,
the call is muted so we now have one way audio (until a DTMF end event is
somehow seen).
* Made set the proceeding flag when the PRI_EVENT_ANSWER event is
received.
* Made absorb the DTMF begin and DTMF end events if we are overlap dialing
and have not seen a PROCEEDING message.
* Added a debug message when absorbing a DTMF event.
JIRA SWP-2690
JIRA ABE-2697
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@298201 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r297965 | twilson | 2010-12-09 16:18:19 -0600 (Thu, 09 Dec 2010) | 28 lines
Merged revisions 297960 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r297960 | twilson | 2010-12-09 16:10:31 -0600 (Thu, 09 Dec 2010) | 21 lines
Merged revisions 297959 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r297959 | twilson | 2010-12-09 16:00:30 -0600 (Thu, 09 Dec 2010) | 14 lines
Ignore spurious REGISTER requests
If a REGISTER request with a Call-ID matching an existing transaction is received
it was possible that the REGISTER request would overwrite the initreq of the
private structure. This info is used to generate messages for other responses in
the transaction. This patch ignores REGISTER requests that match non-REGISTER
transactions.
(closes issue #18051)
Reported by: eeman
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/1050/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297972 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r297957 | dvossel | 2010-12-09 15:32:20 -0600 (Thu, 09 Dec 2010) | 11 lines
Fixes issue with outbound google voice calls not working.
Thanks to az1234 and nevermind_quack for their input in helping debug the issue.
(closes issue #18412)
Reported by: nevermind_quack
Patches:
fix uploaded by dvossel (license 671)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297958 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r297607 | jpeeler | 2010-12-06 16:06:37 -0600 (Mon, 06 Dec 2010) | 25 lines
Merged revisions 297605 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r297605 | jpeeler | 2010-12-06 16:03:04 -0600 (Mon, 06 Dec 2010) | 18 lines
Merged revisions 297603 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r297603 | jpeeler | 2010-12-06 15:57:15 -0600 (Mon, 06 Dec 2010) | 12 lines
Improve handling of REGISTER requests with multiple contact headers.
The changes here attempt to more strictly follow RFC 3261 section 10.3.
Basically the following will now cause a 400 Bad Response to be returned, if:
- multiple Contact headers are present with one set to expire all bindings ("*")
- wildcard parameter is specified for Contact without Expires header or Expires
header is not set to zero.
ABE-2442
ABE-2443
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297608 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r297075 | jpeeler | 2010-12-01 11:53:13 -0600 (Wed, 01 Dec 2010) | 37 lines
Merged revisions 297073 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r297073 | jpeeler | 2010-12-01 11:52:46 -0600 (Wed, 01 Dec 2010) | 30 lines
Merged revisions 297072 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r297072 | jpeeler | 2010-12-01 11:50:09 -0600 (Wed, 01 Dec 2010) | 23 lines
Fix not stopping MOH when transfered local channel queue member is answered.
The problem here is only present when local channels are used with the MOH
passthru option as well as no optimization (/nm). I will describe the slightly
bizarre scenario that was used to test, where phones B and C are queue members:
Phone A dials into a queue with two members using local channels and the above
options. Phone B answers. Phone A blind transfers phone B into the same queue.
Phone A hangs up. Phone C answers, but phone B didn't stop playing MOH.
In this scenario, the unhold frame that should have gotten to phone B never
arrived due to the masquerade from the blind transfer. This is usually fine
since app_queue manages the starting and stopping of MOH. However, with the
passthrough option enabled when app_queue attempts to stop MOH it tries to do
so on the local channel rather than the real channel. The easiest solution
was to just make sure to send an unhold frame during the transfer since it
wouldn't make sense to have MOH playing after a transfer anyway. This only
modifies SIP transfers, but the other transfers did not seem to be a problem.
If DTMF based transfers were a problem it might be okay to add ast_moh_stop
to finishup, but I didn't want to have to add that unless required.
ABE-2624
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@297076 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r296628 | russell | 2010-11-29 15:26:44 -0600 (Mon, 29 Nov 2010) | 6 lines
Complete some error handling in transmit_publish() in chan_sip.c.
This error handling block caught my eye. It was missing a couple of things,
but it should be safe now. Thanks to mmichelson for the quick peer review
on IRC.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296630 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296582 | rmudgett | 2010-11-29 14:46:03 -0600 (Mon, 29 Nov 2010) | 24 lines
Merged revision 296575 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r296575 | rmudgett | 2010-11-29 14:27:37 -0600 (Mon, 29 Nov 2010) | 13 lines
Invalid mISDN PTMP redirecting signaling as TE towards NT.
The mISDN PTMP redirection signaling (NOTIFY redirecting number and
notification code, SETUP redirecting number) is also sent in PTMP/TE mode.
It should only apply in PTMP/NT mode. The call setup proceeds but the
network (Deutsche Telekom) reacts with ugly ISDN STATUS messages.
Also don't send the redirecting number ie when PTP is also sending the
DivertingLegInformation2 facility. The redirecting number ie is redundant
and the network (Deutsche Telekom) complains about it.
Patches:
abe_2651_v4.patch uploaded by rmudgett (license 664)
JIRA ABE-2651
JIRA SWP-2537
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296585 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r296352 | marquis | 2010-11-26 13:19:02 -0500 (Fri, 26 Nov 2010) | 12 lines
Fix reloading of peer when a user is requested.
Prevent peer reloading from causing multiple MWI subscriptions to be created when using realtime. This had the effect of sending one NOTIFY for every time a sip peer made a call, in one case eventually overwhelming the phone and causing it to reboot.
(closes issue #18342)
Reported by: nivek
Patches:
issue0018342p1.patch uploaded by nivek (license 636)
Tested by: nivek
Review: https://reviewboard.asterisk.org/r/1029/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r296167 | rmudgett | 2010-11-24 16:49:48 -0600 (Wed, 24 Nov 2010) | 57 lines
Merged revisions 296166 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r296166 | rmudgett | 2010-11-24 16:42:45 -0600 (Wed, 24 Nov 2010) | 50 lines
Merged revisions 296165 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r296165 | rmudgett | 2010-11-24 16:41:07 -0600 (Wed, 24 Nov 2010) | 43 lines
Oneway audio to SIP phone from FXS port after FXS port gets a CallWaiting pip.
The FXS connected phone has to have CW/CID support to fail, as it will
send back a DTMF 'A' or 'D' when it's ready to receive CallerID. A normal
phone with no CID never fails. Also the SIP phone does not hear MOH when
the CW call is answered.
The DTMF end frame is suppressed when the phone acknowledges the CW signal
for CID. The problem is the DTMF begin frame needs to be suppressed as
well. The DTMF begin frame is causing SIP to start sending the DTMF RTP
frames. Since the DTMF end frame is suppressed, SIP will not stop sending
those DTMF RTP packets.
* Suppress the DTMF begin and end frames when the channel driver is
looking for DTMF digits.
* Fixed a couple issues caused by not cleaning up the CID spill if you
answer the CW call while it is sending the CID spill.
* Fixed not sending CW/CID spill to the phone when the call is natively
bridged. (Fixed by not using native bridge if CW/CID is possible.)
* Suppress received audio when sending CW/CID spills. The other parties
involved do not need to hear the CW/CID spills and may be confused if the
CW call is for them.
(closes issue #18129)
Reported by: alecdavis
Patches:
issue_18129_v1.8_v3.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, rmudgett
NOTE:
* v1.4 does not have the main problem fixed by suppressing the DTMF start
frames. The other three items fixed are relevant.
* If you really must restore native bridging between analog ports, you
need to disable CW/CID either by configuring chan_dahdi.conf
callwaitingcallerid=no or dialing *70 before dialing the number to
temporarily disable CW.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@296168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r295747 | rmudgett | 2010-11-19 21:11:15 -0600 (Fri, 19 Nov 2010) | 13 lines
One way audio before answering call waiting call on analog port.
* Analog call waiting Caller ID spills could get stuck resulting in one
way audio until the waiting call is answered. This only happens on the
second (and later) call waiting call if the active call is not the first
call.
* The CLI/AMI "dahdi show channel" command could report the wrong channel
information.
Must keep the struct analog_pvt.owner and struct dahdi_pvt.owner pointer
in sync.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295748 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r295516 | rmudgett | 2010-11-19 10:47:11 -0600 (Fri, 19 Nov 2010) | 13 lines
Bring sig_analog extraction more into alignment with orig-trunk/v1.6.2 chan_dahdi.
* Restore SMDI support.
* Fixed initial value of struct analog_pvt.use_callerid. It may get
forced on depending upon other config options.
* Call analog_dnd() instead of manual inlined code.
* Removed unused struct analog_pvt.usedistinctiveringdetection.
* Removed the struct analog_pvt.unknown_alarm flag. It was really the
struct analog_pvt.inalarm flag.
* Use ast_debug() instead of ast_log(LOG_DEBUG).
* Rename several function's index variable to idx.
* Some formatting tweaks.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@295517 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294823 | rmudgett | 2010-11-11 20:45:22 -0600 (Thu, 11 Nov 2010) | 25 lines
Merged revisions 294822 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294822 | rmudgett | 2010-11-11 20:44:12 -0600 (Thu, 11 Nov 2010) | 18 lines
Merged revisions 294821 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294821 | rmudgett | 2010-11-11 20:41:13 -0600 (Thu, 11 Nov 2010) | 11 lines
Asterisk is getting a "No D-channels available!" warning message every 4 seconds.
Asterisk is just whining too much with this message: "No D-channels
available! Using Primary channel XXX as D-channel anyway!".
Filtered the message so it only comes out once if there is no D channel
available without an intervening D channel available period.
(closes issue #17270)
Reported by: jmls
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294824 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r294734 | jpeeler | 2010-11-11 15:58:25 -0600 (Thu, 11 Nov 2010) | 32 lines
Merged revisions 294733 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r294733 | jpeeler | 2010-11-11 15:57:22 -0600 (Thu, 11 Nov 2010) | 25 lines
Merged revisions 294688 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r294688 | jpeeler | 2010-11-11 15:12:27 -0600 (Thu, 11 Nov 2010) | 18 lines
Fix problem with qualify option packets for realtime peers never stopping.
The option packets not only never stopped, but if a realtime peer was not in
the peer list multiple options dialogs could accumulate over time. This
scenario has the potential to progress to the point of saturating a link just
from options packets. The fix was to ensure that the poke scheduler checks to
see if a peer is in the peer list before continuing to poke. The reason a peer
must be in the peer list to be able to properly manage an options dialog is
because otherwise the call pointer is lost when the peer is regenerated from
the database, which is how existing qualify dialogs are detected.
(closes issue #16382)
(closes issue #17779)
Reported by: lftsy
Patches:
bug16382-3.patch uploaded by jpeeler (license 325)
Tested by: zerohalo
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294735 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294349 | rmudgett | 2010-11-09 10:55:32 -0600 (Tue, 09 Nov 2010) | 17 lines
Analog lines do not transfer CONNECTED LINE or execute the interception macros.
Add connected line update for sig_analog transfers and simplify the
corresponding sig_pri and chan_misdn transfer code.
Note that if you create a three-way call in sig_analog before transferring
the call, the distinction of the caller/callee interception macros make
little sense. The interception macro writer needs to be prepared for
either caller/callee macro to be executed. The current implementation
swaps which caller/callee interception macro is executed after a three-way
call is created.
Review: https://reviewboard.asterisk.org/r/996/
JIRA ABE-2589
JIRA SWP-2372
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294351 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r294125 | rmudgett | 2010-11-08 11:16:01 -0600 (Mon, 08 Nov 2010) | 33 lines
valgrind reported references to freed memory during a mISDN hangup collision.
Bad things have been happening in chan_misdn because the chan_misdn
channel private struct chan_list is not protected from reentrancy. Hangup
collisions have be causing read and write accesses to freed memory.
Converted chan_misdn struct chan_list to an ao2 object for its reference
counting feature.
**********
Removed an impediment to converting chan_list to an ao2 object.
The use of the other_ch member in chan_list is shaky at best. It is set
if the incoming and outgoing call legs are mISDN. The use of the other_ch
member goes against the Asterisk architecture and can even cause problems.
1) It is used to disable echo cancellation. This could be bad if the call
is forked and the winning call leg is not mISDN or the winning call leg is
not the last mISDN channel called by the fork. The other_ch would become
a dangling pointer.
2) It is used when the far end is alerting to hear the far end's inband
audio instead of Asterisk's generated ringback tone. This is bad if the
call is forked. You would only hear the last forked mISDN channel and it
may not be ringing yet.
The other_ch would become a dangling pointer if the call is later
transferred.
**********
JIRA SWP-2423
JIRA ABE-2614
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294127 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC3261 section 12 about dialog creation says an INVITE transaction
results in an established dialog once it receives the 200 OK response.
It is possible to receive multiple differing 200 OK responses for a
single outbound INVITE Request, and this should result in establishing
multiple dialogs.
This patch allows for all differing 200 OK responses to an INVITE request
to establish a separate dialog, but only the first dialog is kept. All other
resulting dialogs from the initial request are immediately ACKed and then
immediately terminated with a BYE request.
Review: https://reviewboard.asterisk.org/r/946/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@294083 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293803 | twilson | 2010-11-03 11:05:14 -0700 (Wed, 03 Nov 2010) | 25 lines
Avoid valgrind warnings for ast_rtp_instance_get_xxx_address
The documentation for ast_rtp_instance_get_(local/remote)_address stated that
they returned 0 for success and -1 on failure. Instead, they returned 0 if the
address structure passed in was already equivalent to the address instance
local/remote address or 1 otherwise. 90% of the calls to these functions
completely ignored the return address and passed in an uninitialized struct,
which would make valgrind complain even though the operation was technically
safe.
This patch fixes the documentation and converts the get_xxx_address functions
to void since all they really do is copy the address and cannot fail.
Additionally two new functions
(ast_rtp_instance_get_and_cmp_(local/remote)_address) are created for the 3
times where the return value was actually checked. The
get_and_cmp_local_address function is currently unused, but exists for the sake
of symmetry.
The only functional change as a result of this change is that we will not do an
ast_sockaddr_cmp() on (mostly uninitialized) addresses before doing the
ast_sockaddr_copy() in the get_*_address functions. So, even though it is an
API change, it shouldn't have a noticeable change in behavior.
Review: https://reviewboard.asterisk.org/r/995/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293807 | rmudgett | 2010-11-03 13:35:19 -0500 (Wed, 03 Nov 2010) | 34 lines
Merged revisions 293806 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293806 | rmudgett | 2010-11-03 13:31:57 -0500 (Wed, 03 Nov 2010) | 27 lines
Merged revisions 293805 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293805 | rmudgett | 2010-11-03 13:23:04 -0500 (Wed, 03 Nov 2010) | 20 lines
Party A in an analog 3-way call would continue to hear ringback after party C answers.
All parties are analog FXS ports.
1) A calls B.
2) A flash hooks to call C.
3) A flash hooks to bring C into 3-way call before C answers. (A and B hear ringback)
4) C answers
5) A continues to hear ringback during the 3-way call. (All parties can hear each other.)
* Fixed use of wrong variable in dahdi_bridge() that stopped ringback on
the wrong subchannel.
* Made several debug messages have more information.
A similar issue happens if B and C are SIP channels. B continues to hear
ringback. For some reason this only affects v1.8 and trunk.
* Don't start ringback on the real and 3-way subchannels when creating the
3-way conference. Removing this code is benign on v1.6.2 and earlier.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293808 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r293648 | rmudgett | 2010-11-02 16:29:25 -0500 (Tue, 02 Nov 2010) | 20 lines
Merged revisions 293647 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r293647 | rmudgett | 2010-11-02 16:26:30 -0500 (Tue, 02 Nov 2010) | 13 lines
Merged revisions 293639 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r293639 | rmudgett | 2010-11-02 16:24:13 -0500 (Tue, 02 Nov 2010) | 6 lines
Make warning message have more useful information in it.
Change "Unable to get index, and nullok is not asserted" to "Unable to get
index for '<channel-name>' on channel <number> (<function>(), line
<number>)".
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293530 | rmudgett | 2010-11-01 12:29:30 -0500 (Mon, 01 Nov 2010) | 10 lines
Analog 3-way call would not connect all parties if one was using sig_pri.
Also the "dahdi show channel" would not show the correct 3-way call
status.
* Synchronized the inthreeway flag between chan_dahdi and sig_analog.
* Fixed a my_set_linear_mode() sign error and made take an analog sub
channel enum.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r293305 | jpeeler | 2010-10-29 16:48:38 -0500 (Fri, 29 Oct 2010) | 9 lines
Modify sip_setoption to not complain about unknown options.
This now behaves just like the other setoption callbacks. For the curious the
offending option for the reporter was AST_OPTION_CHANNEL_WRITE which was getting
passed due to a fix for chan_local in 286189.
(closes issue #17985)
Reported by: globalnetinc
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@293306 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292868 | dvossel | 2010-10-25 14:07:50 -0500 (Mon, 25 Oct 2010) | 39 lines
Merged revisions 292867 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r292867 | dvossel | 2010-10-25 14:06:21 -0500 (Mon, 25 Oct 2010) | 32 lines
Merged revisions 292866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r292866 | dvossel | 2010-10-25 14:05:07 -0500 (Mon, 25 Oct 2010) | 27 lines
This patch turns chan_local pvts into astobj2 objects.
chan_local does some dangerous things involving deadlock avoidance.
tech_pvt functions like hangup and queue_frame are provided with a
locked channel upon entry. Those functions are completely safe as
long as you don't attempt to give up that channel lock, but that is
impossible to guarantee due to the required deadlock avoidance necessary
to lock both the tech_pvt and both channels involved.
In the past, we have tried to account for this by doing things like
setting a "glare" flag that indicates what function should destroy the
pvt. This was used in local_hangup and local_queue_frame to decided
who should destroy the pvt if they collided in separate threads. I
have removed the need to do this by converting all chan_local tech_pvts
to astobj2. This means we can ref a pvt before deadlock avoidance
and not have to worry about that pvt possibly getting destroyed under
us. It also cleans up where we destroy the tech_pvt. The only unlink
from the tech_pvt container occurs in local_hangup now, which is where
it should occur.
Since there still may be thread collisions on some functions like
local_hangup after deadlock avoidance, I have added some checks to detect
those collisions and exit appropriately. I think this patch is going to
solve quite a bit of weirdness we have had with local channels in the past.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r292787 | lmadsen | 2010-10-22 16:28:43 -0500 (Fri, 22 Oct 2010) | 21 lines
Merged revisions 292786 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r292786 | lmadsen | 2010-10-22 16:16:12 -0500 (Fri, 22 Oct 2010) | 13 lines
Update the LDIF file for LDAP.
The LDIF file asterisk.ldif was quite a bit out of date from the asterisk.ldap-schema file, so I've
now updated that to be in sync. The asterisk.ldif file being out of sync was a problem on my systems
where I was doing an ldapadd to import the schema into the LDAP database, and the existing file
would cause problems and ERROR messages when registering.
Additional documention has been added based on feedback in the issue I'm closing.
(closes issue #13861)
Reported by: scramatte
Patches:
ldap-update.txt uploaded by lmadsen (license 10)
Tested by: lmadsen, jcovert, suretec, rgenthner
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292704 | rmudgett | 2010-10-22 10:47:08 -0500 (Fri, 22 Oct 2010) | 19 lines
Connected line is not updated when chan_dahdi/sig_pri or chan_misdn transfers a call.
When a call is transfered by ECT or implicitly by disconnect in sig_pri or
implicitly by disconnect in chan_misdn, the connected line information is
not exchanged. The connected line interception macros also need to be
executed if defined.
The CALLER interception macro is executed for the held call.
The CALLEE interception macro is executed for the active/ringing call.
JIRA ABE-2589
JIRA SWP-2296
Patches:
abe_2589_c3bier.patch uploaded by rmudgett (license 664)
abe_2589_v1.8_v2.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/958/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292705 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292489 | rmudgett | 2010-10-20 20:02:50 -0500 (Wed, 20 Oct 2010) | 7 lines
Send CONNECT_ACKNOWLEDGE for CIS calls too.
The originator of the Q.SIG call completion signaling link was not changed
to the active state when the CONNECT message came in. The T309 processing
would immediately kill the signaling link because it was not in the active
state.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292490 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r292309 | twilson | 2010-10-19 12:27:32 -0700 (Tue, 19 Oct 2010) | 10 lines
Add sip show peer info about crypto and remove dated comment
This patch adds information about the encryption setting to 'sip show
peers' and removes an out-of-date comment from res_srtp.c and instead
directs users to the proper documentation.
(closes issue #18140)
Reported by: chodorenko
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@292310 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291827 | dvossel | 2010-10-14 16:27:42 -0500 (Thu, 14 Oct 2010) | 18 lines
Safer xml parsing, treat all clients the same, and better local candidate selection.
The gtalk channel driver was doing several unsafe operations
in regards to how it parsed incoming XML messages. I have cleaned
that code up so it should be much safer now.
We now treat all clients types the same. We have no reason to
distinguish between GMAIL and GOOGLE VOICE clients anymore because
they all work the same way.
I also modified how the local ip is found. If no bindaddress is provided
in the config file, we attempt to determine the local ip we
would use to connect to google.com. If that fails, then
we fall back to the ast_find_ourip() function as a last resort.
Using the new method makes it much less likely that we would ever
advertise a local RTP candidate as a loopback address.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291828 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291758 | pabelanger | 2010-10-14 11:15:12 -0400 (Thu, 14 Oct 2010) | 11 lines
Add the ability for ast_find_ourip to return IPv4, IPv6 or both.
While testing chan_gtalk I noticed jabber was using my IPv6 address
and not IPv4. When using bindaddr=0.0.0.0 it is possible for ast_find_ourip()
to return both IPv6 and IPv4 results. Adding a family parameter gives you
the ablility to choose.
Since jabber/gtalk/h323 do not support IPv6, we should only return IPv4 results.
Review: https://reviewboard.asterisk.org/r/973/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291760 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r291656 | rmudgett | 2010-10-13 18:45:11 -0500 (Wed, 13 Oct 2010) | 34 lines
Merged revisions 291655 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r291655 | rmudgett | 2010-10-13 18:36:50 -0500 (Wed, 13 Oct 2010) | 27 lines
Merged revisions 291643 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r291643 | rmudgett | 2010-10-13 18:29:58 -0500 (Wed, 13 Oct 2010) | 20 lines
Deadlock between dahdi_exception() and dahdi_indicate().
There is a deadlock between dahdi_exception() and dahdi_indicate() for
analog ports. The call-waiting and three-way-calling feature can
experience deadlock if these features are trying to do something and an
event from the bridged channel happens at the same time.
Deadlock avoidance code added to obtain necessary channel locks before
attemting an operation with call-waiting and three-way-calling.
(closes issue #16847)
Reported by: shin-shoryuken
Patches:
issue_16847_v1.4.patch uploaded by rmudgett (license 664)
issue_16847_v1.6.2.patch uploaded by rmudgett (license 664)
issue_16847_v1.8_v2.patch uploaded by rmudgett (license 664)
Tested by: alecdavis, rmudgett
Review: https://reviewboard.asterisk.org/r/971/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291541 | rmudgett | 2010-10-13 15:21:02 -0500 (Wed, 13 Oct 2010) | 26 lines
The chan_dahdi faxdetect option only works for the first FAX call.
The chan_dahdi faxdetect option only works for the first call. After that
the option no longer works. The struct dahdi_pvt.callprogress member is
the encoded user config setting for the callprogress and faxdetect config
options. Changing this value alters the configuration for all following
calls until the chan_dahdi.conf file is reloaded.
* Fixed the chan_dahdi ast_channel_setoption callback to not change the
users faxdetect config setting except for the current call.
* Fixed the chan_dahdi ast_channel_queryoption callback to read the active
DSP setting of the faxdetect option.
* Made actually disable the active faxdetect DSP setting for the current
call on the analog port. my_handle_dtmfup() is used for normal analog
ports. dahdi_handle_dtmfup() is the legacy code and is no longer used
unless in a radio mode.
(closes issue #18116)
Reported by: seandarcy
Patches:
issue18116_v1.8.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/972/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291542 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r291507 | rmudgett | 2010-10-13 14:01:48 -0500 (Wed, 13 Oct 2010) | 18 lines
Merged revision 291504 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r291504 | rmudgett | 2010-10-13 13:30:21 -0500 (Wed, 13 Oct 2010) | 11 lines
Hold off ast_hangup() from destroying the ast_channel.
Must get the ast_channel lock before proceeding with release_chan() and
release_chan_early() to hold off ast_hangup() from destroying the
ast_channel.
Missed this change for -r291468.
JIRA ABE-2598
JIRA SWP-2317
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291508 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r291192 | dvossel | 2010-10-11 16:38:39 -0500 (Mon, 11 Oct 2010) | 19 lines
Gtalk enhancements and general code cleanup.
This patch includes several chan_gtalk enhancements.
Two new gtalk.conf options have been added, externip
and stunadd. Setting externip allows us to
manually specify what the external IP address is
outside of a NAT environment. Setting the stunaddr
option to a valid stun server allows for that external
ip to be retrieved via a STUN server automatically. This
external IP is then advertised during call setup as
a possible candidate.
I have also attempted to clean up chan_gtalk's code
so it meets our coding guidelines. During this cleanup
I noticed several things that need to be done in the
code and made a TODO section at the top of the file.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@291193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r290973 | dvossel | 2010-10-08 15:44:59 -0500 (Fri, 08 Oct 2010) | 12 lines
Make outbound Google Voice calls.
This patch allows for outbound Google Voice calls to be
dialed from Asterisk using chan_gtalk. Below is an example
dialstring.
exten -> blah,1,Dial(Gtalk/asterisk/+15552225555@voice.google.com,,)
In this example, 'asterisk' is the jabber.conf profile configured
to connect to your gmail account. In order to receive Google Voice
calls make sure to enable 'allowguest=yes' in gtalk.conf.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290974 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r290829 | dvossel | 2010-10-07 17:38:05 -0500 (Thu, 07 Oct 2010) | 6 lines
Add Philippe Sultan to chan_gtalk author list.
Philippe has made some notable contributions to the
gtalk channel driver. His name deserves to be listed
amoung the authors of that file. Thanks Philippe!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290831 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r290648 | dvossel | 2010-10-06 16:08:19 -0500 (Wed, 06 Oct 2010) | 12 lines
Fixes gtalk outbound DTMF to work properly.
Outbound DTMF with gtalk needs to be done within the RTP stream. I discovered
this after investigating a packet capture from the gmail client. Instead of
performing jingle signaling DTMF, the gtalk servers expect all DTMF to arrive
on the RTP stream using RFC2833 way of doing things. Chan_gtalk also had an issue
with negotiating RTP payload type 106 for the telephony-event and then sending
DTMF as payload 101. This has been resolved by always negotiating 101 as the payload
type like we do everywhere else. With this patch, incoming google voice calls forwarded
to Asterisk via gtalk work.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@290649 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289840 | jpeeler | 2010-10-01 21:43:45 -0500 (Fri, 01 Oct 2010) | 29 lines
Merged revisions 289798 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289798 | jpeeler | 2010-10-01 18:01:31 -0500 (Fri, 01 Oct 2010) | 22 lines
Merged revisions 289797 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
The scenario here is with a non P2P early media session. The reported time
length of DTMF presses are coming up short when sending to the remote side.
Currently the event duration is a running total that is incremented when sending
continuation packets. These continuation packets are only triggered upon
incoming media from the remote side, which means that the running total probably
is not going to end up matching the actual length of time Asterisk received
DTMF. This patch changes the end event duration to be lengthened if it is
detected that the end event is going to come up short.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289701 | jpeeler | 2010-10-01 11:22:19 -0500 (Fri, 01 Oct 2010) | 28 lines
Merged revisions 289700 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r289700 | jpeeler | 2010-10-01 11:21:04 -0500 (Fri, 01 Oct 2010) | 21 lines
Merged revisions 289699 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289699 | jpeeler | 2010-10-01 11:20:00 -0500 (Fri, 01 Oct 2010) | 14 lines
Ensure user portion of SIP URI matches dialplan when using encoded characters.
This commit takes a simliar approach to 288112 and checks the dialplan to
determine the proper action for an incoming contact header as to whether or not
it should be decoded or not. sip_new was blindly always decoding the extension,
which also caused the outgoing contact header to be incorrect as well as failing
to match the encoded extension in the dialplan.
(closes issue #17892)
Reported by: wdoekes
Patches:
bug17892-1.patch uploaded by jpeeler (license 325)
Tested by: wdoekes
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289702 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On every incoming subscribe there is a iteration through all dialogs to find old subscribes and delete them. This is slow and not RFC conform. This was only needed in 1.2 cause a subscribe was not deleted when a dialog was destroyed, after 1.4 a subscribe get removed when its dialog is destroyed.
Review: https://reviewboard.asterisk.org/r/901/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r289549 | rmudgett | 2010-09-30 14:28:36 -0500 (Thu, 30 Sep 2010) | 17 lines
Merged revision 289547 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r289547 | rmudgett | 2010-09-30 14:16:36 -0500 (Thu, 30 Sep 2010) | 10 lines
In chan_misdn, the DivertingLegInformation2 DivertingNr is garbage when the number is restricted.
The same thing happens with DivertingLegInformation1 DivertedTo number.
The misdn_PresentedNumberUnscreened_extract() extracted the Unscreened
PartyNumber field unconditionally. It now checks the presented number
unscreened type to see if the PartyNumber was even present.
JIRA ABE-2595
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@289552 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r288194 | rmudgett | 2010-09-21 19:06:21 -0500 (Tue, 21 Sep 2010) | 40 lines
Merged revisions 288193 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r288193 | rmudgett | 2010-09-21 19:03:37 -0500 (Tue, 21 Sep 2010) | 33 lines
Merged revisions 288192 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r288192 | rmudgett | 2010-09-21 18:55:58 -0500 (Tue, 21 Sep 2010) | 26 lines
In chan_iax2.c:schedule_delivery() calls ast_bridged_channel() on an unlocked channel.
Near the beginning of schedule_delivery(), ast_bridged_channel() is called
on iaxs[fr->callno]->owner. However, the channel is not locked, which can
result in ast_bridged_channel() crashing should owner->tech change to a
technology that doesn't implement bridged_channel.
I also fixed the other calls to ast_bridged_channel() in chan_iax2.c since
the owner lock was not held there either.
Converted the existing channel deadlock avoidance to use
iax2_lock_owner(). Using the new function simplified some awkward code.
In the process of fixing the locking on ast_bridged_channel(), I also
found a memory leak in socket_process() for v1.6.2 and v1.8. The local
struct variable ies.vars is not freed on early/abnormal function exits.
(closes issue #17919)
Reported by: rain
Patches:
issue17919_v1.4.patch uploaded by rmudgett (license 664)
issue17919_w_leak_v1.6.2.patch uploaded by rmudgett (license 664)
issue17919_w_leak_v1.8.patch uploaded by rmudgett (license 664)
Review: https://reviewboard.asterisk.org/r/926/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288195 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r288159 | tilghman | 2010-09-21 17:57:22 -0500 (Tue, 21 Sep 2010) | 29 lines
Merged revisions 288113 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r288113 | tilghman | 2010-09-21 16:59:46 -0500 (Tue, 21 Sep 2010) | 22 lines
Merged revisions 288112 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r288112 | tilghman | 2010-09-21 16:58:13 -0500 (Tue, 21 Sep 2010) | 15 lines
Try both the encoded and unencoded subscription URI for a match in hints.
When a phone sends an encoded URI for a subscription, the URI is not matched
with the actual hint that is in decoded format. For example, if we have an
extension with a hint that is named: "#5601" or "*5601", the subscription will
work fine if the phone subscribes with an already decoded URI, but when it's
decoded like "%255601" or "%2A5601", Asterisk is unable to match it with the
correct hint.
(closes issue #17785)
Reported by: ramonpeek
Patches:
20100831__issue17785.diff.txt uploaded by tilghman (license 14)
Tested by: ramonpeek
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288160 65c4cc65-6c06-0410-ace0-fbb531ad65f3
adding two dialog container, one for dialogs which need destroy, another for rtptimeout checks.
both container will be checked on every loop of do_monitor instead of iterate through all dialogs.
(closes issue #17912)
Reported by: schmidts
Tested by: schmidts
Review: https://reviewboard.asterisk.org/r/917/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@288063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r287683 | rmudgett | 2010-09-20 18:14:42 -0500 (Mon, 20 Sep 2010) | 9 lines
The inalarm flag was not set in sig_analog struct if the port is initially in alarm.
Fixed initial inalarm value for sig_analog ports.
Along with -r261007, this gets the inalarm flag in sync with chan_dahdi
for sig_analog ports.
(closes issue #16983)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r287017 | rmudgett | 2010-09-15 15:53:38 -0500 (Wed, 15 Sep 2010) | 65 lines
Merged revision 287014 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
..........
r287014 | rmudgett | 2010-09-15 15:32:24 -0500 (Wed, 15 Sep 2010) | 58 lines
The handling of call transfer signaling for mISDN PTMP is not fully implemented.
The handling of call transfer signaling for mISDN PTMP is not fully
implemented. The signaling of number updates with ISDN/DSS1 ECT
supplementary services (ETS 300 369-1) comes along with a notification
indicator IE and redirection number IE for PTMP. The implementation in
the current Asterisk mISDN channel unfortunately can handle these
information elements only in a NOTIFY message. These information elements
are also signaled in a FACILTY message with a RequestSubaddress facility,
when the subscriber is already in the active state (see 9.2.4 and 9.2.5 of
ETS 300 369-1).
**********
abe_2526_ast.patch
* Added support to handle the notification indicator IE and redirection
number IE with the RequestSubaddress facility.
* Made misdn_update_connected_line() send a NOTIFY message if Asterisk
originated the call and it is not connected yet.
* Made misdn_update_connected_line() send a FACILITY message if the call
is already connected.
This patch requires the presence of the associated mISDN patches to
compile. I had to enhance mISDN to allow the notification indicator IE
and the redirection number IE to be used with a FACILITY message. Earlier
versions of the Digium enhanced mISDN are no longer going to work.
**********
abe_2526_misdn.patch
* Made an incoming FACILITY message allow the presence of the notification
indicator IE and the redirection number IE.
**********
abe_2526_misdnuser_v3.patch
* Added support to send and receive a FACILITY message with the
notification indicator IE and the redirection number IE.
* Added the ability to send a NOTIFY message in PTMP/NT mode to all
responding subcalls in Q.931 states 6, 7, 8, 9, and 25.
**********
Patches:
abe_2526_ast.patch uploaded by rmudgett (license 664)
abe_2526_misdn.patch uploaded by rmudgett (license 664)
abe_2526_misdnuser_v3.patch uploaded by rmudgett (license 664)
Tested by: rmudgett and reporter
JIRA SWP-2146
JIRA ABE-2526
..........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@287018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286931 | jpeeler | 2010-09-15 14:22:15 -0500 (Wed, 15 Sep 2010) | 16 lines
Add parking extension for non-default parking lots.
This is a new feature that allows for parking to custom parking lots to be
accessed directly, rather than with channel variables or by changing the
default parking lot. The extension is set with the parkext option just as the
default parking lot is done. Also, the manager action has been updated to
optionally allow a specified parking lot.
(closes issue #14882)
Reported by: vmikhnevych
Patches:
patch_14882.txt uploaded by mnick (license 874)
modified by me
Review: https://reviewboard.asterisk.org/r/884/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286939 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286904 | rmudgett | 2010-09-15 13:28:05 -0500 (Wed, 15 Sep 2010) | 12 lines
Unable to originate calls using E&M over T1.
When originating a call from Unit Under Test to Reference Unit using E&M
RBS signaling mode, I get the following warning message: "Ring/Off-hook in
strange state 3 on channel 1".
Fixed the sig_analog outgoing flag. It was never set when sig_analog was
extracted from chan_dahdi.
JIRA SWP-2191
JIRA AST-408
........
r286905 | rmudgett | 2010-09-15 13:29:21 -0500 (Wed, 15 Sep 2010) | 1 line
Simplify some code in sig_analog.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286906 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r286868 | mnicholson | 2010-09-15 08:05:52 -0500 (Wed, 15 Sep 2010) | 16 lines
Set tohost to the domain specified in the configuration file instead of the IP address of the host we are calling.
This fixes a regression introduced in r274783.
(closes issue #17960)
Reported by: adriavidal
Patches:
sip-tohost-fix1.diff uploaded by mnicholson (license 96)
Tested by: mich, mnicholson, adriavidal
(closes issue #17676)
Reported by: outcast
Patches:
sip-tohost-fix1.diff uploaded by mnicholson (license 96)
Tested by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286869 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286189 | twilson | 2010-09-10 17:04:53 -0500 (Fri, 10 Sep 2010) | 30 lines
Merged revisions 286115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286115 | twilson | 2010-09-10 15:35:25 -0500 (Fri, 10 Sep 2010) | 23 lines
Merged revisions 286059 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286059 | twilson | 2010-09-10 14:25:08 -0500 (Fri, 10 Sep 2010) | 16 lines
Inherit CHANNEL() writes to both sides of a Local channel
Having Local (/n) channels as queue members and setting the language in the
extension with Set(CHANNEL(language)=fr) sets the language on the Local/...,2
channel. Hold time report playbacks happen on the Local/...,1 channel and
therefor do not play in the specified language.
This patch modifies func_channel_write to call the setoption callback and pass
the CHANNEL() write info to the callback. chan_local uses this information to
look up the other side of the channel and apply the same changes to it.
(closes issue #17673)
Reported by: Guggemand
Review: https://reviewboard.asterisk.org/r/903/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286190 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r286118 | rmudgett | 2010-09-10 15:55:37 -0500 (Fri, 10 Sep 2010) | 25 lines
Merged revisions 286116 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r286116 | rmudgett | 2010-09-10 15:42:44 -0500 (Fri, 10 Sep 2010) | 18 lines
Merged revisions 286113 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r286113 | rmudgett | 2010-09-10 15:33:16 -0500 (Fri, 10 Sep 2010) | 11 lines
An outgoing call may not get hung up if a pre-connect incoming ISDN call is disconnected.
If the ISDN link a pre-connect incoming call is using fails or is reset,
the outgoing leg may not hang up or be delayed in hanging up. (Causes:
PRI_CAUSE_NETWORK_OUT_OF_ORDER, PRI_CAUSE_DESTINATION_OUT_OF_ORDER, and
PRI_CAUSE_NORMAL_TEMPORARY_FAILURE.)
Just hang up the call if the incoming call leg hangs up before connecting
for any reason. It makes no sense to send a BUSY or CONGESTION control
frame to the outgoing call leg under these circumstances.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@286119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r285564 | dvossel | 2010-09-08 16:48:37 -0500 (Wed, 08 Sep 2010) | 60 lines
Merged revisions 285563 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r285563 | dvossel | 2010-09-08 16:47:29 -0500 (Wed, 08 Sep 2010) | 54 lines
Fixes interoperability problems with session timer behavior in Asterisk.
CHANGES:
1. Never put "timer" in "Require" header. This is not to our benefit
and RFC 4028 section 7.1 even warns against it. It is possible for one
endpoint to perform session-timer refreshes while the other endpoint does
not support them. If in this case the end point performing the refreshing
puts "timer" in the Require field during a refresh, the dialog will
likely get terminated by the other end.
2. Change the behavior of 'session-timer=accept' in sip.conf (which is
the default behavior of Asterisk with no session timer configuration
specified) to only run session-timers as result of an incoming INVITE
request if the INVITE contains an "Session-Expires" header... Asterisk is
currently treating having the "timer" option in the "Supported" header as
a request for session timers by the UAC. I do not agree with this. Session
timers should only be negotiated in "accept" mode when the incoming INVITE
supplies a "Session-Expires" header, otherwise RFC 4028 says we should
treat a request containing no "Session-Expires" header as a session with
no expiration.
Below I have outlined some situations and what Asterisk's behavior is.
The table reflects the behavior changes implemented by this patch.
SITUATIONS:
-Asterisk as UAS
1. Incoming INVITE: NO "Session-Expires"
2. Incoming INVITE: HAS "Session-Expires"
-Asterisk as UAC
3. Outgoing INVITE: NO "Session-Expires". 200 Ok Response HAS "Session-Expires" header
4. Outgoing INVITE: NO "Session-Expires". 200 Ok Response NO "Session-Expires" header
5. Outgoing INVITE: HAS "Session-Expires".
Active - Asterisk will have an active refresh timer regardless if the other endpoint does.
Inactive - Asterisk does not have an active refresh timer regardless if the other endpoint does.
XXXXXXX - Not possible for mode.
______________________________________
|SITUATIONS | 'session-timer' MODES |
|___________|________________________|
| | originate | accept |
|-----------|------------|-----------|
|1. | Active | Inactive |
|2. | Active | Active |
|3. | XXXXXXXX | Active |
|4. | XXXXXXXX | Inactive |
|5. | Active | XXXXXXXX |
--------------------------------------
(closes issue #17005)
Reported by: alexrecarey
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r285006 | dvossel | 2010-09-03 17:21:50 -0500 (Fri, 03 Sep 2010) | 9 lines
Disables auth_options_request option by default.
The auth_options_request option was created to do authentication
on OPTIONS request just like INVITES are done. Since it has been
noted that some endpoints use OPTIONS requests as a way of qualifying
a peer and that a 401 authentication response could result in
interoperability issues, this option has been disabled by default.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@285007 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284950 | dvossel | 2010-09-03 12:29:02 -0500 (Fri, 03 Sep 2010) | 14 lines
authenticate OPTIONS requests just like we would an INVITE
OPTIONS requests should be treated the same as an INVITE
This includes authentication. This patch adds the ability for
incoming out of dialog OPTION requests to be authenticated
before providing a response indicating whether an extension
is available or not. The authentication routine works the
exact same way as it does for incoming INVITEs. This means
that if a peer has 'insecure=invite' in their peer definition,
the same will be true for the processing of the OPTIONS request.
Review: https://reviewboard.asterisk.org/r/881/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284561 | dvossel | 2010-09-01 16:47:01 -0500 (Wed, 01 Sep 2010) | 9 lines
During request to dialog matching, verify init_ruri is present before comparing.
During request to dialog matching, we attempt a best effort routine for fork
detection which requires several elements to be in place. The dialog's
initial request uri is one of those elements. Since it is best effort,
if the init_ruri is not present for some reason we can not proceed with that
routine.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284562 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines
Fix SRTP for changing SSRC and multiple a=crypto SDP lines
Adding code to Asterisk that changed the SSRC during bridges and masquerades
broke SRTP functionality. Also broken was handling the situation where an
incoming INVITE had more than one crypto offer. This patch caches the SRTP
policies the we use so that we can change the ssrc and inform libsrtp of the
new streams. It also uses the first acceptable a=crypto line from the incoming
INVITE.
(closes issue #17563)
Reported by: Alexcr
Patches:
srtp.diff uploaded by twilson (license 396)
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/878/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@284479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283692 | dvossel | 2010-08-26 10:26:37 -0500 (Thu, 26 Aug 2010) | 32 lines
Merged revisions 283691 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283691 | dvossel | 2010-08-26 10:24:40 -0500 (Thu, 26 Aug 2010) | 25 lines
Merged revisions 283690 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283690 | dvossel | 2010-08-26 10:22:28 -0500 (Thu, 26 Aug 2010) | 19 lines
Fixed how Asterisk destroys a dialog on channel hangup before invite receives a response.
If an ast_channel with a SIP tech pvt hangs up before the sip dialog gets a response
to its outgoing INVITE, Asterisk used to pretend_ack the INVITE. This is not rfc
compliant and results in confusion at the other endpoint. sip_pretend_ack will ack
and remove all the packets in the retransmit queue. This means that the INVITE will
stop retransmitting, and that any response to that INVITE that comes after the pretend_ack
occurs will be ignored.
Instead of faking any sort of acknowledgement for an outgoing INVITE during an internal
hangup, we should let the protocol stack process the INVITE transaction and terminate
the dialog properly. This is achieved by setting the PENDING_BYE flag. When this flag
is used, once the dialog proceeds to an escapable state the transaction will either be
canceled with a SIP_CANCEL or completed followed immediately by a BYE. Attempting to do
this any other way is incorrect. If the endpoint is not responding to the INVITE request,
the INVITE must continue to be retransmitted until it times out which will result in the
dialog being destroyed.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283595 | dvossel | 2010-08-25 17:57:56 -0500 (Wed, 25 Aug 2010) | 14 lines
Merged revisions 283594 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r283594 | dvossel | 2010-08-25 17:56:42 -0500 (Wed, 25 Aug 2010) | 7 lines
Add to and from tags to NOTIFY dialog-info xml body so pickup can occur.
When pedantic mode is used, the dialog-info xml generated during a
ringing event must contain the to and from tag values. Otherwise if
a pickup occurs using INVITE with replaces, Astrisk will not be able
to locate the subscription.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283596 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283559 | dvossel | 2010-08-25 10:54:11 -0500 (Wed, 25 Aug 2010) | 16 lines
Merged revisions 283558 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r283558 | dvossel | 2010-08-25 10:52:54 -0500 (Wed, 25 Aug 2010) | 10 lines
Asterisk will not advertise session timers are supported when 'session-timers=refuse' is used.
Asterisk now dynamically builds the "Supported" header depending
on what is enabled/disabled in sip.conf. Session timers used
to always be advertised as being supported even when they were disabled
in the configuration. This caused problems with some end points.
(issue #17005)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283560 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283382 | dvossel | 2010-08-24 11:11:18 -0500 (Tue, 24 Aug 2010) | 25 lines
Merged revisions 283381 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283381 | dvossel | 2010-08-24 11:07:37 -0500 (Tue, 24 Aug 2010) | 18 lines
Merged revisions 283380 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283380 | dvossel | 2010-08-24 11:01:51 -0500 (Tue, 24 Aug 2010) | 11 lines
This fix makes sure the ast_channel hangs up correctly when the dialog's PENDING_BYE flag is set.
When the pending bye flag is used, it is possible that the dialog will terminate
and leave the sip_pvt->owner channel up. This is because we never hangup the
ast_channel after sending the SIP_BYE request. When we receive the response for
the SIP_BYE we set need_destroy which we would expect to destroy the dialog on the
next do_monitor loop, but this is not the case. The dialog will only be destroyed
once the owner is hungup even with the need_destroy flag set. This patch sets the
softhangup flag on the ast_channel when a SIP_BYE request is sent as a result of the
pending bye flag.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283383 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283050 | rmudgett | 2010-08-20 10:35:38 -0500 (Fri, 20 Aug 2010) | 36 lines
Merged revisions 283049 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283049 | rmudgett | 2010-08-20 10:31:03 -0500 (Fri, 20 Aug 2010) | 29 lines
Merged revisions 283048 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283048 | rmudgett | 2010-08-20 10:24:36 -0500 (Fri, 20 Aug 2010) | 22 lines
Q931 - Sending PROGRESS after sending ALERTING is a protocol error
The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.
Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.
Protocol specification reference: T-REC-Q.931-199805-I page 223, "Figure
A.5/Q.931 -- Overview protocol control (network side) point-point
(sheet 3 of 8)"
(closes issue #17874)
Reported by: nic_bellamy
Patches:
asterisk-1.4-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-1.6.2-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-trunk-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@283051 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282895 | dvossel | 2010-08-19 16:07:20 -0500 (Thu, 19 Aug 2010) | 25 lines
Merged revisions 282894 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r282894 | dvossel | 2010-08-19 16:05:54 -0500 (Thu, 19 Aug 2010) | 18 lines
Merged revisions 282893 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282893 | dvossel | 2010-08-19 16:03:24 -0500 (Thu, 19 Aug 2010) | 11 lines
tos_sip option was not being set correctly
When tos_sip is used, the tos of the sip socket is only set
correctly if the socket binding changes on a reload. If the binding
stays the same but the TOS changes, the new tos value would not take
into effect. This patch fixes that.
(closes issue #17712)
Reported by: nickb
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282896 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Consolidates all offhook (new call with dialtone) to setsubstate_offhook. This should be roughly equivalent to existing code, although a couple of calls now run through the full offhook sequence rather than an abbreviated one.
(closes issue #17812)
Reported by: wedhorn
Patches:
cleanup.stateoffhook.diff uploaded by wedhorn (license 30)
Tested by: salecha, wedhorn
Review: NA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282671 | rmudgett | 2010-08-18 10:27:51 -0500 (Wed, 18 Aug 2010) | 1 line
Use the correct operator when calculating the PRI span devstate.
........
r282672 | rmudgett | 2010-08-18 10:28:27 -0500 (Wed, 18 Aug 2010) | 1 line
Use the correct type for aoce_delayhangup bit field.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282673 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282639 | mnicholson | 2010-08-18 08:10:39 -0500 (Wed, 18 Aug 2010) | 13 lines
Properly handle 200 and unknown responses conatined in NOTIFY requests received in response to REFER requests.
This patch fixes the way asterisk handles NOTIFY requests received in response to REFER requests. These changes to NOTIFY handler were first introduced in r217482. This new change properly handles the 200 response by queueing an AST_TRANSFER_SUCCESS control frame and also prevents that control frame from being queued when provisional and unknown responses are received.
(issue #17486)
Reported by: davidw
Tested by: mnicholson
(issue #12713)
Reported by: davidw
Review: https://reviewboard.asterisk.org/r/860/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282334 | rmudgett | 2010-08-13 18:53:36 -0500 (Fri, 13 Aug 2010) | 6 lines
PRI CCSS may use a stale dial string for the recall dial string.
If an outgoing call negotiates a different B channel than initially
requested, the saved original dial string was not transferred to the new B
channel. CCSS uses that dial string to generate the recall dial string.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282236 | dvossel | 2010-08-13 13:58:10 -0500 (Fri, 13 Aug 2010) | 23 lines
Merged revisions 282235 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r282235 | dvossel | 2010-08-13 13:54:53 -0500 (Fri, 13 Aug 2010) | 16 lines
only do magic pickup when notifycid is enabled
A new way of doing BLF pickup was introduced into 1.6.2. This feature
adds a call-id value into the XML of a SIP_NOTIFY message sent to alert
a subscriber that a device is ringing. This option should only be enabled
when the new 'notifycid' option is set... but this was not the case. Instead
the call-id value was included for every RINGING Notify message, which
caused a regression for people who used other methods for call pickup.
(closes issue #17633)
Reported by: urosh
Patches:
chan_sip.txt uploaded by urosh (license )
blf_cid_issue.diff uploaded by dvossel (license 671)
Tested by: dvossel, urosh, okrief, alecdavis
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@282237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281432 | dvossel | 2010-08-09 15:47:53 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r281430 | dvossel | 2010-08-09 15:46:50 -0500 (Mon, 09 Aug 2010) | 13 lines
fixes SIP peers memory leak
We zeroed out the peer's addr before it was removed from the
peers_by_ip container. This made it impossible to be removed
from the container as the addr is the key used by the container
to find the peer.
(closes issue #17774)
Reported by: kkm
Patches:
017774-sip-peer-leak-1.6.2.10.diff uploaded by kkm (license 888)
017774-sip-peer-leak-1.8.diff uploaded by kkm (license 888)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281433 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281429 | jpeeler | 2010-08-09 15:43:54 -0500 (Mon, 09 Aug 2010) | 27 lines
Merged revisions 281391 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281391 | jpeeler | 2010-08-09 15:07:29 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281390 | jpeeler | 2010-08-09 15:04:30 -0500 (Mon, 09 Aug 2010) | 13 lines
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281431 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Cleaned up handling of onhook indications and added indications if more than one sub on device. Also fixes issue in 12324 so that the phone can call itself without locking up.
(closes issue #17692)
Reported by: jmhunter
Patches:
chan_skinny-transfer-v4.txt uploaded by DEA (license 3)
skinnytransfver.v8.diff uploaded by wedhorn (license 30)
Tested by: jmhunter, salecha, wedhorn
Review: NA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281257 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Move call answering stuff into new setsubstate_connected. Also add sub->substate var and set it to SUBSTATE_CONNECTED in setsubstate_connected.
(closes issue #17772)
Reported by: wedhorn
Patches:
cleanup.stateconnected2.diff uploaded by wedhorn (license 30)
Tested by: wedhorn, salecha
Review: NA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@281227 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved inline packet sending to transmit_ subs. Removed handle_keep_alive and handle_register_message to inline in handle_message. Also moved transmit_response(d) to transmit_response_bysessions(s) and created a wrapper transmit_response(d) that calls transmit_response_bysession(d->session).
(closes issue #16980)
Reported by: wedhorn
Patches:
skinny-clean06b.diff uploaded by wedhorn (license 30)
Tested by: wedhorn, DEA
Review: NA
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280589 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r280307 | mnicholson | 2010-07-29 08:56:35 -0500 (Thu, 29 Jul 2010) | 11 lines
Merged revisions 280306 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r280306 | mnicholson | 2010-07-29 08:45:11 -0500 (Thu, 29 Jul 2010) | 2 lines
Implement support for ast_channel_queryoption on local channels. Currently only AST_OPTION_T38_STATE is supported.
ABE-2229
Review: https://reviewboard.asterisk.org/r/813/
........
Additionally, pass AST_CONTROL_T38_PARAMETERS control frames through generic bridges. This change appears to have been unintentionally left out of rev 203699.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@280308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279916 | russell | 2010-07-27 14:50:56 -0500 (Tue, 27 Jul 2010) | 12 lines
Fix inband DTMF detection on outgoing ISDN calls.
This is a regression from the sig_pri split from chan_dahdi. When a call is
first initiated, the inband DTMF detector is not enabled if it's an outgoing
ISDN call. However, it needs to be turned on once the media path starts up.
This handling was put back in the open_media() callback of chan_dahdi. In
sig_pri, open_media() calls were added to a few places where it was needed,
including handling of PRI_EVENT_RINGING, PRI_EVENT_PROGRESS, and
PRI_EVENT_PROCEEDING.
Thanks to rmudgett for helping me with the patch!
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279887 | mmichelson | 2010-07-27 13:54:07 -0500 (Tue, 27 Jul 2010) | 16 lines
Fix parsing error in sip_sipredirect().
The code was written in a way that did a bad job of
parsing the port out of a URI. Specifically, it would
do badly when dealing with an IPv6 address. In this
particular scenario, there was no value from parsing
the port out, so I just removed that logic. And while
I was messing around in the function, I changed some
variable names to be more descriptive.
(closes issue #17661)
Reported by: oej
Patches:
17661.diff uploaded by mmichelson (license 60)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279888 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r279785 | mmichelson | 2010-07-27 10:15:22 -0500 (Tue, 27 Jul 2010) | 20 lines
Merged revisions 279784 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r279784 | mmichelson | 2010-07-27 10:13:24 -0500 (Tue, 27 Jul 2010) | 14 lines
Fix bad behavior of dynamic_exclude_static option in sip.conf.
We were attempting to create a contactdeny rule based on the peer's
IP address before the peer's IP address had been set. By moving the
processing further down in the function, we can ensure stuff works
as we expect for it to.
(closes issue #17717)
Reported by: mmichelson
Patches:
17717.patch uploaded by mmichelson (license 60)
Tested by: DennisD
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279786 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279568 | dvossel | 2010-07-26 14:59:03 -0500 (Mon, 26 Jul 2010) | 21 lines
transaction matching using top most Via header
This patch modifies the way chan_sip.c does transaction to dialog
matching. Asterisk now stores information in the top most Via header
of the initial incoming request and compares that against other Requests
that have the same call-id. This results in Asterisk being able to
detect a forked call in which it has received multiple legs of the
fork. I completely stripped out the previous matching code and made
the comparisons a little more explicit and easier to understand. My
comments in the code should offer all the details involving this patch.
This patch also fixes a bug with the usage of the OBJ-MULTIPLE flag to
find multiple dialogs with the same call-id. Since the callback
function was returning (CMP_MATCH | CMP_STOP) only the first item
found was being returned. I fixed this by making a new callback
function for finding multiple dialogs that only returns (CMP_MATCH)
on a match allowing for multiple items to be returned.
Review: https://reviewboard.asterisk.org/r/776/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279569 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279504 | mmichelson | 2010-07-26 11:04:09 -0500 (Mon, 26 Jul 2010) | 14 lines
Allow for systems without locale support to be usable.
A recent change to SIP URI comparison code added a locale-specific
string comparison to the mix, and certain systems do not support
such functions. This fix allows for those systems to still use
Asterisk 1.8
(closes issue #17697)
Reported by: pprindeville
Patches:
asterisk-trunk-bugid17697.patch uploaded by pprindeville (license 347)
Tested by: mmichelson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279533 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "dahdi show channels" extension column previously only showed the
called number of an incoming call. It now shows the called number for an
outgoing call as well.
(closes issue #17653)
Reported by: amazinzay
Patches:
issue17653_trunk.txt uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@279156 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This initially was created to work around the issue of
using a string comparison instead of a binary comparison
for IP addresses. It evolved a bit when test cases were
created and it was discovered that comparison of URI
parameters was not working exactly as it should.
sip_uri_cmp() and its helpers have been moved to reqresp_parser.c
and a new test has been added.
(closes issue #17662)
Reported by: oej
Review: https://reviewboard.asterisk.org/r/792
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.
Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.
(closes issue #17318)
Reported by: armeniki
Patches:
fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "dahdi show channels" CLI command still reports the DNID of the
previous call even if the call is already hang up. The "dahdi show
channels" command of older releases clear the DNID once the channel is
hang up.
Regression from the sig_analog/sig_pri extraction from chan_dahdi.
(closes issue #17623)
Reported by: klaus3000
Patches:
issue17623.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
[RFC3265]3.1.6.1....
The notifier MAY also check that the duration in the "Expires" header
is not too small. If and only if the expiration interval is greater
than zero AND smaller than one hour AND less than a notifier-
configured minimum, the notifier MAY return a "423 Interval too
small" error which contains a "Min-Expires" header field. The "Min-
Expires" header field is described in SIP [1].
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes some cases of no outgoing calls on FXO before an incoming call.
Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.
If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .
(closes issue #14577)
Reported by: jkroon
Patches:
asterisk_chan_dahdi_hookstate_fix_trunk_new.diff uploaded by frawd (license 610)
Tested by: frawd
Review: https://reviewboard.asterisk.org/r/699/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278501 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If Asterisk sends a 4xx error and the other side sends a CANCEl
before receiving the 4xx and responding with the ACK, Asterisk
will process the CANCEL and send a 487 Request Terminated as
a new final response to the INVITE. Since we are issuing a new
final response to the INVITE, the old one must be pretend_acked
else it will keep retransmitting.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278234 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are two changes here:
1. Since the externip setting can now have a port attached
to it, calling it "externip" is misleading. The option is now
documented and parsed as "externaddr." This also extends to the
"matchexterniplocally" setting. It is now documented and parsed
as "matchexternaddrlocally." The old names for the options may
still be used, but they are no longer used in the sip.conf.sample
file.
2. If no port is set for the externaddr, and UDP is the transport
to be used, then we will set the port of the externaddr to that of
the udpbindaddr. This was how things worked prior to the IPv6 merge,
so this is a regression fix.
(closes issue #17665)
Reported by: mmichelson
Patches:
17665.diff#2 uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277873 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue here is that passing an array to a function prohibits the ARRAY_LEN
macro from returning the real size. To avoid this the size is now defined and
use of ARRAY_LEN is avoided.
(closes issue #15718)
Reported by: alecdavis
Patches:
bug15718.patch uploaded by jpeeler (license 325)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277837 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277814 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277497 | mnicholson | 2010-07-16 16:18:38 -0500 (Fri, 16 Jul 2010) | 4 lines
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
FAX-128
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277530 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277419 | rmudgett | 2010-07-16 15:18:54 -0500 (Fri, 16 Jul 2010) | 15 lines
priexclusive in chan_dahdi.conf ignored when reloading dahdi module
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@277467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Found a unused bag of curly brackets under my table. I always wondered where
they had gone. They where indeed needed in chan_sip.c
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276989 65c4cc65-6c06-0410-ace0-fbb531ad65f3
sip.conf configuration for the channel and for devices.
The Max-Forwards header is used to prevent loops in a SIP network. Each intermediary,
like SIP proxys and SBCs, decrement this counter and detects when it reaches zero,
at which point the SIP request is nicely killed in a SIP-friendly way.
Review: https://reviewboard.asterisk.org/r/778/
Thanks to dvossel for the review and good advice.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Related to changes from 276571, I was accidentally testing with a port set in
my configuration causing me to miss this. Also moved the TCP handling as well
to occur before build_peer is called.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276788 65c4cc65-6c06-0410-ace0-fbb531ad65f3
MWI updates were not being sent if no messages were found in the event cache.
This was corrected since a phone may need to clear its MWI status configured
previously from another mailbox.
Upon module or sip reload, MWI updates could not be sent due to the sipsock
socket not being set early enough in reload_config. The code handling the
descriptor assignment and such has simply been moved before the call to
build_peer.
Issuing a sip reload cleared the IP address of the peer, but skipped checking
the database for registration information. The database is now checked both
for sip reload and actually reloading the module.
If a transmission occurs before the do_monitor thread has started, do not
attempt to send a signal to it.
(closes issue #17398)
Reported by: ip-rob
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276571 65c4cc65-6c06-0410-ace0-fbb531ad65f3
ast_sockaddr_stringiy_fmt (which is call by all ast_sockaddr_stringify* functions)
uses thread-local storage for storing the string that it creates. In cases where
ast_sockaddr_stringify_fmt was being called twice within the same statement, the
result of one call would be overwritten by the result of the other call. This
usually was happening in printf-like statements and was resulting in the same
stringified addressed being printed twice instead of two separate addresses.
I have fixed this by using ast_strdupa on the result of stringify functions if
they are used twice within the same statement. As far as I could tell, there were
no instances where a pointer to the result of such a call were saved anywhere, so
this is the only situation I could see where this error could occur.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276570 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unlike most responses, the 200 Ok to a pending INVITE Request is
acknowledged by an ACK Request. If the ACK Request for this Response is not received
the previous behavior was to immediately destroy the dialog and hangup
the channel. Now in an effort to be more RFC compliant, instead of immediately
destroying the dialog during this special case, termination is done with a BYE Request
as the dialog is technically confirmed when the 200 Ok is sent even if the ACK is
never received. The behavior of immediately hanging up the channel remains.
This only affects how dialog termination proceeds for this one special case.
RFC 3261 section 13.3.1.4
"If the server retransmits the 2xx response for 64*T1 seconds without receiving
an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is
accomplished with a BYE, as described in Section 15."
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276439 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The purpose of this patch is to eliminate struct ast_callerid since it has
turned into a miscellaneous collection of various party information.
Eliminate struct ast_callerid and replace it with the following struct
organization:
struct ast_party_name {
char *str;
int char_set;
int presentation;
unsigned char valid;
};
struct ast_party_number {
char *str;
int plan;
int presentation;
unsigned char valid;
};
struct ast_party_subaddress {
char *str;
int type;
unsigned char odd_even_indicator;
unsigned char valid;
};
struct ast_party_id {
struct ast_party_name name;
struct ast_party_number number;
struct ast_party_subaddress subaddress;
char *tag;
};
struct ast_party_dialed {
struct {
char *str;
int plan;
} number;
struct ast_party_subaddress subaddress;
int transit_network_select;
};
struct ast_party_caller {
struct ast_party_id id;
char *ani;
int ani2;
};
The new organization adds some new information as well.
* The party name and number now have their own presentation value that can
be manipulated independently. ISDN supplies the presentation value for
the name and number at different times with the possibility that they
could be different.
* The party name and number now have a valid flag. Before this change the
name or number string could be empty if the presentation were restricted.
Most channel drivers assume that the name or number is then simply not
available instead of indicating that the name or number was restricted.
* The party name now has a character set value. SIP and Q.SIG have the
ability to indicate what character set a name string is using so it could
be presented properly.
* The dialed party now has a numbering plan value that could be useful to
have available.
The various channel drivers will need to be updated to support the new
core features as needed. They have simply been converted to supply
current functionality at this time.
The following items of note were either corrected or enhanced:
* The CONNECTEDLINE() and REDIRECTING() dialplan functions were
consolidated into func_callerid.c to share party id handling code.
* CALLERPRES() is now deprecated because the name and number have their
own presentation values.
* Fixed app_alarmreceiver.c write_metadata(). The workstring[] could
contain garbage. It also can only contain the caller id number so using
ast_callerid_parse() on it is silly. There was also a typo in the
CALLERNAME if test.
* Fixed app_rpt.c using ast_callerid_parse() on the channel's caller id
number string. ast_callerid_parse() alters the given buffer which in this
case is the channel's caller id number string. Then using
ast_shrink_phone_number() could alter it even more.
* Fixed caller ID name and number memory leak in chan_usbradio.c.
* Fixed uninitialized char arrays cid_num[] and cid_name[] in
sig_analog.c.
* Protected access to a caller channel with lock in chan_sip.c.
* Clarified intent of code in app_meetme.c sla_ring_station() and
dial_trunk(). Also made save all caller ID data instead of just the name
and number strings.
* Simplified cdr.c set_one_cid(). It hand coded the ast_callerid_merge()
function.
* Corrected some weirdness with app_privacy.c's use of caller
presentation.
Review: https://reviewboard.asterisk.org/r/702/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276347 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Retransmission of packets should not be based on how many packets were
sent, but instead on a timeout period. Depending on whether or not the
packet is for a INVITE or NON-INVITE transaction, the number of packets
sent during the retransmission timeout period will be different, so
timing out based on the number of packets sent is not accurate.
This patch fixes this by removing the retransmit limit and only stopping
retransmission after a timeout period is reached. By default this
timeout period is 64*(Timer T1) for both INVITE and non-INVITE
transactions. For more information on sip timer values refer to
RFC3261 Appendix A.
Review: https://reviewboard.asterisk.org/r/749/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Some code improperly assumes that the sessions are still there, so revert the
change until I can find all of them and fix them.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@276206 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Since we are only keeping the dialog around for retransmissions at this point
and there is no possibility that we are still handling RTP, go ahead and
destroy the RTP sessions. Keeping them alive for 32 past when they are used
is unnecessary and can lead to problems with having too many open file
descriptors, etc.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275998 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It was essentially an off-by-one error. The easiest way
to fix this was to use the handy-dandy AST_NONSTANDARD_RAW_ARGS
macro to parse the pieces of the registration string out. Tested
and it works wonderfully.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275385 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a Via header contained an IPv6 address, we would not properly parse
the port. We would instead get the information after the first colon in
the address.
(closes issue #17614)
Reported by: oej
Patches:
diff uploaded by sperreault (license 252)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275308 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This should fix all the CDR tests that were not passing. When they would
originate a call, all fields in the INVITE that contained the source port would
have the port set to 0. Most troubling of these was the Contact header. Tests
are passing locally now and should also pass on the bamboo build agents.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@275294 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Part of the change with the IPv6 changes is to treat a host:port as
a single 'domain' entity. This test was not updated to have the correct
expectation after calling parse_uri().
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a generic API for accommodating IPv6 and IPv4 addresses
within Asterisk. While many files have been updated to make use of the
API, chan_sip and the RTP code are the files which actually support
IPv6 addresses at the time of this commit. The way has been paved for
easier upgrading for other files in the near future, though.
Big thanks go to Simon Perrault, Marc Blanchet, and Jean-Philippe Dionne
for their hard work on this.
(closes issue #17565)
Reported by: russell
Patches:
asteriskv6-test-report.pdf uploaded by russell (license 2)
Review: https://reviewboard.asterisk.org/r/743
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274783 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
........
(no option for trunk, just changing the behavior)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@274284 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A failure when calling the get_destination can mean multiple things. If
the extension is not found, a 404 error is appropriate, but if the URI
scheme is incorrect, a 404 is not approperiate. This patch adds the
get_destination_result enum to differentiate between these and other failure
types. The only logical difference in this patch is that we now send a "416
Unsupported URI scheme" response instead of a "404" when the scheme is not
recognized. This indicates to the initiator of the INVITE to retry the request
with a correct URI.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273427 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines
Allow the "useragent" value to be restored into memory from the realtime backend.
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@273078 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 2361 section 24.4.1 send a 400 Bad Request if the request
can not be understood due to malformed syntax. Currently we
simply ignore a packet with a missing callid, to, from, or
via header. Instead of ignoring we now send the 400 Bad request.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272981 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 section 8.2.2.3 states that if any unsupported options
are found in the Require header field, a "420 (Bad Extension)"
response should be sent with an Unsupported header field containing
only the unsupported options.
This is not currently being done correctly. Right now, if Asterisk
detects any unsupported sip options in a Require header the entire
list of options are returned in the Unsupported header even if some
of those options are in fact supported. This patch fixes that by
building an unsupported options character buffer when parsing the
options that can be sent with the 420 response. A unit test verifying
this functionality has been created. Some code refactoring was required.
Review: https://reviewboard.asterisk.org/r/680/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272880 65c4cc65-6c06-0410-ace0-fbb531ad65f3
I am doing work in this function. I noticed a large number of
coding guidline fixes that needed to be made. Rather than have
those changes distract from my functional changes I decided
to separate these into a separate patch.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272652 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC3261 states that Timer A should start at 500ms (T1) by default.
In chan_sip this value initially started at 1000ms and I changed
it to 500ms recently. After doing that I noticed in my packet
captures that it still occasionally retransmitted starting at
1000ms instead of 500ms like I told it to. This occurs because
the scheduler runs in the do_monitor thread. If a new retransmission
is added while the do_monitor thread is sleeping then it may not
detect that retransmission for nearly 1000ms. To fix this I just
poke the do_monitor thread to wake up when a new packet is sent
reliably requiring retransmits. The thread then detects the new
scheduler entry and adjusts its sleep time to account for it.
Review: https://reviewboard.asterisk.org/r/747
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272557 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The external test suite stops Asterisk using the "core stop gracefully" command.
The logs from the tests show that there are a number of problems with Asterisk
trying to cleanly shut down. This patch addresses the following type of error
that comes from chan_iax2:
[Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy:
chan_iax2.c line 11371 (iax2_process_thread_cleanup):
Error destroying mutex &thread->lock: Device or resource busy
For an example in the context of a build, see:
http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
The primary purpose of this patch is to change the thread pool shutdown
procedure to be more explicit to ensure that the thread exits from a point
where it is not holding a lock. While testing that, I encountered various
crashes due to the order of operations in unload_module() being problematic.
I reordered some things there, as well.
Review: https://reviewboard.asterisk.org/r/736/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272370 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testing proved that if Asterisk sent a connected line reinvite, and
the endpoint to which the reinvite were being sent sent a reinvite, Asterisk
would not properly respond with a 491 response.
The reason is that on connected line reinvites, we set the dialog's invitestate
to INV_CALLING to prevent Asterisk from sending a rapid flurry of connected line
reinvites. For other reinvites we do not do this. Because of the current invitestate,
when Asterisk received the reinvite, we interpreted this as a spiraled INVITE, and thus
did not behave properly.
The fix for this is to not enter the loop detection or spiral logic in handle_request_invite
if the channel state is currently up. This way, no mid-call reinvites will be misinterpreted,
no matter what the nature of the reinvite may have been.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272090 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This small changes prevents destroy_all_channels() from accessing a lock on an
unused dahdi_pri struct, resolving a ton of ERRORs that get spewed out when
shutting Asterisk down gracefully.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@272052 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 section 9 states that a CANCEL has no effect on a
request to a UAS that has already given a final response. This
patch checks to make sure there is a pending invite before
allowing a CANCEL request to be processed, otherwise it responds
to the CANCEL with a "481 Call/Transaction Does Not Exist".
Review: https://reviewboard.asterisk.org/r/697/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
According to RFC 3261 section 17.2.2, which describes non-INVITE server
transaction, when a dialog enters the Completed state it must destroy
the dialog after Timer J (T1*64) fires. For a BYE transaction Asterisk
terminates the dialog immediately during sip_hangup() when it should be
waiting T1*64 ms. This results in some odd behavior. For instance if
Asterisk receives a BYE and transmits a 200ok in response, if the endpoint
never receives the 200ok it will retransmit the BYE to which Asterisk
responds with a "481 Call leg/transaction does not exist" because the
dialog is already gone.
To resolve this I made a function called sip_scheddestroy_final(). This
differs slightly from sip_schedestroy() in that it enables a flag that
will prevent the destruction from ever being rescheduled or canceled
afterwards. It also prevents the pvt's needdestroy flag from being set
which triggers the destruction of the dialog within the do_monitor thread().
By using this function we are guaranteed destruction will not occur
until the scheduled time. This allows Asterisk to respond to any possible
retransmits for a dialog after we process the initial BYE request for T1*64 ms.
Other changes: I removed two instances where sip_cancel_destroy is used
right before calling sip_scheddestroy. sip_scheddestroy always calls
sip_cancel_destroy before scheduling the new destruction so it is completely
unnecessary.
Review: https://reviewboard.asterisk.org/r/694/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@271262 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270867 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Clearing the callwaitcas flag in analog_call was causing the incoming D digit
to be ignored which triggers sending the caller ID.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270658 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "channel" option would chop the channel name at the last '-', which made
it useless for something like a channel transfer from the dialplan. The
"fullchannel" option will return the channel name as-is.
ABE-2218
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@270260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* chan_dahdi supports dialing configuring and dialing by device file name.
DAHDI/span-name!local!1 will use /dev/dahdi/span-name/local/1 . Likewise
it may appear in chan_dahdi.conf as 'channel => span-name!local!1'.
* A new options for chan_dahdi.conf: 'ignore_failed_channels'. Boolean.
False by default. If set, chan_dahdi will ignore failed 'channel' entries.
Handy for the above name-based syntax as it does not depend on
initialization order.
* have my_pri_make_cc_dialstring() only manupulate dial-strings of group
(gGrR) dialing, which make it lsightly more complicated.
https://reviewboard.asterisk.org/r/535/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@269238 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After 5 years in mantis and over a year on reviewboard, SRTP support is finally
being comitted. This includes generic CHANNEL dialplan functions that work for
getting the status of whether a call has secure media or signaling as defined
by the underlying channel technology and for setting whether or not a new
channel being bridged to a calling channel should have secure signaling or
media. See doc/tex/secure-calls.tex for examples.
Original patch by mikma, updated for trunk and revised by me.
(closes issue #5413)
Reported by: mikma
Tested by: twilson, notthematrix, hemanshurpatel
Review: https://reviewboard.asterisk.org/r/191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Extract the SS7 specific code out of chan_dahdi like what was done to
ISDN/PRI and analog signaling. The new SS7 structures were modeled on
sig_pri.
The changes to sig_pri are an enhancement and a bug fix made possible
because SS7 was extracted.
1) The sig_pri TRANSFERCAPABILITY channel variable should have been set
unconditionally in sig_pri_new_ast_channel().
2) SS7/PRI transfer capability interaction in dahdi_new() fixed because of
SS7 extraction.
3) Module ref count error in dahdi_new() if startpbx failed to start the
PBX for some reason.
Review: https://reviewboard.asterisk.org/r/661/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268774 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Changes.
1. RFC 3261 states in section 17.1.2.2 and 17.1.1.2 that retransmission
timers should initially be set to timer T1. T1 by default is 500ms.
Asterisk was starting the retransmission timers at T1*2 which shouldn't
cause any problems, but is not RFC compliant.
2. RFC 3261 states in section 17.1.2.2 that for a non-INVITE client transaction,
if the retransmit timer fires while in the proceeding state that
the request must be retransmitted. Asterisk currently ack's
requests for both INVITE and non-INVITE transactions when a
1XX response is received, this patch changes this for non-INVITE requests.
3. The 'registerattempts' option in sip.conf is supposed to set
how many registry attempts will be made before giving up. When
this option is set to 1, I would expect only one registry attempt
to be made before stopping because of a failure, but instead two are
made. In my opinion this is not expected behavior. This option does
not indicate that these are re-attempts. The logic behind this option
has been changed to only attempt registers the exact number of times
this option is set to. If this option is 0, it still continues to
re-attempt the registration forever.
Review: https://reviewboard.asterisk.org/r/687/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@268205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The problem would manifest itself if your dialplan matching could accept
more digits to match than were actually dialed. The time out waiting for
overlap digits disconnected the call instead of matching any accumulated
digits to the dialplan.
Accidental conversion of a break out of loop as a break out of switch.
(closes issue #17401)
Reported by: avalentin
Patches:
issue17401_digit_timeout.patch uploaded by rmudgett (license 664)
Tested by: avalentin, rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267928 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After some debugging, the random chan_h323 build failures appear to be due
to complications introduced by some chan_h323 specific build stuff getting
triggered during a clean. Simplify this by moving the h323 clean commands
down into channels/makefile.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@267352 65c4cc65-6c06-0410-ace0-fbb531ad65f3
David Vossel
Terry Wilson
Richard Mudgett
Jonathan Rose
Matthew Nicholson
Damien Wedhorn
Gregory Nietsky
Russell Bryant
Leif Madsen
Mark Murawki
Brett Bryant
Alec L Davis
Tilghman Lesher
Tzafrir Cohen
Mark Michelson
Moises Silva
Jason Parker
Paul Belanger
Jeff Peeler
Andrew Latham
Sean Bright
Brad Watkins
Stefan Schmidt
Olle Johansson
Eliel C. Sardanons
Tim Ringenbach