This patch fixes the way asterisk handles NOTIFY requests received in response to REFER requests. These changes to NOTIFY handler were first introduced in r217482. This new change properly handles the 200 response by queueing an AST_TRANSFER_SUCCESS control frame and also prevents that control frame from being queued when provisional and unknown responses are received.
(issue #17486)
Reported by: davidw
Tested by: mnicholson
(issue #12713)
Reported by: davidw
Review: https://reviewboard.asterisk.org/r/860/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If an outgoing call negotiates a different B channel than initially
requested, the saved original dial string was not transferred to the new B
channel. CCSS uses that dial string to generate the recall dial string.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282334 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r282235 | dvossel | 2010-08-13 13:54:53 -0500 (Fri, 13 Aug 2010) | 16 lines
only do magic pickup when notifycid is enabled
A new way of doing BLF pickup was introduced into 1.6.2. This feature
adds a call-id value into the XML of a SIP_NOTIFY message sent to alert
a subscriber that a device is ringing. This option should only be enabled
when the new 'notifycid' option is set... but this was not the case. Instead
the call-id value was included for every RINGING Notify message, which
caused a regression for people who used other methods for call pickup.
(closes issue #17633)
Reported by: urosh
Patches:
chan_sip.txt uploaded by urosh (license )
blf_cid_issue.diff uploaded by dvossel (license 671)
Tested by: dvossel, urosh, okrief, alecdavis
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r281430 | dvossel | 2010-08-09 15:46:50 -0500 (Mon, 09 Aug 2010) | 13 lines
fixes SIP peers memory leak
We zeroed out the peer's addr before it was removed from the
peers_by_ip container. This made it impossible to be removed
from the container as the addr is the key used by the container
to find the peer.
(closes issue #17774)
Reported by: kkm
Patches:
017774-sip-peer-leak-1.6.2.10.diff uploaded by kkm (license 888)
017774-sip-peer-leak-1.8.diff uploaded by kkm (license 888)
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@281432 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r281391 | jpeeler | 2010-08-09 15:07:29 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281390 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r281390 | jpeeler | 2010-08-09 15:04:30 -0500 (Mon, 09 Aug 2010) | 13 lines
Prevent loss of Caller ID information set on local channel after masquerade.
Caller ID set on the channel before a masquerade occurs when using a local
channel would cause the information to be lost. The problem was that the
information was set on a channel destined to be hung up. The somewhat confusing
fix is to detect if any Caller ID has been set on the channel and if so
preswap the Caller ID data so that basically the masquerade puts the data back.
(closes issue #17138)
Reported by: kobaz
Review: https://reviewboard.asterisk.org/r/847/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@281429 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is a regression from the sig_pri split from chan_dahdi. When a call is
first initiated, the inband DTMF detector is not enabled if it's an outgoing
ISDN call. However, it needs to be turned on once the media path starts up.
This handling was put back in the open_media() callback of chan_dahdi. In
sig_pri, open_media() calls were added to a few places where it was needed,
including handling of PRI_EVENT_RINGING, PRI_EVENT_PROGRESS, and
PRI_EVENT_PROCEEDING.
Thanks to rmudgett for helping me with the patch!
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@279916 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The code was written in a way that did a bad job of
parsing the port out of a URI. Specifically, it would
do badly when dealing with an IPv6 address. In this
particular scenario, there was no value from parsing
the port out, so I just removed that logic. And while
I was messing around in the function, I changed some
variable names to be more descriptive.
(closes issue #17661)
Reported by: oej
Patches:
17661.diff uploaded by mmichelson (license 60)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@279887 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r279784 | mmichelson | 2010-07-27 10:13:24 -0500 (Tue, 27 Jul 2010) | 14 lines
Fix bad behavior of dynamic_exclude_static option in sip.conf.
We were attempting to create a contactdeny rule based on the peer's
IP address before the peer's IP address had been set. By moving the
processing further down in the function, we can ensure stuff works
as we expect for it to.
(closes issue #17717)
Reported by: mmichelson
Patches:
17717.patch uploaded by mmichelson (license 60)
Tested by: DennisD
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@279785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch modifies the way chan_sip.c does transaction to dialog
matching. Asterisk now stores information in the top most Via header
of the initial incoming request and compares that against other Requests
that have the same call-id. This results in Asterisk being able to
detect a forked call in which it has received multiple legs of the
fork. I completely stripped out the previous matching code and made
the comparisons a little more explicit and easier to understand. My
comments in the code should offer all the details involving this patch.
This patch also fixes a bug with the usage of the OBJ-MULTIPLE flag to
find multiple dialogs with the same call-id. Since the callback
function was returning (CMP_MATCH | CMP_STOP) only the first item
found was being returned. I fixed this by making a new callback
function for finding multiple dialogs that only returns (CMP_MATCH)
on a match allowing for multiple items to be returned.
Review: https://reviewboard.asterisk.org/r/776/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@279568 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A recent change to SIP URI comparison code added a locale-specific
string comparison to the mix, and certain systems do not support
such functions. This fix allows for those systems to still use
Asterisk 1.8
(closes issue #17697)
Reported by: pprindeville
Patches:
asterisk-trunk-bugid17697.patch uploaded by pprindeville (license 347)
Tested by: mmichelson
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@279504 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This initially was created to work around the issue of
using a string comparison instead of a binary comparison
for IP addresses. It evolved a bit when test cases were
created and it was discovered that comparison of URI
parameters was not working exactly as it should.
sip_uri_cmp() and its helpers have been moved to reqresp_parser.c
and a new test has been added.
(closes issue #17662)
Reported by: oej
Review: https://reviewboard.asterisk.org/r/792
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
FXS lines normally connect to a telephone. However, when FXS lines are routed
to an external PBX or Key System to act as "external" or "CO" lines, it is
extremely difficult, if not impossible for the external PBX to know when
the call has been disconnected without receiving a polarity reversal on the line.
Now using answeronpolarityswitch and hanguponpolarityswitch keywords that
previously were used only for FXO ports, now applies like functionality for
an FXS port, but from the connected equipment's point of view.
(closes issue #17318)
Reported by: armeniki
Patches:
fxs_linepolarity.diff5.txt uploaded by alecdavis (license 585)
Tested by: alecdavis
Review: https://reviewboard.asterisk.org/r/797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278809 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The "dahdi show channels" CLI command still reports the DNID of the
previous call even if the call is already hang up. The "dahdi show
channels" command of older releases clear the DNID once the channel is
hang up.
Regression from the sig_analog/sig_pri extraction from chan_dahdi.
(closes issue #17623)
Reported by: klaus3000
Patches:
issue17623.patch uploaded by rmudgett (license 664)
Tested by: rmudgett
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278777 65c4cc65-6c06-0410-ace0-fbb531ad65f3
[RFC3265]3.1.6.1....
The notifier MAY also check that the duration in the "Expires" header
is not too small. If and only if the expiration interval is greater
than zero AND smaller than one hour AND less than a notifier-
configured minimum, the notifier MAY return a "423 Interval too
small" error which contains a "Min-Expires" header field. The "Min-
Expires" header field is described in SIP [1].
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@278536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
