Prior too this patch, the P-Asserted-Identity header would include anonymous
caller id information which seems to go against the point of the
P-Asserted-Identity header. Now the real caller ID information will be
included in this header. Also, no privacy header would be included.
This patch adds 'Privacy: id' to outgoing SIP messages that include the
P-Asserted-Identity header.
(closes issue AST-1301)
........
Merged revisions 411189 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411190 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@411193 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If update_provisional_keepalive() is called while
send_provisional_keepalive_full() is waiting on the PVT lock, then
pvt->provisional_keepalive_sched_id will be changed to a new sched_id
value by update_provisional_keepalive(), but that new sched_id then may
be overwritten with -1 by send_provisional_keepalive_full(), killing
the pvt's reference to a schedule and "leaking" the reference.
(closes issue ASTERISK-22079)
Review: https://reviewboard.asterisk.org/r/3368/
Reported by: Jamuel Starkey, Matteo, Leif Madsen, Steve Davies
Patches:
provisional_keepalive_fix.diff uploaded by Steve Davies (license 5012)
........
Merged revisions 411088 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411089 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@411091 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/branches/12@410329 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Much needed was a way to assign id to objects on creation, and
much change was necessary to accomplish it. Channel uniqueids
and linkedids are split into separate string and creation time
components without breaking linkedid propgation. This allowed
the uniqueid to be specified by the user interface - and those
values are now carried through to channel creation, adding the
assignedids value to every function in the chain including the
channel drivers. For local channels, the second channel can be
specified or left to default to a ;2 suffix of first. In ARI,
bridge, playback, and snoop objects can also be created with a
specified uniqueid.
Along the way, the args order to allocating channels was fixed
in chan_mgcp and chan_gtalk, and linkedid is no longer lost as
masquerade occurs.
(closes issue ASTERISK-23120)
Review: https://reviewboard.asterisk.org/r/3191/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410157 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a static realtime peer with qualify=yes is loaded, Asterisk will fail to
send an OPTIONS request due to the lastms being equal to 0. This results in
the peer being unable to receive calls from Asterisk because the status is
permanently UNKNOWN.
This patch allows an OPTIONS request to be sent during module load by
ignoring the lastms value on startup only.
Review: https://reviewboard.asterisk.org/r/3294/
(closes issue ASTERISK-17523)
Reported by: Maciej Krajewski
Tested by: wushumasters
patches:
realtime_fix_11.7.0.txt uploaded by Trevor Peirce (license 6112)
........
Merged revisions 410105 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 410106 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@410107 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch moves setting SIP_DEFER_BY_ON_TRANSFER prior to calling
ast_bridge_transfer_blind. This prevents a BYE from being sent prior to the
NOTIFY request that informs the transferor if the transfer succeeded or failed.
This patch also clears said flag from the off nominal NOTIFY paths in the
local_attended_transfer code, as once we've sent the NOTIFY request it is safe
to send by the BYE request.
This was caught by the blind-transfer-accountcode test in the Asterisk Test
Suite.
(closes issue ASTERISK-23290)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3214/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@408069 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Fixes typos of "transfered" instead of "transferred" in various code. Fixes incorrect gosub param help text for app_queue.
Fixes Asterisk man pages containing unquoted minus signs. Adds note about the "textsupport" option in sip.conf.sample.
(issue ASTERISK-23061)
(issue ASTERISK-23028)
(issue ASTERISK-23046)
(issue ASTERISK-23027)
(closes issue ASTERISK-23061)
(closes issue ASTERISK-23028)
(closes issue ASTERISK-23046)
(closes issue ASTERISK-23027)
Reported by: Eugene, Jeremy Laine, Denis Pantsyrev
Patches:
transferred.patch uploaded by Jeremy Laine (license 6561)
hyphen.patch uploaded by Jeremy Laine (license 6561)
sip.conf.sample.patch uploaded by Eugene (license 6360)
........
Merged revisions 405791 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 405792 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@405829 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In ASTERISK-12117, an improvement to insure consistant local from tags
on outbound registrations resulted in an undesirable behavior - caused
by leftover unexpired sip_pvt dialogs (with the previous cseq number),
resulting in many uncessary REGISTER requests. Instead of significant
rework of transmit_register(), this change deletes the dialogs after a
200 OK response indiciating a successful registration, keeping the old
dialogs from interfering with normal operation.
(closes issue ASTERISK-22946)
Reported by: Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/3109/
........
Merged revisions 405433 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 405434 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@405435 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change is in preparation for external MWI support.
Removed code from the system for normal mailbox handling that appends
@default to the mailbox identifier if it does not have a context. The
only exception is the legacy hasvoicemail users.conf option. The legacy
option will only work for app_voicemail mailboxes. The system cannot make
any assumptions about the format of the mailbox identifer used by
app_voicemail.
chan_sip and chan_dahdi/sig_pri had the most changes because they both
tried to interpret the mailbox identifier. chan_sip just stored and
compared the two components. chan_dahdi actually used the box
information.
The ISDN MWI support configuration options had to be reworked because
chan_dahdi was parsing the box@context format to get the box number. As a
result the mwi_vm_boxes chan_dahdi.conf option was added and is documented
in the chan_dahdi.conf.sample file.
Review: https://reviewboard.asterisk.org/r/3072/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@404348 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The change contains a slightly adjusted patch that was on the issue
(submitted by kmoore). A fix was made by adding in a bridge lock
while calling bridge_start/stop from the framehook callback. Since
the framehook callback is not called from the bridging core the bridge
is not locked, but needs to be before calling bridge_start.
(closes issue ASTERISK-22749)
Reported by: Kinsey Moore
Review: https://reviewboard.asterisk.org/r/3066/
Patches:
lock_inversion.diff uploaded by kmoore (license 6273)
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@403767 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds channel locks around calls to create channel snapshots as well
as other functions which operate on a channel and then end up
creating a channel snapshot. Functions that expect the channel to be
locked prior to being called have had their documentation updated to
indicate such.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@403311 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For outbound register requests the tag on the From line was
updated every 20 seconds prior to a successful registration
and also once for each registration renewal. That behavior
can possibly cause the registration to be denied because of
the different tag, and is not aligned with the intention of
RFC 3261 8.1.3.5 "... request constitutes a new transaction
and SHOULD have the same value of the Call-ID, To, and From
of the previous request...". This updates chan_sip to have
a field to keep the local tag in the registration structure
and use that tag for registration requests where the callid
is also unchanged.
(closes issue ASTERISK-12117)
Reported by: Pawel Pierscionek
Review: https://reviewboard.asterisk.org/r/2988/
........
Merged revisions 402604 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 402605 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@402606 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While the structure passed to ast_get_ip should be set memset to 0, thus
initializing the ss_family member to 0, explicitly setting it to AST_AF_UNSPEC
is more portable.
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@402507 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/branches/12@402452 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking at ASTERISK-22236, Walter Doekes pointed out that when running
"sip show peers", the setting being displayed can be confusing. The display of
"N" used to mean NAT (i.e. yes). The NAT setting has gone through many
different changes resulting in the display of different characters to try and
convey what the current setting is for 'Forcerport' (A for Auto and Forcerport
is currently on, a for Auto but Forcerport is off, Y for yes, and N for no).
During the initial code review to try and clarify these settings (especially
since "N" no longer meant what it used to mean in prior versions of Asterisk),
Mark Michelson suggested using the full space available to display the settings
which helped to make the settings very clear. That was a great suggestion.
Therefore, this patch does the following:
* The column for 'Forcerport' now will show: Auto (Yes), Auto (No), Yes, or No.
* A column for the 'Comedia' setting has been added. It too will display the
setting in a non-cryptic way: Auto (Yes), Auto (No), Yes, or No.
* UPGRADE.txt has been updated to document this change.
(closes issue ASTERISK-22728)
Reported by: Walter Doekes
Tested by: Michael L. Young
Patches:
asterisk-forcerport-display-clarification_v3.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2941
........
Merged revisions 402111 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@402112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Adapts the behaviour of avpf to only impact the format of outgoing calls. For
inbound calls, both AVP and AVPF calls will be accepted regardless of the value
of avpf in the configuration.
(closes issue ASTERISK-22005)
Reported by: Torrey Searle
Patches:
optional_avpf_trunk.patch uploaded by tsearle (license 5334)
........
Merged revisions 401884 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@401885 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When trying to determine if a peer is behind NAT, we should not be using the
ports when comparing addresses.
This patch removes the port from being checked and just useds the addresses
now.
(closes issue ASTERISK-22729)
Reported by: Michael L. Young
Tested by: Michael L. Young
Patches:
asterisk-remove-using-port-for-nat-check.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2927/
........
Merged revisions 401182 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@401183 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A condition was added in a commit to fix ASTERISK-21374, that, if the
SIP_PAGE3_NAT_AUTO_RPORT flag was set, to then copy a peer's SIP_NAT_FORCE_RPORT
flag to the dialog. This condition should not have been there since it assumed
that if Asterisk is in an environment where NAT is involved, that the auto_* nat
settings or force_rport setting would be on in the global settings. If the nat
setting in the global setting is set to 'nat=no' and then turned on for peers
(which is not quite the recommended way, although it is allowed) this flag is
never copied to the dialog resulting in problems like, REGISTER replies going
to the wrong port.
This patch removes this conditional check and will now always use the peer's
flag which by this point in the code the checks on whether the peer is behind
NAT or not (if using auto_force_rport) have already been run.
(closes issue ASTERISK-22236)
Reported by: Filip Frank
Tested by: Michael L. Young
Patches:
asterisk-2236-always-set-rport.diff uploaded
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2919/
........
Merged revisions 401167 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@401168 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a 200 OK for an initial INVITE is received, we were doing
the right thing by ACKing and sending an immediate BYE. However,
we also were doing the wrong thing and queuing an answer frame,
thus causing the call to be answered. This would cause the call
to be hung up by the channel thread, thus resulting in a second
BYE being sent out.
In this fix, I also have set the hangupcause to be correct since
the initial BYE being sent by Asterisk had an unknown hangup
cause. I have changed to using "Bearer capabilty not available"
since the call was hung up due to an SDP offer/answer error.
(closes issue ASTERISK-22621)
reported by Kinsey Moore
........
Merged revisions 400970 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400971 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel snapshots have string representations of the channel's native formats.
Prior to this change, the format strings were re-created on ever channel snapshot
creation. Since channel native formats rarely change, this was very wasteful.
Now, string representations of formats may optionally be stored on the ast_format_cap
for cases where string representations may be requested frequently. When formats
are altered, the string cache is marked as invalid. When strings are requested, the
cache validity is checked. If the cache is valid, then the cached strings are copied.
If the cache is invalid, then the string cache is rebuilt and copied, and the cache
is marked as being valid again.
Review: https://reviewboard.asterisk.org/r/2879
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400356 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change introduces the ability to stage channel snapshot
creation and publishing by suppressing the implicit creation
and publishing that some functions have. Once all operations
are executed the staging is marked as done and a single snapshot
is created and published.
Review: https://reviewboard.asterisk.org/r/2889/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400265 65c4cc65-6c06-0410-ace0-fbb531ad65f3
While looking for areas for performance improvement, I realized that an
unused feature in Stasis was negatively impacting performance.
When a message is sent to a subscriber, a dispatch object is allocated
for the dispatch, containing the topic the message was published to, the
subscriber the message is being sent to, and the message itself.
The topic is actually unused by any subscriber in Asterisk today. And
the subscriber is associated with the taskprocessor the message is being
dispatched to.
First, this patch removes the unused topic parameter from Stasis
subscription callbacks.
Second, this patch introduces the concept of taskprocessor local data,
data that may be set on a taskprocessor and provided along with the data
pointer when a task is pushed using the ast_taskprocessor_push_local()
call. This allows the task to have both data specific to that
taskprocessor, in addition to data specific to that invocation.
With those two changes, the dispatch object can be removed completely,
and the message is simply refcounted and sent directly to the
taskprocessor.
Review: https://reviewboard.asterisk.org/r/2884/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400181 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds a global option in chan_sip to allow it to continue
attempting registration if a 403 is received, clearing the cached nonce
and treating it as a non-fatal response. Normally, this would cause
registration attempts to that endpoint to stop.
This also adds a similar per-outbound-registration option to chan_pjsip
which allows the retry interval to be altered for 403 responses to
REGISTER requests.
(closes issue ASTERISK-17138)
Review: https://reviewboard.asterisk.org/r/2874/
Reported by: Rudi
........
Merged revisions 400137 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 400140 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@400141 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk receives a 200 OK in response to an invite, that peer should have
sent an SDP at some point by then. If the channel has never received an SDP,
media won't have been set and the remote address won't be known. Endpoints in
general should not be doing this. This patch makes it so that Asterisk will
simply hang up a call if it sends a 200 OK at this point. So far this odd
behavior for endpoints has only been observed in tests which involved manually
created SIP transactions in SIPp.
(closes issue ASTERISK-22424)
Reported by: Jonathan Rose
Review: https://reviewboard.asterisk.org/r/2827/
........
Merged revisions 399939 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399962 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1st Issue
When a realtime peer sends an un-REGISTER request, Asterisk
un-registers the peer but the database table record still has regseconds and
fullcontact for the peer. This results in calls attempting to be routed to the
peer which is no longer registered. The expected behavior is to get
busy/congested when attempting to call an un-registered peer through the
dialplan.
What was discovered is that we are clearing out the peer's registration in the
database in parse_register_contact() when calling expire_register() but then
upon returning from parse_register_contact(), update_peer() is run which stores
back in the database table regseconds and fullcontact.
2nd Issue
The reporter pointed out that the 200 ok being returned by Asterisk
after un-registering a peer contains a Contact header with ;expires= and the
Expires header is not set to 0. This is actually a regression.
Tests were created for this second issue (ASTERISK-22548). The tests have been
reviewed and a Ship It! was received on those tests.
This patch does the following:
* Do not ignore the Expires header value even when it is set to 0. The patch
sets the pvt->expiry earlier on in the function so that it is set properly and
used.
* If pvt->expiry is 0, do not call update_peer since that means the peer has
already been un-registered and there is no need to update the database record
again since nothing has changed.
(closes issue ASTERISK-22428)
Reported by: Ben Smithurst
Tested by: Ben Smithurst, Michael L. Young
Patches:
asterisk-22428-rt-peer-update-and-expires-header.diff
by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/2869/
........
Merged revisions 399794 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 399795 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399796 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The Dial, Queue, and FollowMe applications need to inhibit the bridging
initial connected line exchange in order to support the 'I' option.
* Replaced the pass_reference flag on ast_bridge_join() with a flags
parameter to pass other flags defined by enum ast_bridge_join_flags.
* Replaced the independent flag on ast_bridge_impart() with a flags
parameter to pass other flags defined by enum ast_bridge_impart_flags.
* Since the Dial, Queue, and FollowMe applications are now the only
callers of ast_bridge_call() and ast_bridge_call_with_flags(), changed the
calling contract to require the initial COLP exchange to already have been
done by the caller.
* Made all callers of ast_bridge_impart() check the return value. It is
important. As a precaution, I also made the compiler complain now if it
is not checked.
* Did some cleanup in parking_tests.c as a result of checking the
ast_bridge_impart() return value.
An independent, but associated change is:
* Reduce stack usage in ast_indicate_data() and add a dropping redundant
connected line verbose message.
(closes issue ASTERISK-22072)
Reported by: Joshua Colp
Review: https://reviewboard.asterisk.org/r/2845/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@399136 65c4cc65-6c06-0410-ace0-fbb531ad65f3
With the new work in Asterisk 12, there are some uses of the
optional_api that are prone to failure. The details are rather involved,
and captured on [the wiki][1].
This patch addresses the issue by removing almost all of the magic from
the optional API implementation. Instead of relying on weak symbol
resolution, a new optional_api.c module was added to Asterisk core.
For modules providing an optional API, the pointer to the implementation
function is registered with the core. For modules that use an optional
API, a pointer to a stub function, along with a optional_ref function
pointer are registered with the core. The optional_ref function pointers
is set to the implementation function when it's provided, or the stub
function when it's now.
Since the implementation no longer relies on magic, it is now supported
on all platforms. In the spirit of choice, an OPTIONAL_API flag was
added, so we can disable the optional_api if needed (maybe it's buggy on
some bizarre platform I haven't tested on)
The AST_OPTIONAL_API*() macros themselves remained unchanged, so
existing code could remain unchanged. But to help with debugging the
optional_api, the patch limits the #include of optional API's to just
the modules using the API. This also reduces resource waste maintaining
optional_ref pointers that aren't used.
Other changes made as a part of this patch:
* The stubs for http_websocket that wrap system calls set errno to
ENOSYS.
* res_http_websocket now properly increments module use count.
* In loader.c, the while() wrappers around dlclose() were removed. The
while(!dlclose()) is actually an anti-pattern, which can lead to
infinite loops if the module you're attempting to unload exports a
symbol that was directly linked to.
* The special handling of nonoptreq on systems without weak symbol
support was removed, since we no longer rely on weak symbols for
optional_api.
[1]: https://wiki.asterisk.org/wiki/x/wACUAQ
(closes issue ASTERISK-22296)
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/2797/
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397989 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
........
Merged revisions 397758 from http://svn.asterisk.org/svn/asterisk/branches/11
git-svn-id: https://origsvn.digium.com/svn/asterisk/branches/12@397759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
