https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284561 | dvossel | 2010-09-01 16:47:01 -0500 (Wed, 01 Sep 2010) | 9 lines
During request to dialog matching, verify init_ruri is present before comparing.
During request to dialog matching, we attempt a best effort routine for fork
detection which requires several elements to be in place. The dialog's
initial request uri is one of those elements. Since it is best effort,
if the init_ruri is not present for some reason we can not proceed with that
routine.
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@284562 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r284477 | twilson | 2010-09-01 13:44:36 -0500 (Wed, 01 Sep 2010) | 17 lines
Fix SRTP for changing SSRC and multiple a=crypto SDP lines
Adding code to Asterisk that changed the SSRC during bridges and masquerades
broke SRTP functionality. Also broken was handling the situation where an
incoming INVITE had more than one crypto offer. This patch caches the SRTP
policies the we use so that we can change the ssrc and inform libsrtp of the
new streams. It also uses the first acceptable a=crypto line from the incoming
INVITE.
(closes issue #17563)
Reported by: Alexcr
Patches:
srtp.diff uploaded by twilson (license 396)
Tested by: twilson
Review: https://reviewboard.asterisk.org/r/878/
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@284479 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283692 | dvossel | 2010-08-26 10:26:37 -0500 (Thu, 26 Aug 2010) | 32 lines
Merged revisions 283691 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@283693 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283595 | dvossel | 2010-08-25 17:57:56 -0500 (Wed, 25 Aug 2010) | 14 lines
Merged revisions 283594 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@283596 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283559 | dvossel | 2010-08-25 10:54:11 -0500 (Wed, 25 Aug 2010) | 16 lines
Merged revisions 283558 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@283560 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r283382 | dvossel | 2010-08-24 11:11:18 -0500 (Tue, 24 Aug 2010) | 25 lines
Merged revisions 283381 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@283383 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282895 | dvossel | 2010-08-19 16:07:20 -0500 (Thu, 19 Aug 2010) | 25 lines
Merged revisions 282894 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@282896 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r282639 | mnicholson | 2010-08-18 08:10:39 -0500 (Wed, 18 Aug 2010) | 13 lines
Properly handle 200 and unknown responses conatined in NOTIFY requests received in response to REFER requests.
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: http://svn.digium.com/svn/asterisk/trunk@282640 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r282236 | dvossel | 2010-08-13 13:58:10 -0500 (Fri, 13 Aug 2010) | 23 lines
Merged revisions 282235 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@282237 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r281432 | dvossel | 2010-08-09 15:47:53 -0500 (Mon, 09 Aug 2010) | 20 lines
Merged revisions 281430 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@281433 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279887 | mmichelson | 2010-07-27 13:54:07 -0500 (Tue, 27 Jul 2010) | 16 lines
Fix parsing error in sip_sipredirect().
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: http://svn.digium.com/svn/asterisk/trunk@279888 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
................
r279785 | mmichelson | 2010-07-27 10:15:22 -0500 (Tue, 27 Jul 2010) | 20 lines
Merged revisions 279784 via svnmerge from
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: http://svn.digium.com/svn/asterisk/trunk@279786 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.8
........
r279568 | dvossel | 2010-07-26 14:59:03 -0500 (Mon, 26 Jul 2010) | 21 lines
transaction matching using top most Via header
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: http://svn.digium.com/svn/asterisk/trunk@279569 f38db490-d61c-443f-a65b-d21fe96a405b
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: http://svn.digium.com/svn/asterisk/trunk@278980 f38db490-d61c-443f-a65b-d21fe96a405b
If the Expire header of a SUBSCRIBE is less that our expiremin,
a log warning will be displayed.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278619 f38db490-d61c-443f-a65b-d21fe96a405b
[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: http://svn.digium.com/svn/asterisk/trunk@278536 f38db490-d61c-443f-a65b-d21fe96a405b
If Asterisk sends a 4xx error and the other side sends a CANCEl
before receiving the 4xx and responding with the ACK, Asterisk
will process the CANCEL and send a 487 Request Terminated as
a new final response to the INVITE. Since we are issuing a new
final response to the INVITE, the old one must be pretend_acked
else it will keep retransmitting.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@278234 f38db490-d61c-443f-a65b-d21fe96a405b
There are two changes here:
1. Since the externip setting can now have a port attached
to it, calling it "externip" is misleading. The option is now
documented and parsed as "externaddr." This also extends to the
"matchexterniplocally" setting. It is now documented and parsed
as "matchexternaddrlocally." The old names for the options may
still be used, but they are no longer used in the sip.conf.sample
file.
2. If no port is set for the externaddr, and UDP is the transport
to be used, then we will set the port of the externaddr to that of
the udpbindaddr. This was how things worked prior to the IPv6 merge,
so this is a regression fix.
(closes issue #17665)
Reported by: mmichelson
Patches:
17665.diff#2 uploaded by pprindeville (license 347)
Tested by: pprindeville
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277873 f38db490-d61c-443f-a65b-d21fe96a405b
ACLs can now be configured to match IPv6 networks. This is only
relevant for ACLs in chan_sip for now since other channel drivers
do not support IPv6 addressing. However, once those channel drivers
are outfitted to support IPv6 addressing, the ACLs will already be
ready for IPv6 support.
https://reviewboard.asterisk.org/r/791
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277814 f38db490-d61c-443f-a65b-d21fe96a405b
https://origsvn.digium.com/svn/asterisk/branches/1.4
........
r277497 | mnicholson | 2010-07-16 16:18:38 -0500 (Fri, 16 Jul 2010) | 4 lines
Default to no udptl error correction so that error correction will be disabled in the event that the remote end indicates that they do not support the error correction mode we requested.
FAX-128
........
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@277530 f38db490-d61c-443f-a65b-d21fe96a405b
Found a unused bag of curly brackets under my table. I always wondered where
they had gone. They where indeed needed in chan_sip.c
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276989 f38db490-d61c-443f-a65b-d21fe96a405b
sip.conf configuration for the channel and for devices.
The Max-Forwards header is used to prevent loops in a SIP network. Each intermediary,
like SIP proxys and SBCs, decrement this counter and detects when it reaches zero,
at which point the SIP request is nicely killed in a SIP-friendly way.
Review: https://reviewboard.asterisk.org/r/778/
Thanks to dvossel for the review and good advice.
git-svn-id: http://svn.digium.com/svn/asterisk/trunk@276951 f38db490-d61c-443f-a65b-d21fe96a405b
dvossel