Previously, Asterisk only processed session timer information if both the
'Supported: timer' and 'Session-Expires' headers were present. However, the
Session-Expires header is optional. If we were to receive a request with a
Min-SE greater than our configured session-expires, we would respond with a
'Session-Expires' header that was too small.
This patch cleans the situation up a bit, always processing timer information
if the 'Supported: timer' header is present.
(closes issue ASTERISK-20787)
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/2299/
........
Merged revisions 380696 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380698 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A user in #asterisk ran into a problem where a configuration error prevented
the chan_sip module from being loaded. Upon fixing their configuratione error,
they could no longer load the chan_sip module. This was because the
configuration checking happened after the SIP provider was registered with the
Asterisk core, and subsequent attempts to load the SIP module failed as the
provider was already registered.
Since we want to detect any failure in registering chan_sip as early as
possible (as that could be emblematic of a deeper mismatch between module
and Asterisk core), this patch does not change the registration location, but
does ensure that if a module load is declined, we unregister the module as
the SIP api provider.
........
Merged revisions 380480 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC5347 section 2.5.2 states the following:
...
The attribute "T38MaxBitRate" was once incorrectly registered with
IANA as "T38maxBitRate" (lower-case "m"). In accordance with T.38
examples and common implementation practice, the form "T38MaxBitRate"
SHOULD be generated by implementations conforming to this package.
In general, it is RECOMMENDED that implementations of this package
accept lowercase, uppercase, and mixed upper/lowercase encodings of
all the T.38 attributes.
...
Asterisk currently does not perform case insensitive matching on the T.38
attributes. This causes the T38MaxBitRate attribute to be negotiated at
2400 baud instead of 14400 (or whatever value you actually wanted).
This patch makes it so that when we compare T.38 attributes, we do so in a case
insensitive fashion.
Note that while the issue reporter did not directly write the patch, they
contributed to it (and would have provided one themselves if the license had
gone through a tad faster), and hence get attribution for it.
Review: https://reviewboard.asterisk.org/r/2298/
(closes issue ASTERISK-20897)
Reported by: Eric Hill
Tested by: Eric Hill
patches:
-- uploaded by Eric Hill
........
Merged revisions 380458 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 380465 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380479 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r369028, chan_sip's processing of media streams in an SDP was modified to
better handle multiple offered media streams. Part of that change modified
how streams were declined. Previously, declined media streams were not
handled in an RFC compliant manner; now, we set the port number to 0 in the
media stream definition and proceed on with the next media stream.
Unfortunately, the formatting of the declined media stream forgot to append a
'\r\n' to the end of the media stream. This is normally added to the accepted
media streams later on in the processing of the SDP. Since the declined media
stream uses a different buffer than the accepted media streams (and is a
malloc'd buffer as opposed to a struct ast_str), it's easier to just slap the
'\r\n' on the declined media stream buffer rather than attempt to append it
later on.
So, that's what we do. And now some devices (and probably some providers) will
be a bit happier (but probably not terribly happy, since we just rejected
something they offered).
Review: https://reviewboard.asterisk.org/r/2297/
(closes issue ASTERISK-20908)
Reported by: Dennis DeDonatis
Tested by: Dennis DeDonatis
........
Merged revisions 380331 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@380332 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Record-Route parsing copied the header into a char[256] array, which can
be a problem if the header is longer than that. This patch parses the
header in place, without the copy, avoiding the issue.
In addition to the original patch, I added a unit test for the new
get_in_brackets_const function.
(closes issue ASTERISK-20837)
Reported by: Corey Farrell
Patches:
chan_sip-build_route-optimized-rev1.patch uploaded by Corey Farrell (license 5909)
(with minor changes by dlee)
........
Merged revisions 379392 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 379393 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@379394 65c4cc65-6c06-0410-ace0-fbb531ad65f3
XML encoding in chan_sip is accomplished by naively building the XML
directly from strings. While this usually works, it fails to take into
account escaping the reserved characters in XML.
This patch adds an 'ast_xml_escape' function, which works similarly to
'ast_uri_encode'. This is used to properly escape the local_display
attribute in XML formatted NOTIFY messages.
Several things to note:
* The Right Thing(TM) to do would probably be to replace the
ast_build_string stuff with building an ast_xml_doc. That's a much
bigger change, and out of scope for the original ticket, so I
refrained myself.
* It is with great sadness that I wrote my own ast_xml_escape
function. There's one in libxml2, but it's knee-deep in
libxml2-ness, and not easily used to one-off escape a
string.
* I only escaped the string we know is causing problems
(local_display). At least some of the other strings are
URI-encoded, which should be XML safe. Rather than figuring out
what's safe and escaping what's not, it would be much cleaner to
simply build an ast_xml_doc for the messages and let the XML
library do the XML escaping. Like I said, that's out of scope.
(closes issue ABE-2902)
Reported by: Guenther Kelleter
Tested by: Guenther Kelleter
Review: http://reviewboard.digium.internal/r/365/
........
Merged revision 378919 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 378933 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378934 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378935 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a multihomed server when sending a NOTIFY message, we were not figuring out
which network should be used to contact the peer.
This patch fixes the problem by calling ast_sip_ouraddrfor() and then
build_via() so that our NOTIFY message contains the correct IP address.
Also, a debug message is being added to help follow the call-id changes that
occur. This was helpful for confirming that the IP address was set properly
since the call-id contains the IP address. It also will be helpful for
troubleshooting purposes when following a call in the debug logs.
(closes issue ASTERISK-20805)
Reported by: Bryan Hunt
Tested by: Bryan Hunt, Michael L. Young
Patches:
asterisk-20805-notify-ip-v2.diff uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2255/
........
Merged revisions 378554 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378559 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378565 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk maintains an internal cache for devices in the event subsystem. The
device state cache holds the state of each device known to Asterisk, such that
consumers of device state information can query for the last known state for
a particular device, even if it is not part of an active call. The concept of
a device in Asterisk can include entities that do not have a physical
representation. One way that this occurred was when anonymous calls are allowed
in Asterisk. A device was automatically created and stored in the cache for
each anonymous call that occurred; this was possible in the SIP and IAX2
channel drivers and through channel drivers that utilized the
res_jabber/res_xmpp resource modules (Gtalk, Jingle, and Motif). These devices
are never removed from the system, allowing anonymous calls to potentially
exhaust a system's resources.
This patch changes the event cache subsystem and device state management to
no longer cache devices that are not associated with a physical entity.
(issue ASTERISK-20175)
Reported by: Russell Bryant, Leif Madsen, Joshua Colp
Tested by: kmoore
patches:
event-cachability-3.diff uploaded by jcolp (license 5000)
........
Merged revisions 378303 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378320 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378321 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had several places where messages received over various network
transports may be copied in a single stack allocation. In the case of TCP,
since multiple packets in a stream may be concatenated together, this can
lead to large allocations that overflow the stack.
This patch modifies those portions of Asterisk using TCP to either
favor heap allocations or use an upper bound to ensure that the stack will not
overflow:
* For SIP, the allocation now has an upper limit
* For HTTP, the allocation is now a heap allocation instead of a stack
allocation
* For XMPP (in res_jabber), the allocation has been eliminated since it was
unnecesary.
Note that the HTTP portion of this issue was independently found by Brandon
Edwards of Exodus Intelligence.
(issue ASTERISK-20658)
Reported by: wdoekes, Brandon Edwards
Tested by: mmichelson, wdoekes
patches:
ASTERISK-20658_res_jabber.c.patch uploaded by mmichelson (license 5049)
issueA20658_http_postvars_use_malloc2.patch uploaded by wdoekes (license 5674)
issueA20658_limit_sip_packet_size3.patch uploaded by wdoekes (license 5674)
........
Merged revisions 378269 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 378286 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 378287 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@378288 65c4cc65-6c06-0410-ace0-fbb531ad65f3
configured codecs to take precedence on an outgoing call.
This change introduces a new peer configuration property named
'ignore_requested_pref' that causes the requested codec to be ignored when
determining the preferred codec for an outgoing call leg. The consequence is
that Asterisk's usual efforts to prefer avoiding transcoding can be overridden
on a peer-by-peer basis where appropriate.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377971 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The issue comes from the fact that transfers may perform
a redirecting update on a channel. The issue is that lock
inversion between the channel and its tech_pvt occurs since
the channel lock is released during the transfer process.
The fix is to move when the redirecting update occurs to a
place where neither the tech_pvt or the channel is locked so
that the two can be locked in the proper order.
(closes issue ASTERISK-20708)
reported by Mark Michelson
patches:
ASTERISK-20708-3.patch uploaded by Mark Michelson (License #5049)
Tested by:
Tim Ringenbach at Asteria Solutions Group
........
Merged revisions 377910 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377911 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During the TLS re-work in chan_sip some TLS specific code was moved
into a separate function. This function operates on a copy of the
incoming SIP request. This copy was never deinitialized causing a
memory leak for each request processed.
This function is now given a SIP request structure which it can use
to copy the incoming request into. This reduces the amount of memory
allocations done since the internal allocated components are reused
between packets and also ensures the SIP request structure is
deinitialized when the TLS connection is torn down.
(closes issue ASTERISK-20763)
Reported by: deti
........
Merged revisions 377257 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 377258 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 377259 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It was a mess. The first part of chan_sip.c is constants, declarations, structures and stuff,
then forward declarations and then actual code. It's still a mess, but a bit less messy ;-)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@377018 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The principal behind this patch is simple. During a transfer,
we manipulate channels that are owned by a separate thread than
the one we currently are running in, so it makes sense that we
need to grab a reference to the channels so that they cannot
disappear out from under us.
In the wild, crashes were sometimes seen when the transferring
party would hang up the call before the transfer target answered
the call. The most common place to see the crash occur was when
attempting to send a connected line update to the transferer
channel.
(closes issue ASTERISK-20226)
Reported by Jared Smith
Patches:
ASTERISK-20226.patch uploaded by Mark Michelson (License #5049)
Tested by: Jared Smith
........
Merged revisions 376901 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 376916 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 376917 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376918 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Websocket by default doesn't return an ast_str for the payload received. When
converting it to an ast_str on chan_sip the last character was being omitted,
because ast_str functions expects that the given length includes the trailing
0x00. payload_len only has the actual string length without counting the
trailing zero.
For most cases this passed unnoticed as most of SIP messages ends with \r\n.
(closes issue ASTERISK-20745)
Reported by: Iñaki Baz Castillo
Review: https://reviewboard.asterisk.org/r/2219/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376820 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk 11 follows RFC3265 that states that after every subscribe or resubscribe a notify should be sent.
Thus the console if filled continuously with the following after every subscribe;
== Extension Changed 8512[phones] new state IDLE for Notify User cisco1
In Asterisk 1.8 only changes would be sent. Thus only when a device state changed was anything emitted to the console.
fix:
Only print to console when device state isn't forced.
(closes issue ASTERISK-20706)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
........
Merged revisions 376540 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376541 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new field is will show up within the response if the requested peer has a
subscribe context set.
(closes issue ASTERISK-20626)
Reported by: Jaco Kroon
Patches:
asterisk-sip-ami-SubscrContext.patch uploaded by jkroon (license 5671)
-with modifications by jrose to conform to style guidelines
Review: https://reviewboard.asterisk.org/r/2195/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376219 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With ICE support enabled in chan_sip and a large number of interfaces on the system it was
possible for the produced SDP to be truncated due to some fixed size buffers. These buffers
have now been changed so they will dynamically grow as needed.
ICE support is now also enabled by default in res_rtp_asterisk to provide a smoother experience
for chan_motif users where it is required. To maintain the previous behavior in chan_sip it is
no longer enabled by default there.
(closes issue ASTERISK-20643)
Reported by: coopvr
........
Merged revisions 376130 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@376131 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at some debug logs, I noticed that it was being reported that the
SDP origin line was unsupported or failed. Upon looking into this on my local
machine, I found that I too was getting this debug message yet everything seemed
to be getting processed properly. What was discovered is, that, the variable to
determine what is displayed in the debug message for the SDP line that was
processed, was not being set for the origin line when the result was successful.
This patch fixes this and was tested on local machine.
........
Merged revisions 375594 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375601 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375613 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375614 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A regression was introduced in chan_sip by changes to sip reload introduced by
r349097. That patch moved peer purging from the beginning of the reload to
after the general configuration was finished. This patch fixes that by undoing
the repositioning of the original peer purging code and using a similar
function after performing general configuration that purges only autocreated
peers that were created when persist mode isn't enabled.
(closes issue ASTERISK-20611)
Reported by: Alisher
Review: https://reviewboard.asterisk.org/r/2171/
........
Merged revisions 375575 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a "sip reload" is issued for a SIP peer, then his
IP address will be cleared, thus resulting in forgetting the
public IP address. Asterisk will then attempt to route SIP
traffic to the private IP address.
The fix here is to make "sip reload" ignore realtime peers
when "host = dynamic" is spotted. Realtime peers can now only
have their IP address reset if they have gone from being not
dynamic to being dynamic.
(closes issue ASTERISK-18203)
reported by daren ferreira
(closes issue ASTERISK-20572)
reported by JoshE
Patches:
fix_nat_realtime.diff uploaded by JoshE (license #6075)
........
Merged revisions 375415 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 375417 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 375437 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375443 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Remove the "RTP Read too short" warning for RTP keepalives. Remove the
the warning about the application delimiter switch from pipe to comma.
(You should've done this by now.) Make cdr_odbc report more when an
insert fails. Make chan_sip warn less when the peer wants SRTP (and we
don't) or sends a zero port to disable a media type.
Review: https://reviewboard.asterisk.org/r/2167
(closes issue ASTERISK-20538)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375137 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In many cases (for peers behind NAT or for TCP sockets) we do not need
to look up any hostname in the Contact (or Route) when sending an
in-dialog request. This should reduce netsock2.c: getaddrinfo errors in
certain scenarios.
Review: https://reviewboard.asterisk.org/r/2156
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375110 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Update and extend the configuration_file group and enable linking. Update title that was left behind many years ago.
(issue ASTERISK-20259)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@375006 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is used to solve an issue where a poll on a file
descriptor does not necessarily correspond to the readiness
of a FILE handle to be read.
This change makes it so that for TCP connections, we do a
recv() on the file descriptor instead.
Because TCP does not guarantee that an entire message or even
just one single message will arrive during a read, a loop has
been introduced to ensure that we only attempt to handle a
single message at a time. The tcptls_session_instance structure
has also had an overflow buffer added to it so that if more
than one TCP message arrives in one go, there is a place to
throw the excess.
Huge thanks goes out to Walter Doekes for doing extensive review
on this change and finding edge cases where code could fail.
(closes issue ASTERISK-20212)
reported by Phil Ciccone
Review: https://reviewboard.asterisk.org/r/2123
........
Merged revisions 374905 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 374906 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 374914 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374924 65c4cc65-6c06-0410-ace0-fbb531ad65f3
During testing, it was discovered that having chan_sip
export global symbols was problematic.
The biggest problem was that load order was affected.
Trying to use realtime could be problematic since in
all likelihood the necessary realtime driver(s) would
not be loaded before chan_sip.
In addition, it was found that it was impossible to
use the Digium Phone Module for Asterisk since it
must be loaded before chan_sip since it must hook
into chan_sip's configuration parsing.
The solution is to use a virtual table in the same
manner that other modules in Asterisk do, like
app_voicemail.
(closes issue ASTERISK-20545)
Reported by: kmoore
........
Merged revisions 374842 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@374849 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This allows for the REDIRECTING dialplan function to be
used to set the reason to any string.
The SIP channel driver has been modified to set the redirecting
reason string to the value received in a Diversion header. In
addition, SIP 480 response reason text will set the redirecting
reason as well.
(closes issue AST-942)
reported by Malcolm Davenport
(closes issue AST-943)
reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/2101
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373701 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The SIP session timer mechanism contains a mandatory 'refresher' parameter
(included in the Session-Expires header) which is used in the session timer
offer/answer signaling within a SIP Invite dialog. It looks like asterisk is
interpreting the uac resp. uas role only as the initial role of client and
server (caller is uac, callee is uas). The standard rfc 4028 however assigns
the client role to the ((RE)-Invite) requester, the server role to the
((RE)-Invite) responder.
This patch has Asterisk track the actual refresher as "us" or "them" as opposed
to relying on just the configured "uas" or "uac" properties.
(closes issue AST-922)
Reported by: Thomas Airmont
Review: https://reviewboard.asterisk.org/r/2118/
........
Merged revisions 373652 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373665 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373690 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373691 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk v1.8 and later was not as vulnerable to this issue.
* Made find_call() lock each private as it processes the found dialogs.
(Primary cause of ABE-2876)
* Made the other functions that traverse the dialogs container lock each
private as it examines them.
* Fix race condition in sip_call() if the thread that sent the INVITE is
held up long enough for a response to be processed. The p->initid for the
INVITE retransmission could be added after it was canceled by the response
processing.
* Made __sip_destroy() clean up resource pointers after freeing. This is
primarily defensive in case someone has a stale private pointer.
* Removed redundant memset() in reqprep(). The call to init_req() already
does the memset() and is the first reference to req in reqprep().
* Removed useless set of req.method in transmit_invite(). The calls to
initreqprep() and reqprep() have to do this because they memset() the req.
JIRA ABE-2876
..........
Merged -r373423 from https://origsvn.digium.com/svn/asterisk/be/branches/C.3-bier
........
Merged revisions 373424 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373466 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373469 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If conditions were right it was possible for both the PBX core and chan_sip to deadlock by both having a lock that the other
wants. In the case of the PBX core it had the contexts lock and wanted a SIP dialog lock, while in the case of chan_sip it
had the SIP dialog lock and wanted the contexts lock.
This fix unlocks the SIP dialog before getting the extension state so that the other thread will not block on trying to lock
it. Once the extension state is retrieved the SIP dialog is locked again and life carries on.
As the SIP dialog is reference counted it is not possible for it to go away after unlocking.
(closes issue ASTERISK-20437)
Reported by: jhutchins
........
Merged revisions 373438 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 373440 from http://svn.asterisk.org/svn/asterisk/branches/10
........
Merged revisions 373454 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@373456 65c4cc65-6c06-0410-ace0-fbb531ad65f3
