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
