ast_module_info->self is often needed to register items with the core. Many
modules have ad-hoc code to make this pointer available to auxiliary sources.
This change updates the module build process to make the needed information
available to all sources in a module.
ASTERISK-25056 #close
Reported by: Corey Farrell
Change-Id: I18c8cd58fbcb1b708425f6757becaeca9fa91815
Odd behaviors have been observed during outbound registrations. The most
common problem witnessed has been one where a request with
authentication credentials cannot be created after receiving a 401
response. Other behaviors include apparently processing an incorrect SIP
response.
Inspecting the code led to an apparent issue with regards to how we
handle transactions in outbound registration code. When a response to a
REGISTER arrives, we save a pointer to the transaction and then push a
task onto the registration serializer. Between the time that we save the
pointer and push the task, it's possible for the transaction to be
destroyed due to a timeout. It's also possible for the address to be
reused by the transaction layer for a new transaction.
To allow for authentication of a REGISTER request to be authenticated
after the transaction has timed out, we now hold a reference to the
original REGISTER request instead of the transaction. The function for
creating a request with authentication has been altered to take the
original request instead of the transaction where the original request
was sent.
ASTERISK-25020
Reported by Mark Michelson
Change-Id: I756c19ab05ada5d0503175db9676acf87c686d0a
Permanent contacts that hadn't been qualified yet were missing
their contact_status entries causing SEGVs when running CLI
commands.
This patch makes sure that contact_statuses are created for
both dynamic and permanent contacts when they are created.
It also adds checks in the CLI code to make sure there's a
contact_status, just in case.
ASTERISK-25018 #close
Reported-by: Ivan Poddubny
Tested-by: Ivan Poddubny
Tested-by: George Joseph
Change-Id: I3cc13e5cedcafb24c400368b515b02d7fb81e029
Currently we use pjsip_parse_hdr to validate contact uris but it
appears that it allows uris without a scheme if there's a port
supplied. I.E myexample.com will fail but myexample.com:5060 will
pass even though it has no scheme. This causes SEGVs later on
whenever the uri is used.
To prevent this, permanent_contact_validate has been updated to check
that the scheme is either 'sip' or 'sips'.
2 uses of possibly-null endpoint have also been fixed in
create_out_of_dialog_request.
ASTERISK-24999
Change-Id: Ifc17d16a4923e1045d37fe51e43bbe29fa556ca2
Reported-by: Brad Latus
Contact status rtt is an int64_t and needs the PRId64 macro to
properly create the format specifier on 32-bit systems.
Change-Id: I4b8ab958fc1e9a179556a9b4ffa49673ba9fdec7
The "Add qualify_timeout processing and eventing" patch introduced
an issue where contacts that had qualify_frequency set to 0 were
showing Unavailable instead Unknown. This patch checks for
qualify_frequency=0 and create an "Unknown" contact_status
with an RTT = 0.
Previously, the lack of contact_status implied Unknown but since
we're now changing endpoint state based on contact_status, I've
had to add new UNKNOWN status so that changes could trigger the
appropriate contact_status observers.
ASTERISK-24977: #close
Change-Id: Ifcbc01533ce57f0e4e584b89a395326e098b8fe7
* changes:
res_pjsip: Add global option to limit the maximum time for initial qualifies
pjsip_options: Add qualify_timeout processing and eventing
res_pjsip: Refactor endpt_send_request to include transaction timeout
Currently when Asterisk starts initial qualifies of contacts are spread out
randomly between 0 and qualify_timeout to prevent network and system overload.
If a contact's qualify_frequency is 5 minutes however, that contact may be
unavailable to accept calls for the entire 5 minutes after startup. So while
staggering the initial qualifies is a good idea, basing the time on
qualify_timeout could leave contacts unavailable for too long.
This patch adds a new global parameter "max_initial_qualify_time" that sets the
maximum time for the initial qualifies. This way you could make sure that all
your contacts are initialy, randomly qualified within say 30 seconds but still
have the contact's ongoing qualifies at a 5 minute interval.
If max_initial_qualify_time is > 0, the formula is initial_interval =
min(max_initial_interval, qualify_timeout * random(). If not set,
qualify_timeout is used.
The default is "0" (disabled).
ASTERISK-24863 #close
Change-Id: Ib80498aa1ea9923277bef51d6a9015c9c79740f4
Tested-by: George Joseph <george.joseph@fairview5.com>
This is the second follow-on to https://reviewboard.asterisk.org/r/4572/ and the
discussion at
http://lists.digium.com/pipermail/asterisk-dev/2015-March/073921.html
The basic issues are that changes in contact status don't cause events to be
emitted for the associated endpoint. Only dynamic contact add/delete actions
update the endpoint. Also, the qualify timeout is fixed by pjsip at 32 seconds
which is a long time.
This patch makes use of the new transaction timeout feature in r4585 and
provides the following capabilities...
1. A new aor/contact variable 'qualify_timeout' has been added that allows the
user to specify the maximum time in milliseconds to wait for a response to an
OPTIONS message. The default is 3000ms. When the timer expires, the contact is
marked unavailable.
2. Contact status changes are now propagated up to the endpoint as follows...
When any contact is 'Available', the endpoint is marked as 'Reachable'. When
all contacts are 'Unavailable', the endpoint is marked as 'Unreachable'. The
existing endpoint events are generated appropriately.
ASTERISK-24863 #close
Change-Id: Id0ce0528e58014da1324856ea537e7765466044a
Tested-by: Dmitriy Serov
Tested-by: George Joseph <george.joseph@fairview5.com>
This change adds the following:
1. A query set implementation. This is an API that allows queries to be executed in parallel and once all have completed a callback is invoked.
2. Unit tests for the query set implementation.
3. An external PJSIP resolver which uses the DNS core API to do NAPTR, SRV, AAAA, and A lookups.
For the resolver it will do NAPTR, SRV, and AAAA/A lookups in parallel. If NAPTR or SRV
are available it will then do more queries. And so on. Preference is NAPTR > SRV > AAAA/A,
with IPv6 preferred over IPv4. For transport it will prefer TLS > TCP > UDP if no explicit
transport has been provided. Configured transports on the system are taken into account to
eliminate resolved addresses which have no hope of completing.
ASTERISK-24947 #close
Reported by: Joshua Colp
Change-Id: I56cb03ce4f9d3d600776f36928e0b3e379b5d71e
Git does not support the ability to replace a token with a version
string during check-in. While it does have support for replacing a
token on clone, this is somewhat sub-optimal: the token is replaced
with the object hash, which is not particularly easy for human
consumption. What's more, in practice, the source file version was often
not terribly useful. Generally, when triaging bugs, the overall version
of Asterisk is far more useful than an individual SVN version of a file. As a
result, this patch removes Asterisk's support for showing source file
versions.
Specifically, it does the following:
* Rename ASTERISK_FILE_VERSION macro to ASTERISK_REGISTER_FILE, and
remove passing the version in with the macro. Other facilities
than 'core show file version' make use of the file names, such as
setting a debug level only on a specific file. As such, the act of
registering source files with the Asterisk core still has use. The
macro rename now reflects the new macro purpose.
* main/asterisk:
- Refactor the file_version structure to reflect that it no longer
tracks a version field.
- Remove the "core show file version" CLI command. Without the file
version, it is no longer useful.
- Remove the ast_file_version_find function. The file version is no
longer tracked.
- Rename ast_register_file_version/ast_unregister_file_version to
ast_register_file/ast_unregister_file, respectively.
* main/manager: Remove value from the Version key of the ModuleCheck
Action. The actual key itself has not been removed, as doing so would
absolutely constitute a backwards incompatible change. However, since
the file version is no longer tracked, there is no need to attempt to
include it in the Version key.
* UPGRADE: Add notes for:
- Modification to the ModuleCheck AMI Action
- Removal of the "core show file version" CLI command
Change-Id: I6cf0ff280e1668bf4957dc21f32a5ff43444a40e
This patch adds support for automatically detecting the type of DTMF that a
PJSIP endpoint supports. When the 'dtmf_mode' endpoint option is set to 'auto',
the channel created for an endpoint will attempt to determine if RFC 4733
DTMF is supported. If so, it will use that DTMF type. If not, the DTMF type
for the channel will be set to inband.
Review: https://reviewboard.asterisk.org/r/4438
ASTERISK-24706 #close
Reported by: yaron nahum
patches:
yaron_patch_3_Feb.diff submitted by yaron nahum (License 6676)
........
Merged revisions 434637 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434638 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When setting the configuration option 'timers' equal to 'no' the bit flag was
not properly negated. This patch clears all associated flags and only sets the
specified one. pjsip will handle any necessary flag combinations. Also went
ahead and did similar for the '100rel' option.
ASTERISK-24910 #close
Reported by: Ray Crumrine
Review: https://reviewboard.asterisk.org/r/4582/
........
Merged revisions 434131 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434132 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes clange compiler warnings for initializer overrides.
Specifically:
res_pjsip/config_transport maps PJSIP_TLSV1_METHOD to the same enumeration
value as PJSIP_SSL_DEFAULT_METHOD. When initializing an array containing
those enum values, we therefore initialize the value twice to two different
values, "tlsv1" and "default". This patch changes it to just initialize
the index in the array to "tlsv1".
Review: https://reviewboard.asterisk.org/r/4539/
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4539.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433682 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433685 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk had an issue where retransmissions of MESSAGE requests resulted in
Asterisk processing the retransmission as if it were a new MESSAGE request.
This patch fixes the issue by creating a transaction in PJSIP on the incoming
request. This way, if a retransmission arrives, the PJSIP transaction layer
will resend the response and Asterisk will not ever see the retransmission.
ASTERISK-24920 #close
Reported by Mark Michelson
Review: https://reviewboard.asterisk.org/r/4532/
........
Merged revisions 433619 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433620 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Incoming PJSIP call legs that have not been answered yet send unnecessary
"180 Ringing" or "183 Progress" messages every time a connected line
update happens. If the outgoing channel is also PJSIP then the incoming
channel will always send a "180 Ringing" or "183 Progress" message when
the outgoing channel sends the INVITE.
Consequences of these unnecessary messages:
* The caller can start hearing ringback before the far end even gets the
call.
* Many phones tend to grab the first connected line information and refuse
to update the display if it changes. The first information is not likely
to be correct if the call goes to an endpoint not under the control of the
first Asterisk box.
When connected line first went into Asterisk in v1.8, chan_sip received an
undocumented option "rpid_immediate" that defaults to disabled. When
enabled, the option immediately passes connected line update information
to the caller in "180 Ringing" or "183 Progress" messages as described
above.
* Added "rpid_immediate" option to prevent unnecessary "180 Ringing" or
"183 Progress" messages. The default is "no" to disable sending the
unnecessary messages.
ASTERISK-24781 #close
Reported by: Richard Mudgett
Review: https://reviewboard.asterisk.org/r/4473/
........
Merged revisions 433338 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433339 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Valgrind found some memory leaks associated with
ast_pjsip_rdata_get_endpoint(). The leaks would manifest when sending
responses to OPTIONS requests, processing MESSAGE requests, and
res_pjsip supplements implementing the incoming_request callback.
* Fix ast_pjsip_rdata_get_endpoint() endpoint ref leaks in
res/res_pjsip.c:supplement_on_rx_request(),
res/res_pjsip/pjsip_options.c:send_options_response(),
res/res_pjsip_messaging.c:rx_data_to_ast_msg(), and
res/res_pjsip_messaging.c:send_response().
* Eliminated RAII_VAR() use with ast_pjsip_rdata_get_endpoint() in
res/res_pjsip_nat.c:nat_on_rx_message().
* Fixed inconsistent but benign return value in
res/res_pjsip/pjsip_options.c:options_on_rx_request().
Review: https://reviewboard.asterisk.org/r/4511/
........
Merged revisions 433222 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433223 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes previously reverted code that caused binary incompatibility
problems with some modules. And like the original patch it makes sure that
no matter what order the endpoint identifier modules were loaded, priority is
given based on the ones specified in the new global 'endpoint_identifier_order'
option.
ASTERISK-24840
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4489/
........
Merged revisions 433028 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433029 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a type=global section is not defined in pjsip.conf the global
defaults are not applied. As a result the mandatory Max-Forwards header
is not added to SIP messages for res_pjsip/chan_pjsip.
The handling of pjsip.conf type=global objects has several problems:
1) If the global object is missing the defaults are not applied.
2) If the global object is missing the default_outbound_endpoint's default
value is not returned by ast_sip_global_default_outbound_endpoint().
3) Defines are needed so default values only need to be changed in one
place.
* Added a sorcery instance observer callback to check if there were any
type=global sections loaded. If there were more than one then issue an
error message. If there were none then apply the global defaults.
* Fixed ast_sip_global_default_outbound_endpoint() to return the
documented default when no type=global object is defined.
* Made defines for the global default values.
* Increased the default_useragent[] size because SVN version strings can
get lengthy and 128 characters may not be enough.
* Fixed an off-nominal code path ref leak in global_alloc() if the string
fields fail to initialize.
* Eliminated RAII_VAR in get_global_cfg() and
ast_sip_global_default_outbound_endpoint().
ASTERISK-24807 #close
Reported by: Anatoli
Review: https://reviewboard.asterisk.org/r/4467/
........
Merged revisions 432766 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
It's possible to have a scenario that will create a conflict between endpoint
identifiers. For instance an incoming call could be identified by two different
endpoint identifiers and the one chosen depended upon which identifier module
loaded first. This of course causes problems when, for example, the incoming
call is expected to be identified by username, but instead is identified by ip.
This patch adds a new 'global' option to res_pjsip called
'endpoint_identifier_order'. It is a comma separated list of endpoint
identifier names that specifies the order by which identifiers are processed
and checked.
ASTERISK-24840 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4455/
........
Merged revisions 432638 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432639 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There have been a couple of times where a crash occurred in the dtls_handler
section of the code for res_pjsip. Unfortunately, in working this issue the
problem was unable to be reproduced. After looking at the backtraces and
through the code the current best guess as to why this happened might be due
to a reentrance problem and the strtok function. So, the current fix is to
convert the strtok function into the reentrant version of the function,
strtok_r.
ASTERISK-24741 #close
Reported by: Zane Conkle
Review: https://reviewboard.asterisk.org/r/4409/
........
Merged revisions 431698 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431699 65c4cc65-6c06-0410-ace0-fbb531ad65f3
There are three CLI commands to stop and restart Asterisk each.
1) core stop/restart now - Hangup all calls and stop or restart Asterisk.
New channels are prevented while the shutdown request is pending.
2) core stop/restart gracefully - Stop or restart Asterisk when there are
no calls remaining in the system. New channels are prevented while the
shutdown request is pending.
3) core stop/restart when convenient - Stop or restart Asterisk when there
are no calls in the system. New calls are not prevented while the
shutdown request is pending.
ARI has made stopping/restarting Asterisk more problematic. While a
shutdown request is pending it is desirable to continue to process ARI
HTTP requests for current calls. To handle the current calls while a
shutdown request is pending, a new committed to shutdown phase is needed
so ARI applications can deal with the calls until the system is fully
committed to shutdown.
* Added a new shutdown committed phase so ARI applications can deal with
calls until the final committed to shutdown phase is reached.
* Made refuse new HTTP requests when the system has reached the final
system shutdown phase. Starting anything while the system is actively
releasing resources and unloading modules is not a good thing.
* Split the bridging framework shutdown to not cleanup the global bridging
containers when shutting down in a hurry. This is similar to how other
modules prevent crashes on rapid system shutdown.
* Moved ast_begin_shutdown(), ast_cancel_shutdown(), and
ast_shutting_down(). You should not have to include channel.h just to
access these system functions.
ASTERISK-24752 #close
Reported by: Matthew Jordan
Review: https://reviewboard.asterisk.org/r/4399/
........
Merged revisions 431692 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431694 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the original patch causing memory corruptions it was removed until the
problem could be resolved. This patch is the original patch plus some added
locking around stasis router subcription that was needed to avoid the memory
corruption.
Description of the original problem and patch (still applicable):
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4363/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 431179 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The res_pjsip module was previously unloadable. With this patch it can now
be unloaded.
This patch is based off the original patch on the issue (listed below) by Corey
Farrell with a few modifications. Namely, removed a few changes not required to
make the module unloadable and also fixed a bug that would cause asterisk to
crash on unloading.
This patch is the first step (should hopefully be followed by another/others at
some point) in allowing res_pjsip and the modules that depend on it to be
unloadable. At this time, res_pjsip and some of the modules that depend on
res_pjsip cannot be unloaded without causing problems of some sort.
The goal of this patch is to get res_pjsip and only res_pjsip to be able to
unload successfully and/or shutdown without incident (crashes, leaks, etc...).
Other dependent modules may still cause problems on unload.
Basically made sure, with the patch applied, that res_pjsip (with no other
dependent modules loaded) could be succesfully unloaded and Asterisk could
shutdown without any leaks or crashes that pertained directly to res_pjsip.
ASTERISK-24485 #close
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4311/
patches:
pjsip_unload-broken-r1.patch submitted by Corey Farrell (license 5909)
........
Merged revisions 430628 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430629 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Made the following AMI actions use list API calls for consistency:
Agents
BridgeInfo
BridgeList
BridgeTechnologyList
ConfbridgeLIst
ConfbridgeLIstRooms
CoreShowChannels
DAHDIShowChannels
DBGet
DeviceStateList
ExtensionStateList
FAXSessions
Hangup
IAXpeerlist
IAXpeers
IAXregistry
MeetmeList
MeetmeListRooms
MWIGet
ParkedCalls
Parkinglots
PJSIPShowEndpoint
PJSIPShowEndpoints
PJSIPShowRegistrationsInbound
PJSIPShowRegistrationsOutbound
PJSIPShowResourceLists
PJSIPShowSubscriptionsInbound
PJSIPShowSubscriptionsOutbound
PresenceStateList
PRIShowSpans
QueueStatus
QueueSummary
ShowDialPlan
SIPpeers
SIPpeerstatus
SIPshowregistry
SKINNYdevices
SKINNYlines
Status
VoicemailUsersList
* Incremented the AMI version to 2.7.0.
* Changed astman_send_listack() to not use the listflag parameter and
always set the value to "Start" so the start capitalization is consistent.
i.e., The FAXSessions used "Start" while the rest of the system used
"start". The corresponding complete event always used "Complete".
* Fixed ami_show_resource_lists() "PJSIPShowResourceLists" to output the
AMI ActionID for all of its list events.
* Fixed off-nominal AMI protocol error in manager_bridge_info(),
manager_parking_status_single_lot(), and
manager_parking_status_all_lots(). Use of astman_send_error() after
responding to the original AMI action request violates the action response
pattern by sending two responses.
* Fixed minor protocol error in action_getconfig() when no requested
categories are found. Each line needs to be formatted as "Header: text".
* Fixed off-nominal memory leak in manager_build_parked_call_string().
* Eliminated unnecessary use of RAII_VAR() in ami_subscription_detail().
ASTERISK-24049 #close
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/4315/
........
Merged revisions 430434 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change enforces the requirements in PJSIP for session timer configuration. The minimum
expiration period must be 90 seconds or higher and the normal expiration period can not
be lower than the minimum expiration period. If either of these were done the code would
assert at session setup time.
ASTERISK-24336 #close
Reported by: Leon Rowland
........
Merged revisions 427978 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427979 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427980 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When handling incoming messages we determine if it is associated with
a dialog. If so we use that to determine what serializer and endpoint
to use for the message. Previously this would pass the endpoint to the
endpoint lookup module to actually place the endpoint completely on the
message. For in-dialog responses, however, this did not occur as
dialog processing took over and the endpoint lookup did not occur.
This change just places the endpoint in the expected spot immediately
instead of relying on the endpoint lookup module. In-dialog responses
thus have the expected endpoint.
AST-1459 #close
Review: https://reviewboard.asterisk.org/r/4146/
........
Merged revisions 427490 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427491 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427492 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testing has shown repeatedly that PJSIP's default behavior of switching
automatically to TCP for large messages can cause issues. The most common
issues are that devices that we are communicating with do not handle the
switch to TCP gracefully, thus causing situations such as broken calls or
broken subscriptions. Now, in order to have this behavior happen, you must
opt into it. The sample file has been updated to warn that enabling the
TCP switch behavior may cause issues for you, so use at your own risk.
........
Merged revisions 427334 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427335 65c4cc65-6c06-0410-ace0-fbb531ad65f3
