https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289797 | jpeeler | 2010-10-01 17:58:38 -0500 (Fri, 01 Oct 2010) | 15 lines
Change RFC2833 DTMF event duration on end to report actual elapsed time.
The scenario here is with a non P2P early media session. The reported time
length of DTMF presses are coming up short when sending to the remote side.
Currently the event duration is a running total that is incremented when sending
continuation packets. These continuation packets are only triggered upon
incoming media from the remote side, which means that the running total probably
is not going to end up matching the actual length of time Asterisk received
DTMF. This patch changes the end event duration to be lengthened if it is
detected that the end event is going to come up short.
Review: https://reviewboard.asterisk.org/r/957/
ABE-2476
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r289699 | jpeeler | 2010-10-01 11:20:00 -0500 (Fri, 01 Oct 2010) | 14 lines
Ensure user portion of SIP URI matches dialplan when using encoded characters.
This commit takes a simliar approach to 288112 and checks the dialplan to
determine the proper action for an incoming contact header as to whether or not
it should be decoded or not. sip_new was blindly always decoding the extension,
which also caused the outgoing contact header to be incorrect as well as failing
to match the encoded extension in the dialplan.
(closes issue #17892)
Reported by: wdoekes
Patches:
bug17892-1.patch uploaded by jpeeler (license 325)
Tested by: wdoekes
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289700 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On every incoming subscribe there is a iteration through all dialogs to find old subscribes and delete them. This is slow and not RFC conform. This was only needed in 1.2 cause a subscribe was not deleted when a dialog was destroyed, after 1.4 a subscribe get removed when its dialog is destroyed.
(closes issue #17950)
Reported by: schmidts
Tested by: schmidts
Review: https://reviewboard.asterisk.org/r/901/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@289622 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.6.2@288193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.6.2@288113 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.6.2@286116 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.6.2@286115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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/branches/1.6.2@285563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283690 | dvossel | 2010-08-26 10:22:28 -0500 (Thu, 26 Aug 2010) | 19 lines
Fixed how Asterisk destroys a dialog on channel hangup before invite receives a response.
If an ast_channel with a SIP tech pvt hangs up before the sip dialog gets a response
to its outgoing INVITE, Asterisk used to pretend_ack the INVITE. This is not rfc
compliant and results in confusion at the other endpoint. sip_pretend_ack will ack
and remove all the packets in the retransmit queue. This means that the INVITE will
stop retransmitting, and that any response to that INVITE that comes after the pretend_ack
occurs will be ignored.
Instead of faking any sort of acknowledgement for an outgoing INVITE during an internal
hangup, we should let the protocol stack process the INVITE transaction and terminate
the dialog properly. This is achieved by setting the PENDING_BYE flag. When this flag
is used, once the dialog proceeds to an escapable state the transaction will either be
canceled with a SIP_CANCEL or completed followed immediately by a BYE. Attempting to do
this any other way is incorrect. If the endpoint is not responding to the INVITE request,
the INVITE must continue to be retransmitted until it times out which will result in the
dialog being destroyed.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@283691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When pedantic mode is used, the dialog-info xml generated during a
ringing event must contain the to and from tag values. Otherwise if
a pickup occurs using INVITE with replaces, Astrisk will not be able
to locate the subscription.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@283594 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk now dynamically builds the "Supported" header depending
on what is enabled/disabled in sip.conf. Session timers used
to always be advertised as being supported even when they were disabled
in the configuration. This caused problems with some end points.
(issue #17005)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@283558 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283380 | dvossel | 2010-08-24 11:01:51 -0500 (Tue, 24 Aug 2010) | 11 lines
This fix makes sure the ast_channel hangs up correctly when the dialog's PENDING_BYE flag is set.
When the pending bye flag is used, it is possible that the dialog will terminate
and leave the sip_pvt->owner channel up. This is because we never hangup the
ast_channel after sending the SIP_BYE request. When we receive the response for
the SIP_BYE we set need_destroy which we would expect to destroy the dialog on the
next do_monitor loop, but this is not the case. The dialog will only be destroyed
once the owner is hungup even with the need_destroy flag set. This patch sets the
softhangup flag on the ast_channel when a SIP_BYE request is sent as a result of the
pending bye flag.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@283381 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r283048 | rmudgett | 2010-08-20 10:24:36 -0500 (Fri, 20 Aug 2010) | 22 lines
Q931 - Sending PROGRESS after sending ALERTING is a protocol error
The PRI layer in chan_dadhi will check if a PROGRESS message has already
been sent, and not allow sending another (although that is technically
allowed by the Q931 spec), however it does not protect against sending an
ALERTING and then sending a PROGRESS message, which is a violation of the
specification.
Most switches don't seem to care too deeply about this, but some do, and
will disconnect the call when receiving this invalid sequence.
Protocol specification reference: T-REC-Q.931-199805-I page 223, "Figure
A.5/Q.931 -- Overview protocol control (network side) point-point
(sheet 3 of 8)"
(closes issue #17874)
Reported by: nic_bellamy
Patches:
asterisk-1.4-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-1.6.2-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
asterisk-trunk-r282537_no-progress-after-alerting.patch uploaded by nic bellamy (license 299)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@283049 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282893 | dvossel | 2010-08-19 16:03:24 -0500 (Thu, 19 Aug 2010) | 11 lines
tos_sip option was not being set correctly
When tos_sip is used, the tos of the sip socket is only set
correctly if the socket binding changes on a reload. If the binding
stays the same but the TOS changes, the new tos value would not take
into effect. This patch fixes that.
(closes issue #17712)
Reported by: nickb
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@282894 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A new way of doing BLF pickup was introduced into 1.6.2. This feature
adds a call-id value into the XML of a SIP_NOTIFY message sent to alert
a subscriber that a device is ringing. This option should only be enabled
when the new 'notifycid' option is set... but this was not the case. Instead
the call-id value was included for every RINGING Notify message, which
caused a regression for people who used other methods for call pickup.
(closes issue #17633)
Reported by: urosh
Patches:
chan_sip.txt uploaded by urosh (license )
blf_cid_issue.diff uploaded by dvossel (license 671)
Tested by: dvossel, urosh, okrief, alecdavis
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@282235 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We zeroed out the peer's addr before it was removed from the
peers_by_ip container. This made it impossible to be removed
from the container as the addr is the key used by the container
to find the peer.
(closes issue #17774)
Reported by: kkm
Patches:
017774-sip-peer-leak-1.6.2.10.diff uploaded by kkm (license 888)
017774-sip-peer-leak-1.8.diff uploaded by kkm (license 888)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281390 | jpeeler | 2010-08-09 15:04:30 -0500 (Mon, 09 Aug 2010) | 13 lines
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@281391 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This changes the request to be sent with the transmit type XMIT_RELIABLE so that
sip_ack doesn't return false and cause the 401 to be ignored in cases where
authentication is required.
(closes issue #14255)
Reported by: zktech
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@280669 65c4cc65-6c06-0410-ace0-fbb531ad65f3
We were attempting to create a contactdeny rule based on the peer's
IP address before the peer's IP address had been set. By moving the
processing further down in the function, we can ensure stuff works
as we expect for it to.
(closes issue #17717)
Reported by: mmichelson
Patches:
17717.patch uploaded by mmichelson (license 60)
Tested by: DennisD
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@279784 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When you are using chan_dahdi ISDN signaling with immediate=yes and a call
comes in without a DNID then you get the DNID of a previous call.
Chan_dahdi does not touch the DNID field on a new call if it does not have
a DNID.
Made always copy the DNID from the new call.
The patches backport the relevant changes from trunk -r210387.
(closes issue #17568)
Reported by: wuwu
Patches:
issue17568_v1.4.patch uploaded by rmudgett (license 664)
issue17568_v1.6.2.patch uploaded by rmudgett (license 664)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes some cases of no outgoing calls on FXO before an incoming call.
Remove an unnecessary testing of an "off-hook" bit from DAHDI for FXO
(KS/GS) channels.In some cases the bit would not be initialized properly
before the first inbound call and thus prevent an outgoing call.
If those tests are actually required by anybody, they should define
DAHDI_CHECK_HOOKSTATE in channels/sig_analog.c .
(closes issue #14577)
Reported by: jkroon
Patches:
asterisk_chan_dahdi_hookstate_fix.diff uploaded by frawd (license 610)
Tested by: frawd
Review: https://reviewboard.asterisk.org/r/699/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@278524 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277530 | mnicholson | 2010-07-16 16:24:45 -0500 (Fri, 16 Jul 2010) | 11 lines
Merged revisions 277497 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277497 | mnicholson | 2010-07-16 16:18:38 -0500 (Fri, 16 Jul 2010) | 4 lines
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
FAX-128
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r277467 | rmudgett | 2010-07-16 15:27:51 -0500 (Fri, 16 Jul 2010) | 22 lines
Merged revisions 277419 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277419 | rmudgett | 2010-07-16 15:18:54 -0500 (Fri, 16 Jul 2010) | 15 lines
priexclusive in chan_dahdi.conf ignored when reloading dahdi module
During a reload, the priexclusive and outsignalling parameters are not
read in from the config file as intended. Unfortunately, they get set to
defaults as a result. This patch makes sure that they do not get set to
defaults during a reload.
(closes issue #17441)
Reported by: mtryfoss
Patches:
issue17441_v1.4.patch uploaded by rmudgett (license 664)
issue17441_v1.6.2.patch uploaded by rmudgett (license 664)
issue17441_trunk.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@277485 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r276788 | jpeeler | 2010-07-15 15:21:03 -0500 (Thu, 15 Jul 2010) | 6 lines
Correct not setting the bindport before attempting to open the socket.
Related to changes from 276571, I was accidentally testing with a port set in
my configuration causing me to miss this. Also moved the TCP handling as well
to occur before build_peer is called.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@276809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r276571 | jpeeler | 2010-07-14 17:58:24 -0500 (Wed, 14 Jul 2010) | 21 lines
Fix MWI notification transmission problems over SIP.
MWI updates were not being sent if no messages were found in the event cache.
This was corrected since a phone may need to clear its MWI status configured
previously from another mailbox.
Upon module or sip reload, MWI updates could not be sent due to the sipsock
socket not being set early enough in reload_config. The code handling the
descriptor assignment and such has simply been moved before the call to
build_peer.
Issuing a sip reload cleared the IP address of the peer, but skipped checking
the database for registration information. The database is now checked both
for sip reload and actually reloading the module.
If a transmission occurs before the do_monitor thread has started, do not
attempt to send a signal to it.
(closes issue #17398)
Reported by: ip-rob
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@276572 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r245192 | mmichelson | 2010-02-06 08:43:03 -0600 (Sat, 06 Feb 2010) | 21 lines
Remove useless sip options related to hash table size.
First off, these options weren't actually doing anything.
By the time the options were parsed, the peer and dialog
containers had already been allocated with their default
values.
Second, hash table size is something that doesn't really
make sense to change in a config file. If a user is that
interested in changing the hashtable size, he can modify
the source itself.
I have removed the parsing of the hash_peer, hash_user,
and hash_dialog options. I have removed the hash_user_size
variable altogether since it is not used at all. I also
changed hash_peer_size and hash_dialog_size to be constant,
and have changed the symbols to be in all caps as constants
typically are. I have also removed the entire section in
sip.conf.sample regarding configurable hashtable sizes.
........
(merge to 1.6.2 inspired by issue #17553)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@275469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r274284 | twilson | 2010-07-06 17:15:27 -0500 (Tue, 06 Jul 2010) | 18 lines
Merged revisions 274280 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r274280 | twilson | 2010-07-06 17:08:20 -0500 (Tue, 06 Jul 2010) | 9 lines
Add option to not do a call forward on 482 Loop Detected
Asterisk has always set up a forwarded call when receiving a 482 Loop Detected.
This prevents handling the call failure by just continuing on in the dialplan.
Since this would be a change in behavior, the new option to disable this
behavior is forwardloopdetected which defaults to 'yes'.
Review: https://reviewboard.asterisk.org/r/764/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@274360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r273078 | tilghman | 2010-06-29 18:20:40 -0500 (Tue, 29 Jun 2010) | 17 lines
Merged revisions 273060 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r273060 | tilghman | 2010-06-29 18:15:28 -0500 (Tue, 29 Jun 2010) | 10 lines
Allow the "useragent" value to be restored into memory from the realtime backend.
This value is purely informational. It does not alter configuration at all.
(closes issue #16029)
Reported by: Guggemand
Patches:
realtime-useragent.patch uploaded by Guggemand (license 897)
Tested by: Guggemand
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@273087 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r272370 | russell | 2010-06-23 18:09:28 -0500 (Wed, 23 Jun 2010) | 23 lines
Resolve some errors produced during module unload of chan_iax2.
The external test suite stops Asterisk using the "core stop gracefully" command.
The logs from the tests show that there are a number of problems with Asterisk
trying to cleanly shut down. This patch addresses the following type of error
that comes from chan_iax2:
[Jun 22 16:58:11] ERROR[29884]: lock.c:129 __ast_pthread_mutex_destroy:
chan_iax2.c line 11371 (iax2_process_thread_cleanup):
Error destroying mutex &thread->lock: Device or resource busy
For an example in the context of a build, see:
http://bamboo.asterisk.org/browse/AST-TRUNK-739/log
The primary purpose of this patch is to change the thread pool shutdown
procedure to be more explicit to ensure that the thread exits from a point
where it is not holding a lock. While testing that, I encountered various
crashes due to the order of operations in unload_module() being problematic.
I reordered some things there, as well.
Review: https://reviewboard.asterisk.org/r/736/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@272371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r271690 | mnicholson | 2010-06-22 07:58:28 -0500 (Tue, 22 Jun 2010) | 18 lines
Merged revisions 271689 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r271689 | mnicholson | 2010-06-22 07:52:27 -0500 (Tue, 22 Jun 2010) | 8 lines
Modify chan_sip's packet generation api to automatically calculate the Content-Length. This is done by storing packet content in a buffer until it is actually time to send the packet, at which time the size of the packet is calculated. This change was made to ensure that the Content-Length is always correct.
(closes issue #17326)
Reported by: kenner
Tested by: mnicholson, kenner
Review: https://reviewboard.asterisk.org/r/693/
........
This change also adds an ast_str_copy_string() function (similar to ast_copy_string), that copies one ast_str into another, properly handling embedded nulls.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@271691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r269307 | rmudgett | 2010-06-09 11:54:38 -0500 (Wed, 09 Jun 2010) | 12 lines
Eliminate deadlock potential in dahdi_fixup().
Calling dahdi_indicate() within dahdi_fixup() while the owner pointers are
in a potentially inconsistent state is a potentially bad thing in
principle.
However, calling dahdi_indicate() when the channel private lock is already
held can cause a deadlock if the PRI lock is needed because
dahdi_indicate() will also get the channel private lock. The pri_grab()
function assumes that the channel private lock is held once to avoid
deadlock.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@271338 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r270867 | dvossel | 2010-06-16 12:36:51 -0500 (Wed, 16 Jun 2010) | 28 lines
Merged revisions 270866 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r270866 | dvossel | 2010-06-16 12:35:29 -0500 (Wed, 16 Jun 2010) | 22 lines
fixes chan_iax2 race condition
There is code in chan_iax2.c that attempts to guarantee that only a single
active thread will handle a call number at a time. This code works once
the thread is added to an active_list of threads, but we are not currently
guaranteed that a newly activated thread will enter the active_list immediately
because it is left up to the thread to add itself after frames have been
queued to it. This means that if two frames come in for the same call number
at the same time, it is possible for them to grab two separate threads because
the first thread did not add itself to the active_list fast enough. This
causes some pretty complex problems.
This patch resolves this race condition by immediately adding an activated
thread to the active_list within the network thread and only depending on
the thread to remove itself once it is done processing the frames queued to
it. By doing this we are guaranteed that if another frame for the same call
number comes in at the same time, that this thread will immediately be found
in the active_list of threads.
Review: https://reviewboard.asterisk.org/r/720/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@270868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r270658 | twilson | 2010-06-15 15:18:04 -0500 (Tue, 15 Jun 2010) | 20 lines
Make contactdeny apply to src ip when nat=yes
chan_sip's "contactdeny" feature screens the "to be registered contact".
In case of nat=yes it should not use the address information from the
Contact header (which is not used at all for routing), but the source
IP address of the request.
Thus, if nat=yes and a client sends a request from a denied IP address
(e.g. by spoofing the src-IP address) it can bypass the screening.
This commit makes contactdeny apply to the src ip when nat=yes instead.
(closes issue #17276)
Reported by: klaus3000
Patches:
patch-asterisk-trunk-contactdeny.txt uploaded by klaus3000 (license 65)
Tested by: klaus3000
Review: [full review board URL with trailing slash]
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@270693 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r267352 | russell | 2010-06-02 17:46:37 -0500 (Wed, 02 Jun 2010) | 7 lines
try to fix some random chan_h323 compilation failures
After some debugging, the random chan_h323 build failures appear to be due
to complications introduced by some chan_h323 specific build stuff getting
triggered during a clean. Simplify this by moving the h323 clean commands
down into channels/makefile.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@267353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r265698 | mmichelson | 2010-05-25 15:59:04 -0500 (Tue, 25 May 2010) | 12 lines
Properly use peer's outboundproxy for outbound REGISTERs.
The logic used in transmit_register to get the outboundproxy for a peer
was flawed since this value would be overridden shortly afterwards when
create_addr was called.
In addition, this also fixes some logic used when parsing users.conf so
that the peer name is placed in the internally-generated register string
so that an outboundproxy set in the Asterisk GUI will be used for outbound
REGISTERs.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@265699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264452 | mmichelson | 2010-05-19 16:29:08 -0500 (Wed, 19 May 2010) | 86 lines
Fix transcode_via_sln option with SIP calls and improve PLC usage.
From reviewboard:
The problem here is a bit complex, so try to bear with me...
It was noticed by a Digium customer that generic PLC (as configured in
codecs.conf) did not appear to actually be having any sort of benefit when
packet loss was introduced on an RTP stream. I reproduced this issue myself
by streaming a file across an RTP stream and dropping approx. 5% of the
RTP packets. I saw no real difference between when PLC was enabled or disabled
when using wireshark to analyze the RTP streams.
After analyzing what was going on, it became clear that one of the problems
faced was that when running my tests, the translation paths were being set
up in such a way that PLC could not possibly work as expected. To illustrate,
if packets are lost on channel A's read stream, then we expect that PLC will
be applied to channel B's write stream. The problem is that generic PLC can
only be done when there is a translation path that moves from some codec to
SLINEAR. When I would run my tests, I found that every single time, read
and write translation paths would be set up on channel A instead of channel
B. There appeared to be no real way to predict which channel the translation
paths would be set up on.
This is where Kevin swooped in to let me know about the transcode_via_sln
option in asterisk.conf. It is supposed to work by placing a read translation
path on both channels from the channel's rawreadformat to SLINEAR. It also
will place a write translation path on both channels from SLINEAR to the
channel's rawwriteformat. Using this option allows one to predictably set up
translation paths on all channels. There are two problems with this, though.
First and foremost, the transcode_via_sln option did not appear to be working
properly when I was placing a SIP call between two endpoints which did not
share any common formats. Second, even if this option were to work, for PLC
to be applied, there had to be a write translation path that would go from
some format to SLINEAR. It would not work properly if the starting format
of translation was SLINEAR.
The one-line change presented in this review request in chan_sip.c fixed the
first issue for me. The problem was that in sip_request_call, the
jointcapability of the outbound channel was being set to the format passed to
sip_request_call. This is nativeformats of the inbound channel. Because of this,
when ast_channel_make_compatible was called by app_dial, both channels already
had compatibly read and write formats. Thus, no translation path was set up at
the time. My change is to set the jointcapability of the sip_pvt created during
sip_request_call to the intersection of the inbound channel's nativeformats and
the configured peer capability that we determined during the earlier call to
create_addr. Doing this got the translation paths set up as expected when using
transcode_via_sln.
The changes presented in channel.c fixed the second issue for me. First and
foremost, when Asterisk is started, we'll read codecs.conf to see the value of
the genericplc option. If this option is set, and ast_write is called for a
frame with no data, then we will attempt to fill in the missing samples for
the frame. The implementation uses a channel datastore for maintaining the
PLC state and for creating a buffer to store PLC samples in. Even when we
receive a frame with data, we'll call plc_rx so that the PLC state will have
knowledge of the previous voice frame, which it can use as a basis for when
it comes time to actually do a PLC fill-in.
So, reviewers, now I ask for your help. First off, there's the one line change
in chan_sip that I have put in. Is it right? By my logic it seems correct, but
I'm sure someone can tell me why it is not going to work. This is probably the
change I'm least concerned about, though. What concerns me much more is the
set of changes in channel.c. First off, am I even doing it right? When I run
tests, I can clearly see that when PLC is activated, I see a significant increase
in RTP traffic where I would expect it to be. However, in my humble opinion, the
audio sounds kind of crappy whenever the PLC fill-in is done. It sounds worse to
me than when no PLC is used at all. I need someone to review the logic I have used
to be sure that I'm not misusing anything. As far as I can see my pointer arithmetic
is correct, and my use of AST_FRIENDLY_OFFSET should be correct as well, but I'm
sure someone can point out somewhere where I've done something incorrectly.
As I was writing this review request up, I decided to give the code a test run under
valgrind, and I find that for some reason, calls to plc_rx are causing some invalid
reads. Apparently I'm reading past the end of a buffer somehow. I'll have to dig around
a bit to see why that is the case. If it's obvious to someone reviewing, speak up!
Finally, I have one other proposal that is not reflected in my code review. Since
without transcode_via_sln set, one cannot predict or control where a translation
path will be up, it seems to me that the current practice of using PLC only when
transcoding to SLINEAR is not useful. I recommend that once it has been determined
that the method used in this code review is correct and works as expected, then
the code in translate.c that invokes PLC should be removed.
Review: https://reviewboard.asterisk.org/r/622/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264453 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r264331 | dvossel | 2010-05-19 14:21:04 -0500 (Wed, 19 May 2010) | 13 lines
fixes crash in check_rtp_timeout
During deadlock avoidance the sip dialog pvt is locked and
unlocked. When this occurs we have no guarantee the pvt's owner
is still valid. We were trying to access the pvt's owner after
this without checking to see if it still existed first.
(closes issue #17271)
Reported by: under
Patches:
check_rtp_timeout.diff uploaded by under (license 914)
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@264332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r262236 | dvossel | 2010-05-10 13:36:10 -0500 (Mon, 10 May 2010) | 11 lines
fixes crash in chan_console
There is a race condition between console_hangup()
and start_stream(). It is possible for console_hangup()
to be called and then the stream thread to begin after the hangup.
To avoid this a check in start_stream() to make sure the pvt-owner
still exists while the pvt lock is held is made. If the owner
is gone that means the channel hung up and start_stream should
be aborted.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@262237 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r261560 | tilghman | 2010-05-06 10:39:10 -0500 (Thu, 06 May 2010) | 8 lines
Permit more lines within a SIP body to be parsed.
The example given within the related issue showed 120 lines, which was mostly
a result of the body being XML.
(closes issue #17179)
Reported by: khw
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@261563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Russell Bryant
Richard Mudgett
Jeff Peeler
Stefan Schmidt
Matthew Nicholson
Terry Wilson
David Vossel
Paul Belanger
Tilghman Lesher
Jason Parker
Brett Bryant
Mark Michelson
Tzafrir Cohen