This patch adds a new dahdi_wait function to specifically wait for the wink
event. If the wink is not eventually received the channel is hung up.
(closes issue #14434)
Reported by: araasch
Patches:
emwinkmod uploaded by araasch (license 693)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@207638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r207424 | mmichelson | 2009-07-20 14:48:12 -0500 (Mon, 20 Jul 2009) | 39 lines
Merged revisions 207423 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r207423 | mmichelson | 2009-07-20 14:39:59 -0500 (Mon, 20 Jul 2009) | 33 lines
Answer video SDP offers properly when videosupport is not enabled.
Copied from Review board:
In issue 12434, the reporter describes a situation in which audio and video
is offered on the call, but because videosupport is disabled in sip.conf,
Asterisk gives no response at all to the video offer. According to RFC 3264,
all media offers should have a corresponding answer. For offers we do not
intend to actually reply to with meaningful values, we should still reply
with the port for the media stream set to 0.
In this patch, we take note of what types of media have been offered and
save the information on the sip_pvt. The SDP in the response will take into
account whether media was offered. If we are not otherwise going to answer
a media offer, we will insert an appropriate m= line with the port set to 0.
It is important to note that this patch is pretty much a bandage being
applied to a broken bone. The patch *only* helps for situations where video
is offered but videosupport is disabled and when udptl_pt is disabled but
T.38 is offered. Asterisk is not guaranteed to respond to every media offer.
Notable cases are when multiple streams of the same type are offered.
The 2 media stream limit is still present with this patch, too.
In trunk and the 1.6.X branches, things will be a bit different since Asterisk
also supports text in SDPs as well.
(closes issue #12434)
Reported by: mnnojd
Review: https://reviewboard.asterisk.org/r/311
Review: https://reviewboard.asterisk.org/r/313
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@207523 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
to make merging easier. These changes are already on trunk.
................
r145293 | rmudgett | 2008-09-30 18:55:24 -0500 (Tue, 30 Sep 2008) | 54 lines
channels/chan_misdn.c
channels/misdn/isdn_lib.c
* Miscellaneous other fixes from trunk to make merging easier later.
........
r145200 | rmudgett | 2008-09-30 16:00:54 -0500 (Tue, 30 Sep 2008) | 7 lines
* Miscellaneous formatting changes to make v1.4 and trunk
more merge compatible in the mISDN area.
channels/chan_misdn.c
* Eliminated redundant code in cb_events() EVENT_SETUP
........
r144257 | crichter | 2008-09-24 03:42:55 -0500 (Wed, 24 Sep 2008) | 9 lines
improved helptext of misdn_set_opt.
........
r142181 | rmudgett | 2008-09-09 12:30:52 -0500 (Tue, 09 Sep 2008) | 1 line
Cleaned up comment
........
r138738 | rmudgett | 2008-08-18 16:07:28 -0500 (Mon, 18 Aug 2008) | 30 lines
channels/chan_misdn.c
* Made bearer2str() use allowed_bearers_array[]
* Made use the causes.h defines instead of hardcoded numbers.
* Made use Asterisk presentation indicator values if either of the
mISDN presentation or screen options are negative.
* Updated the misdn_set_opt application option descriptions.
* Renamed the awkward Caller ID presentation misdn_set_opt
application option value not_screened to restricted.
Deprecated the not_screened option value.
channels/misdn/isdn_lib.c
* Made use the causes.h defines instead of hardcoded numbers.
* Fixed some spelling errors and typos.
* Added all defined facility code strings to fac2str().
channels/misdn/isdn_lib.h
* Added doxygen comments to struct misdn_bchannel.
channels/misdn/isdn_lib_intern.h
* Added doxygen comments to struct misdn_stack.
channels/misdn_config.c
configs/misdn.conf.sample
* Updated the mISDN presentation and screen parameter descriptions.
doc/misdn.txt (doc/tex/misdn.tex)
* Updated the misdn_set_opt application option descriptions.
* Fixed some spelling errors and typos.
................
r158010 | rmudgett | 2008-11-19 19:46:09 -0600 (Wed, 19 Nov 2008) | 9 lines
Merged revision 157977 from
https://origsvn.digium.com/svn/asterisk/team/group/issue8824
........
Fixes JIRA ABE-1726
The dial extension could be empty if you are using MISDN_KEYPAD
to control ISDN provider features.
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@207315 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r206939 | dvossel | 2009-07-17 11:13:22 -0500 (Fri, 17 Jul 2009) | 20 lines
Merged revisions 206938 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206938 | dvossel | 2009-07-17 11:05:06 -0500 (Fri, 17 Jul 2009) | 14 lines
SIP incorrect From: header information when callpres is prohib
Some ITSP make use of the "Anonymous" display name to detect a
requirement to withhold caller id across the PSTN. This does
not work if the display name is "Unknown".
(closes issue #14465)
Reported by: Nick_Lewis
Patches:
chan_sip.c-callerpres.patch uploaded by Nick (license 657)
chan_sip.c-callerpres_trunk.patch uploaded by dvossel (license 671)
Tested by: Nick_Lewis, dvossel
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206940 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r206768 | dvossel | 2009-07-15 17:04:13 -0500 (Wed, 15 Jul 2009) | 8 lines
Session timer were not activated if Supported header field in INVITE had both "timer" and other options.
(closes issue #15403)
Reported by: makoto
Patches:
sip-session-timer.patch uploaded by makoto (license
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206770 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r206707 | rmudgett | 2009-07-15 16:14:41 -0500 (Wed, 15 Jul 2009) | 33 lines
Merged revisions 206706 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r206706 | rmudgett | 2009-07-15 15:44:55 -0500 (Wed, 15 Jul 2009) | 26 lines
Merged revision 206700 from
https://origsvn.digium.com/svn/asterisk/be/branches/C.2-...
..........
Fixed chan_misdn crash because mISDNuser library is not thread safe.
With Asterisk the mISDNuser library is driven by two threads concurrently:
1. channels/misdn/isdn_lib.c::manager_event_handler()
2. channels/misdn/isdn_lib.c::misdn_lib_isdn_event_catcher()
Calls into the library are done concurrently and recursively from
isdn_lib.c.
Both threads can fiddle with the master/child layer3_proc_t lists. One
thread may traverse the list when the other interrupts it and then removes
the list element which the first thread was currently handling. This is
exactly what caused the crash. About 60 calls were needed to a Gigaset
CX475 before it occurred once.
This patch adds locking when calling into the mISDNuser library.
This also fixes some cb_log calls with wrong port parameter.
JIRA ABE-1913
Patches: misdn-locking.patch (Modified with mostly cosmetic changes)
..........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206765 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r206702 | dvossel | 2009-07-15 15:20:01 -0500 (Wed, 15 Jul 2009) | 10 lines
callerid(num) is wrong when username is missing
A domain only sip uri <sip:123.123.123.123> would return
123.123.123.123 as callid num. Now, if the username is
missing from a uri, the callerid num field is left empty.
(closes issue #15476)
Reported by: viraptor
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206703 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r206489 | rmudgett | 2009-07-14 12:01:48 -0500 (Tue, 14 Jul 2009) | 35 lines
Merged revisions 206487 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r206487 | rmudgett | 2009-07-14 11:44:47 -0500 (Tue, 14 Jul 2009) | 28 lines
Fixes several call transfer issues with chan_misdn.
* issue #14355 - Crash if attempt to transfer a call to an application.
Masquerade the other pair of the four asterisk channels involved in the
two calls. The held call already must be a bridged call (not an
applicaton) or it would have been rejected.
* issue #14692 - Held calls are not automatically cleared after transfer.
Allow the core to initate disconnect of held calls to the ISDN port. This
also fixes a similar case where the party on hold hangs up before being
transferred or taken off hold.
* JIRA ABE-1903 - Orphaned held calls left in music-on-hold.
Do not simply block passing the hangup event on held calls to asterisk
core.
* Fixed to allow held calls to be transferred to ringing calls.
Previously, held calls could only be transferred to connected calls.
* Eliminated unused call states to simplify hangup code.
* Eliminated most uses of "holded" because it is not a word.
(closes issue #14355)
(closes issue #14692)
Reported by: sodom
Patches:
misdn_xfer_v14_r205839.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r206386 | russell | 2009-07-14 09:51:44 -0500 (Tue, 14 Jul 2009) | 20 lines
Merged revisions 206385 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
................
r206385 | russell | 2009-07-14 09:48:00 -0500 (Tue, 14 Jul 2009) | 13 lines
Merged revisions 206384 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.2
........
r206384 | russell | 2009-07-14 09:45:47 -0500 (Tue, 14 Jul 2009) | 6 lines
Ensure apathetic replies are sent out on the proper socket.
chan_iax2 supports multiple address bindings. The send_apathetic_reply()
function did not attempt to send its response on the same socket that the
incoming message came in on.
........
................
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@206389 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205985 | dvossel | 2009-07-10 16:42:10 -0500 (Fri, 10 Jul 2009) | 16 lines
SIP register not using peer's outbound proxy
If callbackextension is defined for a peer it successfully causes
a registration to occur, but the registration ignores the
outboundproxy settings for the peer. This patch allows the
peer to be passed to obproxy_get() in transmit_register().
(closes issue #14344)
Reported by: Nick_Lewis
Patches:
callbackextension_peer_trunk.diff uploaded by dvossel (license 671)
Tested by: dvossel
Review: https://reviewboard.asterisk.org/r/294/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205986 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r205840 | dvossel | 2009-07-10 11:42:04 -0500 (Fri, 10 Jul 2009) | 37 lines
Merged revisions 205804 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205804 | dvossel | 2009-07-10 11:23:59 -0500 (Fri, 10 Jul 2009) | 31 lines
SIP registration auth loop caused by stale nonce
If an endpoint sends two registration requests in a very short
period of time with the same nonce, both receive 401 responses
from Asterisk, each with a different nonce (the second 401
containing the current nonce and the first one being stale).
If the endpoint responds to the first 401, it does not match
the current nonce so Asterisk sends a third 401 with a newly
generated nonce (which updates the current nonce)... Now if
the endpoint responds to the second 401, it does not match the
current nonce either and Asterisk sends a fourth 401 with a
newly generated nonce... This loop goes on and on.
There appears to be a simple fix for this. If the nonce from
the request does not match our nonce, but is a good response
to a previous nonce, instead of sending a 401 with a newly
generated nonce, use the current one instead. This breaks
the loop as the nonce is not updated until a response is
received. Additional logic has been added to make sure no
nonce can be responded to twice though.
(closes issue #15102)
Reported by: Jamuel
Patches:
patch-bug_0015102 uploaded by Jamuel (license 809)
nonce_sip.diff uploaded by dvossel (license 671)
Tested by: Jamuel
Review: https://reviewboard.asterisk.org/r/289/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205841 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r205776 | mmichelson | 2009-07-10 10:56:45 -0500 (Fri, 10 Jul 2009) | 16 lines
Merged revisions 205775 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205775 | mmichelson | 2009-07-10 10:51:36 -0500 (Fri, 10 Jul 2009) | 10 lines
Ensure that outbound NOTIFY requests are properly routed through stateful proxies.
With this change, we make note of Record-Route headers present in any SUBSCRIBE
request that we receive so that our outbound NOTIFY requests will have the proper
Route headers in them.
(closes issue #14725)
Reported by: ibc
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r205728 | rmudgett | 2009-07-09 18:37:53 -0500 (Thu, 09 Jul 2009) | 21 lines
No audio on calls from Asterisk to various ISDN devices until DTMF sent by caller.
Add missing clearing of the dialing flag when the ISDN call is CONNECTED.
(i.e. When libpri generates the event PRI_EVENT_ANSWER.)
(closes issue #15420)
Reported by: scottbmilne
Patches:
bug15420-1.4.25.1-diff2.txt uploaded by alecdavis (license 585)
Tested by: scottbmilne, alecdavis
(closes issue #15416)
Reported by: avinoash
(closes issue #15389)
Reported by: alecdavis
This patch should also fix the following issue:
(issue #15205)
Reported by: vinsik
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r205696 | kpfleming | 2009-07-09 16:20:23 -0500 (Thu, 09 Jul 2009) | 16 lines
Repair ability of SendFAX/ReceiveFAX to respond to T.38 switchover.
Recent changes in T.38 negotiation in Asterisk caused these applications to
not respond when the other endpoint initiated a switchover to T.38; this
resulted in the T.38 switchover failing, and the FAX attempt to be made
using an audio connection, instead of T.38 (which would usually cause the
FAX to fail completely).
This patch corrects this problem, and the applications will now correctly
respond to the T.38 switchover request. In addition, the response will include
the appopriate T.38 session parameters based on what the other end offered
and what our end is capable of.
(closes issue #14849)
Reported by: afosorio
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@205699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r204835 | rmudgett | 2009-07-02 17:01:28 -0500 (Thu, 02 Jul 2009) | 17 lines
Merged revisions 204834 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204834 | rmudgett | 2009-07-02 16:59:43 -0500 (Thu, 02 Jul 2009) | 10 lines
Removed confusing warning message "Got Busy in Connected State"
If an incoming mISDN call is answered with the Answer application and a
subsequent Dial gets a busy endpoint then it is valid for that already
connected channel to get the busy indication. Asterisk will play the busy
tones until the dialplan plays something else or hangs up the call.
(closes issue #11974)
Reported by: fvdb
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@204838 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r204301 | mmichelson | 2009-06-29 17:50:35 -0500 (Mon, 29 Jun 2009) | 15 lines
Merged revisions 204300 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204300 | mmichelson | 2009-06-29 17:45:34 -0500 (Mon, 29 Jun 2009) | 9 lines
Add error message so that it is clear why a SIP peer was not processed when
a DNS lookup fails on a host or outboundproxy.
(closes issue #13432)
Reported by: p_lindheimer
Patches:
outboundproxy.patch uploaded by p (license 558)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@204304 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r204247 | mmichelson | 2009-06-29 16:48:54 -0500 (Mon, 29 Jun 2009) | 32 lines
Merged revisions 204243,204246 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r204243 | mmichelson | 2009-06-29 16:23:43 -0500 (Mon, 29 Jun 2009) | 22 lines
Fix a problem where chan_sip would ignore "old" but valid responses.
chan_sip has had a problem for quite a long time that would manifest when
Asterisk would send multiple SIP responses on the same dialog before receiving
a response. The problem occurred because chan_sip only kept track of the highest
outgoing sequence number used on the dialog. If Asterisk sent two requests out,
and a response arrived for the first request sent, then Asterisk would ignore
the response. The result was that Asterisk would continue retransmitting the
requests and ignoring the responses until the maximum number of retransmissions
had been reached.
The fix here is to rearrange the code a bit so that instead of simply comparing
the sequence number of the response to our latest outgoing sequence number, we
walk our list of outstanding packets and determine if there is a match. If there is,
we continue. If not, then we ignore the response.
In doing this, I found a few completely useless variables that I have now removed.
(closes issue #11231)
Reported by: flefoll
Review: https://reviewboard.asterisk.org/r/298
........
r204246 | mmichelson | 2009-06-29 16:37:05 -0500 (Mon, 29 Jun 2009) | 3 lines
Fix build oops.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@204250 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203909 | rmudgett | 2009-06-26 20:07:52 -0500 (Fri, 26 Jun 2009) | 23 lines
Merged revisions 203908 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203908 | rmudgett | 2009-06-26 19:55:12 -0500 (Fri, 26 Jun 2009) | 16 lines
The ISDN CPE side should not exclusively pick B channels normally.
Before this patch, Asterisk unconditionally picked B channels exclusively
on the CPE side and normally allowed alternative B channels on the network
side. Now Asterisk does the opposite.
Reasons for the CPE side to normally not pick B channels exclusively:
* For CPE point-to-multipoint mode (i.e. phone side), the CPE side does
not have enough information to exclusively pick B channels. (There may be
other devices on the line.)
* Q.931 gives preference to the network side picking B channels.
* Some telcos require the CPE side to not pick B channels exclusively.
(closes issue #14383)
Reported by: mbrancaleoni
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203941 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r203672 | jpeeler | 2009-06-26 14:03:25 -0500 (Fri, 26 Jun 2009) | 16 lines
Check if polarityonanswerdelay has elapsed before setting a channel as answered
after a polarity reversal.
Previously on a polarity switch event chan_dahdi would set the channel
immediately as answered. This would cause problems if a polarity reversal
occurred when the line was picked up as the dial would not have yet occurred.
Now if the polarity reversal occurs before delay has elapsed after coming off
hook or an answer, it is ignored. Also, some refactoring was done in
_handle_event.
(closes issue #13917)
Reported by: alecdavis
Patches:
chan_dahdi.bug13917.feb09.diff2.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203709 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r203258 | qwell | 2009-06-25 14:22:46 -0500 (Thu, 25 Jun 2009) | 10 lines
Unmute when we get a dtmfup (we muted on dtmfdown) event.
This would occasionally cause one-way audio when using hardware DTMF detection.
(closes issue #14761)
Reported by: tzafrir
Patches:
v1-14761.patch uploaded by dimas (license 88)
Tested by: tzafrir, dimas
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203276 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203116 | russell | 2009-06-25 11:04:10 -0500 (Thu, 25 Jun 2009) | 18 lines
Merged revisions 203115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203115 | russell | 2009-06-25 11:02:16 -0500 (Thu, 25 Jun 2009) | 11 lines
Resolve a crash related to a T.38 reinvite race condition.
This change resolves a crash observed locally during some T.38 testing.
A call was set up using a call file, and when the T.38 reinvite came in,
the channel state was still AST_STATE_DOWN. The reason is explained by
a comment in the code that previously lived in the handling of
AST_STATE_RINGING. This change modifies the logic to handle the same
race condition for any channel state that is not UP.
(closes ABE-1895)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203119 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r203037 | rmudgett | 2009-06-24 16:08:55 -0500 (Wed, 24 Jun 2009) | 15 lines
Merged revisions 203036 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r203036 | rmudgett | 2009-06-24 16:01:43 -0500 (Wed, 24 Jun 2009) | 8 lines
Improved chan_dahdi.conf pritimer error checking.
Valid format is: pritimer=timer_name,timer_value
* Fixed segfault if the ',' is missing.
* Completely check the range returned by pri_timer2idx() to prevent
possible access outside array bounds.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@203077 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r202343 | mmichelson | 2009-06-22 09:58:24 -0500 (Mon, 22 Jun 2009) | 36 lines
Merged revisions 202341-202342 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r202341 | mmichelson | 2009-06-22 09:42:55 -0500 (Mon, 22 Jun 2009) | 26 lines
Fix a situation in which Asterisk would not stop retransmitting 487s.
If a CANCEL were received by Asterisk, we would send a 487 in response
to the original INVITE and a 200 OK for the CANCEL. If there were a network
hiccup which caused the 200 OK and the 487 to be lost, then the UA communicating
with Asterisk may try to retransmit its CANCEL. Asterisk's response to this used
to be to try sending another 487 to the canceled INVITE and another 200 OK to the
CANCEL.
The problem here is that the originally-sent 487 was sent "reliably" meaning that
it will be retransmitted until it is received properly. So when we receive the second
CANCEL it is likely that the first batch of 487s we sent is still going strong and
reaches the UA. The result was that the second set of 487s would be retransmitted
constantly until the maximum number of retries had been reached.
The fix for this is that if we receive a second CANCEL for an INVITE, then we cancel
the retransmission of the first set of 487s and start a second set. This causes the
dialog to be terminated reasonably.
(closes issue #14584)
Reported by: klaus3000
Patches:
14584_v2.patch uploaded by mmichelson (license 60)
Tested by: klaus3000
........
r202342 | mmichelson | 2009-06-22 09:44:58 -0500 (Mon, 22 Jun 2009) | 3 lines
Remove an extra debug line left from previous commit.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@202346 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r202337 | mmichelson | 2009-06-22 09:35:09 -0500 (Mon, 22 Jun 2009) | 31 lines
Merged revisions 202336 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r202336 | mmichelson | 2009-06-22 09:34:05 -0500 (Mon, 22 Jun 2009) | 25 lines
Fix a possible infinite loop in SDP parsing during glare situation.
There was a while loop in get_ip_and_port_from_sdp which was controlled
by a call to get_sdp_iterate. The loop would exit either if what we were
searching for was found or if the return was NULL. The problem is that
get_sdp_iterate never returns NULL. This means that if what we were searching
for was not present, the loop would run infinitely. This modification of the
loop fixes the problem.
(closes issue #15213)
Reported by: schmidts
(closes issue #15349)
Reported by: samy
(closes issue #14464)
Reported by: pj
(closes issue #15345)
Reported by: aragon
Patches:
sip_inf_loop.patch uploaded by mmichelson (license 60)
Tested by: aragon
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@202340 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201570 | dvossel | 2009-06-18 10:16:05 -0500 (Thu, 18 Jun 2009) | 11 lines
parsing extension correctly from sip register lines
If a transport type was specified, but no extension, parsing of the extension would return whatever was after the transport rather than defaulting to 's'.
(closes issue #15111)
Reported by: ffs
Patches:
chan_sip.c_register-parser.patch uploaded by ffs (license 730)
Tested by: ffs, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201462 | mmichelson | 2009-06-17 15:10:01 -0500 (Wed, 17 Jun 2009) | 12 lines
Fix problem with no audio due to ignoring the SDP.
A recent change to our SDP version comparison made audio not function
on some calls. This was because of a test wherein we were trying to
see if an unsigned value was less than 0. This is a dumb comparison
and arguably the compiler should have warned about it. Alas, though,
it slipped past. Now it's fixed by changing the variable to be a
signed type.
Found by several developers. Tested by mnicholson and dbrooks.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201465 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r201344 | dvossel | 2009-06-17 10:20:26 -0500 (Wed, 17 Jun 2009) | 16 lines
SIP registry ref count error
During a sip reload, the list of sip_registry objects are
supposed to be traversed, unlinked, and destroyed, but
destruction never takes place due to a ref counting error.
This causes a memory leak when registry items are removed
from sip.conf and reloaded. While the registries are removed
from the global list, they are not removed from the scheduler.
Because of this, SIP register attempts continue to be sent
out for the item even though it may no longer be in the .conf.
(closes issue #15295)
Reported by: amorsen
Review: https://reviewboard.asterisk.org/r/282/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@201360 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200946 | dvossel | 2009-06-16 11:03:30 -0500 (Tue, 16 Jun 2009) | 32 lines
SIP transport type issues
What this patch addresses:
1. ast_sip_ouraddrfor() by default binds to the UDP address/port
reguardless if the sip->pvt is of type UDP or not. Now when no
remapping is required, ast_sip_ouraddrfor() checks the sip_pvt's
transport type, attempting to set the address and port to the
correct TCP/TLS bindings if necessary.
2. It is not necessary to send the port number in the Contact
header unless the port is non-standard for the transport type.
This patch fixes this and removes the todo note.
3. In sip_alloc(), the default dialog built always uses transport
type UDP. Now sip_alloc() looks at the sip_request (if present)
and determines what transport type to use by default.
4. When changing the transport type of a sip_socket, the file
descriptor must be set to -1 and in some cases the tcptls_session's
ref count must be decremented and set to NULL. I've encountered
several issues associated with this process and have created a function,
set_socket_transport(), to handle the setting of the socket type.
(closes issue #13865)
Reported by: st
Patches:
dont_add_port_if_tls.patch uploaded by Kristijan (license 753)
13865.patch uploaded by mmichelson (license 60)
tls_port_v5.patch uploaded by vrban (license 756)
transport_issues.diff uploaded by dvossel (license 671)
Tested by: mmichelson, Kristijan, vrban, jmacz, dvossel
Review: https://reviewboard.asterisk.org/r/278/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200689 | kpfleming | 2009-06-15 15:42:38 -0500 (Mon, 15 Jun 2009) | 11 lines
Accept T.38 re-INVITE responses with invalid SDP versions.
This commit changes the 'incoming SDP version' check logic a bit more; when
'ignoresdpversion' is *not* set for a peer, if we initiate a re-INVITE to
switch to T.38, we'll always accept the peer's SDP response, even if they
don't properly increment the SDP version number as they should. If this situation
occurs, a warning message will be generated suggesting that the peer's
configuration be changed to include the 'ignoresdpversion' configuration option
(although ideally they'd fix their SIP implementation to be RFC compliant).
AST-221
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200690 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r200477 | moy | 2009-06-14 01:13:48 -0500 (Sun, 14 Jun 2009) | 3 lines
added openr2 to menuselect-deps.in, recent commit in menuselect made me realize this was never done but was working anyways
also added support for skip category request feature of openr2 and updated chan_dahdi.conf.sample
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@200512 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r199818 | dvossel | 2009-06-09 15:47:57 -0500 (Tue, 09 Jun 2009) | 11 lines
CLI NOTIFY sending wrong transport type.
SIP's cli NOTIFY command only used UDP rather than copying the transport type from the peer.
(closes issue #15283)
Reported by: jthurman
Patches:
sip-notify-tcp-svn199728.patch uploaded by jthurman (license 614)
Tested by: jthurman, dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@199819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r199227 | mmichelson | 2009-06-05 08:51:08 -0500 (Fri, 05 Jun 2009) | 14 lines
Correct "dahdi show channels" output when specifying a group.
Since a DAHDI channel may belong to multiple groups, we need to use
a bitwise and instead of equivalence to determine whether to display
the channel information.
(closes issue #15248)
Reported by: gentian
Patches:
15248.patch uploaded by mmichelson (license 60)
Tested by: gentian
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@199230 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r198824 | dvossel | 2009-06-02 12:55:35 -0500 (Tue, 02 Jun 2009) | 8 lines
fixes issue with channels not going down after transfer
Iax2 currently does not support native bridging if the timeoutms value is set. We check for that in iax2_bridge, but then set timeoutms to 0 by default. If the timeoutms is not provided it is set to -1. By setting timeoutms to 0 it is processed causing a bridging retry loop.
(closes issue #15216)
Reported by: oxymoron
Tested by: dvossel
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@198827 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197621 | eliel | 2009-05-28 12:01:48 -0400 (Thu, 28 May 2009) | 19 lines
Merged revisions 197562 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197562 | eliel | 2009-05-28 11:21:32 -0400 (Thu, 28 May 2009) | 13 lines
Use the address we already know when reloading a peer with nat=yes.
If we already have an address for a peer, and we are reloading the sip
configuration, try to use that address to contact the peer, instead of
getting it from the Contact.
(closes issue #15194)
Reported by: ibc
Patches:
sip.patch uploaded by eliel (license 64)
Tested by: manwe
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197625 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197606 | mmichelson | 2009-05-28 10:32:19 -0500 (Thu, 28 May 2009) | 22 lines
Recorded merge of revisions 197588 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197588 | mmichelson | 2009-05-28 10:27:49 -0500 (Thu, 28 May 2009) | 16 lines
Allow for media to arrive from an alternate source when responding to a reinvite with 491.
When we receive a SIP reinvite, it is possible that we may not be able to process the
reinvite immediately since we have also sent a reinvite out ourselves. The problem is
that whoever sent us the reinvite may have also sent a reinvite out to another party,
and that reinvite may have succeeded.
As a result, even though we are not going to accept the reinvite we just received, it
is important for us to not have problems if we suddenly start receiving RTP from a new
source. The fix for this is to grab the media source information from the SDP of the
reinvite that we receive. This information is passed to the RTP layer so that it will
know about the alternate source for media.
Review: https://reviewboard.asterisk.org/r/252
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197619 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r197467 | file | 2009-05-28 10:47:45 -0300 (Thu, 28 May 2009) | 15 lines
Merged revisions 197466 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r197466 | file | 2009-05-28 10:44:58 -0300 (Thu, 28 May 2009) | 8 lines
Fix a bug where the flag indicating the presence of rport would get overwritten by the nat setting.
The presence of rport is now stored as a separate flag. Once the dialog is setup and authenticated
(or it passes through unauthenticated) the proper nat flag is set.
(closes issue #13823)
Reported by: dimas
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@197471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196988 | seanbright | 2009-05-27 09:02:54 -0400 (Wed, 27 May 2009) | 9 lines
Display an error message when chan_alsa fails to load due to a missing
or inaccessible configuration file.
Before this change, when chan_alsa failed to load due to a missing or
inaccessible configuration file, no message would be displayed. With this
change, when chan_alsa fails to load due to a missing or inaccessible
configuration file, a message will be displayed.
(closes issue #14760)
Reported by: Nick_Lewis
Patches:
chan_alsa.c-confload.patch uploaded by Nick (license 657)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196991 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r196416 | dvossel | 2009-05-22 16:09:45 -0500 (Fri, 22 May 2009) | 19 lines
SIP set outbound transport type from Registration
In sip.conf the transport option allows for the configuration of what transport types (udp, tcp, and tls) a peer will accept, but only the first type listed was used for outbound connections. This patch changes this. Now the default transport type is only used until the peer registers. When registration takes place the transport type is parsed out of the Contact header. If the Contact header's transport type is equal to one that the peer supports, the peer's default transport type for outbound connections is set to match the Contact header's type. If the Contact header's transport type is not present, then the peer's default transport type is set to match the one the peer registered with. When a peer unregisters or the registration expires, the default transport type for that peer is reset.
(closes issue #12282)
Reported by: rjain
Patches:
reg_patch_1.diff uploaded by dvossel (license 671)
Tested by: dvossel
(closes issue #14727)
Reported by: pj
Patches:
reg_patch_3.diff uploaded by dvossel (license 671)
Tested by: pj, dvossel
Review: https://reviewboard.asterisk.org/r/249/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r195995 | dvossel | 2009-05-21 14:11:49 -0500 (Thu, 21 May 2009) | 20 lines
Merged revisions 195991 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r195991 | dvossel | 2009-05-21 14:04:56 -0500 (Thu, 21 May 2009) | 14 lines
Sign problem calculating timestamp for iax frame leads to no audio on the receiving peer.
There are rare cases in which a frame's delivery timestamp is slightly less than the iax2_pvt's offset. This causes the pvt's timestamp to be a small negative number, but since the timestamp value is unsigned it looks like a huge positive number. This patch checks for this negative case and sets the ms to zero. A similar check is already done right below this one in the 'else' statement.
(closes issue #15032)
Reported by: guillecabeza
Patches:
chan_iax2.c.patch_timestamp uploaded by guillecabeza (license 380)
Tested by: guillecabeza
(closes issue #14216)
Reported by: Andrey Sofronov
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@196000 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r194833 | dvossel | 2009-05-15 15:52:12 -0500 (Fri, 15 May 2009) | 24 lines
Merged revisions 194557,194685 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194557 | dvossel | 2009-05-14 17:59:43 -0500 (Thu, 14 May 2009) | 10 lines
IAX2 "Ghost" Channels
There is a bug tracker issue where people are reporting "Ghost" channels in their 'iax2 show channels' output. The confusion is caused by channels being listed as "(NONE)" with format "unknown". These are not channels of coarse. They are usually just pending registration or poke requests, but it is confusing output. To help make sense of this I have added two columns to 'iax2 show channels'. One shows the first message which started the transaction, and the second shows the last message sent by either side of the call. This helps diagnose why the entry exists and why it may not go away.
(closes issue #14207)
Reported by: clive18
Review: https://reviewboard.asterisk.org/r/246/
........
r194685 | dvossel | 2009-05-15 10:40:37 -0500 (Fri, 15 May 2009) | 6 lines
Update to previous IAX2 "Ghost" Channels patch.
Fixed some comments made on reviewboard for the previous patch.
(issue #14207)
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@194836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r194496 | mmichelson | 2009-05-14 17:20:51 -0500 (Thu, 14 May 2009) | 30 lines
Merged revisions 194484 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r194484 | mmichelson | 2009-05-14 17:17:55 -0500 (Thu, 14 May 2009) | 24 lines
Fix a race condition where a reinvite could trigger a 482 response.
The loop detection/spiral detection code in chan_sip used the owner
channel's state as a criterion for determining if the incoming INVITE
is a looped request. The problem with this is that the INVITE-handling
code happens in a different thread than the thread that marks the owner
channel as being up. As a result, if a reinvite were to come in very quickly,
say from another Asterisk on the same LAN, it was possible for the reinvite
to arrive before the owner channel had been set to the up state.
This patch corrects the problem by using the invitestate of the sip_pvt
instead, since that can be guaranteed to be set correctly by the time
the reinvite arrives. Since there is a switch statement further in the
INVITE-handling code, the AST_STATE_RINGING state also checks the invitestate
of the sip_pvt in case we should actually be treating the channel as if it were
up already.
(closes issue #12215)
Reported by: jpyle
Patches:
12215_confirmed.patch uploaded by mmichelson (license 60)
Tested by: lmadsen
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@194510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193954 | mmichelson | 2009-05-12 15:28:13 -0500 (Tue, 12 May 2009) | 18 lines
Update spiral support in trunk and 1.6.X to match what is in 1.4.
In 1.4, a SIP spiral is treated the same way as a call forward. This
works much better than what is currently in trunk and 1.6.X. The code
in trunk and 1.6.X did not create a new call to the recipient of the spiral,
instead trying to continue the same call. In addition to just being plain
wrong, this also had the side effect of only being able to spiral calls
to other SIP channels.
With this in place, as long as call forwards are honored, SIP spirals
will work properly. This means that it will work for outbound calls
made by the Queue, Dial, and Page applications. For originated calls and
spool calls, however, the spiral will not work properly until a generic
call forward mechanism is introduced into Asterisk.
(relates to issue #13630)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193962 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r193614 | rmudgett | 2009-05-11 14:11:29 -0500 (Mon, 11 May 2009) | 19 lines
Merged revisions 193613 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193613 | rmudgett | 2009-05-11 14:09:00 -0500 (Mon, 11 May 2009) | 12 lines
Sent wrong message to clear a call we started if the other end has not responed yet.
In the state MISDN_CALLING (i.e. SETUP was sent but no answer has arrived yet),
it is not allowed to clear the call with RELEASE_COMPLETE. It must be
cleared with DISCONNECT. A RELEASE_COMPLETE is only allowed as an answer
to a SETUP. (See Q.931 ch. 5.3.2, 5.3.2.a, 5.3.2.b)
Patches:
chan-misdn-ccstate7.patch uploaded by customer.
JIRA ABE-1862
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193617 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r193387 | dvossel | 2009-05-08 15:32:51 -0500 (Fri, 08 May 2009) | 7 lines
TCP not matching valid peer.
find_peer() does not find a valid peer when using pvt->recv as the sockaddr_in argument. Because of the way TCP works, the port number in pvt->recv is not what we're looking for at all. There is currently only one place that find_peer searches for a peer using the sockaddr_in argument. If the peer is not found after using pvt->recv (works for UDP since the port number will be correct), a temp sockaddr_in struct is made using the Contact header in the sip_request. This has the correct port number in it.
Review: http://reviewboard.digium.com/r/236/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193390 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r193077 | rmudgett | 2009-05-07 17:24:04 -0500 (Thu, 07 May 2009) | 12 lines
Merged revisions 193050 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r193050 | rmudgett | 2009-05-07 17:17:06 -0500 (Thu, 07 May 2009) | 5 lines
Give a more helpful message when an incoming call's dialed extension does not match.
Added the dialed extension and context to the chan_misdn messages warning
that the dialed number cannot be matched in the dialplan.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@193080 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r192933 | tilghman | 2009-05-07 11:43:56 -0500 (Thu, 07 May 2009) | 17 lines
Merged revisions 192932 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r192932 | tilghman | 2009-05-07 11:29:08 -0500 (Thu, 07 May 2009) | 10 lines
Eliminate repetition of fullcontact during reconstruction.
If the fullcontact field appears in both the sippeers and the
sipregs table, then during reconstruction of the field, it will
otherwise be doubled.
(closes issue #14754)
Reported by: Alexei Gradinari
Patches:
20090506__bug14754.diff.txt uploaded by tilghman (license 14)
Tested by: lmadsen
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@192936 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r192808 | file | 2009-05-06 14:38:51 -0300 (Wed, 06 May 2009) | 10 lines
Fix a bug where a timer would be created but not acknowledged.
This scenario crept up if chan_iax2 was loaded with no configuration file present.
It would create a timer and tell it to go at an interval but the thread that normally
acknowledges it would not be created because no configuration file was present. The timer
will now be closed if no configuration file is present.
(closes issue #15014)
Reported by: madkins
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@192810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r192387 | file | 2009-05-05 11:22:47 -0300 (Tue, 05 May 2009) | 10 lines
Fix a bug with setting t38pt_udptl at the user or peer level.
If an incoming call authenticated as a user or peer and t38pt_udptl was
not set to yes in general then no UDPTL session would be present and any
T38 related things would fail. This commit changes it so that if after
authenticating T38 is enabled but no UDPTL session is present one will be
created.
(issue AST-215)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@192402 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r190287 | file | 2009-04-23 16:15:30 -0300 (Thu, 23 Apr 2009) | 13 lines
Merged revisions 190286 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r190286 | file | 2009-04-23 16:13:18 -0300 (Thu, 23 Apr 2009) | 6 lines
Fix a bug in chan_local glare hangup detection.
If both sides of a Local channel were hung up at around the same time it was
possible for one thread to destroy the local private structure and have the other thread
immediately try to remove the already freed structure from the local channel list.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@190297 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189993 | jpeeler | 2009-04-22 14:23:49 -0500 (Wed, 22 Apr 2009) | 18 lines
Make chan_h323 respect packetization settings and fix small reload issue.
Previously, packetization settings were ignored and now they are not. A new
config option 'autoframing' has been added to mirror the way chan_sip handles
it. Turning on the autoframing option (available both as a global option or per
peer) overrides the local settings with the remote packetization settings.
Testing was performed with varying packetization levels with the following
codecs: ulaw, alaw, gsm, and g729.
Also, an unrelated config reload issue has been fixed in the case of the config
file not changing.
(closes issue #12415)
Reported by: pj
Patches:
2009012200_h323packetization.diff.txt uploaded by mvanbaak (license 7),
modified by me
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189997 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189911 | tilghman | 2009-04-22 11:01:30 -0500 (Wed, 22 Apr 2009) | 7 lines
Do not continue to receive DTMF, when the channel is hungup and about to be destroyed.
(closes issue #14858)
Reported by: barryf
Patches:
20090421__bug14858.diff.txt uploaded by tilghman (license 14)
Tested by: barryf
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189914 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189771 | dvossel | 2009-04-21 15:28:37 -0500 (Tue, 21 Apr 2009) | 11 lines
Fixes segfault when switching UDP to TCP in sip.conf after reload.
If transport in sip.conf is switched from UDP to TCP, Asterisk segfaults right after issuing a sip reload. The problem is the socket type is changed to TCP but the fd may still be present for UDP. Later, when the TCP session should be created or set using an existing one, it isn't because the old file descriptor is still present. Now every time transport is changed during a sip.conf reload, the file descriptor is set to -1, signifying it must be created or found.
(closes issue #14727)
Reported by: pj
Tested by: dvossel
Review: http://reviewboard.digium.com/r/229/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189775 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189350 | file | 2009-04-20 14:05:15 -0300 (Mon, 20 Apr 2009) | 10 lines
Fix a bug with non-UDP connections that caused dialogs to not get freed.
This issue crept up because of a reference count issue on non-UDP based dialogs.
The dialog reference count was increased when transmitting a packet reliably but never
decreased. This caused the dialog structure to hang around despite being unlinked from
the dialogs container.
(closes issue #14919)
Reported by: vrban
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189353 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r188647 | dvossel | 2009-04-15 17:10:04 -0500 (Wed, 15 Apr 2009) | 18 lines
Merged revisions 188646 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r188646 | dvossel | 2009-04-15 17:08:40 -0500 (Wed, 15 Apr 2009) | 12 lines
National prefix inserted even when caller ID not available
When the caller ID is restricted, the expected behavior is for the caller id to be blank. In chan_dahdi, the national prefix is placed onto the callers number even if its restricted (empty) causing the caller id to be the national prefix rather than blank.
(closes issue #13207)
Reported by: shawkris
Patches:
national_prefix.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/220/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189208 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r189204 | dvossel | 2009-04-17 20:28:45 -0500 (Fri, 17 Apr 2009) | 18 lines
Merged revisions 189203 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r189203 | dvossel | 2009-04-17 20:27:19 -0500 (Fri, 17 Apr 2009) | 12 lines
Fixed autologoff in agents.conf not working when agent logs in via AgentLogin app
An agent logs in by calling an extension that calls the AgentLogin app. In agents.conf ackcall=always is set, so when they get a call they have the choice to either acknowledge it or ignore it. autologoff=10 is set as well, so if the agent ignores the call over 10sec one may assume that the agent should be logged out (and in this case hungup on as well), but this was not happening.
(closes issue #14091)
Reported by: evandro
Patches:
autologoff.diff uploaded by dvossel (license 671)
Review: http://reviewboard.digium.com/r/225/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189207 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r189097 | mmichelson | 2009-04-17 15:20:23 -0500 (Fri, 17 Apr 2009) | 13 lines
Prevent a crash when SIP blonde transferring an unbridged call.
If one attempts to use the attended transfer button on a SIP phone
to transfer an unbridged call (such as a call to an IVR) but hangs
up while the target of the transfer is still ringing, we need to not
crash.
The problem was that ast_hangup was called from outside the channel
thread.
AST-211
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@189105 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r188947 | file | 2009-04-17 11:44:56 -0300 (Fri, 17 Apr 2009) | 22 lines
Merged revisions 188946 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r188946 | file | 2009-04-17 11:41:25 -0300 (Fri, 17 Apr 2009) | 15 lines
Fix a bug where a value used to create the channel name was bogus.
This commit fixes the scenario where an incoming call is authenticated
using a peer entry. Previously the channel name was created using either
the username setting from the sip.conf entry or the IP address that the
call came from. Now the channel name will be created using the peer name
itself. This commit will not change the way the channel name is generated
for users or friends.
(closes issue #14256)
Reported by: Nick_Lewis
Patches:
chan_sip.c-chname.patch uploaded by Nick (license 657)
Tested by: Nick_Lewis, file
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@188950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188247 | file | 2009-04-14 10:14:21 -0300 (Tue, 14 Apr 2009) | 7 lines
Fix a bug with the change I made yesterday to outbound proxy support.
Per discussion with oej on IRC we need the actual IP address, not the
outbound proxy IP address, in the sa field. Upon further inspection
this should make the behaviour of all other uses of the outbound proxy
in the code.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@188259 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r188067 | file | 2009-04-13 13:28:06 -0300 (Mon, 13 Apr 2009) | 10 lines
Fix a bug where using an outbound proxy would cause the local address to be 127.0.0.1.
Copy the outbound proxy IP address into the SIP dialog structure as the IP address we will
be sending to. This has to be done because the logic that determines what local IP address to use
in the SIP messages is not aware of an outbound proxy being in place. It only knows what IP address
we are sending to.
(closes issue #12006)
Reported by: mnicholson
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@188070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r187906 | jpeeler | 2009-04-10 15:26:46 -0500 (Fri, 10 Apr 2009) | 12 lines
Fix module embedding for chan_h323.
Include libchanh323.a in the modules.link file so that all the symbols can be
resolved at link time.
(closes issue #11966)
Reported by: dome
Patches:
issue_11966.patch uploaded by kpfleming (license 421)
Tested by: jpeeler
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@187916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185846 | dvossel | 2009-04-01 14:03:32 -0500 (Wed, 01 Apr 2009) | 16 lines
Merged revisions 185845 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185845 | dvossel | 2009-04-01 14:02:00 -0500 (Wed, 01 Apr 2009) | 10 lines
Fixes issue with dropped calles due to re-Invite glare and re-Invites never executing after a 491
Acknowledgement for 491 responses were never being processed because it didn't match our pending invite's seqno. Since the ACK was never processed, the 491 frame would continue to be retransmitted until eventually the call was dropped due to max retries. Now during a pending invite, if we receive another invite, we send an 491 and hold on to that glare invite's seqno in the "glareinvite" variable for that sip_pvt struct. When ACK's are received, we first check to see if it is in response to our pending invite, if not we check to see if it is in response to a glare invite. In this case, it is in response to the glare invite and must be dealt with or the call is dropped. I've changed the wait time for resending the re-Invite after receving a 491 response to comply with RFC 3261. Before this patch the scheduled re-Invite would only change a flag indicating that the re-Invite should be sent out, now it actually sends it out as well.
(closes issue #12013)
Reported by: alx
Review: http://reviewboard.digium.com/r/213/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@187531 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r186928 | russell | 2009-04-08 07:35:57 -0500 (Wed, 08 Apr 2009) | 13 lines
Update some comments and resolve potential memory corruption in chan_sip.
While browsing chan_sip the other day, I noticed this dangerous code in
dialog_needdestroy(). This function is an ao2_callback. It is absolutely
_not_ okay to unlock the container from within this function. It's also not
clear why it was useful. Given that it could cause memory corruption, I have
removed it.
There was also a TODO comment left describing a potential implementation of
an improvement to the needdestroy handling. I'm not convinced that what was
described is the best choice here, so I have briefly described the way that
this function is used today that could be improved.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@186929 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r186461 | kpfleming | 2009-04-03 15:20:01 -0500 (Fri, 03 Apr 2009) | 11 lines
Merged revisions 186458 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r186458 | kpfleming | 2009-04-03 15:19:20 -0500 (Fri, 03 Apr 2009) | 5 lines
Fix a bug where DAHDI/Zaptel channels would not properly switch formats when requested
Don't offer AST_FORMAT_SLINEAR on DAHDI/Zaptel channels... while it could provide a slight performance benefit, the translation core in Asterisk has some flaws when a channel driver offers multiple raw formats. this fix is much simpler than fixing the translation core to solve that issue (although that will be done later).
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@186469 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185953 | kpfleming | 2009-04-02 08:51:44 -0500 (Thu, 02 Apr 2009) | 11 lines
Merged revisions 185952 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185952 | kpfleming | 2009-04-02 08:43:43 -0500 (Thu, 02 Apr 2009) | 5 lines
the DAHDI_GETCONF, DAHDI_SETCONF and DAHDI_GET_PARAMS ioctls were recently corrected to show that they do, in fact, read data from userspace as part of their work. due to this fix, valgrind now reports a number of cases where chan_dahdi passed an uninitialized (or partially) buffer to these ioctls, which could lead to unexpected behavior.
this patch corrects chan_dahdi to ensure that buffers passed to these ioctls are always fully initialized.
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@185957 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185363 | dbrooks | 2009-03-31 11:46:57 -0500 (Tue, 31 Mar 2009) | 44 lines
Merged revisions 185362 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185362 | dbrooks | 2009-03-31 11:37:12 -0500 (Tue, 31 Mar 2009) | 35 lines
Fix incorrect parsing in chan_gtalk when xmpp contains extra whitespaces
To drill into the xmpp to find the capabilities between channels, chan_gtalk
calls iks_child() and iks_next(). iks_child() and iks_next() are functions in
the iksemel xml parsing library that traverse xml nodes. The bug here is that
both iks_child() and iks_next() will return the next iks_struct node
*regardless* of type. chan_gtalk expects the next node to be of type IKS_TAG,
which in most cases, it is, but in this case (a call being made from the
Empathy IM client), there exists iks_struct nodes which are not IKS_TAG data
(they are extraneous whitespaces), and chan_gtalk doesn't handle that case,
so capabilities don't match, and a call cannot be made.
iks_first_tag() and iks_next_tag(), on the other hand, will not return the
very next iks_struct, but will check to see if the next iks_struct is of
type IKS_TAG. If it isn't, it will be skipped, and the next struct of type
IKS_TAG it finds will be returned. This assures that chan_gtalk will find
the iks_struct it is looking for.
This fix simply changes all calls to iks_child() and iks_next() to become
calls to iks_first_tag() and iks_next_tag(), which resolves the capability
matching.
The following is a payload listing from Empathy, which, due to the extraneous
whitespace, will not be parsed correctly by iksemel:
<iq from='dbrooksjab@235-22-24-10/Telepathy' to='astjab@235-22-24-10/asterisk' type='set' id='542757715704'> <session xmlns='http://www.google.com/session' initiator='dbrooksjab@235-22-24-10/Telepathy' type='initiate' id='1837267342'> <description xmlns='http://www.google.com/session/phone'> <payload-type clockrate='16000' name='speex' id='96'/>
<payload-type clockrate='8000' name='PCMA' id='8'/>
<payload-type clockrate='8000' name='PCMU' id='0'/>
<payload-type clockrate='90000' name='MPA' id='97'/>
<payload-type clockrate='16000' name='SIREN' id='98'/>
<payload-type clockrate='8000' name='telephone-event' id='99'/>
</description>
</session>
</iq>
Review: http://reviewboard.digium.com/r/181/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@185428 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r185122 | rmudgett | 2009-03-30 15:41:24 -0500 (Mon, 30 Mar 2009) | 26 lines
Merged revisions 185120 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r185120 | rmudgett | 2009-03-30 15:38:11 -0500 (Mon, 30 Mar 2009) | 19 lines
Make chan_misdn BRI TE side normally defer channel selection to the NT side.
Channel allocation collisions are not handled by chan_misdn very well.
This patch simply avoids the problem for BRI only.
For PRI, allocation collisions are still possible but less likely since
there are simply more channels available and each end could use a different
allocation strategy.
misdn.conf options available:
te_choose_channel - Use to force the TE side to allocate channels.
method - Specify the channel allocation strategy.
(closes issue #13488)
Reported by: Christian_Pinedo
Patches:
isdn_lib.patch.txt uploaded by crich
Tested by: crich, siepkes, festr
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@185128 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r184948 | file | 2009-03-30 11:37:47 -0300 (Mon, 30 Mar 2009) | 21 lines
Merged revisions 184947 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184947 | file | 2009-03-30 11:35:47 -0300 (Mon, 30 Mar 2009) | 14 lines
Improve our handling of T38 in the initial INVITE from a device.
We now answer with matching media streams to what is requested. If an INVITE
is received with both a T38 and RTP media stream this means we answer with both.
For any outgoing calls created as a result of this inbound one no T38 is requested
in the initial INVITE. Instead if we start receiving udptl packets we trigger a
reinvite on the outbound side.
(closes issue #12437)
Reported by: marsosa
Tested by: pinga-fogo, okrief, file, afu
Review: http://reviewboard.digium.com/r/208/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184951 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184838 | russell | 2009-03-29 00:32:04 -0500 (Sun, 29 Mar 2009) | 8 lines
Simplify chan_h323 build to not require a second run of "make".
(closes issue #14715)
Reported by: jthurman
Patches:
h323-makefile-1.6.2.0-beta1.patch uploaded by jthurman (license 614)
Tested by: tzafrir, russell
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184839 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184762 | kpfleming | 2009-03-27 14:10:32 -0500 (Fri, 27 Mar 2009) | 12 lines
Improve timing interface to remember which provider provided a timer
The ability to load/unload timing interfaces is nice, but it means that when a timer is allocated, it may come from provider A, but later provider B becomes the 'preferred' provider. If this happens, all timer API calls on the timer that was provided by provider A will actually be handed to provider B, which will say WTF and return an error.
This patch changes the timer API to include a pointer to the provider of the timer handle so that future operations on the timer will be forwarded to the proper provider.
(closes issue #14697)
Reported by: moy
Review: http://reviewboard.digium.com/r/211/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184779 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r184566 | file | 2009-03-27 10:15:26 -0300 (Fri, 27 Mar 2009) | 16 lines
Merged revisions 184565 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r184565 | file | 2009-03-27 10:06:45 -0300 (Fri, 27 Mar 2009) | 9 lines
Fix an issue where nat=yes would not always take effect for the RTP session on outgoing calls.
If calls were placed using an IP address or hostname the global nat setting was copied over
but was not set on the RTP session itself. This caused the RTP stack to not perform symmetric RTP
actions.
(closes issue #14546)
Reported by: acunningham
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184612 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184339 | russell | 2009-03-25 16:57:19 -0500 (Wed, 25 Mar 2009) | 35 lines
Improve performance of the ast_event cache functionality.
This code comes from svn/asterisk/team/russell/event_performance/.
Here is a summary of the changes that have been made, in order of both
invasiveness and performance impact, from smallest to largest.
1) Asterisk 1.6.1 introduces some additional logic to be able to handle
distributed device state. This functionality comes at a cost.
One relatively minor change in this patch is that the extra processing
required for distributed device state is now completely bypassed if
it's not needed.
2) One of the things that I noticed when profiling this code was that a
_lot_ of time was spent doing string comparisons. I changed the way
strings are represented in an event to include a hash value at the front.
So, before doing a string comparison, we do an integer comparison on the
hash.
3) Finally, the code that handles the event cache has been re-written.
I tried to do this in a such a way that it had minimal impact on the API.
I did have to change one API call, though - ast_event_queue_and_cache().
However, the way it works now is nicer, IMO. Each type of event that
can be cached (MWI, device state) has its own hash table and rules for
hashing and comparing objects. This by far made the biggest impact on
performance.
For additional details regarding this code and how it was tested, please see the
review request.
(closes issue #14738)
Reported by: russell
Review: http://reviewboard.digium.com/r/205/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184343 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184280 | file | 2009-03-25 16:22:06 -0300 (Wed, 25 Mar 2009) | 5 lines
Fix issue with a T38 reinvite being sent even if not configured to do so.
If we receive a T38 request negotiate control frame we should only attempt to do so
if the option is enabled on the dialog.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184283 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r184037 | russell | 2009-03-24 16:40:44 -0500 (Tue, 24 Mar 2009) | 6 lines
Exclude slin16, siren7, and siren14 from bandwidth=low and =medium
The default codec configuration for chan_iax2 is bandwidth=low. I noticed
slin16 being negotiated as the codec in some test calls, but that no longer
happens after this change.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@184041 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r183117 | mmichelson | 2009-03-19 11:07:54 -0500 (Thu, 19 Mar 2009) | 20 lines
Merged revisions 183115 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r183115 | mmichelson | 2009-03-19 11:04:02 -0500 (Thu, 19 Mar 2009) | 14 lines
Fix an issue where cancelled outgoing SIP calls would erroneously report the device as "in use."
A user was having an issue where if an outgoing SIP call was canceled, the SIP device
would remain in use if we had not received any response to the initial INVITE we sent out.
The SIP device would remain in use until the autocongestion timer was exhausted.
I tracked down the cause of this to be the section of code I am removing here. I asked several
people what the purpose of this code was meant to be, but no one could give me any sort of
answer as to why this was here. The person who was having this issue has been using this patch
for several months and it has stopped the problems they have had.
AST-196
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@183122 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r183108 | file | 2009-03-19 12:37:23 -0300 (Thu, 19 Mar 2009) | 11 lines
Improve our triggering of a T38 switchover internally when triggered by a received reinvite.
Previously we reached across the channel bridge to get the other party's SIP dialog
structure in order to trigger an outgoing reinvite. This is extremely dangerous to do
and only works if bridged to another SIP channel. This patch changes this to use the
T38 control frame method of requesting a switchover. This change also causes the SIP
channel driver to propogate back whether the switchover worked or not instead of blindly
accepting the incoming T38 reinvite.
Review: http://reviewboard.digium.com/r/200/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@183111 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
................
r182847 | russell | 2009-03-17 21:28:55 -0500 (Tue, 17 Mar 2009) | 52 lines
Merged revisions 182810 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182810 | russell | 2009-03-17 21:09:13 -0500 (Tue, 17 Mar 2009) | 44 lines
Fix cases where the internal poll() was not being used when it needed to be.
We have seen a number of problems caused by poll() not working properly on
Mac OSX. If you search around, you'll find a number of references to using
select() instead of poll() to work around these issues. In Asterisk, we've
had poll.c which implements poll() using select() internally. However, we
were still getting reports of problems.
vadim investigated a bit and realized that at least on his system, even
though we were compiling in poll.o, the system poll() was still being used.
So, the primary purpose of this patch is to ensure that we're using the
internal poll() when we want it to be used.
The changes are:
1) Remove logic for when internal poll should be used from the Makefile.
Instead, put it in the configure script. The logic in the configure
script is the same as it was in the Makefile. Ideally, we would have
a functionality test for the problem, but that's not actually possible,
since we would have to be able to run an application on the _target_
system to test poll() behavior.
2) Always include poll.o in the build, but it will be empty if AST_POLL_COMPAT
is not defined.
3) Change uses of poll() throughout the source tree to ast_poll(). I feel
that it is good practice to give the API call a new name when we are
changing its behavior and not using the system version directly in all cases.
So, normally, ast_poll() is just redefined to poll(). On systems where
AST_POLL_COMPAT is defined, ast_poll() is redefined to ast_internal_poll().
4) Change poll() in main/poll.c to be ast_internal_poll().
It's worth noting that any code that still uses poll() directly will work fine
(if they worked fine before). So, for example, out of tree modules that are
using poll() will not stop working or anything. However, for modules to work
properly on Mac OSX, ast_poll() needs to be used.
(closes issue #13404)
Reported by: agalbraith
Tested by: russell, vadim
http://reviewboard.digium.com/r/198/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@182947 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182722 | jpeeler | 2009-03-17 15:47:31 -0500 (Tue, 17 Mar 2009) | 15 lines
Allow H.323 Plus library to be used in addition to the OpenH323 library
Chan_h323 can now be compiled against both the previously supported versions of
OpenH323 as well as the current H.323 Plus (version 1.20.2). The configure
script has been modified to look in the default install location of h323 to
hopefully help avoid using the environment variables OPENH323DIR and PWLIBDIR.
Also, the CLI command "h323 show version" has been added which indicates which
version of h323 is in use.
(closes issue #11261)
Reported by: vhatz
Patches:
asterisk-1.6.0.6-h323plus.patch uploaded by jthurman (license 614)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@182725 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/trunk
........
r182408 | rmudgett | 2009-03-16 20:54:53 -0500 (Mon, 16 Mar 2009) | 8 lines
OPENR2 uses an incorrect string value if the extension delimiter is not present.
* Fixed OPENR2 using an incorrect string value if the extension
delimiter is not present in the Dial() function. This was fixed for
SS7 and PRI in trunk -r172400.
* Made OPENR2 stripmsd behavior the same as the SS7, PRI, and others.
* Removed trailing whitespace that appeared with OPENR2.
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.6.2@182409 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This commit introduces official support for R2 signaling in chan_dahdi. The
modifications to chan_dahdi, and the supporting library, LibOpenR2, were both
written by Moises Silva.
Many users are using this code, or a variant of it, in Asterisk 1.2, 1.4 and 1.6
in Brazil, México and Argentina. An unknown number of users (but at least 1)
are using it in each of the following countries: Colombia, Nepal, Thailand,
Venezuela, Perú, and probably others.
To use this code, LibOpenR2 must be installed from http://www.libopenr2.org/.
Information about configuration can be found in configs/chan_dahdi.conf.sample.
The code committed is the most up to date version, which was being maintained
in svn/asterisk/team/moy/mfcr2/.
I would also like to include a Thank You to the many others that tested this
code beyond those listed in this commit message. These are the names that I
could find in the mantis issue.
(closes issue #12509)
Reported by: moy
Patches:
chan_zap-mfr2.patch uploaded by moy (license 222)
Tested by: moy, korihor, viniciusfontes, Skarmeth, loloski, asbestoshead, titogarrido, heliocoelhojr, konsultex, ncorrare, ecarruda, rtorresduque, PTorres, ychen
Review: http://reviewboard.digium.com/r/40/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182355 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r182281 | dvossel | 2009-03-16 12:47:42 -0500 (Mon, 16 Mar 2009) | 7 lines
Randomize IAX2 encryption padding
The 16-32 byte random padding at the beginning of an encrypted IAX2 frame turns out to not be all that random at all. This patch calls ast_random to fill the padding buffer with random data. The padding is randomized at the beginning of every encrypted call and for every encrypted retransmit frame.
Review: http://reviewboard.digium.com/r/193/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182282 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code responsible for sending the T38 reinvite did not check if an INVITE was
already being handled. This caused things to get confused and the call to fail.
The code now defers sending the T38 reinvite until the current INVITE is done being
handled.
(issue AST-191)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@182022 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181768 | mmichelson | 2009-03-12 13:29:48 -0500 (Thu, 12 Mar 2009) | 22 lines
Properly send a 487 on an INVITE we have not responded to if we receive a BYE.
If we receive an INVITE from an endpoint and then later receive a BYE from that
same endpoint before we have sent a final response for the INVITE, then we need
to respond to the INVITE with a 487.
There was logic in the code prior to this commit which seemed to exist solely to
handle this situation, but there was one condition in an if statement which
was incorrect. The only way we would send a 487 was if the sip_pvt had no owner
channel. This made no sense since we created the owner channel when we received
the INVITE, meaning that the majority of the time we would never send the 487.
The 487 being sent should not rely on whether we have created a channel. Its
delivery should be dependent on the current state of the initial INVITE transaction.
With this commit, that logic is now correctly in place.
(closes issue #14149)
Reported by: legranjl
Patches:
14149.patch uploaded by mmichelson (license 60)
Tested by: legranjl
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181769 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181340 | dvossel | 2009-03-11 12:25:31 -0500 (Wed, 11 Mar 2009) | 11 lines
encrypted IAX2 during packet loss causes decryption to fail on retransmitted frames
If an iax channel is encrypted, and a retransmit frame is sent, that packet's iseqno is updated while it is encrypted. This causes the entire frame to be corrupted. When the corrupted frame is sent, the other side decrypts it and sends a VNAK back because the decrypted frame doesn't make any sense. When we get the VNAK, we look through the sent queue and send the same corrupted frame causing a loop. To fix this, encrypted frames requiring retransmission are decrypted, updated, then re-encrypted. Since key-rotation may change the key held by the pvt struct, the keys used for encryption/decryption are held within the iax_frame to guarantee they remain correct.
(closes issue #14607)
Reported by: stevenla
Tested by: dvossel
Review: http://reviewboard.digium.com/r/192/
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181371 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181328 | file | 2009-03-11 14:22:52 -0300 (Wed, 11 Mar 2009) | 14 lines
Fix issue where an attended transfer could not be completed under a rare scenario.
When completing an attended transfer chan_sip does a check to make sure the extension
in the URI portion of the Refer-To header is a local valid extension. We don't actually
need to check this since we know for sure the other channel is already up and talking to
the extension. Some devices do not put the extension in the Refer-To header either, which
can cause the extension check to fail. We now no longer do this check if it is an attended
transfer.
(closes issue #14628)
Reported by: sverre
Patches:
14628.diff uploaded by file (license 11)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181345 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r181295 | file | 2009-03-11 13:36:50 -0300 (Wed, 11 Mar 2009) | 9 lines
Fix a problem with inband DTMF detection on outgoing SIP calls when dtmfmode=auto.
When dtmfmode was set to auto the inband DTMF detector was not setup
on outgoing SIP calls. This caused inband DTMF detection to fail.
The inband DTMF detector is now setup for both dtmfmode inband and auto.
(closes issue #13713)
Reported by: makoto
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@181296 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Jeff Peeler
Mark Michelson
Richard Mudgett
David Vossel
Russell Bryant
Kevin P. Fleming
Joshua Colp
Jason Parker
Matthew Fredrickson
Matthew Nicholson
David Brooks
Moises Silva
Eliel C. Sardanons
Sean Bright
Tilghman Lesher
Leif Madsen