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: http://svn.digium.com/svn/asterisk/trunk@312510 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@312384 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@312023 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@311613 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@311559 f38db490-d61c-443f-a65b-d21fe96a405b
dect_read() should not be called since audio is queued when available
through dect_dl_u_data_ind(). Return ast_null_frame so the core won't
hang up the channel and print a warning.
Signed-off-by: Patrick McHardy <kaber@trash.net>
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: http://svn.digium.com/svn/asterisk/trunk@311373 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@311298 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@309809 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@309446 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@309257 f38db490-d61c-443f-a65b-d21fe96a405b
Fix timers not firing and events not triggering. The exact reason is unknown,
synchronizing the event handler to chan_sip fixes it however.
Signed-off-by: Patrick McHardy <kaber@trash.net>
The kernel doesn't depend on getting correctly sized frames anymore, use
the frame size given by asterisk.
Signed-off-by: Patrick McHardy <kaber@trash.net>
'c' is only set if there is a RING_PATTERN environment variable,
'pattern' is the correct pointer to use.
Signed-off-by: Patrick McHardy <kaber@trash.net>
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: http://svn.digium.com/svn/asterisk/trunk@308946 f38db490-d61c-443f-a65b-d21fe96a405b
-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: http://svn.digium.com/svn/asterisk/trunk@308582 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@307964 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@307883 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@307433 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306755 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306670 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306396 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306216 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306128 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@306010 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@305939 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@305344 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@305255 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@303963 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@303772 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@303509 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@302413 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@302048 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@301947 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@301791 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@301135 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@300716 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@300302 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@300212 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@299406 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@299355 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@299249 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@299091 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@298545 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@298201 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@297972 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@297958 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@297608 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@297076 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@296630 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@296585 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@296353 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@296168 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@295748 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@295517 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@294824 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@294735 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@294351 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@294127 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@294083 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@293809 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@293808 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@293649 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@293531 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@293306 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@292869 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@292788 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@292705 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@292490 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@292310 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291828 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291760 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291658 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291542 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291508 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@291193 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@290974 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@290831 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@290649 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@289841 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@289702 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@289623 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@289552 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r288748 | twilson | 2010-09-24 09:02:27 -0700 (Fri, 24 Sep 2010) | 19 lines
Merged revisions 288747 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r288747 | twilson | 2010-09-24 08:37:39 -0700 (Fri, 24 Sep 2010) | 12 lines
Merged revisions 288746 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r288746 | twilson | 2010-09-24 08:26:09 -0700 (Fri, 24 Sep 2010) | 5 lines
Don't fail a masquerade if it is already being hung up
This avoids noise on some Local channel situations where we don't use /n.
Thanks to Alec Davis for the suggestion.
........
................
................
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@288749 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@288195 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@288160 f38db490-d61c-443f-a65b-d21fe96a405b
rmudgett
Patrick McHardy