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
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
........
r282469 | lmadsen | 2010-08-16 13:00:09 -0500 (Mon, 16 Aug 2010) | 7 lines
Add information about creating sounds files using
the sounds tools publically available so that others can create their
own sounds prompts using the same tools we use to generate sounds releases.
This allows people creating their own prompts to sound consistent with
the prompts available from the open source project.
SWP-595
........
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282470 65c4cc65-6c06-0410-ace0-fbb531ad65f3
https://origsvn.digium.com/svn/asterisk/branches/1.6.2
................
r282467 | twilson | 2010-08-16 12:32:01 -0500 (Mon, 16 Aug 2010) | 23 lines
Merged revisions 282430 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r282430 | twilson | 2010-08-16 12:06:37 -0500 (Mon, 16 Aug 2010) | 16 lines
Send a SRCCHANGE indication when we masquerade
Masquerading a channel means that the src of the audio is potentially
changing, so send a SRCCHANGE so that RTP-based media streams can get
a new SSRC generated to reflect the change. Original patch by addix
(along with lots of testing--thanks!).
(closes issue #17007)
Reported by: addix
Patches:
1001-reset-SSRC-original-channel.diff uploaded by addix (license 1006)
srcchange.diff uploaded by twilson (license 396)
Tested by: addix, twilson
Review: https://reviewboard.asterisk.org/r/862/
........
................
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282468 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
The libsrtp build system currently does not produce a shared library
or a static library compiled with -fPIC, so on 64-bit systems it is
possible that we will get a compile error if libsrtp is installed and
res_srtp is selected in menuselect.
This patch attempts to detect this situation and provide the user with
instructions to work around the problem.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/1.8@282200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
