This disables building by default for all extended modules for
Certified Asterisk 11.6. This commit was missed from 11.2-cert when
creating the 11.6-cert branch.
ASTERISK-24104 #close
Reported by: Rusty Newton
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@421209 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r402345 | kmoore | 2013-11-01 05:31:49 -0700 (Fri, 01 Nov 2013) | 11 lines
chan_sip: Fix RTCP port for SRFLX ICE candidates
This corrects one-way audio between Asterisk and Chrome/jssip as a
result of Asterisk inserting the incorrect RTCP port into RTCP SRFLX
ICE candidates. This also exposes an ICE component enumeration to
extract further details from candidates.
(closes issue ASTERISK-21383)
Reported by: Shaun Clark
Review: https://reviewboard.asterisk.org/r/2967/
........
r405234 | kharwell | 2014-01-09 08:49:55 -0800 (Thu, 09 Jan 2014) | 19 lines
res_rtp_asterisk: Fails to resume WebRTC call from hold
In ast_rtp_ice_start if the ice session create check list failed, start check
was never initiated and ice_started was never set to true. Upon re-entering
the function (for instance, [un]hold) it would try to create the check list
again with duplicate remote candidates.
Fixed so that if the create check list fails the necessary data structures
are properly re-initialized for any subsequent retries.
Note, it was decided to not stop ice support (by calling ast_rtp_ice_stop) on a
check list failure because it possible things might still work. However, a
debug message was added to help with any future troubleshooting.
(closes issue ASTERISK-22911)
Reported by: Vytis Valentinavičius
Patches:
works_on_my_machine.patch uploaded by xytis (license 6558)
........
r409129 | jrose | 2014-02-27 11:19:02 -0800 (Thu, 27 Feb 2014) | 15 lines
res_rtp_asterisk: Fix checklist creating problems in ICE sessions
Prior to this patch, local candidate lists including SRFLX would fail to start
properly when building ICE candidate check lists. This patch fixes that problem
by making sure that each SRFLX candidate is associated with the proper
base address so that the check list can create matches properly.
This patch was written by jcolp. The issue will be left open to await testing
by the issue participants.
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
r409130 | jrose | 2014-02-27 11:38:10 -0800 (Thu, 27 Feb 2014) | 8 lines
res_rtp_asterisk: correct build error from r409129
Accidentally placed a declaration below functional code
(issue ASTERISK-23213)
Reported by: Andrea Suisani
Review: https://reviewboard.asterisk.org/r/3256/
........
r409565 | jrose | 2014-03-04 08:40:39 -0800 (Tue, 04 Mar 2014) | 9 lines
res_rtp_asterisk: Fix one way audio problems with hold/unhold when using ICE
ICE sessions will now be restarted if sessions are changed to use new sets of
remote candidates.
(closes issue ASTERISK-22911)
Reported by: Vytis Valentinavičius
Review: https://reviewboard.asterisk.org/r/3275/
........
r413008 | mjordan | 2014-04-25 10:47:21 -0700 (Fri, 25 Apr 2014) | 14 lines
res_rtp_asterisk: Add support for DTLS handshake retransmissions
On congested networks, it is possible for the DTLS handshake messages to get
lost. This patch adds a timer to res_rtp_asterisk that will periodically
check to see if the handshake has succeeded. If not, it will retransmit the
DTLS handshake.
Review: https://reviewboard.asterisk.org/r/3337
ASTERISK-23649 #close
Reported by: Nitesh Bansal
patches:
dtls_retransmission.patch uploaded by Nitesh Bansal (License 6418)
........
r417141 | file | 2014-06-23 11:49:14 -0700 (Mon, 23 Jun 2014) | 5 lines
res_rtp_asterisk: Return the length of data written when sending via ICE instead of 0.
ASTERISK-23834 #close
Reported by: Richard Kenner
........
r417677 | file | 2014-06-30 12:42:18 -0700 (Mon, 30 Jun 2014) | 12 lines
res_rtp_asterisk: Add SHA-256 support for DTLS and perform DTLS negotiation on RTCP.
This change fixes up DTLS support in res_rtp_asterisk so it can accept and provide
a SHA-256 fingerprint, so it occurs on RTCP, and so it occurs after ICE negotiation
completes. Configuration options to chan_sip have also been added to allow behavior
to be tweaked (such as forcing the AVP type media transports in SDP).
ASTERISK-22961 #close
Reported by: Jay Jideliov
Review: https://reviewboard.asterisk.org/r/3679/
........
Merged revisions 402345,405234,409129-409130,409565,413008,417141,417677 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@417724 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Simply establishing a TCP connection and never sending anything to the
configured HTTP port in http.conf will tie up a HTTP connection. Since
there is a maximum number of open HTTP sessions allowed at a time you can
block legitimate connections.
A similar problem exists if a HTTP request is started but never finished.
* Added http.conf session_inactivity timer option to close HTTP
connections that aren't doing anything. Defaults to 30000 ms.
* Removed the undocumented manager.conf block-sockets option. It
interferes with TCP/TLS inactivity timeouts.
* AMI and SIP TLS connections now have better authentication timeout
protection. Though I didn't remove the bizzare TLS timeout polling code
from chan_sip.
* chan_sip can now handle SSL certificate renegotiations in the middle of
a session. It couldn't do that before because the socket was non-blocking
and the SSL calls were not restarted as documented by the OpenSSL
documentation.
* Fixed an off nominal leak of the ssl struct in
handle_tcptls_connection() if the FILE stream failed to open and the SSL
certificate negotiations failed.
The patch creates a custom FILE stream handler to give the created FILE
streams inactivity timeout and timeout after a specific moment in time
capability. This approach eliminates the need for code using the FILE
stream to be redesigned to deal with the timeouts.
This patch indirectly fixes most of ASTERISK-18345 by fixing the usage of
the SSL_read/SSL_write operations.
ASTERISK-23673 #close
Reported by: Richard Mudgett
........
Merged revisions 415841 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 415854 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@415977 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When overlap dialing is enabled, the lack of inband audio available
information in the SETUP_ACKNOWLEDGE events causes an interoperability
problem with SIP. sig_pri doesn't know if there is dialtone present when
a SETUP_ACKNOWLEDGE is received so it assumes it is there and posts an
AST_CONTROL_PROGRESS frame. The SIP channel driver then sends out a 183
Session Progress and blocks the desired 180 Ringing message when the
ALERTING message comes in.
* Made the configure script detect if the installed version of libpri
supports the SETUP_ACKNOWLEDGE enhancements.
* Using the new API, made generate an AST_CONTROL_PROGRESS frame on an
incoming SETUP_ACKNOWLEDGE message when the message indicates inband audio
is present instead of assuming that dialtone is present.
* Using the new API, made SETUP_ACKNOWLEDGE send out an inband audio
available indication only if dialtone is expected. The change also makes
the fallback behaviour of sending the PROGRESS message better by sending
it only if dialtone is expected.
* Changed receiving a PROCEEDING message to not generate an
AST_CONTROL_PROGRESS frame if the progress indication ie indicates
non-end-to-end-ISDN. This helps interoperability with SIP.
* Changed sending a PROCEEDING message in response to an
AST_CONTROL_PROCEEDING frame to not indicate inband audio available. It
was silly to do so anyway because the channel driver doesn't know if
inband audio is even available. This helps interoperability with SIP.
This patch and a corresponding change in libpri work together to allow
Asterisk to control the inband audio available progress indication ie on
the SETUP_ACKNOWLEDGE message when dialtone is present.
AST-1338 #close
Reported by: Tyler Stewart
Review: https://reviewboard.asterisk.org/r/3521/
........
Merged revisions 413714 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 413765 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@413773 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change allows chan_sip to avoid creation of the channel and
consumption of associated file descriptors altogether if the inbound
request is going to be rejected anyway.
(closes issue ASTERISK-23373)
Reported by: Corey Farrell
Patches:
chan_sip-earlier-st-1.8.patch uploaded by Corey Farrell (license 5909)
chan_sip-earlier-st-11.patch uploaded by Corey Farrell (license 5909)
........
Merged revisions 410308 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410311 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@410359 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Establishing an IAX2 call between Asterisk v1.4 and v1.8 (or later)
results in an unexpected call disconnect. The problem happens because
newer values in the enum ast_control_frame_type are not consistent between
the branch versions of Asterisk.
For example:
1) v1.4 calls v1.8 (or later) using IAX2
2) v1.8 answers and sends a connected line update control frame. (on v1.8
AST_CONTROL_CONNECTED_LINE = 22)
3) v1.4 receives the control frame as an end-of-q (on v1.4
AST_CONTROL_END_OF_Q = 22)
4) v1.4 disconnects the call once the receive queue becomes empty.
Several things are done by this patch to fix the problem and attempt to
prevent it from happening again in the future:
* Added a warning at the definition of enum ast_control_frame_type about
how to add new control frame values.
* Made block sending and receiving control frames that have no reason to
go over the wire.
* Extended the connectedline iax.conf parameter to also include the
redirecting information updates.
* Updated the connectedline iax.conf parameter documentation to include a
notice that the parameter must be "no" when the peer is an Asterisk v1.4
instance.
(closes issue AST-1302)
Review: https://reviewboard.asterisk.org/r/3174/
........
Merged revisions 407678 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 407727 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@407746 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When performing a SIP transfer to a Park extension, if the Park fails, chan_sip
will currently not hang up either the transferer or the transfer target. This
results in the channels being orphaned with no thread to service frames,
resulting in stuck channels.
This patch immediately hangs up the two channels if a Park fails.
(closes issue ASTERISK-22834)
Reported by: rsw686
Tested by: rsw686
(closes issue ASTERISK-23047)
Reported by: Tommy Thompson
Tested by: Tommy Thomspon
Review: https://reviewboard.asterisk.org/r/3107
........
Merged revisions 405380 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@405536 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The presentation indicator in a callerid (e.g. set by dialplan function
Set(CALLERID(name-pres)= ...)) is not checked when SIP Dialog Info Notifies
are generated during extension monitoring. Added a check to make sure the
name and/or number presentations on the callee (remote identity) are set to
allow. If they are restricted then "anonymous" is used instead.
(closes issue AST-1175)
Reported by: Thomas Arimont
Review: https://reviewboard.asterisk.org/r/2976/
........
Merged revisions 402450 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/certified/branches/11.6@402463 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a new IAX2 client registers, the astdb database is updated with the
value of minregexpire defined in iax.conf instead of using the expiry time
that is provided by the client. The provided expiry time of the client is
updated after inserting the astdb entry. As a consequence, restarting or
reloading asterisk creates clients whose registration may expire before
they reregister. The clients are therefore unavailable after minregexpire
seconds until they reregister.
* Move updating of the expiry time to before inserting into the astdb.
(closes issue ASTERISK-22504)
Reported by: Stefan Wachtler
Patches:
chan_iax2.c.patch (license #6533) patch uploaded by Stefan Wachtler
........
Merged revisions 399158 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@399159 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If we receive a 200 OK without SDP, we will now check to see if
the remote address has been established for that channel's RTP
session and if the to tag for that channel has changed from
the most recent to tag in a response less than 200.
If either a change has been made since the last to-tag was
received or the remote address is unset, then we will drop
the call.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/diff/#index_header
........
Merged revisions 398835 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398836 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes the things in chan_h323 that were missed or ignored in the
great channel opaquification and gets chan_h323 back into a compiling
state.
(closes issue ASTERISK-22365)
Reported by: Dmitry Melekhov
Patches:
chan_h323.patch uploaded by Dmitry Melekhov
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398510 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix stray reference to idle_list in cleanup_thread_list(). This may be
the reason for the note in iax2_process_thread() about threads not being
removed from the task lists.
* Move cleanup_thread_list(&idle_list) to after the other lists are
cleaned up.
........
Merged revisions 398416 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398417 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fix bridgecallno deadlock avoidance. When doing deadlock avoidance, you
need to retest the status of values for each loop to see if you still need
the lock for bridgecallno.
* As a safety check, after acquiring the bridgecallno lock you should
check if iaxs[bridgecallno] is NULL just like the current callno checks.
* Move setting thread->iostate to IAX_IOSTATE_IDLE to after processing any
deferred frames to ensure that the iostate is IDLE when it is placed back
into the idle list. defer_full_frame() tries to ensure
iax2_process_thread() wakes up to process the frame.
........
Merged revisions 398379 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398380 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fix the misdn debug output to remote consoles. chan_misdn uses
ast_console_puts() which doesn't know about verbose levels. Better to use
ast_verbose() instead. Without this patch the misdn debug messages are
appended to the verbose level which ever was set by the message sent to
the console before, i.e. any undefined level.
(closes issue AST-1218)
Reported by: Guenther Kelleter
Patches:
misdnlog.patch (license #6372) patch uploaded by Guenther Kelleter
........
Merged revisions 398235 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@398236 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Refactored cases where a combination of ast_verbose/options_verbose were
present. Also in general tried to eliminate, in as many places as possible,
where the options_verbose global variable was being used. Refactored the way
local and remote consoles handle verbose message logging in an attempt to
solve the various discrepancies that sometimes would show between the two.
(closes issue AST-1193)
Reported by: Guenther Kelleter
Review: https://reviewboard.asterisk.org/r/2798/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397948 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If the SIP channel driver processes an invalid SDP that defines media
descriptions before connection information, it may attempt to reference
the socket address information even though that information has not yet
been set. This will cause a crash.
This patch adds checks when handling the various media descriptions that
ensures the media descriptions are handled only if we have connection
information suitable for that media.
Thanks to Walter Doekes, OSSO B.V., for reporting, testing, and providing
the solution to this problem.
(closes issue ASTERISK-22007)
Reported by: wdoekes
Tested by: wdoekes
patches:
issueA22007_sdp_without_c_death.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397756 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397757 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397758 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A remote exploitable crash vulnerability exists in the SIP channel driver if an
ACK with SDP is received after the channel has been terminated. The handling
code incorrectly assumed that the channel would always be present.
This patch adds a check such that the SDP will only be parsed and applied if
Asterisk has a channel present that is associated with the dialog.
Note that the patch being applied was modified only slightly from the patch
provided by Walter Doekes of OSSO B.V.
(closes issue ASTERISK-21064)
Reported by: Colin Cuthbertson
Tested by: wdoekes, Colin Cutherbertson
patches:
issueA21064_fix.patch uploaded by wdoekes (License 5674)
........
Merged revisions 397710 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 397711 from http://svn.asterisk.org/svn/asterisk/branches/10
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397712 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Review https://reviewboard.asterisk.org/r/2580/ tried to fix the mismatch
in memory pools but had a math error determining the buffer size and
didn't address other similar memory pool mismatches.
* Effectively reverted the previous patch to go in the same direction as
trunk for the returned memory pool of ast_bt_get_symbols().
* Fixed memory leak in ast_bt_get_symbols() when BETTER_BACKTRACES is
defined.
* Fixed some formatting in ast_bt_get_symbols().
* Fixed sig_pri.c freeing memory allocated by libpri when MALLOC_DEBUG is
enabled.
* Fixed __dump_backtrace() freeing memory from ast_bt_get_symbols() when
MALLOC_DEBUG is enabled.
* Moved __dump_backtrace() because of compile issues with the utils
directory.
(closes issue ASTERISK-22221)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2778/
........
Merged revisions 397525 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397528 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a From header on an outbound out-of-call SIP MESSAGE were
malformed, the result could crash Asterisk.
In addition, if a From header on an incoming out-of-call SIP
MESSAGE request were malformed, the message was happily accepted
rather than being rejected up front. The incoming message path
would not result in a crash, but the behavior was bad nonetheless.
(closes issue ASTERISK-22185)
reported by Zhang Lei
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397254 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In 1.8, r384779 introduced a regression by retrieving an old dialog and keeping
the old recv address since recv was already set. This has caused a problem when
a proxy is involved since responses to incoming requests from the proxy server,
after an outbound call is established, are never sent to the correct recv
address.
In 11, r382322 introduced this regression.
The fix is to revert that change and always store the recv address on incoming
requests.
Thank you Walter Doekes for helping to point out this error and Mark Michelson
for your input/review of the fix.
(closes issue ASTERISK-22071)
Reported by: Alex Zarubin
Tested by: Alex Zarubin, Karsten Wemheuer
Patches:
asterisk-22071-store-recvd-address.diff by Michael L. Young (license 5026)
........
Merged revisions 397204 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@397205 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a peer is used in a register line and TLS is defined as the transport, the
registration fails since the transport on the dialog is never set properly
resulting in UDP being used instead of TLS.
This patch sets the dialog's transport based on the transport that was defined
in the register line. If the register line does not specify a transport, the
parsing function for the register line always defaults back to UDP.
(closes issue ASTERISK-21964)
Reported by: Doug Bailey
Tested by: Doug Bailey
Patches:
asterisk-21964-set-reg-dialog-transport.diff
by Michael L. Young (license 5026)
........
Merged revisions 396240 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@396248 65c4cc65-6c06-0410-ace0-fbb531ad65f3
from mixing different variants or general MFC-R2 settings within the same E1 line.
Most users do not have a problem with this since MFC-R2 lines are usually fractional E1s, or
the whole E1 has the same country variant and R2 settings.
In Venezuela however is common to have inbound MFC-R2 and outbound DTMF-R2 within the same E1.
This fix now properly parses the chan_dahdi.conf file to generate a new openr2 context every
time a new channel => section is found and the configuration was changed.
(closes issue ASTERISK-21117)
Reported by: Rafael Angulo
Related Elastix issue: http://bugs.elastix.org/view.php?id=1612
........
Merged revisions 394106 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@394173 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes the following memory leaks:
* http.c: The structure containing the addresses to bind to was not being
deallocated when no longer used
* named_acl.c: The global configuration information was not disposed of
* config_options.c: An invalid read was occurring for certain option types.
* res_calendar.c: The loaded calendars on module unload were not being
properly disposed of.
* chan_motif.c: The format capabilities needed to be disposed of on module
unload. In addition, this now specifies the default options for the
maxpayloads and maxicecandidates in such a way that it doesn't cause the
invalid read in config_options.c to occur.
(issue ASTERISK-21906)
Reported by: John Hardin
patches:
http.patch uploaded by jhardin (license 6512)
named_acl.patch uploaded by jhardin (license 6512)
config_options.patch uploaded by jhardin (license 6512)
res_calendar.patch uploaded by jhardin (license 6512)
chan_motif.patch uploaded by jhardin (license 6512)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@392810 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1). When touching the bridgecallno, we need to lock it.
2). stop_stuff() which calls iax2_destroy_helper()
Assumes the lock on the pvt is already held, when iax2_destroy_helper() is called.
Thus we need to lock the bridgecallno pvt before we call stop_stuff(iaxs[fr->callno]->bridgecallno);
3). When evaluating the state of 'callno->transferring' of the current leg,
we can't change it to READY unless the bridgecallno is locked.
Why, if we are interrupted by the other call leg before 'transferring = TRANSFER_RELEASED',
the interrupt will find that it is READY and that the bridgecallno is also READY so Releases the legs.
(closes issue ASTERISK-21409)
Reported by: alecdavis
Tested by: alecdavis
alecdavis (license 585)
Review https://reviewboard.asterisk.org/r/2594/
........
Merged revisions 391062 from http://svn.asterisk.org/svn/asterisk/branches/1.8
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@391063 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The prior code committed, r385473, failed to take into consideration that not
all outgoing calls will be to a peer. My fault.
This patch does the following:
* Check if there is a related peer involved. If there is, check and set NAT
settings according to the peer's settings.
* Fix a problem with realtime peers. If the global setting has auto_force_rport
set and we issued a "sip reload" while a peer is still registered, the peer's
flags for NAT are reset to off. When this happens, we were always setting the
contact address of the peer to that of the full contact info that we had.
(closes issue ASTERISK-21374)
Reported by: jmls
Tested by: Michael L. Young
Patches:
asterisk-21374-fix-crash-and-rt-peers.diff by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2524/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/11@388601 65c4cc65-6c06-0410-ace0-fbb531ad65f3
