This was essentially duplicated functionality where normal channels used
AST_CAUSE_ANSWERED_ELSEWHERE while local channels and queues used
AST_FLAG_ANSWERED_ELSEWHERE. This removes the flag and converts that usage
into AST_CAUSE_ANSWERED_ELSEWHER usage.
Review: https://reviewboard.asterisk.org/r/1944
(closes issue ASTERISK-19865)
Patch-by: Birger Harzenetter
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368519 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 351130 broke corect HANGUPCAUSE setting
for the 404 case in chan_sip. Other cases were also
potentially broken. This patch fixes the relaying
of causes to be what they used to be.
(closes issue ASTERISK-19914)
Reported by Pavel Troller
Tested by Walter Doekes (via a reviewboard test to be committed later)
Patches:
chan_sip.diff uploaded by Pavel Troller (license #6302)
........
Merged revisions 368498 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368499 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Presence support has been added. This is accomplished by
allowing for presence hints in addition to device state
hints. A dialplan function called PRESENCE_STATE has been
added to allow for setting and reading presence. Presence
can be transmitted to Digium phones using custom XML
elements in a PIDF presence document.
Voicemail has new APIs that allow for moving, removing,
forwarding, and playing messages. Messages have had a new
unique message ID added to them so that the APIs will work
reliably. The state of a voicemail mailbox can be obtained
using an API that allows one to get a snapshot of the mailbox.
A voicemail Dialplan App called VoiceMailPlayMsg has been
added to be able to play back a specific message.
Configuration hooks have been added. Configuration hooks
allow for a piece of code to be executed when a specific
configuration file is loaded by a specific module. This is
useful for modules that are dependent on the configuration
of other modules.
chan_sip now has a public method that allows for a custom
SIP INFO request to be sent mid-dialog. Digium phones use
this in order to display progress bars when files are played.
Messaging support has been expanded a bit. The main
visible difference is the addition of an AMI action
MessageSend.
Finally, a ParkingLots manager action has been added in order
to get a list of parking lots.
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk should not accept SDP offers that contain unknown RTP profiles (for
audio/video streams) or unknown top-level media types. When it does, it answers
with an SDP that does not match the offer properly, and this will nearly
always result in a broken call. This patch causes such offers to be rejected.
Review: https://reviewboard.asterisk.org/r/1811/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368269 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* 'Unsupported media type' is only reported when that is in fact the case,
not when a supported media type is included in an 'm' line that has an
invalid format.
* All warning messages related to parsing 'm' lines now include the 'm' line contents.
* (minor bugfix) newline added to port-number-zero warning messages.
* Warning messages improved to use RFC-specified terminology for various items.
* Warnings for offers that include more than one port for a single media type now
include the media type.
Review: https://reviewboard.asterisk.org/r/1811/
........
Merged revisions 368218 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 368267 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368268 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk servers are set up back-to-back, and
direct media is to be used betweeen endpoints, it is
fairly common for the two Asterisk servers to send
direct media reinvites to each other simultaneously.
This results in 491s and ACKs being exchanged between
the servers. While the media eventually gets set up
properly, the problem is that there can be a noticeable
delay for the streams to stabilize.
This patch adds a new directmedia option called "outgoing".
With this set, an immediate direct media reinvite will only
be sent if the call direction is outgoing. For incoming
dialogs, an immediate direct media reinvite will not be sent,
but further "reactionary" direct media reinvites may be sent.
Review: https://reviewboard.asterisk.org/r/1954
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@368143 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The pvt_sip allowtransfer was not being set to that of the peer's setting.
Therefore, the global allowtransfer setting was being used instead which would
lead to calls not being transfered if the global setting was set to 'no' despite
the setting on the peer being 'yes' and vice versa, calls would be allowed to
transfer even if the peer's setting was 'no' but the global setting was 'yes'.
(Closes issue ASTERISK-19856)
Reported by: Jacek
Tested by: Michael L. Young, Jacek
Patches:
issue-asterisk-19856-branch10-v3.diff uploaded by
Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/1923/
........
Merged revisions 367730 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367731 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367732 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When remotely bridging calls with directmedia, Asterisk would check
the address of the peers/users holding directmedia ACLs (set via
directmediapermit/directmediadeny) instead of the bridged peer. This
is similar to r366547, but trunk specific and involves changes to
the rtpengine instead of just chan_sip.
(closes issue AST-876)
review: https://reviewboard.asterisk.org/r/1924/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367640 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously, MWI logic utilized a counter called 'lastmsgssent' to know whether
or not MWI NOTIFY requests had been sent to a specific peer. When MWI
notifications were changed to use the internal event framework, this value was
no longer needed for its original purpose. Hence, it was no longer updated
with the new/old message counts for a peer. The value was previously removed
for Asterisk 10; however, since it was still present in Asterisk 1.8 and still
useful for reporting purposes, it was decided to re-add the value.
This patch re-adds the 'LastMsgsSent' field in the response to an AMI/CLI 'sip
show peer [peer]' command, and makes it so that the value of lastmsgssent is
updated appropriately. The value should now display the new/old message counts
for a particular peer.
(closes issue ASTERISK-17866)
Reported by: Steve Davies
patches by:
ast-17866-rb1272.patch (License #5041 by irroot)
Modified slightly for this commit
Review: https://reviewboard.asterisk.org/r/1939
........
Merged revisions 367362 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367369 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367376 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change accommodates two methods by which calls can be directed to
a user's voicemail.
* Incoming calls can be redirected to any user's voicemail.
* Established calls can be blind transferred to any user's voicemail.
Digium phones indicate the desire to direct a call to voicemail by using
a Diversion header with a reason parameter of "send_to_vm".
This patch adds the "send_to_vm" reason as a valid redirecting reason. In
addition, chan_sip.c has been modified to update redirecting information
on the transferred channel by reading a Diversion header on a REFER request.
(closes issue AST-871)
Reported by Malcolm Davenport
Review: https://reviewboard.asterisk.org/r/1925
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367163 65c4cc65-6c06-0410-ace0-fbb531ad65f3
SSL_CTX structures were allocated but never freed. This was a bigger
issue for clients than servers since new SSL_CTX structures could be
allocated for each connection. Servers, on the other hand, typically
set up a single SSL_CTX for their lifetime.
This is solved in two ways:
1. In __ssl_setup(), if a tcptls_cfg has an ssl_ctx on it, it is
freed so that a new one can take its place.
2. A companion to ast_ssl_setup() called ast_ssl_teardown() has
been added so that servers can properly free their SSL_CTXs.
(issue ASTERISK-19278)
........
Merged revisions 367002 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 367003 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@367010 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds to what was fixed in r366880. Specifically, it addresses the
following:
* chan_sip: dispose of an allocated frame in off nominal code paths in
sip_rtp_read
* func_odbc: when disposing of an allocated resultset, ensure that any rows
that were appended to that resultset are also disposed of
* cli: free the created return string buffer in another off nominal code
path
* chan_dahdi: free a frame that was allocated by the dsp layer if we choose
not to process that frame
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922/
........
Merged revisions 366944 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366948 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366955 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses a number of memory leaks in a variety of modules that were
found by a static analysis tool. A brief summary of the changes:
* app_minivm: free ast_str objects on off nominal paths
* app_page: free the ast_dial object if the requested channel technology
cannot be appended to the dialing structure
* app_queue: if a penalty rule failed to match any existing rule list
names, the created rule would not be inserted and its memory
would be leaked
* app_read: dispose of the created silence detector in the presence of
off nominal circumstances
* app_voicemail: dispose of an allocated unique ID field for MWI event
un-subscribe requests in off nominal paths; dispose of
configuration objects when using the secret.conf option
* chan_dahdi: dispose of the allocated frame produced by ast_dsp_process
* chan_iax2: properly unref peer in CLI command "iax2 unregister"
* chan_sip: dispose of the allocated frame produced by sip_rtp_read's
call of ast_dsp_process; free memory in parse unit tests
* func_dialgroup: properly deref ao2 object grhead in nominal path of
dialgroup_read
* func_odbc: free resultset in off nominal paths of odbc_read
* cli: free match_list in off nominal paths of CLI match completion
* config: free comment_buffer/list_buffer when configuration file load
is unchanged; free the same buffers any time they were
created and config files were processed
* data: free XML nodes in various places
* enum: free context buffer in off nominal paths
* features: free ast_call_feature in off nominal paths of applicationmap
config processing
* netsock2: users of ast_sockaddr_resolve pass in an ast_sockaddr struct
that is allocated by the method. Failures in
ast_sockaddr_resolve could result in the users of the method
not knowing whether or not the buffer was allocated. The
method will now not allocate the ast_sockaddr struct if it
will return failure.
* pbx: cleanup hash table traversals in off nominal paths; free
ignore pattern buffer if it already exists for the specified
context
* xmldoc: cleanup various nodes when we no longer need them
* main/editline: various cleanup of pointers not being freed before being
assigned to other memory, cleanup along off nominal paths
* menuselect/mxml: cleanup of value buffer for an attribute when that attribute
did not specify a value
* res_calendar*: responses are allocated via the various *_request method
returns and should not be allocated in the various
write_event methods; ensure attendee buffer is freed if no
data exists in the parsed node; ensure that calendar objects
are de-ref'd appropriately
* res_jabber: free buffer in off nominal path
* res_musiconhold: close the DIR* object in off nominal paths
* res_rtp_asterisk: if we run out of ports, close the rtp socket object and free
the rtp object
* res_srtp: if we fail to create the session in libsrtp, destroy the
temporary ast_srtp object
(issue ASTERISK-19665)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/1922
........
Merged revisions 366880 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366881 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366917 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch improves the handling of call id logging significantly with regard
to transfers and adding APIs to better handle specific aspects of logging.
Also, changes have been made to chan_sip in order to better handle the creation
of callids and to enable the monitor thread to bind itself to a particular
call id when a dialog is determined to be related to a callid. It then unbinds
itself before returning to normal monitoring.
review: https://reviewboard.asterisk.org/r/1886/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366842 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This is the starting point for the Asterisk 11: Who Hung Up work and provides
a framework which will allow channel drivers to report the types of hangup
cause information available in SIP_CAUSE without incurring the overhead of the
MASTER_CHANNEL dialplan function. The initial implementation only includes
cause generation for chan_sip and does not include cause code translation
utilities.
This change deprecates SIP_CAUSE and replaces its method of reporting cause
codes with the new framework. This change also deprecates the 'storesipcause'
option in sip.conf.
Review: https://reviewboard.asterisk.org/r/1822/
(Closes issue SWP-4221)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366408 65c4cc65-6c06-0410-ace0-fbb531ad65f3
To make a long story short, reinvite glares were broken
because Asterisk would invert the To and From headers
when ACKing a 491 response.
The reason was because the initreq of the dialog was being
changed to the incoming glared reinvite instead of being
set to the outgoing glared reinvite. This change has three
parts
* In handle_incoming, we never will reject an ACK because it
has a to-tag present, even if we think the request may be out
of dialog.
* In handle_request_invite, we do not change the initreq when
receiving a reinvite to which we will respond with a 491.
* In handle_request_invite, several superflous settings up
pendinginvite have been removed since this is dones automatically
by transmit_response_reliable
Review: https://reviewboard.asterisk.org/r/1911
........
Merged revisions 366389 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366390 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366401 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This resolves core findings from ASTERISK-19650 numbers 0-2, 6, 7, 9-11, 14-20,
22-24, 28, 30-32, 34-36, 42-56, 82-84, 87, 89-90, 93-102, 104, 105, 109-111,
and 115. Finding numbers 26, 33, and 29 were already resolved. Those skipped
were either extended/deprecated or in areas of code that shouldn't be
disturbed.
(Closes issue ASTERISK-19650)
........
Merged revisions 366167 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 366168 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@366169 65c4cc65-6c06-0410-ace0-fbb531ad65f3
chan_sip was coded under the assumption that a SIP dialog with an owner channel
will always be destroyed after the owner channel has been hung up.
However, there are situations where the SIP dialog can time out and auto destruct
before the corresponding channel has hung up. A typical example of this would be
if the 'h' extension in the dialplan takes a long time to complete. In such cases,
__sip_autodestruct() would complain about the dialog being auto destroyed with
an owner channel still in place. The problem is that even once the owner channel
was hung up, the sip_pvt would still be linked in its ao2_container because nothing
would ever unlink it.
The fix for this is that if __sip_autodestruct() is called for a sip_pvt that still
has an owner channel in place, the destruction is rescheduled for 10 seconds in the
future. This will continue until the owner channel is finally hung up.
(closes issue ASTERISK-19425)
reported by David Cunningham
Patches:
ASTERISK-19425.patch uploaded by Mark Michelson (License #5049)
(closes issue ASTERISK-19455)
reported by Dean Vesvuio
Tested by Dean Vesvuio
........
Merged revisions 365896 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365898 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365913 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This uses the calling channel's caller ID and connected line information
to populate the remote and local identities in the dialog-info NOTIFY when
an extension is ringing.
There is a bit of an oddity here, and that is that we seed the remote target
with the To header of the outbound call rather than the from header. This
is because it was reported that seeding with the from header caused hints
to be broken with certain SNOM devices. A comment has been added to the code
to explain this.
(closes issue ASTERISK-16735)
reported by Maciej Krajewski
patches:
local_remote_hint2.diff uploaded by Mark Michelson (license #5049)
16735_tweak1.diff uploaded by Mark Michelson (license #5049)
Tested by Niccolo Belli
........
Merged revisions 365574 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365575 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365576 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most of the changes here are trivial NULL checks. There are a couple
optimizations to remove the need to check for NULL and outboundproxy parsing
in chan_sip.c was rewritten to avoid use of strtok. Additionally, a bug was
found and fixed with the parsing of outboundproxy when "outboundproxy=," was
set.
(Closes issue ASTERISK-19654)
........
Merged revisions 365398 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 365399 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@365400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reason I'm removing this is that Coverity reported a STRAY_SEMICOLON
issue here. Since the function has been unused for so long, I just elected
to remove it altogether.
(closes issue ASTERISK-19660)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364915 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Revision 360862 was intended to improve identities sent in dialog-info
NOTIFY requests. Some users reported that hint became broken once this
was done. It's not clear exactly what part of the patch has caused this
regression, but broken hints are bad.
For now, this revision is being reverted so that the next releases of
Asterisk do not have bad behavior in them. The original reported issue
will have to be fixed differently in the next version of Asterisk.
(issue ASTERISK-16735)
........
Merged revisions 364706 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364707 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364708 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If enabled using the keepalive option in sip.conf a small packet will be sent
at a regular interval to keep the NAT mapping open. This is lightweight as the
remote side does not need to parse and handle a SIP message.
(closes issue AST-783)
Review: https://reviewboard.asterisk.org/r/1756/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364500 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Unref the SIP pvt stored in the refer structure as soon as it is no longer
needed so that the pvt and associated file descriptors can be freed sooner.
This change makes a reference decrement unnecessary in code that handles SIP
BYE/Also transfers which should not touch the reference anyway.
(Closes issue ASTERISK-19579)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
........
Merged revisions 364258 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364259 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364260 65c4cc65-6c06-0410-ace0-fbb531ad65f3
As a continuation of the patch in r356604, which allowed for the
reloading of SRTP keys in re-INVITE transfer scenarios, this patch
addresses the more common case where a new key is requested within
the context of a current SIP dialog. This can occur, for example, when
certain phones request a SIP hold.
Previously, once a dialog was associated with an SRTP object, any
subsequent attempt to process crypto keys in any SDP offer - either
the current one or a new offer in a new SIP request - were ignored. This
patch changes this behavior to only ignore subsequent crypto keys within
the current SDP offer, but allows future SDP offers to change the keys.
(issue ASTERISK-19253)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Review: https://reviewboard.asteriskorg/r/1885/
........
Merged revisions 364203 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 364204 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@364205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reference held for SIP blind transfers using the Replaces header in an
INVITE was never freed on success and also failed to be freed in some error
conditions. This caused a file descriptor leak since the RTP structures in use
at the time of the transfer were never freed. This reference leak and another
relating to subscriptions in the same code path have now been corrected.
(closes issue ASTERISK-19579)
........
Merged revisions 363986 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363987 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363988 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If Asterisk receives a SIP UPDATE request after a call has been terminated and
the channel has been destroyed but before the SIP dialog has been destroyed, a
condition exists where a connected line update would be attempted on a
non-existing channel. This would cause Asterisk to crash. The patch resolves
this by first ensuring that the SIP dialog has an owning channel before
attempting a connected line update. If an UPDATE request is received and no
channel is associated with the dialog, a 481 response is sent.
(closes issue ASTERISK-19770)
Reported by: Thomas Arimont
Tested by: Matt Jordan
Patches:
ASTERISK-19278-2012-04-16.diff uploaded by Matt Jordan (license 6283)
........
Merged revisions 363106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 363107 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@363108 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a bind address is set to an ANY address (udpbindport=::), a warning message
is displayed stating that "Address remapping activated in sip.conf but we're
using IPv6, which doesn't need it. Please remove 'localnet' and/or 'externaddr'
settings." But if one is running dual stack, we shouldn't be told to turn those
settings off.
This patch checks if the bind address is an ANY address or not. The warning
message will now only be displayed if the bind address is NOT an ANY address and
IPv6 is being used.
Also, updated the copyright year.
(closes issue ASTERISK-19456)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
chan_sip_ipv6_message.diff uploaded by Michael L. Young (license 5026)
........
Merged revisions 362253 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 362264 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@362266 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change makes use of connected party information in addition to caller ID in order
to populate local and remote XML elements in the dialog-info NOTIFYs.
(closes issue ASTERISK-16735)
Reported by: Maciej Krajewski
Tested by: Maciej Krajewski
Patches:
local_remote_hint2.diff uploaded by Mark Michelson (license 5049)
........
Merged revisions 360862 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360863 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360872 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk detects a hangup and cannot send a BYE due to a pending
INVITE, it sets the pendingbye flag and waits for the final response to that
INVITE. When the response is received, it transmits the BYE. If, however,
that INVITE request is a pending re-INVITE, it needs to first send a CANCEL
request to terminate the pending re-INVITE. In that circumstance, Asterisk
was, in some scenarios, clearing the pendingbye flag after processing the
CANCEL request and not checking for a pending BYE when receiving the final
487 response to the INVITE.
This patch ensures that if the pendingbye flag is set, it is honored
regardless of the nature of the INVITE request currently in flight.
(closes issue ASTERISK-19365)
Reported by: Thomas Arimont
Tested by: Thomas Arimont
Patches:
bugASTERISK-19365_2012_03_08.patch uploaded by mjordan (license 6283)
Review: https://reviewboard.asterisk.org/r/1807
........
Merged revisions 360086 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 360088 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@360089 65c4cc65-6c06-0410-ace0-fbb531ad65f3
