https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r284280 | tilghman | 2010-08-30 17:27:06 -0500 (Mon, 30 Aug 2010) | 11 lines
Fix 3 coding errors:
1) After we close FD, we should not be trying to write to it.
2) Call _exit(0), not exit(0), to avoid running shutdown routines in a child.
3) Use endian, not processor, detection to ensure bytes are written in the correct order.
(closes issue #15706)
Reported by: modelnine
Patches:
asterisk-1.6.1.1-festival-debug.patch uploaded by modelnine (license 865)
Tested by: gmartinez
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@284281 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, this code required exactly one space to be after the ':' in headers
for an AMI action. This now makes whitespace optional, and allows whitespace that
is there to vary in amount.
(closes issue #17862)
Reported by: cmoye
Patches:
manager.c.patch_trunk uploaded by cmoye (license 858)
manager.c.patch_1.8 uploaded by cmoye (license 858)
Tested by: cmoye
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@284065 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283691 | dvossel | 2010-08-26 10:24:40 -0500 (Thu, 26 Aug 2010) | 25 lines
Merged revisions 283690 via svnmerge from
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.8@283692 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r283594 | dvossel | 2010-08-25 17:56:42 -0500 (Wed, 25 Aug 2010) | 7 lines
Add to and from tags to NOTIFY dialog-info xml body so pickup can occur.
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.8@283595 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r283558 | dvossel | 2010-08-25 10:52:54 -0500 (Wed, 25 Aug 2010) | 10 lines
Asterisk will not advertise session timers are supported when 'session-timers=refuse' is used.
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.8@283559 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283381 | dvossel | 2010-08-24 11:07:37 -0500 (Tue, 24 Aug 2010) | 18 lines
Merged revisions 283380 via svnmerge from
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.8@283382 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Really, having 2 enums for this is silly and error prone, demonstrated by
the crash that I hit because there was an assumption in the code that the
values in each matched up. However, this is a quick fix to get them to
match up so it will work.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@283230 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Include the usage of CSV_QUOTE() to ensure data has valid CSV formatting. Also list
the special CEL variables that are available for use in the mapping.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@283173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r283049 | rmudgett | 2010-08-20 10:31:03 -0500 (Fri, 20 Aug 2010) | 29 lines
Merged revisions 283048 via svnmerge from
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.8@283050 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r282894 | dvossel | 2010-08-19 16:05:54 -0500 (Thu, 19 Aug 2010) | 18 lines
Merged revisions 282893 via svnmerge from
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.8@282895 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
