The sending codec is switched to the receiving codec and then
is switched back to the best native codec on EVERY receiving RTP packets.
This is because after call of ast_channel_set_rawwriteformat there is call
of ast_set_write_format which calls set_format which sets rawwriteformat
to the best native format.
This patch adds a new function ast_set_write_format_path which set
specific write path on channel and uses this function to switch
the sending codec.
ASTERISK-26603 #close
Change-Id: I5b7d098f8b254ce8f45546e6c36e5d324737f71d
Per RFC 7118 5.2, the SIP URI 'transport' parameter should advertise
'ws' when WebSockets are to be used as the transport. This applies to
both secure and insecure WebSockets.
There were two bugs in Asterisk with respect to this:
(1) The most egregious occurs in res_pjsip. There, we advertise 'ws' for
insecure websockets and 'wss' for secure websockets. While this
would seem to make sense - since 'WS' and 'WSS' are used for the Via
Transport parameter - this is not the case for the SIP URI. This
patch corrects that by registering the secure websockets with
pjproject using the shorthand 'WS', and by returning 'ws' when asked
for the transport parameter. Note that in pjproject, it is perfectly
valid to have multiple transports use the same shorthand.
(2) In chan_sip, we return an upper-case version of the transport 'WS'
instead of 'ws'. Since we should be strict in what we send and
liberal in what we accept (within reason), this patch lower-cases
the transport before appending it to the parameter.
ASTERISK-24330 #close
Reported by: cervajs, Inaki Baz Castillo
Change-Id: Iff77b645f8cc3b7cd35168a6676c26b147f22f42
If a TCP/TLS connection was pending (not accepted and not timed out) during
unload of chan_sip, Asterisk would segfault when trying to send a signal to
a thread whose thread ID hadn't been recorded yet. This commit fixes that by
recording the thread ID before calling the blocking connect() syscall.
This was a regression introduced by 776a14386a.
The above wasn't enough to fix the segfault, which was now delayed to the
point where connect() timed out. Therefore, it was necessary to also remove
the SA_RESTART flag from the SIGURG sigaction so that pthread_kill() could be
used to interruput the connect() syscall.
This was a regression introduced by 5d313f51b9.
ASTERISK-26586 #close
Change-Id: I76fd9d47d56e4264e2629bce8ec15fecba673e7b
fopencookie/funclose is a non-standard API and should not be used
in portable software. Additionally, the way FILE's fd is used in
non-blocking mode is undefined behaviour and cannot be relied on.
This introduces internal abstraction for io streams, that allows
implementing the desired virtualization of read/write operations
with necessary timeout handling.
ASTERISK-24515 #close
ASTERISK-24517 #close
Change-Id: Id916aef418b665ced6a7489aef74908b6e376e85
Fix ASTERISK-26565 by adding ast_rtp_instance_stop before
rtp instance destroy for chan_unistim. Also several fixes
for displayed text translation.
Change-Id: If42a03eea09bd1633471406bdc829cf98bf6affc
Correct typo of end-pints to end-points
Re-wrap session timer parameter docs to max 80 chars wide; this
eases reading on terminals with lower resolution, commonly the case
for those with visual impairments.
ASTERISK-26573
Change-Id: I22c94459f4bb6b8a2f6713cfd22e87c32f204e6b
Signed-off-by: C.J. Collier <cjcollier@linuxfoundation.org>
This reverts commit 93332cb1d0.
Unfortunately, the aforementioned commit caused a regression (incoming calls
would eventually disconnect). Thus it is being removed.
ASTERISK-26523 #close
ASTERISK-25270
Change-Id: Ibf5586adc303073a8eac667a4cbfdb6be184a64d
If in sip.conf (general section) set option register_retry_403=no,
the command "sip show settings" return value:
Outbound reg. retry 403:0
If in sip.conf (general section) set option register_retry_403=yes,
the command "sip show settings" return value:
Outbound reg. retry 403:-1
* In static char "sip show settings" for "Outbound.reg. retry 403"
option use AST_CLI_YESNO
ASTERISK-26476 #close
Change-Id: I3c14272f05f1067bd2aeaa8b3ef9cf8fcb12dcf9
Support for referring to DAHDI channels by logical names was added in
(FIXME: when? Asterisk 11? 1.8?) and was intended to be part of support
of refering to channels by name.
While technically usable, it has never been properly supported in
dahdi-tools, as using it would require many changes at the Asterisk
level. Instead logical mapping was added at the kernel level.
Thus it seems that refering to DAHDI channels by name is not really used
by anyone, and therefore should probably be removed.
Change-Id: I7d50bbfd9d957586f5cd06570244ef87bd54b485
ASTERISK_REGISTER_FILE no longer has any purpose so this commit removes
all traces of it.
Previously exported symbols removed:
* __ast_register_file
* __ast_unregister_file
* ast_complete_source_filename
This also removes the mtx_prof static variable that was declared when
MTX_PROFILE was enabled. This variable was only used in lock.c so it
is now initialized in that file only.
ASTERISK-26480 #close
Change-Id: I1074af07d71f9e159c48ef36631aa432c86f9966
When channel format changes occurred as a result of an RTP
re-negotiation the bridge was not informed this had happened.
As a result the bridge technology was not re-evaluated and the
channel may have been in a bridge technology that was incompatible
with its formats. The bridge is now unbridged and the technology
re-evaluated when this occurs.
The chan_pjsip module also allowed asymmetric codecs for sending
and receiving. This did not work with all devices and caused one
way audio problems. The default has been changed to NOT do this
but to match the sending codec to the receiving codec. For users
who want asymmetric codecs an option has been added, asymmetric_rtp_codec,
which will return chan_pjsip to the previous behavior.
The codecs returned by the chan_pjsip module when queried by
the bridge_native_rtp module were also not reflective of the
actual negotiated codecs. The nativeformats are now returned as
they reflect the actual negotiated codecs.
ASTERISK-26423 #close
Change-Id: I6ec88c6e3912f52c334f1a26983ccb8f267020dc
On heavy loaded system the TCP/TLS incoming calls could be
disconnected by pjproject while these calls are being
processed by asterisk.
This patch uses functions pjsip_inv_add_ref/pjsip_inv_dec_ref
to inform pjproject that an INVITE session is in use.
ASTERISK-26482 #close
Change-Id: Ia2e3e2f75358cdb530252a9ce158af3d5d9fdf33
Previously, the settings videosupport=always and videosupport=yes behaved
identically and unconditionally caused a video offer to be sent in the SDP on
an outgoing call. This was a regression introduced with commit
5a1d90e1fb in Asterisk 1.6.1.
This commit restores correct behavior: videosupport=always causes a video offer
to be sent unconditionally, while videosupport=yes will only offer video on an
outbound channel if the incoming channel it is bridged to also supports video.
That way, the device receiving the outgoing call can display the correct user
interface elements for audio or video and will not unnecessarily show a blank
video window on an audio-only call.
ASTERISK-17470 #close
Change-Id: I782f4409d436114dbc97061c3570c0cd24f7c3ae
In the SIP channel driver chan_sip, auto_comedia was expected to be used in
tandem with auto_force_rport. Or stated differently: Only when auto_force_rport
was chosen (the default), auto_comedia worked. This change allows auto_comedia
to be set independently of the state of (auto_)force_rport. For example,
nat=force_rport,auto_comedia is useful for IPv4/IPv6 Dual Stack deployments
when IPv6 clients are behind a Firewall.
ASTERISK-26457 #close
Change-Id: Ib29d66c6dbb61648e371e01fc36c6978ddae5bc2
In the SIP channel driver chan_sip, the default is "auto_force_rport". When no
NAT was detected, for example in case of IPv6, Asterisk uses the IP address
from the headers within the SIP-REGISTER for subsequent SIP signaling. When
the remote party specifies support for Symmetric Response (RFC 3581) via the
parameter "rport", Asterisk should not extract the port from the SIP headers
but reuse the port of the transport. This did not happen because of a typo.
ASTERISK-26438 #close
Change-Id: If6e7891848aaf96666dee5305695f7c6667cd5a6
For the channel driver chan_sip, you specify externhost=example.com in sip.conf
when your Asterisk is behind a NAT and your IP address is assigned dynamically.
Or stated differently: You do not have a static IP address to use "externaddr"
directly. This NAT support is quite handy but just about IPv4. Previously,
Asterisk resolved "externhost" to any IP version. When the first DNS answer
resolved to an IPv6, Asterisk sent an IPv6 in SIP/SDP for origin (o=) and
connection (c=). This happened in outgoing SIP-REGISTER and while answering
SIP-INVITE. If the remote peer is IPv4-only, it might not handle o=/c= with an
IPv6. This change makes sure, no IPv6 is resolved anymore for "externhost".
ASTERISK-18232 #close
Reported by: Jacek Kowalski
Tested by: Alexander Traud
patches:
changes.patch submitted by Alessandro Crespi
Change-Id: If68eedbeff65bd1c1d8a9ed921c02ba464b32dac
Users upgrading from asterisk 13.5 to a later version and who use
realtime with peers that have mailboxes were experiencing runaway
situations that manifested as a continuous stream of taskprocessor
congestion errors, memory leaks and an unresponsive chan_sip.
A related issue was that setting rtcachefriends=no NEVER worked in
asterisk 13 (since the move to stasis). In 13.5 and earlier, when a
peer tried to register, all of the stasis threads would block and
chan_sip would again become unresponsive. After 13.5, the runaway
would happen.
There were a number of causes...
* mwi_event_cb was (indirectly) calling build_peer even though calls to
mwi_event_cb are often caused by build_peer.
* In an effort to prevent chan_sip from being unloaded while messages
were still in flight, destroy_mailboxes was calling
stasis_unsubscribe_and_join but in some cases waited forever for the
final message.
* add_peer_mailboxes wasn't properly marking the existing mailboxes
on a peer as "keep" so build_peer would always delete them all.
* add_peer_mwi_subs was unsubscribing existing mailbox subscriptions
then just creating them again.
All of this was causing a flood of subscribes and unsubscribes on
multiple threads all for the same peer and mailbox.
Fixes...
* add_peer_mailboxes now marks mailboxes correctly and build_peer only
deletes the ones that really are no longer needed by the peer.
* add_peer_mwi_subs now only adds subscriptions marked as "new" instead
of unsubscribing and resubscribing everything. It also adds the peer
object's address to the mailbox instead of its name to the subscription
userdata so mwi_event_cb doesn't have to call build_peer.
With these changes, with rtcachefriends=yes (the most common setting),
there are no leaks, locks, loops or crashes at shutdown.
rtcachefriends=no still causes leaks but at least it doesn't lock, loop
or crash. Since making rtcachefriends=no work wasnt in scope for this
issue, further work will have to be deferred to a separate patch.
Side fixes...
* The ast_lock_track structure had a member named "thread" which gdb
doesn't like since it conflicts with it's "thread" command. That
member was renamed to "thread_id".
ASTERISK-25468 #close
Change-Id: I07519ef7f092629e1e844f855abd279d6475cdd0
HANGUPCAUSE not return 'SIP 200 Ok' when dialed channel answered.
This patch change the call order of ast_queue_control_data
and ast_queue_control in chan_pjsip_incoming_response.
ASTERISK-26396 #close
Reported by: AaronAn
Tested by: AaronAn
Change-Id: Ide2d31723d8d425961e985de7de625694580be61
Change-Id I1cd33453c77c56c8e1394cd60a6f17bb61c1d957 Enable Session-Timers for
SIP over TCP (and TLS) also disables SIP retransmits in chan_sip for non-UDP
connections, allowing the TCP layer to handle the retransmits. Unfortunately,
this caused sessions to be terminated with a retransmit timeout becasue it
stopped at the point of the first retrans call.
This patch waits for the 64*T1 timer to expire instead.
ASTERISK-19968
Change-Id: I844f26801aada10bc94e9bebe6e151f0a8443204
Previously, the Contact was stored only on initial INVITE and on any
18X and 200. That meant that after re-INVITEs from *us* the Contact
could get updated, but after re-INVITEs from the *peer*, it did not.
This changeset fixes this inconsistency, properly allowing target
refreshes through re-INVITES (RFC3261, 12.2).
If your strictrtp setting allows it, this change allows you to switch
the source IP of a connected/calling device mid-call with a simple
re-INVITE from the new IP.
ASTERISK-26358 #close
Change-Id: Ibb8512054ab27c8c3d2514022568fde943bf2435
In some scenarios dialog_initialize_rtp can be called multiple times on
the same dialog. This can cause RTP instances to be leaked along with
multiple file descriptors for each instance.
This change makes it so the existing RTP instances are destroyed and
not overwritten, stopping the memory leak.
ASTERISK-26272 #close
patches:
ASTERISK-26272-13.patch submitted by Corey Farrell (license 5909)
Change-Id: Id529de1184c68f2f4d254ab41a1f458dafdb5f73
Following the Encrypt-all-the-things paradigm:
The user enters his SIP-URI and password. Thanks to DNS-NAPTR, the phone
determines SIP-over-TLS as preferred transport. In SIP/SDP, the phone starts
the call with a crypto attribute, but not as RTP/sAVP but the RTP/AVP profile
(sRTP is preferred aka optional; not mandatory). If the VoIP server does not
support sRTP and TLS, the phone shows an open padlock icon.
This paradigm is supported by several VoIP/SIP clients on default. Some
implementations even cannot be changed to RTP/sAVP. Therefore here, this
change allows Preferred sRTP for ingress. For egress, please, create a dial
plan which starts with RTP/SAVP, and when rejected tries again with RTP/AVP.
ASTERISK-20234 #close
Reported by: tootai
Tested by: tootai, Alexander Traud
patches:
srtp_patches.diff submitted by Matt Jordan
Change-Id: I42cb779df3a9c7b3dd03a629fb3a296aa4ceb0fd
Certain SNOM phones send so-called "optional crypto" in their SDP body.
Regular SRTP setup looks like this:
m=audio 64620 RTP/SAVP 8 0 9 99 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...
SNOM-style "optional crypto" looks like this:
m=audio 61438 RTP/AVP 8 0 9 99 3 18 4 101
a=crypto:1 AES_CM_128_HMAC_SHA1_32 inline:...
A crypto line is supplied, but the m-line does not have SAVP.
When res_srtp.so is *not* loaded, then chan_sip.so treats the optional
crypto as regular RTP, but when res_srtp.so *is* loaded, it refuses the
incoming call with the following message:
WARNING: process_sdp: Failed to receive SDP offer/answer with
required SRTP crypto attributes for audio
For platforms that want to start providing SRTP this presents a
compatibility problem.
This changeset lets chan_sip handle the SDP as if no crypto-line was
supplied: i.e. accept the call as regular RTP, just like it did before
res_srtp was loaded.
Now you'll get this informative warning instead:
WARNING: Ignoring crypto attribute in SDP because RTP transport is
insecure
ASTERISK-23989 #close
Reported by: Olle Johansson
Change-Id: I91a15ae05a0296e398d6b65f53bb11afde1d80e2
Starting from draft 2 of RFC 5456 (October 23, 2006) plaintext auth
is not supported in IAX2 protocol. Please refer to section 8.6.13 of
RFC 5456.
But plaintext auth is still supported by Asterisk implementation of IAX2.
This support should be dropped.
Patch, based on asterisk-dev discussion, adds deprecation warning on
startup if 'auth' is set to 'plaintext', changes default values of
'auth' from 'md5, plaintext' to 'md5'.
Patch is safe in terms of backwards compatibility, will work even if
remote peers have auth=plaintext and we have defaults.
auth=plaintext setting will remain deprecated in Asterisk 14 and 15,
and IAX2 plaintext support will be removed in Asterisk 16.
ASTERISK-22820 #close
Change-Id: I5d2f3830cb57645604818f87518916e8a5c317bf
Historically, Asterisk has always specified annexb=no for the g729 format.
However, when using res_pjsip no format attribute was specified. This patch
makes it so the SDP now contains a format attribute line with annexb=no.
Note, that this means only g729a is negotiated. Even for pass through support.
According to rfc7261 the type of annex used (a or b) is dependent upon the
answerer. However, Asterisk being a back to back user agent makes this tricky
to support at this time, thus we only allow annex 'a' for now.
ASTERISK-26228 #close
patches:
res_format_attr_g729.c submitted by Jason Parker (license 4993)
Change-Id: I76bc20cc0a01af01536e9915afef319c269c22d0
This updates func_channel.c and main/message.c to use a generic xpointer
include instead of including info from each channel driver. Now the
name attribute of info is CHANNEL or CHANNEL_EXAMPLES to be included in
documentation for func_channel. Setting the name attribute of info to
MessageToInfo or MessageFromInfo causes it to be included in the
MessageSend application and AMI action.
Change-Id: I89fd8276a3250824241a618009714267d3a8d1ea
Packets are read regulary, when there is no data in buffer fr->frametype
is AST_FRAME_NULL. There was no check of frametype and lastrtprx always
updated and, therefore, rtptimeout did not work at all.
ASTERISK-25270 #close
Change-Id: If3b5ca0dbb822582a86eb7d01dcae4e83448c41d
* Following the example of the PJSIP channel driver, the channel
technology specific documentation has been moved to the respective
channel drivers that provide that functionality. This has the benefit
of locating the documentation of items with those modules that provide
it.
* Examples of using the CHANNEL function for both standard items as well
as for PJSIP have been added.
* The 'max_forwards' standard item has been documented.
Change-Id: Ifaa79a232c8ac99cf8da6ef6cc7815d398b1b79b
This patch adds a new PJSIP specific dialplan function,
PJSIP_SEND_SESSION_REFRESH. When invoked on a PJSIP channel, the media
session will be refreshed via either an UPDATE or re-INVITE request.
When used in conjunction with the PJSIP_MEDIA_OFFER dialplan function,
the formats in use on a PJSIP channel can be re-negotiated and changed
dynamically after call setup.
ASTERISK-26277 #close
Change-Id: Ib98fe09ba889aafe26d58d32f0fd1323f8fd9b1b
(cherry picked from commit eec60dd773)
Asterisk defaults to timers=accept/refresher=uas. In that scenario, only in that
scenario, Sessions-Timers (RFC 4028) had no effect via TCP. This change enables
Session-Timers for SIP over TCP (and for SIP over TLS).
However with longer international calls via TCP, the SIP channel might break,
because all hops on the Internet route must stay online (have not a single power
outage, for example). Therefore with Session-Timers enabled (which are enabled
at default), you might see dropped calls. Consequently even with this change,
you might be better-off going for session-timers=refuse in your sip.conf.
ASTERISK-19968 #close
Change-Id: I1cd33453c77c56c8e1394cd60a6f17bb61c1d957
sip_show_channels locks the dialogs container first then locks each
sip_pvt so it can spit out the details. The rest of sip dialog
processing locks the sip_pvt first then locks the dialogs container
if it needs to. Both lock in the order they need but deadlocks can
result. To fix, sip_show_channels and sip_show_channelstats have
been converted to use an iterator rather than ao2_callback. This way
the container is locked only while getting the next entry and is
unlocked when the callback is called.
ASTERISK-23013 #close
Change-Id: Id9980419909e811f89484950ed46ef117b9eb990
The dahdi_handle_dtmf() and my_handle_dtmf() have the potential to
deadlock if an incoming fax happens during the Playback or similar
application.
* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.
ASTERISK-26216 #close
Reported by: Richard Mudgett
Change-Id: I9144b84ade5f96690996624ec8a2d40c56af40aa
The sip_read() has the potential to deadlock if an incoming fax happens
during the Playback or similar application.
* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.
* Made always eat the fax detection frame whether there is a fax extension
or not.
ASTERISK-26216
Reported by: Richard Mudgett
Change-Id: I6d3f5cccd4b77c3aa6ffc1a54c0f6bde61c9278e
The chan_pjsip_cng_tone_detected() has the potential to deadlock if an
incoming fax happens during the Playback or similar application.
* Fixed the potential deadlock by not calling ast_async_goto() with the
channel lock held.
* Made always eat the fax detection frame whether there is a fax extension
or not.
ASTERISK-26216
Reported by: Richard Mudgett
Change-Id: I32aecbb4818af646dc5a619f0dc040e9b1f222e5
The new option allows the channel driver's faxdetect option to timeout on
a call after the specified number of seconds into a call. The new feature
is disabled if the timeout is set to zero. The option is disabled by
default.
* Don't clear dsp_features after passing them to the dsp code in
my_pri_ss7_open_media(). We should still remember them especially for the
new faxdetect_timeout option.
ASTERISK-26214
Reported by: Richard Mudgett
Change-Id: Ieffd3fe788788d56282844774365546dce8ac810
The new endpoint option allows the PJSIP channel driver's fax_detect
endpoint option to timeout on a call after the specified number of
seconds into a call. The new feature is disabled if the timeout is set
to zero. The option is disabled by default.
ASTERISK-26214
Reported by: Richard Mudgett
Change-Id: Id5a87375fb2c4f9dc1d4b44c78ec8735ba65453d
If AST_TEST_DEFINE is not conditional to TEST_FRAMEWORK it produces dead
code. This places all existing unit tests into a conditional block if
they weren't already.
ASTERISK-26211 #close
Change-Id: I8ef83ee11cbc991b07b7a37ecb41433e8c734686
Cleanup the peer reference when stasis_subscription_final_message is
true. Also free peer_name even if peer exists, after reload a new
peer_name will be allocated.
ASTERISK-26193 #close
Change-Id: If7ecd52facdc5c227f701c760841e3f6ca53cc69
* get_sip_pvt_from_replaces leaks sip_pvt_ptr on any error.
* build_peer leaks peer on failure to allocate the endpoint.
This patch fixes get_sip_pvt by using an RAII_VAR, build_peer is fixed
with an unref in the appropriate place.
ASTERISK-26184 #close
Change-Id: I728b424648ad041409f7d90880f4c28b3ce2ca12
Some T.38 implementations may send another re-invite after the initial
one which adds additional negotiation details (such as the max bitrate).
Currently this will fail when passthrough is being done in chan_sip as we
do nothing if T.38 is already active.
Other handlers of T.38 inside of Asterisk (such as res_fax) handle this
scenario so this change adds support for it to chan_sip and res_pjsip_t38.
If a request to negotiate is received while T.38 is already enabled a
new re-INVITE is sent and negotiation is done again.
ASTERISK-26179 #close
Change-Id: I0298494d3da6df3219bbfa4be9aa04015043145c
pjsip_inv_end_session() is documented as being able to return the
passed in tdata parameter set to NULL on success.
Change-Id: I09d53725c49b7183c41bfa1be3ff225f3a8d3047
gcc 6.1.1 caught a few more issues.
Made sure the unit tests still pass for the func_env and stdtime
issues.
ASTERISK-26157 #close
Change-Id: I6664d8f34a45bc1481d2a854481c7878b0c1cf8e
This change removes hardcoded SDP parsing and generation for
Siren7 and Siren14 from chan_sip and moves it to format attribute
modules so it can also be used by chan_pjsip.
With this the fmtp lines for both are added with the bitrate
information.
ASTERISK-26021
Change-Id: Ibb004eda37a14c0a35ef0613f6237977fc800037
A code block only enabled when HAVE_PKTINFO is not defined (FreeBSD)
was using a pointer to a pointer as the destination of a memcpy and a
'&' instead of '*' in the sizeof.
ASTERISK-26138 #close
Change-Id: Id4927ff256c0e470bdf7bcfc025146a2f656e708
bridge_native_rtp can call into an RTP-capable channel driver in order
for the driver to update information about who the channel is
communicating with. For SIP channel drivers, this means deactivating
RTCP and sending a reinvite so that the endpoints can communicate
directly.
bridge_native_rtp does the right thing and has the channel locked when
calling into the channel driver. chan_pjsip can't alter session
properties in this thread, though. chan_pjsip queues a task on the
session serializer in order to update properties there.
The problem is that this queued task was not locking the channel. This
meant that the queued task could attempt to deactivate RTCP at the same
time that the channel thread was attempting to process an incoming RTCP
packet. This could lead to a crash.
This patch fixes the issue by locking the channel in the queued task
when altering RTP properties.
ASTERISK-26092 #close
Reported by Niklas Larsson
Change-Id: I3464e226a3c41f6b915f97891e07fa1599e2a159
A change to glibc 2.22 changed the order of the sockadddr_storage
members which caused the places where we do an initialization of
ast_sockaddr with '{ { 0, 0, } }' to fail compilation. Those
initializers (which we shouldn't have been using anyway) have been
replaced with memsets.
Change-Id: Idd1b3b320903d8771bfe221f0b015685de628fa4
POSIX defines signal.h. sys/signal.h should not be used as it is
c-library internal header which may or may not exist. Notably with
musl it generates warning of being incorrect.
Change-Id: Ia56b0aa1d84b5c590114867b1b384a624f39a6fc
This saves around 100 bytes when G.711, G.722, G.729, and GSM are advertised in
SDP. This reduces the chance to hit the MTU bearer of 1300 bytes for SIP over
UDP, if many codecs are allowed in Asterisk. This new feature is enabled
together with the optional feature compactheaders=yes via the file sip.conf.
ASTERISK-25578 #close
Change-Id: I16491b1937862de26f84fa0ffe679a6bab925044
Currently chan_sip can give weird messages if the contacts don't
fit in the From: or To: headers. This fix changes the from,to and
invite variables to use ast_str, allocates and deallocates them and
resizes them if needed.
ASTERISK-26069 #close
Change-Id: I1b68fcbddca6f6cc7d7a92fe1cb0d5430282b2b3
Change the awkward and not as flexible UnicastRTP options format
From:
Dial(UnicastRTP/127.0.0.1[/[<engine>][/[<codec>]]])
To:
Dial(UnicastRTP/127.0.0.1[/[<options>]])
Where <options> can be standard Asterisk flag options:
c(<codec>) - Specify which codec/format to use such as 'ulaw'.
e(<engine>) - Specify which RTP engine to use such as 'asterisk'.
More option flags can be easily added later such as the codec's RTP
payload type to use when the codec does not have a static payload type
defined.
Change-Id: I0c297aaf09e2ee515536cb7437bb8042ff8ff3c9
This adds a new parameter to the end of a multicast RTP dialing string.
This parameter defines the following options:
* i: Set the interface from which multicast RTP is sent
* l: Set whether multicast packets are looped back to the sender
* t: Set the TTL for multicast packets
* c: Set the codec to use for RTP
ASTERISK-26068 #close
Reported by Mark Michelson
Change-Id: I033b706b533f0aa635c342eb738e0bcefa07e219
* Fixed NULL crash potential if parameters are missing.
* Reordered some operations so further diagnostic messages can be
more helpful.
Change-Id: Ibbdc67a2496508cbfbfef0cf19c35177ae2fbd70
When chan_sip does a re-INVITE to refresh a session and authentication
is required, the INVITE with the Authorization header containes a
second Session-Expires header without the ";refersher=" parameter.
This is causing some proxies to return a 400. Also, when Asterisk is
the uas and the refresher, it is including the Session-Expires and
Min-SE headers in OPTIONS messages which is not allowed per RFC4028.
This patch (based on the reporter's) Checks to see if a Session-Expires
header is already in the message before adding another one. It also
checks that the method is INVITE or UPDATE.
ASTERISK-26030 #close
Change-Id: I58a7b07bab5a3177748d8a7034fb8ad8e11ce1d9
The unload process currently tells each TCP/TLS to terminate but
does not wait for them to do so. This introduces a race condition
where the container holding the threads may be destroyed before
the threads are able to remove themselves from it. When they
finally do the container is invalid and can't be used causing a
crash.
A previous change existed which waited a bit to wait for any
stranglers to finish. This change extends this and waits longer.
ASTERISK-25961 #close
Change-Id: Idc6262b670ca49ede32061159e323b7b63c6f3c6
Since Stasis has been introduced, an attempt to send AMI messages by an
autocreated peer caused a crash, and all events from autocreated peers were
semi-inadvertently disabled altogether in 0b83761. This change restores the
disabled functionality.
ASTERISK-25950
Change-Id: Iecc350f23db603fadb2f302064643ebe9664e974
This eliminates some casts that I made a note saying v10 and above
would no longer need them.
Better late than never :)
Change-Id: I346cdb3032b6478ceb40eb6fe732978b54035572
Added the ability to show channel statistics to chan_pjsip (cli_functions.c)
Moved the existing 'pjsip show channel(s)' functionality from
pjsip_configuration to cli_functions.c. The stats needed chan_pjsip's
private header so it made sense to move the existing channel commands as well.
Now using stasis_cache_dump to get the channel snapshots rather than retrieving
all endpoints, then getting each one's channel snapshots. Much more efficient.
Change-Id: I03b114522126d27434030b285bf6d531ddd79869
Asterisk 13.7.0 included a fix for ASTERISK-24543, not to send all those
codecs, which the caller did not request/support. That fix was not complete
because on the second Session Timer all codecs were sent again. Some VoIP/SIP
clients interpreted that complete codec-list as a change in the SIP session.
Because of that, Asterisk did not send the RTP audio via NAT anymore which
created a non-audio scenario after the second Session Timer fired.
ASTERISK-24543 #close
Change-Id: I1881827816ab7fd47eb4287a95961179b34a0b66
check_via() already skips leading blanks where the sent-by address (with the
optional port) should be placed.
Since RFC 3261 allows for blanks between the port ant the Via parameters:
> https://tools.ietf.org/html/rfc3261#section-20.42
(actually it allows a lot of blanks more ;-)). I just switched from
ast_skip_blanks() to ast_strip() on the local copy of the string.
ASTERISK-21301 #close
Change-Id: Ie5b8fe5a07067b7c0dc9bcdd1707e99b23b02b06
During a transfer involving direct media a race occurs between when the
transferer channel is swapped out, initiating rtp changes/updates, and the
subsequent reinvites.
When Alice, after speaking with Charlie (Bob is on hold), connects Bob and
Charlie invites are sent to each in order to establish the call between them.
Bob is taken off hold and Charlie is told to have his media flow through
Asterisk. However, if before those invites go out the bridge updates Bob's
and/or Charlie's rtp information with direct media data (i.e. address, port)
then the invite(s) will contain the remote data in the SDP instead of the
Asterisk data.
The race occurs in the native bridge glue code when updating the peer. The
direct_media_address can get set twice before sending out the first invite
during call connection. This can happen because the checking/setting of the
direct_media_address happened in one thread while the sending of the invite(s)
happened in another thread.
This fix removes the race condition by moving the checking/setting of the
direct_media_address to be in the same thread as the sending of the invites(s).
This serializes the checking/setting and sending so they can no longer happen
out of order.
ASTERISK-25849 #close
Change-Id: Idfea590175e74f401929a601dba0c91ca1a7f873
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023 #close
Change-Id: I96d429c57a48861fd8bde63dd93db4e92dc3adb6
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I2e40de89efc8ae6e8850771d089ca44bc604b508
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Made always run check_pendings() under the scheduler thread so scheduler
ids can be checked safely.
ASTERISK-25023
Change-Id: Ia834d6edd5bdb47c163e4ecf884428a4a8b17d52
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: If595e4456cd059d7171880c7f354e844c21b5f5f
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I6d65269151ba95e0d8fe4e9e611881cde2ab4900
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I9c11b9d597468f63916c99e1dabff9f4a46f84c1
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Fix clearing autokillid in __sip_autodestruct() even though we could
reschedule.
ASTERISK-25023
Change-Id: I450580dbf26e2e3952ee6628c735b001565c368f
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
* Fix retrans_pkt() to call check_pendings() with both the owner channel
and the private objects locked as required.
* Refactor dialog retransmission packet list to safely remove packet
nodes. The list nodes are now ao2 objects. The list has a ref and the
scheduled entry has a ref.
ASTERISK-25023
Change-Id: I50926d81be53f4cd3d572a3292cd25f563f59641
This patch is part of a series to resolve deadlocks in chan_sip.c.
Stopping a scheduled event can result in a deadlock if the scheduled event
is running when you try to stop the event. If you hold a lock needed by
the scheduled event while trying to stop the scheduled event then a
deadlock can happen. The general strategy for resolving the deadlock
potential is to push the actual starting and stopping of the scheduled
events off onto the scheduler/do_monitor() thread by scheduling an
immediate one shot scheduled event. Some restructuring may be needed
because the code may assume that the start/stop of the scheduled events is
immediate.
ASTERISK-25023
Change-Id: I98a694fd42bc81436c83aa92de03226e6e4e3f48
This patch is part of a series to resolve deadlocks in chan_sip.c.
* Make dialog_unlink_all() unschedule all items at once in the sched
thread.
ASTERISK-25023
Change-Id: I7743072fb228836e8228b72f6dc46c8cc50b3fb4
This patch is part of a series to resolve deadlocks in chan_sip.c.
The reordering of chan_sip's shutdown is to handle any immediate events
that get put onto the scheduler so resources aren't leaked. The typical
immediate events at this time are going to be concerned with stopping
other scheduled events.
ASTERISK-25023
Change-Id: I3f6540717634f6f2e84d8531a054976f2bbb9d20
This patch is part of a series to resolve deadlocks in chan_sip.c.
Delaying destruction of the chan_sip sip_pvt structures caused the
/channels/chan_sip/test_sip_rtpqos unit test to crash. That test
registers a special test ast_rtp_engine with the rtp engine module. When
the unit test completes it cleans up by unregistering the test
ast_rtp_engine and exits. Since the delayed destruction of the sip_pvt
happens after the unit test returns, the destructor tries to call the rtp
engine destroy callback of the test ast_rtp_engine auto variable which no
longer exists on the stack.
* Change the test ast_rtp_engine auto variable to a static variable. Now
the variable can still exist after the unit test exits so the delayed
sip_pvt destruction can complete successfully.
ASTERISK-25023
Change-Id: I61e34a12d425189ef7e96fc69ae14993f82f3f13
Remove destructor calling destroy_it calling really_destroy_it
for no benefit. Just make the destructor the really_destroy_it
function.
Change-Id: Idea0d47b27dd74f2488db75bcc7f353d8fdc614a
Previous chan_sip behavior:
Before this patch chan_sip would always strip any quotes from an incoming
reason and pass that value up as the REDIRECTING(reason). For an outgoing
reason value, chan_sip would check the value against known values and
quote any it didn't recognize. Incoming 480 response message reason text
was just assigned to the REDIRECTING(reason).
Previous chan_pjsip behavior:
Before this patch chan_pjsip would always pass the incoming reason value
up as the REDIRECTING(reason). For an outgoing reason value, chan_pjsip
would send the reason value as passed down.
With this patch:
Both channel drivers match incoming reason values with values documented
by REDIRECTING(reason) and values documented by RFC5806 regardless of
whether they are quoted or not. RFC5806 values are mapped to the
equivalent REDIRECTING(reason) documented value and is set in
REDIRECTING(reason). e.g., an incoming RFC5806 'unconditional' value or a
quoted string version ('"unconditional"') is converted to
REDIRECTING(reason)'s 'cfu' value. The user's dialplan only needs to deal
with 'cfu' instead of any of the aliases.
The incoming 480 response reason text supported by chan_sip checks for
known reason values and if not matched then puts quotes around the reason
string and assigns that to REDIRECTING(reason).
Both channel drivers send outgoing known REDIRECTING(reason) values as the
unquoted RFC5806 equivalent. User custom values are either sent as is or
with added quotes if SIP doesn't allow a character within the value as
part of a RFC3261 Section 25.1 token. Note that there are still
limitations on what characters can be put in a custom user value. e.g.,
embedding quotes in the middle of the reason string is silly and just
going to cause you grief.
* Setting a REDIRECTING(reason) value now recognizes RFC5806 aliases.
e.g., Setting REDIRECTING(reason) to 'unconditional' is converted to the
'cfu' value.
* Added missing malloc() NULL return check in res_pjsip_diversion.c
set_redirecting_reason().
* Fixed potential read from a stale pointer in res_pjsip_diversion.c
add_diversion_header(). The reason string needed to be copied into the
tdata memory pool to ensure that the string would always be available.
Otherwise, if the reason string returned by reason_code_to_str() was a
user's reason string then the string could be freed later by another
thread.
Change-Id: Ifba83d23a195a9f64d55b9c681d2e62476b68a87
chan_sip could not handle AST_T38_TERMINATED frames being sent to it when
the channel left the bridge. The action resulted in overlapping outgoing
reINVITEs. The testsuite tests/fax/sip/directmedia_reinvite_t38 was not
happy.
* Force T.38 to be remembered as locally bridged. Now when the channel
leaves the native RTP bridge after T.38, the channel remembers that it has
already reINVITEed the media back to Asterisk. It just needs to terminate
T.38 when the AST_T38_TERMINATED arrives.
* Prevent redundant AST_T38_TERMINATED from causing problems. Redundant
AST_T38_TERMINATED frames could cause overlapping outgoing reINVITEs if
they happen before the T.38 state changes to disabled. Now the T.38 state
is set to disabled before the reINVITE is sent.
ASTERISK-25582 #close
Change-Id: I53f5c6ce7d90b3f322a942af1a9bcab6d967b7ce
Use the correct comparison function since we only care if the address
without the port is the same.
Change-Id: Ibf6c485f843a1be6dee58a47b33d81a7a8cbe3b0
Previously you could add [!dnid] to the SIP dial string to alter the To:
header. This change allows you to alter the From header as well.
SIP dial string extra options now look like this:
[![touser[@todomain]][![fromuser][@fromdomain]]]
INCOMPATIBLE CHANGE: If you were using an exclamation mark in your To:
header, that is no longer possible.
ASTERISK-25803 #close
Change-Id: I2457e9ba7a89eb1da22084bab5a4d4328e189db7
Setting the sip.conf timert1 value to a value higher than 1245 can cause
an integer overflow and result in large retransmit timeout times. These
large timeout times hold system file descriptors hostage and can cause the
system to run out of file descriptors.
NOTE: The default sip.conf timert1 value is 500 which does not expose the
vulnerability.
* The overflow is now detected and the previous timeout time is
calculated.
ASTERISK-25397 #close
Reported by: Alexander Traud
Change-Id: Ia7231f2f415af1cbf90b923e001b9219cff46290
When I ask asterisk to send a SIP NOTIFY message to a sip peer using either a)
AMI action: SIPnotify or b) cli command: sip notify <cmd> <peer>, I expect
asterisk to include the same value for its own ip in both cases a) and b),
but it seems a) produces a contact header like Contact:
<sip:asterisk@192.168.1.227:8060> whereas b) produces a contact header like
<sip:asterisk@127.0.0.1:8060>. 0.0.0.0:8060 is my udpbindaddr in sip.conf
My guess is that manager_sipnotify should call
ast_sip_ouraddrfor(&p->sa, &p->ourip, p) the same way sip_cli_notify does,
because after applying this patch, both cases a) and b) produce
the contact header that I expect: <sip:asterisk@192.168.1.227:8060>
Reported by: Stefan Engström
Tested by: Stefan Engström
Change-Id: I86af5e209db64aab82c25417de6c768fb645f476
sip_sipredirect uses sscanf to copy up to 256 characters to a stacked buffer
of 256 characters. This patch reduces the copy to 255 characters to leave
room for the string null terminator.
ASTERISK-25722 #close
Change-Id: Id6c3a629a609e94153287512c59aa1923e8a03ab
In the sample sip.conf this is written with regard to notifyringing:
;notifyringing = no ; Control whether subscriptions already INUSE get sent
RINGING when another call is sent (default: yes)
However, this setting changes whether or not any RINGING indications are sent
to subscriptions. There is no separate configurable setting that allows
to control whether INUSE subscriptions also get sent RINGING. This is however
a useful option, to see (using BLF) if somebody else is able to handle an
incoming call or if everybody is busy.
This patch corrects the documentation for notifyringing (so the documentation
matches the functionality) and make notifyringing a tri-state option, by adding
the value 'notinuse' (in addition to 'yes' and 'no'). When notifyringing =
notinuse, only subscriptions that are not INUSE are sent the RINGING signal.
The default setting for notifyringing remains set to yes, so the default
behaviour is not affected.
ASTERISK-25558
Change-Id: I88f7036ee084bb3f43b74f15612695c6708f74aa
websocket_write_timeout was not being set to its default value
during sip config reload, which meant that prior to this commit,
1) the default value of 100 was not used, unless an invalid value
(or 1) was specified in sip.conf for websocket_write_timeout, and
2) if the websocket_write_timeout directive was removed from sip.conf
without a full restart of asterisk, then the previous value would
continue to be used indefinitely.
This essentially lead to a 0ms write timeout (the first write attempt
in ast_careful_fwrite must have succeeded) in websocket write requests
from chan_sip, unless websocket_write_timeout was explicitely set in sip.conf.
Changes to websocket_write_timeout still only apply to new websocket
sessions, after the sip reload -- timeouts on existing sessions are
not adjusted during sip reload.
Change-Id: Ibed3816ed29cc354af6564c5ab3e75eab72cb953
Per the documentation the WebSocket support in chan_sip is
supposed to be enabled by default but is not. This change
corrects that.
Change-Id: Icb02bbcad47b11a795c14ce20a9bf29649a54423
Adds the TCP Keep Alive option to TCP and TLS server sockets. Previously
this option was only being set on session sockets.
http://www.tldp.org/HOWTO/html_single/TCP-Keepalive-HOWTO/
According to the link above, the SO_KEEPALIVE option is useful for knowing
when a TCP connected endpoint has severed communication without indicating
it or has become unreachable for some reason. Without this patch, keep
alive is not set on the socket listening for incoming TCP sessions and
in Komatsu's report this resulted in the thread listening for TCP becoming
stuck in a waiting state.
ASTERISK-25364 #close
Reported by: Hiroaki Komatsu
Change-Id: I7ed7bcfa982b367dc64b4b73fbd962da49b9af36
The current logic for ICE negotiation starts it
when receiving an SDP with ICE candidates. This is
incorrect as ICE negotiation can only start when each
call party have at least one pair of local and remote
candidate. Starting ICE negotiation early would result
in negotiation failure and ultimately no audio.
This change makes it so ICE negotiation is only started
when a response with SDP is received or when a response
with SDP is sent.
ASTERISK-24146
Change-Id: I55a632bde9e9827871b09141d82747e08379a8ca
Asterisk may crash when calling ast_channel_get_t38_state(c)
on a locked channel which is being hung up.
ASTERISK-25609 #close
Change-Id: Ifaa707c04b865a290ffab719bd2e5c48ff667c7b
A crash happens sometimes when performing a CLI "sip reload". The bogus
peer gets refreshed while it is in use by a new call which can cause the
crash.
* Protected the global bogus peer object with an ao2 global object
container.
ASTERISK-25610 #close
Change-Id: I5b528c742195681abcf713c6e1011ea65354eeed
Current support for reason header did work only in SIP responses.
According to RFC3336 the reason header might appear in any SIP request.
But it seems to make most sence in BYE and CANCEL so parasing is done
there too (if use_q850_reason=yes).
Change-Id: Ib6be7b34c23a76d0e98dfd0816c89931000ac790
chan_sip.c:
* Initialize mwi subscription scheduler ids earlier because of ASTOBJ to
ao2 conversion.
* Initialize register scheduler ids earlier because of ASTOBJ to ao2
conversion.
chan_skinny.c:
* Fix more scheduler usage for the valid 0 id value.
ASTERISK-25476
Change-Id: If9f0e5d99638b2f9d102d1ebc9c5a14b2d706e95
channels/chan_iax2.c:
* Initialize struct chan_iax2_pvt scheduler ids earlier because of
iax2_destroy_helper().
channels/chan_sip.c:
channels/sip/config_parser.c:
* Fix initialization of scheduler id struct members. Some off nominal
paths had 0 as a scheduler id to be destroyed when it was never started.
chan_skinny.c:
* Fix some scheduler id comparisons that excluded the valid 0 id.
channel.c:
* Fix channel initialization of the video stream scheduler id.
pbx_dundi.c:
* Fix channel initialization of the packet retransmission scheduler id.
ASTERISK-25476
Change-Id: I07a3449f728f671d326a22fcbd071f150ba2e8c8
When a channel is in a direct media bridge, a re-INVITE may arrive that forces
Asterisk to re-negotiate the media to a T.38 fax. When this occurs, the bridge
must change its technology to a simple bridge, and re-INVITE the media back
to Asterisk.
Generally, this logic mostly already exists in Asterisk. However, prior to this
patch, there were a few bugs:
(1) The T.38 framehook currently prevents a channel capable of T.38 faxes from
ever entering into a direct media bridge. This applies even when the only
media being passed over the channel is audio. This patch fixes this bug
by having the framehook specify that it defers caring about any frame type.
This allows the channels to enter into a direct media bridge, which will
be broken when a re-INVITE is received.
(2) When a re-INVITE is received, nothing instructed the bridging layer to
re-inspect the allowed bridging technology. This now occurs when either
a re-INVITE is received from a peer, or when a response is received from
the far end (that is, when the T.38 state changes to either
T38_PEER_REINVITE or T38_LOCAL_REINVITE).
(3) chan_pjsip needs to do a small amount of work to prevent a direct media
bridge from being chosen when a T.38 session is in progress. When a T.38
session supplement has a t38 datastore - which is added when we detect
we should start thinking about T.38 on a channel - we now refuse a native
RTP bridge.
(4) When a BYE request is received, we don't terminate the T.38 session. If
the other side of a T.38 fax survives the hangup (due to the 'g' flag
in Dial, for example), we don't currently re-INVITE the media on the
other channel back to audio. This patch now has res_pjsip_t38 intercept
BYE requests and inform the far side that the T.38 session is terminated.
This naturally causes the correct re-INVITEs to be sent.
ASTERISK-25582
Change-Id: Iabd6aa578e633d16e6b9f342091264e4324a79eb
When ASTERISK-25449 was closed, a number of scheduler issues mentioned in
the comments were missed. These have since beed raised in ASTERISK-25476
and elsewhere.
This patch attempts to collect all of the scheduler issues discovered so
far and address them sensibly.
ASTERISK-25476 #close
Change-Id: I87a77d581e2e0d91d33b4b2fbff80f64a566d05b
This patch adds a new setting "websockets_enabled" to sip.conf.
Setting this to false allows chan_sip to be used without causing
conflicts with res_pjsip_transport_websocket.
ASTERISK-24106 #close
Reported by: Andrew Nagy
Change-Id: I04fe8c4f2d57b2d7375e0e25826c91a72e93bea7
Since version 13, Asterisk sent all allowed codecs as callee, even when the
caller did not request/support them. In case of dynamic RTP payloads, this led
to the same ID for different codecs, which is not allowed by SIP/SDP. Now, the
intersection between the requested and the supported codecs is send again.
ASTERISK-24543 #close
Change-Id: Ie90cb8bf893b0895f8d505e77343de3ba152a287
Fixed 1 issue in each of the affected files.
ASTERISK-25494 #close
Reported-by: George Joseph
Tested-by: George Joseph
Change-Id: I818f149cd66a93b062df421e1c73c7942f5a4a77
With Asterisk 13, the structures ast_format and ast_codec changed. Because of
that, the paketization timing (framing) of the RTP channel moved away from the
formats/codecs. In the course of that change, the ptime of the callee was not
honored anymore, when the optional autoframing was enabled.
ASTERISK-25484 #close
Change-Id: Ic600ccaa125e705922f89c72212c698215d239b4
To quote Olle:
"When issuing a hangup due to RTP timeouts the cause code is not set. I have
selected 44 based on Cisco's implementation..."
ASTERISK-25135 #close
Reported by: Olle Johansson
patches:
rtp-timeout-cause-1.8.diff uploaded by Olle Johansson (License 5267)
Change-Id: Ia62100c55077d77901caee0bcae299f8dc7375fc
If a Via header containes an IPv6 address and a port number is ommitted,
as it is the standard port, we now leave the port empty and to not set it
to the value after the first colon of the IPv6 address.
ASTERISK-25443 #close
Change-Id: Ie3c2f05471cd006bf04ed15598589c09577b1e70
Apparently some endpoints attempt to send a reINVITE before completing the
initial INVITE transaction. In this case PJSIP responds appropriately to
the reINVITE with a 491 INVITE request pending. Unfortunately chan_pjsip
is using the initial INVITE transaction state to determine if an INVITE is
the initial INVITE or a reINVITE. Since the initial INVITE transaction
has not been confirmed yet chan_pjsip thinks the reINVITE is an initial
INVITE and starts another PBX thread on the channel. The extra PBX thread
ensures that hilarity ensues.
* Fix checks for a reINVITE on incoming requests to look for the presence
of a to-tag instead of the initial INVITE transaction state.
* Made caller_id_incoming_request() determine what to do if there is a
channel on the session or not. After a channel is created it is too late
to just store the new party id on the session because the session's party
id has already been copied to the channel's caller id.
ASTERISK-25404 #close
Reported by: Chet Stevens
Change-Id: Ie78201c304a2b13226f3a4ce59908beecc2c68be
When 5c713fdf18 was merged, it allowed for scheduled items to have an ID of
'0' returned. While this was valid per the documentation for the API, it was
apparently never returned previously. As a result, several users of the
scheduler API viewed the result as being invalid, causing them to reschedule
already scheduled items or otherwise fail in interesting ways.
This patch corrects the users such that they view '0' as valid, and a returned
ID of -1 as being invalid.
Note that the failing HEP RTCP tests now pass with this patch. These tests
failed due to a duplicate scheduling of the RTCP transmissions.
ASTERISK-25449 #close
Change-Id: I019a9aa8b6997584f66876331675981ac9e07e39
Some systems require the REFER packet to include a Referred-By header.
If the channel variable SIPREFERREDBYHDR is set, it passes that value as the
Referred-By header value. Otherwise, it adds the current dialog’s local info.
Reported by: Dan Cropp
Tested by: Dan Cropp
Change-Id: I3d17912ce548667edf53cb549e88a25475eda245
The CALLERID(num) and CALLERID(name) and other info are placed into the
`char from[256]` in initreqprep. If the name was too long, the addr-spec
and params wouldn't fit.
Code is moved around so the addr-spec with params is placed there first,
and then fitting in as much of the display-name as possible.
ASTERISK-25396 #close
Change-Id: I33632baf024f01b6a00f8c7f35c91e5f68c40260
Although unlikely, if the tech private is returned as
a NULL, chan_pjsip_get_rtp_peer() would crash.
ASTERISK-25323
Change-Id: Ie231369bfa7da926fb2b9fdaac228261a3152e6a
Change validation on reload module because now used the cli function for
reload. The sip_reload() function never fail and ever return NULL for this
reason on reload() now use the call the sip_reload() and return
AST_MODULE_LOAD_SUCCESS.
This problem is dectected on reload by PUT method on ARI, getting always
404 http code when the module is reloaded.
ASTERISK-25325 #close
Reporte by: Rodrigo Ramírez Norambuena
Change-Id: I41215877fb2cfc589e0d4d464000cf6825f4d7fb
This patch adds a new option to the CHANNEL function that allows for the
extraction of the SIP call-id. It is used in conjunction with the 'pjsip'
option, and will return the Call-ID of the INVITE request that established
the PJSIP channel.
ASTERISK-25352
Change-Id: I278d1f8bcfe3a53c5aa1dadebc14e92b0abd476a
In chan_pjsip_new, if allocation of the pvt
structure fails, ast_hangup is called. But
it was written to assume pvt was valid, and
this change corrects that.
ASTERISK-25323
Reported by: Scott Griepentrog
Change-Id: I5f47860fe9cee4cd56abd3f79b108678ab72cc87
The call pickup implementation in chan_sip currently sets the channel
hangup cause to "normal clearing" if call pickup is successfully
performed. This action overwrites the "answered elsewhere" hangup cause
set by the call pickup code and can result in the SIP device in
question showing a missed call when it should not.
This change sets the hangup cause to "normal clearing" as a
default initially but allows the call pickup to change it as
needed.
ASTERISK-25346 #close
Change-Id: I00ac2c269cee9e29586ee2c65e83c70e52a02cff
There are numerous problems with the current implementation of the RTP
payload type mapping in Asterisk. It uses only one mapping structure to
associate payload types to codecs. The single mapping is overkill if all
of the payload type values are well known values. Dynamic payload type
mappings do not work as well with the single mapping because RFC3264
allows each side of the link to negotiate different dynamic mappings for
what they want to receive. Not only could you have the same codec mapped
for sending and receiving on different payload types you could wind up
with the same payload type mapped to different codecs for each direction.
1) An independent payload type mapping is needed for sending and
receiving.
2) The receive mapping needs to keep track of previous mappings because of
the slack to when negotiation happens and current packets in flight using
the old mapping arrive.
3) The transmit mapping only needs to keep track of the current negotiated
values since we are sending the packets and know when the switchover takes
place.
* Needed to create ast_rtp_codecs_payload_code_tx() and make some callers
use the new function because ast_rtp_codecs_payload_code() was used for
mappings in both directions.
* Needed to create ast_rtp_codecs_payloads_xover() for cases where we need
to pass preferred codec mappings to the peer channel for early media
bridging or when we need to prefer the offered mapping that RFC3264 says
we SHOULD use.
* ast_rtp_codecs_payloads_xover() and ast_rtp_codecs_payload_code_tx() are
the only new public functions created. All the others were only used for
the tx or rx mapping direction so the function doxygen now reflects which
direction the function operates.
* chan_mgcp.c: Removed call to ast_rtp_codecs_payloads_clear() as doing
that makes no sense when processing an incoming SDP. We would be wiping
out any mappings that we set for the possible outgoing SDP we sent
earlier.
ASTERISK-25166
Reported by: Kevin Harwell
ASTERISK-17410
Reported by: Boris Fox
Change-Id: Iaf6c227bca68cb7c414cf2fd4108a8ac98bd45ac
In chan_sip, after handling an incoming invite a security event is raised
describing authorization (success, failure, etc...). However, it was doing
a lookup of the peer by extension. This is fine for register messages, but
in the case of an invite it may search and find the wrong peer, or a non
existent one (for instance, in the case of call pickup). Also, if the peers
are configured through realtime this may cause an unnecessary database lookup
when caching is enabled.
This patch makes it so that sip_report_security_event searches by IP address
when looking for a peer instead of by extension after an invite is processed.
ASTERISK-25320 #close
Change-Id: I9b3f11549efb475b6561c64f0e6da1a481d98bc4
Pressing DTMF digits on a phone to go out on a DAHDI channel can result in
the digit not being recognized or even heard by the peer.
Phone -> Asterisk -> DAHDI/channel
Turns out the DAHDI behavior with DTMF generation (and any other generated
tones) is exposed by the "buffers=" setting in chan_dahdi.conf. When
Asterisk requests to start sending DTMF then DAHDI waits until its write
buffer is empty before generating any samples for the DTMF tones. When
Asterisk subsequently requests DAHDI to stop sending DTMF then DAHDI
immediately stops generating the DTMF samples. As a result, the more
samples there are in the DAHDI write buffer the shorter the time DTMF
actually gets sent on the wire. If there are more samples in the write
buffer than the time DTMF is supposed to be sent then no DTMF gets sent on
the wire. With the "buffers=12,half" setting and each buffer representing
20 ms of samples then the DAHDI write buffer is going to contain around
120 ms of samples. For DTMF to be recognized by the peer the actual sent
DTMF duration needs to be a minimum of 40 ms. Therefore, the intended
duration needs to be a minimum of 160 ms for the peer to receive the
minimum DTMF digit duration to recognize it.
A simple and effective solution to work around the DAHDI behavior is for
Asterisk to flush the DAHDI write buffer when sending DTMF so the full
duration of DTMF is actually sent on the wire. When someone is going to
send DTMF they are not likely to be talking before sending the tones so
the flushed write samples are expected to just contain silence.
* Made dahdi_digit_begin() flush the DAHDI write buffer after requesting
to send a DTMF digit.
ASTERISK-25315 #close
Reported by John Hardin
Change-Id: Ib56262c708cb7858082156bfc70ebd0a220efa6a
There is a window of opportunity for DTMF to not go out if an audio frame
is in the process of being written to DAHDI while another thread starts
sending DTMF. The thread sending the audio frame could be past the
currently dialing check before being preempted by another thread starting
a DTMF generation request. When the thread sending the audio frame
resumes it will then cause DAHDI to stop the DTMF tone generation. The
result is no DTMF goes out.
* Made dahdi_write() lock the private struct before writing to the DAHDI
file descriptor.
ASTERISK-25315
Reported by John Hardin
Change-Id: Ib4e0264cf63305ed5da701188447668e72ec9abb
iLBC 20 was advertised in a SIP/SDP negotiation. However, only iLBC 30 is
supported. Removes "a=fmtp:x mode=y" from SDP. Because of RFC 3952 section 5,
only iLBC 30 is negotiated now.
ASTERISK-25309 #close
Change-Id: I92d724600a183eec3114da0ac607b994b1a793da
We have seen a rash of test failures on a 32-bit build agent. Commit
48698a5e21 solved an obvious problem where
we were not encoding a 64-bit value correctly over the wire. This
commit, however, did not solve the test failures.
In the failing tests, ARI is attempting to send a 537 byte text frame
over a websocket. When sending a frame this small, 16 bits are all that
is required in order to encode the payload length on the websocket
frame. However, ast_websocket_write() thinks that the payload length is
greater than 65535 and therefore writes out a 64 bit payload length.
Inspecting this payload length, the lower 32 bits are exactly what we
would expect it to be, 537 in hex. The upper 32 bits, are junk values
that are not expected to be there.
In the failure, we are passing the result of strlen() to a function that
expects a uint64_t parameter to be passed in. strlen() returns a size_t,
which on this 32-bit machine is 32 bits wide. Normally, passing a 32-bit
unsigned value to somewhere where a 64-bit unsigned value is expected
would cause no problems. In fact, in manual runs of failing tests, this
works just fine. However, ast_websocket_write() uses the Asterisk
optional API, which means that rather than a simple function call, there
are a series of macros that are used for its declaration and
implementation. These macros may be causing some sort of error to occur
when converting from a 32 bit quantity to a 64 bit quantity.
This commit changes the logic by making existing ast_websocket_write()
calls use ast_websocket_write_string() instead. Within
ast_websocket_write_string(), the 64-bit converted strlen is saved in a
local variable, and that variable is passed to ast_websocket_write()
instead.
Note that this commit message is full of speculation rather than
certainty. This is because the observed test failures, while always
present in automated test runs, never occur when tests are manually
attempted on the same test agent. The idea behind this commit is to fix
a theoretical issue by performing changes that should, at the least,
cause no harm. If it turns out that this change does not fix the failing
tests, then this commit should be reverted.
Change-Id: I4458dd87d785ca322b89c152b223a540a3d23e67
This change adds support for the 'rtp_timeout' and 'rtp_timeout_hold'
endpoint options. These allow the channel to be hung up if RTP
is not received from the remote endpoint for a specified number of
seconds.
ASTERISK-25259 #close
Change-Id: I3f39daaa7da2596b5022737b77799d16204175b9
Receipt of an RTP packet currently causes the formats on an PJSIP channel to
change to the format of the RTP packet. In some off-nominal cases it's possible
for this to be a format that has not been configured or negotiated. This change
makes it so only formats explicitly configured on the endpoint are allowed.
ASTERISK-25258 #close
Change-Id: If93d641fb6418a285928839300d7854cab8c1020
In channels/sig_pri.h, struct sig_pri_span, the field
force_restart_unavailable_chans is only defined if
#if defined(HAVE_PRI_MCID) is true.
All other occurences of force_restart_unavailable_chans are outside of the
#if defined(HAVE_PRI_MCID)
endif
scope.
ASTERISK-25257 #close
Reported by: Patric Marschall
Change-Id: I071de89cc2cd0d85927a013036e235851f672549
This patch updates a variety of Makefiles in Asterisk's build system to
remove .gcda and .gcno files when 'make clean' is executed. These files
are generated when '--enable-coverage' is passed to the Asterisk
configure script.
Change-Id: Ib70b41eea2ee2908885bff02e80faf9f40c84602
When handle_invite_replaces() was called, and either ast_bridge_impart()
failed or there was no bridge (because the channel we're picking up was
still ringing), chan_sip would leak a channel.
Thanks Matt and Corey for checking the bridge path.
ASTERISK-25226 #close
Change-Id: Ie736bb182170a73eef5bcef0ab0376f645c260c8
On reload, previously allowed codecs were not removed. Therefore, it was not
possible to remove codecs while Asterisk was running. Furthermore, newly added
codecs got appended behind the previous codecs. Therefore, it was not possible
to add a codec with a priority of #1. This change removes the old capabilities
before the current ones are added.
ASTERISK-25182 #close
Reported by: Alexander Traud
patches:
asterisk_13_allow_codec_reload.patch uploaded by Alexander Traud (License 6520)
Change-Id: I62a06bcf15e08e8c54a35612195f97179ebe5802
Due to the use of stasis_unsubscribe_and_join in the peer destructor
it is possible for a deadlock to occur when an event callback is
occurring at the same time.
This happens because the peer may be destroyed while holding the
peers container lock. If this occurs the event callback will never
be able to acquire the container lock and the unsubscribe will
never complete.
This change makes it so the peers that have been removed from the
peers container are not destroyed with the container lock held.
ASTERISK-25163 #close
Change-Id: Ic6bf1d9da4310142a4d196c45ddefb99317d9a33
If a client sends and INVITE which is 401 rejected, then subsequently
sends a new INVITE with the auth info and uses a different fromtag
from the first INVITE, Asterisk will accept the new INVITE as part of
the original dialog - match_req_to_dialog() specifically ignores the
fromtag. However it does not update the stored dialog with the new
fromtag.
This results in Asterisk being unable to match future packets that are
part of this dialog (such as the ACK to the OK or the OK to the BYE),
and the call is dropped.
This problem was originally found when using an NEC-i SV8100-GE (NEC SIP
Card).
* After a successful match of a packet to the dialog, if the packet is
not a SIP_RESPONSE, authentication is present and the fromtags are
different, the stored fromtag is updated with the one from the recent
INVITE.
ASTERISK-25154 #close
Reported by: Damian Ivereigh
Tested by: Damian Ivereigh
Change-Id: I5c16cf3b409e5ef9f2b2fe974b6bd2a45a6aa17e
Prior to this patch, chan_pjsip was failing to pass the endpoint's
context and the desired extension to the ast_channel_alloc_* routine.
This caused a new channel snapshot to be issued without a context and
extension, which can cause some reporting issues for users of AMI, CEL,
and other APIs. The channel driver would later set the context and
extension on the channel such that the channel would start in the
correct location in the dialplan, but the information reported in the
initial event would be incorrect.
This patch modifies the channel driver such that it now passes the
context and extension directly into the allocation routine. This
provides the information in the new channel snapshot published over
Stasis.
ASTERISK-25156 #close
Reported by: cloos
Change-Id: Ic6f8542836e596db8f662071d118e8f934fdf25e
Although ast_context_find, ast_context_find_or_create and
ast_context_destroy perform locking of the contexts table,
any context pointer can become invalid at any time that the
contexts table is unlocked. This change adds locking around
all complete operations involving these functions.
Places where ast_context_find was followed by ast_context_destroy
have been replaced with calls ast_context_destroy_by_name.
ASTERISK-25094 #close
Reported by: Corey Farrell
Change-Id: I1866b6787730c9c4f3f836b6133ffe9c820734fa
Many uses of stasis_unsubscribe in modules can be reached through unload.
These have been switched to stasis_unsubscribe_and_join.
Some subscription callbacks do nothing, for these I've created a noop
callback function in stasis.c. This is used by some modules that monitor
MWI topics in order to enable cache, since the callback does not become
invalid after dlclose it is safe to use stasis_unsubscribe on these, even
during module unload.
ASTERISK-25121 #close
Change-Id: Ifc2549fbd8eef7d703c222978e8f452e2972189c
channels/chan_iax.c: Prevent the deadlock between iax2_hangup and send_lagrq/
send_ping. This deadlock happens because the scheduled task send_lagrq(or
send_ping) starts execution after the call hangup procedure starts but before
it deletes the tasks in the scheduler.
The solution is to delete scheduled lagrq (and ping) task asynchronously
(i.e. schedule AST_SCHED_DEL for these tasks); By this, AST_SCHED_DEL will
be called in a new context (doesn't have callno locked).
This commit also cleans up the procedure of sending LAGRQ and PING.
main/sched.c: Do not assert when deleting non existant entry from scheduler.
This assert seems to be the reason for a lot of awkward code to avoid it.
ASTERISK-24983 #close
Reported by: Y Ateya
Change-Id: I03bec1fc8faacb89630269e935fa667c6d6c080c
Add missing return -1 when no endpoint name is specified.
ASTERISK-25086 #close
Reported by: snuffy
Change-Id: I9de76c2935a1f4e3f0cffe97a670106f5605e89e
If an ISDN call is hungup by both sides at the same time a crash could
happen.
* Added missing NULL checks for the owner channel after calling
pri_queue_pvt_cause_data() in two places. Code after those calls need to
check the owner channel pointer for NULL before use because
pri_queue_pvt_cause_data() needs to do deadlock avoidance to lock the
owner and the owner may get hung up.
ASTERISK-21893 #close
Reported by: Alexandr Gordeev
Change-Id: Ica3e266ebc7a894b41d762326f08653e1904bb9a
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
A few cases exist where headers of optional_api provders are included but
not needed. This causes unneeded calls to ast_optional_api_use.
* Don't include optional_api.h from sip_api.h.
* Move 'struct ast_channel_monitor' to channel.h.
* Don't include monitor.h from chan_sip.c, channel.c or features.c.
The move of struct ast_channel_monitor is needed since channel.c depends on
it. This has no effect on users of monitor.h since channel.h is included
from monitor.h.
ASTERISK-25051 #close
Reported by: Corey Farrell
Change-Id: I53ea65a9fc9693c89f8bcfd6120649bfcfbc3478
This patch has two main purposes:
1) Improve warning messages when ACLs are configured improperly.
2) Prevent misconfigured ACLs from allowing potentially unwanted
traffic.
To acomplish point (2) in most cases, whatever configuration object that
the ACL belonged to was not allowed to load.
The one exception is res_pjsip_acl. In that case, ACLs are their own
configuration object. Furthermore, the module loading code has no
indication that a ACL configuration had a failure. So the tactic taken
here is to create an ACL that just blocks everything.
ASTERISK-24969
Reported by Corey Farrell
Change-Id: I2ebcb6959cefad03cea4d81401be946203fcacae
Some telco switches occasionally ignore ISDN RESTART requests. The fix
for ASTERISK-19608 added an escape clause for B channels in the restarting
state if the telco ignores a RESTART request. If the telco fails to
acknowledge the RESTART then Asterisk will assume the telco acknowledged
the RESTART on the second call attempt requesting the B channel by the
telco. The escape clause is good for dealing with RESTART requests in
general but it does cause the next call for the restarting B channel to be
rejected if the telco insists the call must go on that B channel.
chan_dahdi doesn't really need to issue a RESTART request in response to
receiving a cause 44 (Requested channel not available) code. Sending the
RESTART in such a situation is not required (nor prohibited) by the
standards. I think chan_dahdi does this for historical reasons to deal
with buggy peers to get channels unstuck in a similar fashion as the
chan_dahdi.conf resetinterval option.
* Add the chan_dahdi.conf force_restart_unavailable_chans compatability
option that when disabled will prevent chan_dahdi from trying to RESTART
the channel in response to a cause 44 code.
ASTERISK-25034 #close
Reported by: Richard Mudgett
Change-Id: Ib8b17a438799920f4a2038826ff99a1884042f65
Flags are 64 bits. Without LLU suffix the value of 1<<31 is negative.
Although it doesn't have an effect on the current implementation, it will
be problem if more flags are added.
Change-Id: Ic290c81cfbbbf062872392d99d3322932cc49487
* The REF_DEBUG compiler flag no longer has any effect on code that uses
Astobj2. It is used to determine if reference debugging is enabled by
default. Reference debugging can be enabled or disabled in asterisk.conf.
* Caller information is provided in logger errors for ao2 bad magic numbers.
* Optimizes AO2 by merging internal functions with the public counterpart.
This was possible now that we no longer require a dual ABI.
ASTERISK-24974 #close
Reported by: Corey Farrell
Change-Id: Icf3552721fe999365ba8a8cf00a965aa6b897cc1
A typo in commit f8e21a1adf resulted in a compilation error in
chan_skinny. This patch fixes the typo.
ASTERISK-24917
Change-Id: Id7f4ad1fe948eb2408622e80c27936ce4516c33c
clang can warn about a so called tautological-compare, when it finds
comparisons which are logically always true, and are therefor deemed
unnecessary.
Exanple:
unsigned int x = 4;
if (x > 0) // x is always going to be bigger than 0
Enum Case:
Each enumeration is its own type. Enums are an integer type but they
do not have to be *signed*. C leaves it up to the compiler as an
implementation option what to consider the integer type of a particu-
lar enumeration is. Gcc treats an enum without negative values as
an int while clang treats this enum as an unsigned int.
rmudgett & mmichelson: cast the enum to (unsigned int) in assert.
The cast does have an effect. For gcc, which seems to treat all enums
as int, the cast to unsigned int will eliminate the possibility of
negative values being allowed. For clang, which seems to treat enums
without any negative members as unsigned int, the cast will have no
effect. If for some reason in the future a negative value is ever
added to the enum the assert will still catch the negative value.
ASTERISK-24917
Change-Id: Ief23ef68916192b9b72dabe702b543ecfeca0b62
The chan_dahdi channel driver is a very old driver. The ability for it to
support ISDN was added well after the initial analog support. Setting the
softhangup flags is a carry over from the original analog code. The
driver was not updated to call ast_queue_hangup() which will post the AMI
HangupRequest event.
* Changed sig_pri.c to call ast_queue_hangup() instead of setting the
softhangup flag when the remote party initiates a hangup.
ASTERISK-24895 #close
Reported by: Andrew Zherdin
Change-Id: I5fe2e48556507785fd8ab8e1c960683fd5d20325
This new macro allows a single line to add all additional
sources to a module. This helps prevent modules from
missing steps, and makes future changes easier since
they can be made in a single place.
ASTERISK-24960 #close
Reported by: Corey Farrell
Change-Id: I38f12d8b72c5e7bb37a879b2fb51761a2855eb4b
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
With this patch, chan_pjsip/res_pjsip now sets the native formats to the
codecs negotiated by a call.
* The changes in chan_pjsip.c and res_pjsip_sdp_rtp.c set the native
formats to include all the negotiated audio codecs instead of only the
initial preferred audio codec and later the currently received audio
codec.
* The audio frame handling in channel.c:ast_read() is more streamlined and
will automatically adjust to changes in received frame formats. The new
policy is to remove translation and pass the new frame format to the
receiver except if the translation was to a signed linear format. A more
long winded version is commented in ast_read() along with some caveats.
* The audio frame handling in channel.c:ast_write() is more streamlined
and will automatically adjust any needed translation to changes in the
frame formats sent. Frame formats sent can change for many reasons such
as a recording is being played back or the bridged peer changed the format
it sends. Since it is a normal expectation that sent formats can change,
the codec mismatch warning message is demoted to a debug message.
* Removed the short circuit check in
channel.c:ast_channel_make_compatible_helper(). Two party bridges need to
make channels compatible with each other. However, transfers and moving
channels among bridges can result in otherwise compatible channels having
sub-optimal translation paths if the make compatible check is short
circuited. A result of forcing the reevaluation of channel compatibility
is that the asterisk.conf:transcode_via_slin and codecs.conf:genericplc
options take effect consistently now. It is unfortunate that these two
options are enabled by default and negate some of the benefits to the
changes in channel.c:ast_read() by forcing translation through signed
linear on a two party bridge.
* Improved the softmix bridge technology to better control the translation
of frames to the bridge. All of the incoming translation is now normally
handled by ast_read() instead of splitting any translation steps between
ast_read() and the slin factory. If any frame comes in with an unexpected
format then the translation path in ast_read() is updated for the next
frame and the slin factory handles the current frame translation.
This is the final patch in a series of patches aimed at improving
translation path choices. The other patches are on the following reviews:
https://reviewboard.asterisk.org/r/4600/https://reviewboard.asterisk.org/r/4605/
ASTERISK-24841 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4609/
........
Merged revisions 434671 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434672 65c4cc65-6c06-0410-ace0-fbb531ad65f3
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
POKE is used to check for peer availability; however, in networks with packet
loss, the current calculations may result in POKE expiration times that are too
short. This patch alters the expiration/retry time logic to take into account
the last known qualify round trip time, as opposed to always using a static
value for each peer.
Review: https://reviewboard.asterisk.org/r/4536
ASTERISK-22352 #close
Reported by: Frederic Van Espen
ASTERISK-24894 #close
Reported by: Y Ateya
patches:
poke_noanswer_duration.diff submitted by Y Ateya (License 6693)
........
Merged revisions 434564 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434565 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new configuration parameter, 'calltokenexpiration', that
controls how long before an authentication call token is expired. The default
maintains the RFC specified 10 seconds. Setting it to a higher value may be
useful in lossy networks.
Review: https://reviewboard.asterisk.org/r/4588
ASTERISK-24939 #close
Reported by: Y Ateya
patches:
ctoken_configuration.diff submitted by Y Ateya (License 6693)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This fixes autological comparison warnings in the following:
* chan_skinny: letohl may return a signed or unsigned value, depending on the
macro chosen
* func_curl: Provide a specific cast to CURLoption to prevent mismatch
* cel: Fix enum comparisons where the enum can never be negative
* enum: Fix comparison of return result of dn_expand, which returns a signed
int value
* event: Fix enum comparisons where the enum can never be negative
* indications: tone_data.freq1 and freq2 are unsigned, and hence can never be
negative
* presencestate: Use the actual enum value for INVALID state
* security_events: Fix enum comparisons where the enum can never be negative
* udptl: Don't bother to check if the return value from encode_length is less
than 0, as it returns an unsigned int
* translate: Since the parameters are unsigned int, don't bother checking
to see if they are negative. The cast to unsigned int would already blow
past the matrix bounds.
* res_pjsip_exten_state: Use a temporary value to cache the return of
ast_hint_presence_state
* res_stasis_playback: Fix enum comparisons where the enum can never be
negative
* res_stasis_recording: Add an enum value for the case where the recording
operation is in error; fix enum comparisons
* resource_bridges: Use enum value as opposed to -1
* resource_channels: Use enum value as opposed to -1
Review: https://reviewboard.asterisk.org/r/4533
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4533.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434469 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434470 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434471 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a channel enters the bridging system it is first made compatible with
the bridge and then the bridge technology makes the channel compatible
with the technology. For all but the DAHDI native and softmix bridge
technologies the make channel compatible with the bridge step is an
effective noop because the other technologies allow all audio formats.
For the DAHDI native bridge technology it doesn't matter because it is not
an initial bridge technology and chan_dahdi allows only one native format
per channel. For the softmix bridge technology, it is a noop at best and
harmful at worst because the wrong translation path could be setup if the
channel's native formats allow more than one audio format.
This is an intermediate patch for a series of patches aimed at improving
translation path choices.
* Removed code dealing with the unnecessary step of making the channel
compatible with the bridge.
ASTERISK-24841
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/4600/
........
Merged revisions 434424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434430 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes an access to the peer callnumber that is unprotected by a
corresponding mutex. The peer->callno value can be changed by multiple threads,
and all data inside the iaxs array must be procted by a corresponding lock
of iaxsl.
The patch moves the unprotected access to a location where the mutex is
safely obtained.
Review: https://reviewboard.asterisk.org/r/4599/
ASTERISK-21211 #close
Reported by: Jaco Kroon
patches:
asterisk-11.2.1-iax2_poke-segfault.diff submitted by Jaco Kroon (License 5671)
........
Merged revisions 434291 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434292 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When udpbindaddr is set to the IPv6 bind all address of '::', Asterisk will
attempt to handle both IPv4 and IPv6 addresses, although the information will
be stored in a struct with an AF_INET6 address type. However, the current
NAT handling code won't handle the IPv4 mapped IPv6 addresses correctly.
This patch adds an additional check for the mapped address case, allowing
the NAT code to handle clients even when the address is IPv6.
Review: https://reviewboard.asterisk.org/r/4563/
ASTERISK-18032 #close
Reported by: Christoph Timm
patches:
nat_with_ipv6.diff submitted by Valentin Vidić (License 6697)
........
Merged revisions 434288 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434289 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434290 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes several warnings pointed out by the clang compiler.
* chan_pjsip: Removed check for data->text, as it will always be non-NULL.
* app_minivm: Fixed evaluation of etemplate->locale, which will always
evaluate to 'true'. This patch changes the evaluation to use
ast_strlen_zero.
* app_queue:
- Fixed evaluation of qe->parent->monfmt, which always evaluates to
true. Instead, we just check to see if the dereferenced pointer
evaluates to true.
- Fixed evaluation of mem->state_interface, wrapping it with a call to
ast_strlen_zero.
* res_smdi: Wrapped search_msg->mesg_desk_term with calls to ast_strlen_zero.
Review: https://reviewboard.asterisk.org/r/4541
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4541.patch submitted by dkdegroot (License 6600)
........
Merged revisions 434285 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434286 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434287 65c4cc65-6c06-0410-ace0-fbb531ad65f3
These are fixes for compilation under gcc 5.0...
chan_sip.c: In parse_request needed to make 'lim' unsigned.
inline_api.h: Needed to add a check for '__GNUC_STDC_INLINE__' to detect C99
inline semantics (same as clang).
ccss.c: In ast_cc_set_parm, needed to fix weird comparison.
dsp.c: Needed to work around a possible compiler bug. It was throwing
an array-bounds error but neither
sgriepentrog, rmudgett nor I could figure out why.
manager.c: In action_atxfer, needed to correct an array allocation.
This patch will go to 11, 13, trunk.
Review: https://reviewboard.asterisk.org/r/4581/
Reported-by: Jeffrey Ollie
Tested-by: George Joseph
ASTERISK-24932 #close
........
Merged revisions 434113 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 434114 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@434115 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch fixes some invalid enum conversion warnings caught by clang. In
particular:
* chan_sip: Several functions mixed usage of the st_refresher_param
enum and st_refresher enum. This patch corrects the functions to use the
right enum.
* chan_pjsip: Fixed mixed usage of ast_sip_session_t38state and ast_t38_state.
* strings: Fixed incorrect usage of AO2 flags with strings container.
* res_stasis: Change a return enumeration to stasis_app_user_event_res.
Review: https://reviewboard.asterisk.org/r/4535
ASTERISK-24917
Reported by: dkdegroot
patches:
rb4535.patch submitted by dkdegroot (License 6600)
........
Merged revisions 433746 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 433747 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@433748 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
The res_pjsip modules were manually checking both name and number
presentation values when there is a function that determines the combined
presentation for a party ID struct. The function takes into account if
the name or number components are valid while the manual code rarely
checked if the data was even valid.
* Made use ast_party_id_presentation() rather than manually checking party
ID presentation values.
* Ensure that set_id_from_pai() and set_id_from_rpid() will not return
presentation values other than what is pulled out of the SIP headers. It
is best if the code doesn't assume that AST_PRES_ALLOWED and
AST_PRES_USER_NUMBER_UNSCREENED are zero.
* Fixed copy paste error in add_privacy_params() dealing with RPID
privacy.
* Pulled the id->number.valid test from add_privacy_header() and
add_privacy_params() up into the parent function add_id_headers() to skip
adding PAI/RPID headers earlier.
* Made update_connected_line_information() not send out connected line
updates if the connected line number is invalid. Lower level code would
not add the party ID information and thus the sent message would be
unnecessary.
* Eliminated RAII_VAR usage in send_direct_media_request().
Review: https://reviewboard.asterisk.org/r/4472/
........
Merged revisions 432892 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432893 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Switch logger callid's from AO2 objects to simple integers.
This helps in two ways. Copying integers is faster than
referencing AO2 objects, so this will result in a small
reduction in logger overhead. This also erases the possibility
of an infinate loop caused by an invalid callid in
threadstorage.
ASTERISK-24833 #comment Committed callid conversion to trunk.
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/4466/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432834 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The distinctive ring feature interferes with detecting Caller ID and
appears to have been broken for years. What happens is if you have a
ring-ring cadence as used in the UK you get too many DAHDI events for the
distinctive ring pattern array and Caller ID detection is aborted. I
think when Zapata/DAHDI added the ring begin event it broke distinctive
ring. More events happen than before and the code does no filtering of
which event times are recorded in the pattern array.
* Made distinctive ring only record the ringt count when the ring ends
instead of on just any DAHDI event. Distinctive ring can be ring,
ring-ring, ring-ring-ring, or different ring durations for the up to three
rings.
* Fixed the distinctive ring detection enable (chan_dahdi.conf option
usedistinctiveringdetection) to be per port instead of somewhat per port
and somewhat global. This has been broken since v1.8.
* Fixed using the default distinctive ring context when the detected
pattern does not match any configured dringX patterns. The default
context did not get set when the previous call was a matched distinctive
ring pattern and the current call is not matched. This has been broken
since v1.8.
* Made distinctive ring have no effect on Caller ID detection when it is
disabled. Caller ID detection just monitors for 10 seconds before giving
up.
* Fixed leak of struct callerid_state memory when a polarity reversal
during Caller ID detection causes the incoming call to be aborted.
DAHDI-1143
AST-1545
ASTERISK-24825 #close
Reported by: Richard Mudgett
ASTERISK-17588
Reported by: Daniel Flounders
Review: https://reviewboard.asterisk.org/r/4444/
........
Merged revisions 432530 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432534 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432551 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When Asterisk fails to start a PBX thread for a new channel - for example, when
the maxcalls setting in asterisk.conf is exceeded - we currently send a final
response, and then attempt to send a BYE request to the UA. Since that's all
sorts of wrong, this patch fixes that by setting sipalreadygone on the sip_pvt
such that we don't get stuck sending BYE requests to something that does not
want it.
Note that this patch is a slight modification of the one on ASTERISK-15434.
For clarity, it explicitly calls sipalreadygone with the calls to transmit a
final response.
ASTERISK-21845
ASTERISK-15434 #close
Reported by: Makoto Dei
Tested by: Matt Jordan
patches:
sip-pbxstart-failed.patch uploaded by Makoto Dei (License 5027)
........
Merged revisions 432320 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432321 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432322 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When we receive an SDP as part of an offer/answer for a peer/friend has been
configured to require encryption, and that SDP offer/answer failed to provide
acceptable crypto attributes, we currently issue a WARNING that uses the phrase
"we" and "requested". In this case, both of those terms are ambiguous - the
user will probably think "we" is Asterisk (it most likely isn't) and it may
not be a "request", so much as an SDP that was received in some fashion.
This patch makes the WARNING messages slightly less bad and a bit more
accurate as well.
ASTERISK-23214 #close
Reported by: Rusty Newton
........
Merged revisions 432277 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432278 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432279 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the monitor thread is stopped, its pthread ID is set to a specific value
(AST_PTHREADT_STOP) so that later portions of the code can determine whether
or not it is safe to manipulate the thread. Unfortunately, __sip_reliable_xmit
failed to check for that value, checking instead only for AST_PTHREAD_STOP.
Passing the invalid yet very specific value to pthread_kill causes a crash.
This patch adds a check for AST_PTHREADT_STOP in __sip_reliable_xmit such that
it doesn't attempt to poke the thread if the thread has already been stopped.
ASTERISK-24800 #close
Reported by: JoshE
........
Merged revisions 432198 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 432199 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432200 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses the following problems:
* ari/resource_channels: In ARI, we currently create a format capability
structure of SLIN and apply it to the new channel being created. This was
originally done when the PBX core was used to create the channel, as there
was a condition where a newly created channel could be created without any
formats. Unfortunately, now that the Dial API is being used, this has two
drawbacks:
(a) SLIN, while it will ensure audio will flows, can cause a lot of
needless transcodings to occur, particularly when a Local channel is
created to the dialplan. When no format capabilities are available, the
Dial API handles this better by handing all audio formats to the requsted
channels. As such, we defer to that API to provide the format
capabilities.
(b) If a channel (requester) is causing this channel to be created, we
currently don't use its format capabilities as we are passing in our own.
However, the Dial API will use the requester channel's formats if none
are passed into it, and the requester channel exists and has format
capabilities. This is the "best" scenario, as it is the most likely to
create a media path that minimizes transcoding.
Fixing this simply entails removing the providing of the format capabilities
structure to the Dial API.
* chan_pjsip: Rather than blindly picking the first format in the format
capability structure - which actually *can* be a video or text format - we
select an audio format, and only pick the first format if that fails. That
minimizes the weird scenario where we attempt to transcode between video/audio.
* res_pjsip_sdp_rtp: Applied the joint capapbilites to the format structure.
Since ast_request already limits us down to one format capability once the
format capabilities are passed along, there's no reason to squelch it here.
* channel: Fixed a comment. The reason we have to minimize our requested
format capabilities down to a single format is due to Asterisk's inability
to convey the format to be used back "up" a channel chain. Consider the
following:
PJSIP/A => L;1 <=> L;2 => PJSIP/B
g,u,a g,u,a g,u,a u
That is, we have PJSIP/A dialing a Local channel, where the Local;2 dials
PJSIP/B. PJSIP/A has native format capabilities g722,ulaw,alaw; the Local
channel has inherited those format capabilities down the line; PJSIP/B
supports only ulaw. According to these format capabilities, ulaw is
acceptable and should be selected across all the channels, and no
transcoding should occur. However, there is no way to convey this: when L;2
and PJSIP/B are put into a bridge, we will select ulaw, but that is not
conveyed to PJSIP/A and L;1. Thus, we end up with:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
g g X u u
Which causes g722 to be written to PJSIP/B.
Even if we can convey the 'ulaw' choice back up the chain (which through
some severe hacking in Local channels was accomplished), such that the chain
looks like:
PJSIP/A <=> L;1 <=> L;2 <=> PJSIP/B
u u u u
We have no way to tell PJSIP/A's *channel driver* to Answer in the SDP back
with only 'ulaw'. This results in all the channel structures being set up
correctly, but PJSIP/A *still* sending g722 and causing the chain to fall
apart.
There's a lot of difficulty just in setting this up, as there are numerous
race conditions in the act of bridging, and no clean mechanism to pass the
selected format backwards down an established channel chain. As such, the
best that can be done at this point in time is clarifying the comment.
Review: https://reviewboard.asterisk.org/r/4434/
ASTERISK-24812 #close
Reported by: Matt Jordan
........
Merged revisions 432195 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@432196 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new feature to ARI to redirect a channel to another server,
and fixes a few bugs in PJSIP's handling of the Transfer dialplan
application/ARI redirect capability.
*New Feature*
A new operation has been added to the ARI channels resource, redirect. With
this, a channel in a Stasis application can be redirected to another endpoint
of the same underlying channel technology.
*Bug fixes*
In the process of writing this new feature, two bugs were fixed in the PJSIP
stack:
(1) The existing .transfer channel callback had the limitation that it could
only transfer channels to a SIP URI, i.e., you had to pass
'PJSIP/sip:foo@my_provider.com' to the dialplan application. While this is
still supported, it is somewhat unintuitive - particularly in a world full
of endpoints. As such, we now also support specifying the PJSIP endpoint to
transfer to.
(2) res_pjsip_multihomed was, unfortunately, trying to 'help' a 302 redirect by
updating its Contact header. Alas, that resulted in the forwarding
destination set by the dialplan application/ARI resource/whatever being
rewritten with very incorrect information. Hence, we now don't bother
updating an outgoing response if it is a 302. Since this took a looong time
to find, some additional debug statements have been added to those modules
that update the Contact headers.
Review: https://reviewboard.asterisk.org/r/4316/
ASTERISK-24015 #close
Reported by: Private Name
ASTERISK-24703 #close
Reported by: Matt Jordan
........
Merged revisions 431717 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431718 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
When a SIP device that has its registration stored in RealTime unregisters,
the entry for that device is updated with blank values, i.e., "", indicating
that it is no longer registered. Unfortunately, one of those values that is
'blanked' is the device's port. If the column type for the port is not a
string datatype (the recommended type is integer), an ODBC or database error
will be thrown. MariaDB does not coerce empty strings to a valid integer value.
This patch updates the query run from chan_sip such that it replaces the port
value with a value of '0', as opposed to a blank value. This is the value that
other database backends coerce the empty string ("") to already, and the
handling of reading a RealTime registration value from a backend already
anticipates receiving a port of '0' from the backends.
ASTERISK-24772 #close
Reported by: Richard Miller
patches:
chan_sip.diff uploaded by Richard Miller (License 5685)
........
Merged revisions 431673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431674 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431675 65c4cc65-6c06-0410-ace0-fbb531ad65f3
RFC 3261 sections 8.1.1.8 and 12.1.1 dictate specific
scenarios when we are required to use SIPS URIs in Contact
headers. Asterisk's non-compliance with this could actually
cause calls to get dropped when communicating with clients
that are strict about checking the Contact header.
Both of the SIP stacks in Asterisk suffered from this issue.
This changeset corrects the behavior in chan_sip.
ASTERISK-24646 #close
Reported by Stephan Eisvogel
Review: https://reviewboard.asterisk.org/r/4346
........
Merged revisions 431423 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431424 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431425 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When refreshing (with a small expiration) a registration that was sent to
chan_sip the nonce would be considered stale and reject the registration.
What was happening was that the initial registration's "dialog" still existed
in the dialogs container and upon refresh the dialog match algorithm would
choose that as the "dialog" instead of the newly created one. This occurred
because the algorithm did not check to see if the from tag matched if
authentication info was available after the 401. So, it ended up assuming
the original "dialog" was a match and stopped the search. The old "dialog"
of course had an old nonce, thus the stale nonce message.
This fix attempts to leave the original functionality alone except in the case
of a REGISTER. If a REGISTER is received if searches for an existing "dialog"
matching only on the callid. If the expires value is low enough it will reuse
dialog that is there, otherwise it will create a new one.
ASTERISK-24715 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/4367/
........
Merged revisions 431187 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 431194 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses compilation errors on OS X. It's been a while, so
there's quite a few things.
* Fixed __attribute__ decls in route.h to be portable.
* Fixed htonll and ntohll to work when they are defined as macros.
* Replaced sem_t usage with our ast_sem wrapper.
* Added ast_sem_timedwait to our ast_sem wrapper.
* Fixed some GCC 4.9 warnings using sig*set() functions.
* Fixed some format strings for portability.
* Fixed compilation issues with res_timing_kqueue (although tests still fail
on OS X).
* Fixed menuconfig /sbin/launchd detection, which disables res_timing_kqueue
on OS X).
ASTERISK-24539 #close
Reported by: George Joseph
ASTERISK-24544 #close
Reported by: George Joseph
Review: https://reviewboard.asterisk.org/r/4327/
........
Merged revisions 431092 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@431093 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the SIP registrations were migrated to using ao2 in what was then trunk,
the explicit destruction of the registrations on module reload was removed and
not replaced with an ao2 equivalent. Debugging done by Stefan Engström, the
issue reporter, on ASTERISK-24673 confirmed that the reference in the
registry_list container was being leaked.
Since the purpose of cleanup_all_regs is to prep a registration for
destruction, this function now calls an ao2_callback function callback with the
OBJ_MULTIPLE | OBJ_NODATA | OBJ_UNLINK flags used to remove the registrations.
This cleans up each registration, and also removes it from the registration
container registry_list.
Review: https://reviewboard.asterisk.org/r/4355/
ASTERISK-24640 #close
Reported by: Max Man
ASTERISK-24673 #close
Reported by: Stefan Engström
Tested by: Stefan Engström
........
Merged revisions 430864 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430866 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling ast_channel_bridge_peer() cannot be done while holding any channel
locks. The reported issue hit the deadlock in chan_iax2, but an audit of
the ast_channel_bridge_peer() calls found three more locations where the
same deadlock can occur.
* Made CHANNEL(peer), res_fax, and the SNMP agent not call
ast_channel_bridge_peer() with any channel locked. For CHANNEL(peer) I
had to rework the logic to not hold the channel lock.
* Made chan_iax2 no longer call ast_channel_bridge_peer(). It was done
for legacy reasons that no longer apply.
* Removed the iax.conf forcejitterbuffer option. It is now always enabled
when the jitterbuffer option is enabled. If you put a jitter buffer on a
channel it will be on the channel.
ASTERISK-24600 #close
Reported by: Jeff Collell
Review: https://reviewboard.asterisk.org/r/4342/
........
Merged revisions 430817 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430819 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Different clients react differently to being told that a blind transfer
has failed. Some will simply send a BYE and be done with it. Others will
attempt to reinvite themselves back onto the call.
In the latter case, we were creating a new channel and then leaving it to
sit forever doing nothing. With this code change, that new channel will
not be created and the dialog with the transferring channel will be cleaned
up properly.
ASTERISK-24624 #close
Reported by Zane Conkle
Review: https://reviewboard.asterisk.org/r/4339
........
Merged revisions 430714 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430715 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The 'pjsip_get_dest_info' function is used to determine if the signaling transport
of the dialog is secure or not. This function was added in PJSIP 2.3 and does not
exist in earlier versions.
This configure check allows Asterisk to build and run with older versions at the
loss of the 'secure' argument for the PJSIP CHANNEL dialplan function. Usage of
this argument will require upgrading to PJSIP 2.3.
ASTERISK-24665 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/4329/
........
Merged revisions 430546 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@430547 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
Given the following scenario:
* Three SIP phones (A, B, C), all communicating via a proxy with Asterisk
* A call is established between A and B. B performs a SIP attended transfer of
A to C. B sets the call on hold (A is hearing MOH) and dials the extension of
C. While phone C is ringing, B transfers the call (that is, what we typically
call a 'blond transfer').
* When the transfer completes, A hears the ringing of phone C, while B is idle.
In the SIP messaging for the above scenario, a REFER request is sent to
transfer the call. When "sendrpid=yes" is set in sip.conf, Asterisk may send an
UPDATE request to phone C to update party information. This update is sent
directly to phone C, not through the intervening proxy. This has the unfortunate
side effect of providing route information, which is then set on the sip_pvt
structure for C. If someone (e.g. B) is trying to get the call back (through a
directed pickup), Asterisk will send a CANCEL request to C. However, since we
have now updated the route set, the CANCEL request will be sent directly to C
and not through the proxy. The phone ignores this CANCEL according to RFC3261
(Section 9.1).
This patch updates reqprep such that the route is not updated if an UPDATE
request is being sent while the INVITE state is INV_PROCEEDING or
INV_EARLY_MEDIA. This ensures that a subsequent CANCEL request is still sent
to the correct location.
Review: https://reviewboard.asterisk.org/r/4279
ASTERISK-24628 #close
Reported by: Karsten Wemheuer
patches:
issue.patch uploaded by Karsten Wemheuer (License 5930)
........
Merged revisions 429982 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429983 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429984 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When the configuration section scheme of chan_dahdi.conf is used (keyword
dahdichan instead of channel) all setvar= options are completely ignored.
No variable defined this way appears in the created DAHDI channels.
* Move the clearing of setvar values to after the deferred processing of
dahdichan.
AST-1378 #close
Reported by: Guenther Kelleter
Patch by: Guenther Kelleter
........
Merged revisions 429825 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429829 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For the featdmf signaling mode the incoming MF Caller-ID information is
formatted as follows: *${CALLERID(ani2)}${CALLERID(ani)}#*${EXTEN}#
Rather than discarding the ani2 digits, populate the CALLERID(ani2) value
with what is received instead.
AST-1368 #close
Reported by: Denis Martinez
Patches:
extract_ani2_for_featdmf_v11.patch (license #5621) patch uploaded by Richard Mudgett
........
Merged revisions 429783 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429784 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429785 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, we were using the PJSIP dialog's secure flag
to determine if a secure transport was being used. Unfortunately,
the dialog's secure flag was only set if a SIPS URI were in use,
as required by RFC 3261 sections 12.1.1 and 12.1.2. What we're interested
in is not dialog security, but transport security. This code change
switches to a model where we use the dialog's target URI to determine
what transport would be used to communicate, and then check if that
transport is secure.
AST-1450 #close
Reported by John Bigelow
Review: https://reviewboard.asterisk.org/r/4277
........
Merged revisions 429739 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429740 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r413586 (1.8) various casts were added to silence gcc 4.10 warnings.
Those fixes included things like:
-out += sprintf(out, "%%%02X", (unsigned char) *ptr);
+out += sprintf(out, "%%%02X", (unsigned) *ptr);
That works for low ascii characters, but for the high range that yields
e.g. FFFFFFC3 when C3 is expected.
This changeset:
- fixes those casts to use the 'hh' unsigned char modifier instead
- consistently uses %02x instead of %2.2x (or other non-standard usage)
- adds a few 'h' modifiers in various places
- fixes a 'replcaes' typo
- dev/urandon typo (in 13+ patch)
Review: https://reviewboard.asterisk.org/r/4263/
ASTERISK-24619 #close
Reported by: Stefan27 (on IRC)
........
Merged revisions 429673 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429674 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429675 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429683 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Previously when SRTP was enabled on a channel it was not possible
to switch to T.38 as no crypto attributes would be present.
This change makes it so it is now possible. If a T.38 re-invite
comes in SRTP is terminated since in practice you can't encrypt
a UDPTL stream. Now... if we were doing T.38 over RTP (which
does exist) then we'd have a chance but almost nobody does that so
here we are.
ASTERISK-24449 #close
Reported by: Andreas Steinmetz
patches:
udptl-ignore-srtp-v2.patch submitted by Andreas Steinmetz (license 6523)
........
Merged revisions 429632 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 429633 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429634 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When direct media is enabled and a pjsip channel is answered a race would occur
between the handling of the answer and bridge setup. Sometimes the media
negotiation would take place after the native bridge was setup. This resulted
in a NULL media address, which in turn resulted in Asterisk using its address
as the remote media address when sending a reinvite. This patch makes the
chan_pjsip answer handler synchronous thus alleviating the race condition (the
bridge won't start setting things up until after it returns).
ASTERISK-24563 #close
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4257/
........
Merged revisions 429477 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429478 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Given the scenario where a PJSIP channel is in a native RTP bridge with direct
media and the channel is then hung up the code will currently re-INVITE the channel
back to Asterisk and send a BYE at the same time. Many SIP implementations dislike
this greatly.
This change makes it so that if a re-INVITE transaction is in progress the BYE
is queued to occur after the completion of the transaction (be it through normal
means or a timeout).
Review: https://reviewboard.asterisk.org/r/4248/
........
Merged revisions 429409 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429410 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When endpoints with direct_media enabled, behind a firewall (Asterisk on a
separate network) and were bridged sometimes Asterisk would send the ip
address of the firewall in the sdp to one of the phones in the reinvite
resulting in one way audio. When sending the reinvite Asterisk will retrieve
the media address from the associated rtp instance, but if frames were being
read this can be overwritten with another address (in this case the
firewall's). This patch ensures that Asterisk uses the original device
address when using direct media.
ASTERISK-24563
Reported by: Steve Pitts
Review: https://reviewboard.asterisk.org/r/4216/
........
Merged revisions 429195 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 429196 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@429197 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Prior to this patch, all Stasis subscriptions would receive a dedicated
thread for servicing published messages. In contrast, prior to r400178
(see review https://reviewboard.asterisk.org/r/2881/), the subscriptions
shared a thread pool. It was discovered during some initial work on Stasis
that, for a low subscription count with high message throughput, the
threadpool was not as performant as simply having a dedicated thread per
subscriber.
For situations where a subscriber receives a substantial number of messages
and is always present, the model of having a dedicated thread per subscriber
makes sense. While we still have plenty of subscriptions that would follow
this model, e.g., AMI, CDRs, CEL, etc., there are plenty that also fall into
the following two categories:
* Large number of subscriptions, specifically those tied to endpoints/peers.
* Low number of messages. Some subscriptions exist specifically to coordinate
a single message - the subscription is created, a message is published, the
delivery is synchronized, and the subscription is destroyed.
In both of the latter two cases, creating a dedicated thread is wasteful (and
in the case of a large number of peers/endpoints, harmful). In those cases,
having shared delivery threads is far more performant.
This patch adds the ability of a subscriber to Stasis to choose whether or not
their messages are dispatched on a dedicated thread or on a threadpool. The
threadpool is configurable through stasis.conf.
Review: https://reviewboard.asterisk.org/r/4193
ASTERISK-24533 #close
Reported by: xrobau
Tested by: xrobau
........
Merged revisions 428681 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428687 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428688 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Due to the serialized architecture of chan_pjsip there exists a race condition where a CANCEL may
be received and processed before responses (such as 180 Ringing, 183 Session Progress, and 200 OK)
are sent. Since the session is in an unexpected state PJSIP will assert when this is attempted.
This change makes it so that these responses are not sent on disconnected sessions.
ASTERISK-24471 #close
Reported by: yaron nahum
........
Merged revisions 428301 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 428302 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@428303 65c4cc65-6c06-0410-ace0-fbb531ad65f3
For chan_motif the direct return value of the underlying config options framework
was passed back. This can relay various states which the module loader would not
interpet as success. It has been changed so only on errors will it report back
an error.
For chan_pjsip the code implemented a dummy reload function which always
returned an error. This has been removed as all configuration is held within
res_pjsip instead.
ASTERISK-23651 #close
Reported by: Rusty Newton
........
Merged revisions 427981 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427982 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427983 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Configuration of DTLS in the general section will be applied to any users
or peers. If configuration exists at their level it overrides the general
section values.
ASTERISK-24128 #close
Reported by: Michael K.
patches:
dtls_default_settings.patch submitted by Michael K. (license 6621)
Review: https://reviewboard.asterisk.org/r/3867/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427950 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r227276, a while loop was turned into a for loop. Unfortunately, a portion
of the while loop was left in the code such that, when a static gateway is
encountered in the list of MGCP gateways, the next gateway would be skipped.
At best, we would simply flip past a gateway; at worst, this could lead to a
crash.
ASTERISK-24500 #close
Reported by: Xavier Hienne
patches:
chan_mgcp.patch uploaded by Xavier Hienne (License 6657)
........
Merged revisions 427613 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 427614 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 427615 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427616 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This change adds an option, moh_passthrough, that when enabled will pass
hold and unhold requests through using a SIP re-invite. When placing on
hold a re-invite with sendonly will be sent and when taking off hold a
re-invite with sendrecv will be sent. This allows remote servers to handle
the musiconhold instead of the local Asterisk instance being responsible.
Review: https://reviewboard.asterisk.org/r/4103/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@427112 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Calling PJSIP_MEDIA_OFFER on a non-PJSIP channel is hazardous to your health.
It will treat the channels as a PJSIP channel, eventually hitting an ao2 error,
FRACKing on assertion error, and quite likely crashing.
This patch adds checks to the read/write callbacks that ensure that the channel
technology is of type 'PJSIP' before attempting to operate on the channel.
#SIPit31
ASTERISK-24382 #close
Reported by: Matt Jordan
........
Merged revisions 424621 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424622 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424623 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Performing a directed call pickup resulted in a deadlock when PJSIP
channels were involved.
A masquerade needs to hold onto the channel locks while it swaps channel
information between the two channels involved in the masquerade. With
PJSIP channels, the fixup routine needed to push a fixup task onto the
PJSIP channel's serializer. Unfortunately, if the serializer was also
processing a task that needed to lock the channel, you get deadlock.
* Added a new control frame that is used to notify the channels that a
masquerade is about to start and when it has completed.
* Added the ability to query taskprocessors if the current thread is the
taskprocessor thread.
* Added the ability to suspend/unsuspend the PJSIP serializer thread so a
masquerade could fixup the PJSIP channel without using the serializer.
ASTERISK-24356 #close
Reported by: rmudgett
Review: https://reviewboard.asterisk.org/r/4034/
........
Merged revisions 424471 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 424472 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@424473 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This gets rid of most old libc free/malloc/realloc and replaces them
with ast_free and friends. When compiling with MALLOC_DEBUG you'll
notice it when you're mistakenly using one of the libc variants. For
the legacy cases you can define WRAP_LIBC_MALLOC before including
asterisk.h.
Even better would be if the errors were also enabled when compiling
without MALLOC_DEBUG, but that's a slightly more invasive header
file change.
Those compiling addons/format_mp3 will need to rerun
./contrib/scripts/get_mp3_source.sh.
ASTERISK-24348 #related
Review: https://reviewboard.asterisk.org/r/4015/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423978 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Outgoing PJSIP calls can result in non-negotiated formats listed in the
channel's native formats if video formats are listed in the endpoint's
configuration. The resulting call could then use a non-negotiated format
resulting in one way audio.
* Simplified the update of session->req_caps in set_caps(). Why do
something in five steps when only one is needed?
AFS-162 #close
Review: https://reviewboard.asterisk.org/r/4000/
........
Merged revisions 423561 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423563 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This module supports sending both unicast and multicast RTP
to a specified target. Multicast functionality is the same as
chan_multicast_rtp was. In the case of unicast a specific
IP address and port can be specified, along with optional RTP
engine and format in the form of:
UnicastRTP/<ip address>:<port>/<engine>/<format>
This can be useful for sending a copy of a media stream to
another application for processing.
Review: https://reviewboard.asterisk.org/r/3981/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@423004 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Testsuite tests will occasionally fail because on reception of a 200 OK SIP response,
an AST_CONTROL_ANSWER frame is queued prior to when media has finished being
negotiated. This is because session supplements are called into before PJSIP's
inv_session code has told us that media has been updated. Sometimes the queued answer
frame is handled by the PBX thread before the ensuing media negotiations occur, causing
a test failure.
As it turns out, there is another place that session supplements could be called into, which is
after media has finished getting negotiated. What this commit introduces is a means for session
supplements to indicate when they wish to be called into when handling an incoming SIP response.
By default, all session supplements will be run at the same point that they were prior to this
commit. However, session supplements may indicate that they wish to be handled earlier than
normal on redirects, or they may indicate they wish to be handled after media has been negotiated.
In this changeset, two session supplements have been updated to indicate a preference for when
they should be run: res_pjsip_diversion executes before handling redirection in order to get
information from the Diversion header, and chan_pjsip now handles responses to INVITEs after
media negotiation to fix the race condition mentioned previously.
ASTERISK-24212 #close
Reported by Matt Jordan
Review: https://reviewboard.asterisk.org/r/3930
........
Merged revisions 422536 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422542 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422543 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The reporter on the issue found some issues when upgrading from version 10 to 11
on 55 hosts.
Two situations that can occur with dynamic registrations.
1. With dnsmgr disabled, if the host is not resolvable we are not trying to
resolve the host again when it is time to attempt to register again. This
results in never registering to the host.
2. With dnsmgr enabled, when the host is temporarily not resolvable the
address is set to 0.0.0.0:0 and then when the host is resolvable the port
is not being restored and stays set to 0.
This patch resolves these two issues by:
* Storing the hostname so that it can be used for resolving with DNS.
* Resolve the hostname on the next scheduled attempt to register.
* Storing the port used to reach the host so that when the hostname is
resolvable again, we can set the port again if the port is still unset after
looking up the host.
ASTERISK-23767 #close
Reported by: David Herselman
Tested by: David Herselman, Michael L. Young
Patches:
asterisk-23767-dns_reg_retry_and_set_port_11_v3.diff
uploaded by Michael L. Young (license 5026)
Review: https://reviewboard.asterisk.org/r/3856/
........
Merged revisions 422274 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 422275 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 422276 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422277 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Users now have the ability to bind the rtpengine instance to a specific IP
address. For example, you want chan_sip (call control) on eth0 but rtp (media)
on eth1.
ASTERISK-24280 #close
Reported by: Paul Belanger
Tested by: Paul Belanger
Review: https://reviewboard.asterisk.org/r/3952/
Patches:
rtpengine.diff uploaded by Paul Belanger
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@422241 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This code originally worked around an issue within res_rtp_asterisk itself.
The wrong socket was being used for the STUN check for RTCP, causing the
port to be the same as RTP. This was subsequently fixed and the RTCP port
provided for the ICE candidate is correct and does not need to be incremented.
ASTERISK-23997 #close
Reported by: Badalian Vyacheslav
Patches:
plus1.diff submitted by Badalian Vyacheslav (license 5249)
........
Merged revisions 421909 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 421910 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421911 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421912 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On a SIP reinvite that changes media strams, the PJSIP channel driver was
flooding the log with "Asked to transmit frame type %s, while native
formats is %s" warnings.
* Fixes PJSIP not setting up translation paths when the formats change on
a reinvite. AFS-63 was effectively reintroduced because of the media
formats work. res_pjsip_sdp_rtp.c:set_caps()
* Improved the unexpected frame format WARNING message to include more
information.
* Added protective locking while altering formats on a channel. Reworked
set_format() to simplify and protect the formats under manipulation.
* Restored some code that got lost in the media_formats work.
(channel.c:set_format() and res_pjsip_sdp_rtp.c:set_caps())
AFS-137 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3906/
........
Merged revisions 421645 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421646 65c4cc65-6c06-0410-ace0-fbb531ad65f3
A calls B
B answers
B SIP attended transfers to C
C answers, B and C can see each other's connected line information
B completes the transfer
A has number but no name connected line information about C
while C has the full information about A
I examined the incoming and outgoing party id information handling of
chan_pjsip and found several issues:
* Fixed ast_sip_session_create_outgoing() not setting up the configured
endpoint id as the new channel's caller id. This is why party A got
default connected line information.
* Made update_initial_connected_line() use the channel's CALLERID(id)
information. The core, app_dial, or predial routine may have filled in or
changed the endpoint caller id information.
* Fixed chan_pjsip_new() not setting the full party id information
available on the caller id and ANI party id. This includes the configured
callerid_tag string and other party id fields.
* Fixed accessing channel party id information without the channel lock
held.
* Fixed using the effective connected line id without doing a deep copy
outside of holding the channel lock. Shallow copy string pointers can
become stale if the channel lock is not held.
* Made queue_connected_line_update() also update the channel's
CALLERID(id) information. Moving the channel to another bridge would need
the information there for the new bridge peer.
* Fixed off nominal memory leak in update_incoming_connected_line().
* Added pjsip.conf callerid_tag string to party id information from
enabled trust_inbound endpoint in caller_id_incoming_request().
AFS-98 #close
Reported by: Mark Michelson
Review: https://reviewboard.asterisk.org/r/3913/
........
Merged revisions 421400 from http://svn.asterisk.org/svn/asterisk/branches/12
........
Merged revisions 421403 from http://svn.asterisk.org/svn/asterisk/branches/13
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@421404 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed the iax.conf bandwidth option. This is the root cause of
ASTERISK-24150.
* Added checks in iax2_request() to ensure that there are actual formats
requested for the new channel to prevent any more fracks from issues like
ASTERISK-24150. This is a consequence of the iax.conf bandwidth option
not working.
* Fixed struct iax2_codec_pref.order member size mismatch issue when
converting to and from the codec preference order list passed over the
wire. In addition the values sent over the wire are now compatible with
previous Asterisk versions.
* Fixed several issues dealing with the struct iax2_codec_pref members.
Off-by-one, array limit errors, and the order/framing members always need
to be updated together.
* Made iax2_request() setup the channel's native format preference order
according to the user's wishes. The new media format strategy needs the
order specified earler.
* Fixed usage of ast_format_compatibility_bitfield2format(). The function
can return NULL if the bitfield was not associated with a function.
* Deleted dead code iax2_codec_pref_getsize() and
iax2_codec_pref_setsize().
* Made iax2_parse_allow_disallow() and iax2_codec_pref_string() call
iax2_codec_pref_to_cap() instead of inlining it.
* Made IAX_CAPABILITY_MEDBANDWIDTH, IAX_CAPABILITY_LOWBANDWIDTH, and
IAX_CAPABILITY_LOWFREE constants again as they were in Asterisk v1.8.
* Renamed prefs to prefs_global so it won't get confused with the local
pref versions.
* Fixed too small buffer in handle_cli_iax2_show_peer().
* Fixed ast_cli() calls in handle_cli_iax2_show_peer() to output complete
lines.
* Changed struct create_addr_info.prefs to be struct iax2_codec_pref as an
optimization so iax2_request() and iax2_call() do less work.
* Fixed a potential deadlock in ast_iax2_new() on an off-nominal path when
the pbx could not get started.
* Made set_config() setup a local prefs list along side the local
capability format bitfield. Once the config is loaded, then the local
copies are put into the global versions.
* Fix unininialized codec_buf in function_iaxpeer().
ASTERISK-24150 #close
Reported by: Scott Griepentrog
Review: https://reviewboard.asterisk.org/r/3890/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420364 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
r420089 | mjordan | 2014-08-05 15:10:52 -0500 (Tue, 05 Aug 2014) | 72 lines
ARI: Add channel technology agnostic out of call text messaging
This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp). Messages are sent using the
endpoints resource, and can be sent directly through that resource, or to a
particular endpoint.
For example, the following would send the message "Hello there" to PJSIP
endpoint alice with a display URI of sip:asterisk@mycooldomain.org:
ari/endpoints/sendMessage?to=pjsip:alice&from=sip:asterisk@mycooldomain.org&body=Hello+There
This is equivalent to the following as well:
ari/endpoints/PJSIP/alice/sendMessage?from=sip:asterisk@mycooldomain.org&body=Hello+There
Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.
Inbound messages can now be received over ARI as well. An ARI application that
subscribes to endpoints will receive messages from those endpoints:
{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" <sip:alice@127.0.0.1>",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}
The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has
two callbacks: one to determine if the handler has a destination for the
message, and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them.
Various other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when
the lifetime of things is well defined and the number of things is very
small.
res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.
Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the
fix for that as well.
Review: https://reviewboard.asterisk.org/r/3726
ASTERISK-23692 #close
Reported by: Matt Jordan
ASTERISK-23969 #close
Reported by: Andrew Nagy
........
r420090 | mjordan | 2014-08-05 15:16:37 -0500 (Tue, 05 Aug 2014) | 2 lines
Remove automerge properties :-(
........
r420097 | mjordan | 2014-08-05 16:36:25 -0500 (Tue, 05 Aug 2014) | 2 lines
test_message: Fix strict-aliasing compilation issue
........
Merged revisions 420089-420090,420097 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@420098 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds a new module to Asterisk, res_hep_rtcp. The module subscribes
to the RTCP topics in Stasis and receives RTCP information back from the
message bus. It encodes into HEPv3 packets and sends the information to the
res_hep module for transmission.
Using this, someone with a Homer server can get live call quality monitoring
for all RTP-based channels in their Asterisk 12+ systems.
In addition, there were a few bugs in the RTP engine, res_rtp_asterisk, and
chan_pjsip that were uncovered by the tests written for the Asterisk Test
Suite. This patch fixes the following:
1) chan_pjsip failed to set its channel unique ids on its RTP instance on
outbound calls. It now does this in the appropriate location, in the
serialized call callback.
2) The rtp_engine was overflowing some values when packed into JSON.
Specifically, some longs and unsigned ints can't be be packed into integer
values, for obvious reasons. Since libjansson only supports integers,
floats, strings, booleans, and objects, we print these values into strings.
3) res_rtp_asterisk had a few problems:
(a) it would emit a source IP address of 0.0.0.0 if bound to that IP
address. We now use ast_find_ourip to get a better IP address, and
properly marshal the result into an ast_strdupa'd string.
(b) Reports can be generated with no report bodies. In particular, this
occurs when a sender is transmitting information to a receiver (who
will send no RTP back to the sender). As such, the sender has no report
body for what it received. We now properly handle this case, and the
sender will emit SR reports with no body. Likewise, if we receive an
RTCP packet with no report body, we will still generate the appropriate
events.
ASTERISK-24119 #close
........
Merged revisions 419823 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419825 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In Asterisk, it is possible for a device to have a status of ONHOLD. This is
not typically an easy thing to determine, as a channel being on hold is not
a direct channel state. Typically, this has to be calculated outside of the
core independently in channel drivers, notably, chan_sip and chan_pjsip. Both
of these channel drivers already have to calculate device state in a fashion
more complex than the core can handle, as they aggregate all state of all
channels associated with a peer/endpoint; they also independently track
whether or not one of those channels is currently on hold and mark the device
state appropriately.
In 12+, we now have the ability to report an AST_DEVICE_ONHOLD state for all
channels that defer their device state to the core. This is due to channel hold
state actually now being tracked on the channel itself. If a channel driver
defers its device state to the core (which many, such as DAHDI, IAX2, and
others do in most situations), the device state core already goes out to get a
channel associated with the device. As such, it can now also factor the channel
hold state in its calculation.
This patch adds this logic to the device state core. It also uses an existing
mapping between device state and channel state to handle more channel states.
chan_pjsip has been updated slightly as well to make use of this (as it was,
for some reason, reporting a channel state of BUSY as a device state of INUSE,
which feels slightly wrong).
Review: https://reviewboard.asterisk.org/r/3771/
ASTERISK-24038 #close
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419358 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch serves two purposes:
(1) It fixes some bugs with endpoint subscriptions not reporting all of the
channel events
(2) It serves as the preliminary work needed for ASTERISK-23692, which allows
for sending/receiving arbitrary out of call text messages through ARI in a
technology agnostic fashion.
The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an
arbitrary technology defined URI. This is less straight forward, as
endpoints are formed from a tech + resource pair. We don't have a
mechanism to note that a technology that *may* have endpoints exists.
This patch provides such a mechanism, and fixes a few bugs along the way.
The first major bug this patch fixes is the forwarding of channel messages
to their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed
most of the interesting bits (such as channel creation, destruction, state
changes, etc.)
(2) Channels weren't associated with their endpoint until after creation.
This resulted in endpoints missing the channel creation message, which
limited the usefulness of the subscription in the first place (a major use
case being 'tell me when this endpoint has a channel'). Unfortunately,
this meant another parameter to ast_channel_alloc. Since not all channel
technologies support an ast_endpoint, this patch makes such a call
optional and opts for a new function, ast_channel_alloc_with_endpoint.
When endpoints are created, they will implicitly create a technology endpoint
for their technology (if one does not already exist). A technology endpoint is
special in that it has no state, cannot have channels created for it, cannot
be created explicitly, and cannot be destroyed except on shutdown. It does,
however, have all messages from other endpoints in its technology forwarded to
it.
Combined with the bug fixes, we now have Stasis messages being properly
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar),
where bar has a single channel associated with it and foo has two channels
associated with it. The messages would be forwarded as follows:
channel PJSIP/foo-1 --
\
--> endpoint PJSIP/foo --
/ \
channel PJSIP/foo-2 -- \
---- > endpoint PJSIP
/
channel PJSIP/bar-1 -----> endpoint PJSIP/bar --
ARI, through the applications resource, can:
- subscribe to endpoint:PJSIP/foo and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
- subscribe to endpoint:PJSIP/bar and get notifications for channels
PJSIP/bar-1 and endpoint PJSIP/bar
- subscribe to endpoint:PJSIP and get notifications for channels
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar
Note that since endpoint PJSIP never changes, it never has events itself. It
merely provides an aggregation point for all other endpoints in its technology
(which in turn aggregate all channel messages associated with that endpoint).
This patch also adds endpoints to res_xmpp and chan_motif, because the actual
messaging work will need it (messaging without XMPP is just sad).
Review: https://reviewboard.asterisk.org/r/3760/
ASTERISK-23692
........
Merged revisions 419196 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419203 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The iax2_best_codec function was changed to convert the formats
into a format compatibilities structure and grab the first
format from it. The resulting order differs from the previous
order of iax2_best_codec which causes unexpected formats to
get chosen (such as g723).
This commit brings back the old behavior of iax2_best_codec by
having a specified preference list.
Review: https://reviewboard.asterisk.org/r/3835/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419180 65c4cc65-6c06-0410-ace0-fbb531ad65f3
After merging the media formats branch, chan_iax2 was discarding
codec preferences for the purpose of choosing which codec a
channel would use once a call started. This patch restores the
Asterisk 1.8-12 codec choice behaviors.
ASTERISK-23958 #close
Review: https://reviewboard.asterisk.org/r/3800/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@419109 65c4cc65-6c06-0410-ace0-fbb531ad65f3
progressinband=never in sip.conf is easily defeated if an onward trunk sends a
progress indication of its own. This is almost certain to happen if the onward
trunk is ISDN or IAX as these technologies send a progress indication even if
early media is not required. This progress message is passed to the caller,
and causes the "never" option to be rather badly named.
This patch changes the behaviour of this setting in the following ways:
1) In sip_write(), do not pass the media unless we have either progressed
beyond INV_EARLY_MEDIA, or we are in INV_EARLY_MEDIA state, and early
media is both set-up and wanted. This helps resolve double-ringing on some
buggy handsets.
2) In sip_indicate(), if we see AST_CONTROL_PROGRESS, but
SIP_PROG_INBAND_NEVER is set, send a 180 Ringing instead to avoid implicitly
enabling early media. Avoid sending double ring indications.
NOTE: the meaning of the SIP_PROGRESS_SENT flag changes slightly in this patch
to also encapsulate the fact that a channel has *sent or received* a 183
Progress indication. This makes the updated code in sip_write() much more
simple.
Review: https://reviewboard.asterisk.org/r/3700
ASTERISK-23972 #close
Reported by: Steve Davies
patches:
inband_never_present_early_media2 uploaded by Steve Davies (License 5012)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418868 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Most channel drivers let you specify a default accountcode to be set on
channels associated with a particular peer/endpoint/object. Prior to this
patch, chan_pjsip/res_pjsip did not support such a setting.
This patch adds a new setting to the res_pjsip endpoint object, 'accountcode'.
When a channel is created that is associated with an endpoint with this value
set, the channel will automatically have its accountcode property set to the
value configured for the endpoint.
Review: https://reviewboard.asterisk.org/r/3724/
ASTERISK-24000 #close
Reported by: Matt Jordan
........
Merged revisions 418756 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418757 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This corrects two issues with the extra field information in Asterisk
12+ in channel event logs.
It is possible to inject custom values into the dialstatus provided by
ast_channel_dial_type() Stasis messages that fall outside the
enumeration allowed for the DIALSTATUS channel variable. CEL now
filters for the allowed values and ignores other values.
The "hangupsource" extra field key is always blank if the far end
channel is a chan_pjsip channel. This is because the hangupsource is
never set for the pjsip channel driver. This change sets the
hangupsource whenever a hangup is queued for chan_pjsip channels.
This corrects an issue with the pjsip channel driver where the
hangupcause information was not being set properly.
Review: https://reviewboard.asterisk.org/r/3690/
........
Merged revisions 418071 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418084 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Billing records are fair,
To get paid is quite bright,
You should really use ODBC;
Good-bye cdr_sqlite.
Microsoft did once push H.323,
Hell, we all remember NetMeeting.
But try to compile chan_h323 now
And you will take quite a beating.
The XMPP and SIP war was fierce,
And in the distant fray
Was birthed res_jabber/chan_jingle;
But neither to stay.
For everyone did care and chase what Google professed.
"Free Internet Calling" was what devotees cried,
But Google did change the specs so often
That the developers were happy the day chan_gtalk died.
And then there was that odd application
Dedicated to the Polish tongue.
app_saycountpl was subsumed by Say;
One could say its bell was rung.
To read and parse a file from the dialplan
You could (I guess) use an application.
app_readfile did fill that purpose, but I think
A function is perhaps better in its creation.
Barging is rude, I'm not sure why we do it.
Inwardly, the caller will probably sigh.
But if you really must do it,
Don't use app_dahdibarge, use ChanSpy.
We all despise the sound of tinny robots
It makes our queues so cold.
To control such an abomination
It's better to not use Wait/SetMusicOnHold.
It's often nice to know properties of a channel
It makes our calls right
We have a nice function called CHANNEL
And so SIPCHANINFO is sent off into the night.
And now things get odd;
Apparently one could delimit with a colon
Properties from the SIPPEER function!
Commas are in; all others are done.
Finally, a word on pipes and commas.
We're sorry. We can't say it enough.
But those compatibility options in asterisk.conf;
To maintain them forever was just too tough.
This patch removes:
* cdr_sqlite
* chan_gtalk
* chan_jingle
* chan_h323
* res_jabber
* app_saycountpl
* app_readfile
* app_dahdibarge
It removes the following applications/functions:
* WaitMusicOnHold
* SetMusicOnHold
* SIPCHANINFO
It removes the colon delimiter from the SIPPEER function.
Finally, it also removes all compatibility options that were configurable from
asterisk.conf, as these all applied to compatibility with Asterisk 1.4 systems.
Review: https://reviewboard.asterisk.org/r/3698/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@418019 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The new inband_on_setup_ack option causes Asterisk to assume inband audio
may be present when a SETUP_ACKNOWLEDGE message is received.
Q.931 Section 5.1.3 says that in scenarios with overlap dialing, when a
dialtone is sent from the network side, progress indicator 8 "Inband info
now available" MAY be sent to the CPE if no digits were received with the
SETUP. It is thus implied that the ie is mandatory if digits came with
the SETUP and dialtone is needed. This option should be enabled, when the
network sends dialtone and you want to hear it, but the network doesn't
send the progress indicator when needed.
NOTE: For Q.SIG setups this option should be enabled when outgoing overlap
dialing is also enabled because Q.SIG does not send the progress indicator
with the SETUP ACK.
The commit -r413714 (AST-1338) which causes this issue was dealing with a
SIP-to-ISDN interoperability issue.
This commit is a merge of the two patches indicated below.
ASTERISK-23897 #close
Reported by: Pavel Troller
Patches:
pri-4.diff (license #6302) patch uploaded by Pavel Troller
jira_asterisk_23897_v11.patch (license #5621) patch uploaded by rmudgett
Review: https://reviewboard.asterisk.org/r/3633/
........
Merged revisions 417956 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417957 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417958 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417976 65c4cc65-6c06-0410-ace0-fbb531ad65f3
........
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 and chan_pjsip 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/
Review: https://reviewboard.asterisk.org/r/3686/
........
Merged revisions 417678 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417679 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is essentially a backport of a small portion of r397526 from
ASTERISK-21981. In that patch, pass through support and format attribute
negotiation was added for Opus. Part of that included being more tolerant to
whitespace in the fmtp line of an SDP; that part of the patch is being
applied here.
As the author of the backport pointed out, in SDP, the fmtp line is allowed to
include whitespace between attributes. RFC 3267 chapter 8.3 (from 2001)
includes an example for this. This was not removed in the updated RFC 4867 in
2007.
Review: https://reviewboard.asterisk.org/r/3658
#ASTERISK-23916 #close
Reported by: Alexander Traud
patches:
sdpFMTPspace_Asterisk11.patch uploaded by Alexander Traud (License 6520)
........
Merged revisions 417587 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 417588 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417589 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417590 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a client takes a long time to process information received from Asterisk,
a write operation using fwrite may fail to write all information. This causes
the underlying file stream to be in an unknown state, such that the socket
must be disconnected. Unfortunately, there are two problems with this in
Asterisk's existing websocket code:
1. Periodically, during the read loop, Asterisk must write to the connected
websocket to respond to pings. As such, Asterisk maintains a reference to
the session during the loop. When ast_http_websocket_write fails, it may
cause the session to decrement its ref count, but this in and of itself
does not break the read loop. The read loop's write, on the other hand,
does not break the loop if it fails. This causes the socket to get in a
'stuck' state, preventing the client from reconnecting to the server.
2. More importantly, however, is that the fwrite in ast_http_websocket_write
fails with a large volume of data when the client takes awhile to process
the information. When it does fail, it fails writing only a portion of
the bytes. With some debugging, it was shown that this was failing in a
similar fashion to ASTERISK-12767. Switching this over to ast_careful_fwrite
with a long enough timeout solved the problem.
Note that this version of the patch, unlike r417310 in Asterisk 11, exposes
configuration options beyond just chan_sip's sip.conf. Configuration options
to configure the write timeout have also been added to pjsip.conf and ari.conf.
#ASTERISK-23917 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3624/
........
Merged revisions 417310 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 417311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417317 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a DAHDI span disappears, we wish for its representation in Asterisk
to be destroyed as well.
The information about the span's removal may come from several paths:
1. DAHDI sends DAHDI_EVENT_REMOVE on every channel.
2. An extra DAHDI_EVENT_REMOVED is sent on every subsequent call to
DAHDI_GET_EVENT.
3. Every read (including the internal one by libpri on the D-channel)
returns -ENODEV.
Asterisk responsds to DAHDI_EVENT_REMOVE on a channel by destroying it.
Destroying a channel requires holding the channel list lock (iflock).
Destroying a channel that is part of a span requires holding the span's
lock. Destroying a channel from a context that holds the span lock,
while at the same time another channel is destroyed directly, leads to a
deadlock. Solution: don't destroy span while holding the channels list
lock.
Thus changes in this patch:
* Deferring removal of PRI spans in response to events: doomed spans
are collected on a list.
* Doomed spans are removed periodically by the monitor thread.
* ENODEV reads from the D-channel will warant the same deferred removal.
Review: https://reviewboard.asterisk.org/r/3548/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@417059 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* SS7 support now requires libss7 v2.0 or later. The new libss7 is not
backwards compatible.
* Added SS7 support for connected line and redirecting.
* Most SS7 CLI commands are reworked as well as new SS7 commands added.
See online CLI help.
* Added several SS7 config option parameters described in
chan_dahdi.conf.sample.
* ISUP timer support reworked and now requires explicit configuration.
See ss7.timers.sample.
Special thanks to Kaloyan Kovachev for his support and persistence in
getting the original patch by adomjan updated and ready for release.
SS7-27 #close
Reported by: adomjan
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416416 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When a framehook is removed - such as the fax gateway framehook - the bridge
framework will re-evaluate the bridge mixing technologies to see if it can
improve the bridging. When this occurs, get_rtp_info will be called to
determine if local or remote bridging can be used. Using remote bridging
will cause a fax to fail, as direct media negotiation will cause some small
number of packets to not arrive at the remote endpoint.
This patch forces local native bridging if T.38 negotiation is in progress or
has been established.
........
Merged revisions 416318 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@416319 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
........
Merged revisions 415896 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@415907 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch addresses some aesthetic issues in Asterisk. These are all just
minor tweaks to improve the look of the CLI when used in a variety of
settings. Specifically:
* A number of chatty verbose messages were removed or demoted to DEBUG
messages. Verbose messages with a verbosity level of 5 or higher were -
if kept as verbose messages - demoted to level 4. Several messages
that were emitted at verbose level 3 were demoted to 4, as announcement
of dialplan applications being executed occur at level 3 (and so the
effects of those applications should generally be less).
* Some verbose messages that only appear when their respective 'debug'
options are enabled were bumped up to always be displayed.
* Prefix/timestamping of verbose messages were moved to the verboser
handlers. This was done to prevent duplication of prefixes when the
timestamp option (-T) is used with the CLI.
* Verbose magic is removed from messages before being emitted to
non-verboser handlers. This prevents the magic in multi-line verbose
messages (such as SIP debug traces or the output of DumpChan) from
being written to files.
* _Slightly_ better support for the "light background" option (-W) was
added. This includes using ast_term_quit in the output of XML
documentation help, as well as changing the "Asterisk Ready" prompt to
bright green on the default background (which stands a better chance of
being displayed properly than bright white).
Review: https://reviewboard.asterisk.org/r/3547/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414798 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Asterisk started counting the session timer at INVITE while the other
end correctly started at 200. This meant that for short session-expiries
(90 seconds) combined with long ringing times (e.g. 30 seconds), asterisk
would wrongly assume that the timer was hit before the other end thought
it was time to send a session refresh. This resulted in prematurely
ended calls.
This changes the session timer to start counting first at 200 like RFC
says it should.
(Also removed a few excess NULL checks that would never hit, because if
they did, asterisk would have crashed already.)
ASTERISK-22551 #close
Reported by: i2045
Review: https://reviewboard.asterisk.org/r/3562/
........
Merged revisions 414620 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 414628 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 414636 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@414643 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
........
Merged revisions 413771 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413772 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Per rfc3892, the Referred-By header in a REFER must be copied into the
referenced request (IE. The outgoing INVITE to the transfer target).
* Automatically put the Referred-By header in the outgoing INVITE message
if the SIPREFERREDBYHDR channel variable is defined with a value.
* Made chan_sip.c:get_refer_info() set SIPREFERREDBYHDR for inheritance so
chan_pjsip has a better chance to interoperate.
* Fixed refer_blind_callback() and refer_incoming_refer_request() to not
modify the data in the pointer returned by pjsip_msg_find_hdr_by_name().
It seems wrong to modify that data since the calling routine doesn't own
the buffer.
ASTERISK-23501 #close
Reported by: John Bigelow
Review: https://reviewboard.asterisk.org/r/3514/
........
Merged revisions 413210 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413211 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Fixed early exit in sip_msg_send() not destroying the message iterator.
* Made ast_msg_var_iterator_next() and ast_msg_var_iterator_destroy()
tolerant of a NULL iter parameter in case ast_msg_var_iterator_init()
fails.
* Made ast_msg_var_iterator_destroy() clean up any current message data
ref.
* Made struct ast_msg_var_iterator, ast_msg_var_iterator_init(),
ast_msg_var_iterator_next(), ast_msg_var_unref_current(), and
ast_msg_var_iterator_destroy() use iter instead of i.
* Eliminated RAII_VAR usage in res_pjsip_messaging.c:vars_to_headers().
........
Merged revisions 413139 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 413142 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413144 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If a task was in-flight which required the channel or bridge lock
it was possible for the synchronous task retrieving the call-id
to deadlock as it holds those locks.
After discussing with Mark Michelson the synchronous task was
removed and the call-id accessed directly. This should be safe as
each object involved is guaranteed to exist and the call-id will
never change.
........
Merged revisions 413140 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413141 65c4cc65-6c06-0410-ace0-fbb531ad65f3
1) Added the unistim.conf variable dtmf_duration which can select the DTMF playback duration from 0ms to 150ms (0 is off and is the new default)
2) Enabled the transmission of month names, which are sent with the date and changed the dateformat variable to accept the values 0-3 as per the UNISTIM standard (2 & 3 match the previous 1 & 2 formats).
3) Enabled the "Mute" packet so muting microphone works as expected and microphone muted for all calls while LED light on
4) Changed Duree to Timer on i2004 display
(closes issue ASTERISK-23592)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@413048 65c4cc65-6c06-0410-ace0-fbb531ad65f3
In r411189, some behavior was changed which made sendrpid behavior
act in a more trusting manner by sending full user data for peers
set with private caller presence in P-Asserted-Identity headers.
Since this changed long time expected behaviors, we decided to pull
that patch when that was pointed out by the community. Instead, this
patch provides a trust_id_outbound setting which will expose the data
per RFC-3325 if set to 'yes' and simply not send the PAI/RPID headers
at all if set to 'no'. By default trust_id_outbound will be set to
'legacy' which will preserve the behavior prior to these patches.
Extra special thanks to Walter Doekes for providing advice and
feedback.
(closes issue AST-1301)
(closes issue ASTERISK-19465)
Reported by: Krzysztof Chmielewski
Review: https://reviewboard.asterisk.org/r/3447/
........
Merged revisions 412744 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412746 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 412747 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412759 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch is a continuation of https://reviewboard.asterisk.org/r/3349/,
committed in r412303.
It resolves a finding oej had that the phone-context be available in a
channel variable separate from SIPDOMAIN. This patch adds that variable as
SIPURIPHONECONTEXT. It also allows a local number (or global number specified
in the TEL URI) to be used to look up as a peer.
(issue ASTERISK-17179)
Review: https://reviewboard.asterisk.org/r/3349/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412467 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Remove unused RAII_VAR() declarations. The compiler cannot catch these
because the cleanup function "references" the unused variable. Some
actually allocated and released resources that were never used.
* Fixed some whitespace issues in stasis_bridges.c.
........
Merged revisions 412399 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412400 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The failing assertion ensures that the final snapshot gets generated so
CDR records can get finalized. The only place where a channel staging
snapshot flag could be left set is in chan_sip.c:handle_request_bye().
The function could return before clearing the flag because the channel
could dissappear while the function had to have the channel unlocked.
* Fixed handle_request_bye() channel snapshot staging coverage area to not
have a return in the middle of it and be unable to clear the staging flag.
* Pushed the channel snapshot staging coverage area into
ast_rtp_instance_set_stats_vars() to ensure that the staging is not
interrutped.
* Made callers of ast_rtp_instance_set_stats_vars() not call it with any
channels or channel driver private locks held to eliminate the deadlock
potential. The callers must hold references to the passed in channel and
rtp objects.
* Eliminated sip_hangup() trying to get the bridge peer. It is futile at
this point because the channel could never be in a bridge.
Review: https://reviewboard.asterisk.org/r/3431/
........
Merged revisions 412385 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412386 65c4cc65-6c06-0410-ace0-fbb531ad65f3
---
r411189 | jrose | 2014-03-26 10:50:48 -0500 (Wed, 26 Mar 2014) | 12 lines
chan_sip: Send real CallerID information with P-Assserted-Identity (RFC-3325)
Prior to 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 412328 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412329 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 412330 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412331 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds support for handling TEL URIs in inbound INVITE requests.
This includes the Request URI and the From URI. The number specified in
the Request URI will be the destination of the inbound channel in the dialplan.
The phone-context specified in the Request URI will be stored in the
TELPHONECONTEXT channel variable.
Review: https://reviewboard.asterisk.org/r/3349
ASTERISK-17179 #close
Reported by: Geert Van Pamel
Tested by: Geert Van Pamel
patches:
asterisk-12.0.0-chan_sip-RFC3966_patch.txt uploaded by Geert Van Pamel (License 6140)
asterisk-12.0.0-reqresp_parser-RFC3966_patch.txt uploaded by Geert Van Pamel (License 6140)
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412292 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch does the following:
(1) It makes REF_DEBUG a meneselect item. Enabling REF_DEBUG now enables
REF_DEBUG globally throughout Asterisk.
(2) The ref debug log file is now created in the AST_LOG_DIR directory.
Every run will now blow away the previous run (as large ref files
sometimes caused issues). We now also no longer open/close the file
on each write, instead relying on fflush to make sure data gets written
to the file (in case the ao2 call being performed is about to cause a
crash)
(3) It goes with a comma delineated format for the ref debug file. This
makes parsing much easier. This also now includes the thread ID of the
thread that caused ref change.
(4) A new python script instead for refcounting has been added in the
contrib/scripts folder.
(5) The old refcounter implementation in utils/ has been removed.
Review: https://reviewboard.asterisk.org/r/3377/
........
Merged revisions 412114 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 412115 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 412153 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@412154 65c4cc65-6c06-0410-ace0-fbb531ad65f3
The masquerade supertest frequently fails because either the local channel
chain doesn't completely optimize out or the DTMF handshake doesn't
completely get accross. Local channel optimization requires frames
flowing to trigger when optimization can happen. When optimization
happens the media frame that triggered the optimization is dropped.
Sending DTMF requires frames to flow in the other direction for timing
purposes while sending nothing. If internal timing is not enabled when
MOH is playing, Asterisk switches to received timing when an audio frame
is received. With optimization dropping media frames and MOH not sending
frames unless it receives frames, occasionaly there are no more frames
being passed and the test fails.
* The asterisk command line -I option and the asterisk.conf
internal_timing option are removed. Asterisk now always uses internal
timing when needed if any timing module is loaded. The issue
ASTERISK-14861 did this quite awhile ago in v1.4 but effectively is broken
if other internal timing modules besides DAHDI are used. The
ast_read_generator_actions() now only does received timing if it has no
choice for frame generators like MOH, silence, and playback streaming.
* Cleaned up some code dealing with frame generators in
ast_deactivate_generator(), generator_write_format_change(),
ast_activate_generator(), and ast_channel_stop_silence_generator().
* Removed ast_internal_timing_enabled(), AST_OPT_FLAG_INTERNAL_TIMING, and
ast_opt_internal_timing.
ASTERISK-22846 #close
Reported by: Matt Jordan
Review: https://reviewboard.asterisk.org/r/3414/
........
Merged revisions 411715 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 411716 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 411717 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411724 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
........
Merged revisions 411091 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@411092 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/
........
Merged revisions 410157 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@410158 65c4cc65-6c06-0410-ace0-fbb531ad65f3
When accidentally compiling against a wrong version of
pjsip headers with a different pjsip_inv_session size,
the invite_tsx structure could be null in the answer()
function. This led to a crash because it attempted to
send the session response with an uninitialized packet
pointer. This patch presets packet to null and adds a
diagnostic log message to explain why the call fails.
Review: https://reviewboard.asterisk.org/r/3267/
........
Merged revisions 408970 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408971 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/
........
Merged revisions 408069 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@408070 65c4cc65-6c06-0410-ace0-fbb531ad65f3
* Move route code to sip/route.c + sip/include/route.h
* Rename functions to sip_route_*
* Replace ad-hoc list code with macro's from linkedlists.h
* Create sip_route_process_header() to processes Path and Record-Route headers
(previously done with different code in build_route and build_path)
* Add use of const where possible
* Move struct uriparams, struct contact and contactliststruct from sip.h to
reqresp_parser.h. sip/route.c uses reqresp_parser.h but not sip.h, this was
a problem. These moved declares are not used outside of reqresp_parser.
* While modifying reqprep() the lack of {} caused me trouble. I added them.
* Code outside route.c treats sip_route as an opaque structure, using macro's
or procedures for all access.
(closes issue ASTERISK-22582)
Reported by: Corey Farrell
Review: https://reviewboard.asterisk.org/r/3173/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407926 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
........
Merged revisions 407729 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407731 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Locking issues in skinny when picking up a call that doesn't exist. Cleaned
up sub locking by fully removing and using the chan lock instead. Also
changed ast_call_pickup to check whether chan was masq'd.
(closes issue ASTERISK-23249)
Reported by: wedhorn
Tested by: snuffy, myself
Patches:
skinny-locking01.diff uploaded by wedhorn (license 5019)
........
Merged revisions 407197 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@407198 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
........
Merged revisions 405829 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405830 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This adds Path support to chan_pjsip in res_pjsip_path.c with minimal
additions in res_pjsip_registrar.c to store the path and additions in
res_pjsip_outbound_registration.c to enable advertisement of path
support to registrars and intervening proxies.
Path information is stored on contacts and is enabled via Address of
Record (AoRs) and Registration configuration sections.
While adding path support, it became necessary to be able to add SIP
supplements that handled messages outside of sessions, so a framework
for handling these types of hooks was added in parallel to the
already-existing session supplements and several senders of
out-of-dialog requests were refactored as a result.
(closes issue ASTERISK-21084)
Review: https://reviewboard.asterisk.org/r/3050/
........
Merged revisions 405565 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@405566 65c4cc65-6c06-0410-ace0-fbb531ad65f3
dahdi show channels output slices the callerid (which is dnid copied over on
PRI channels). If the channel naming structures look like:
'DAHDI/i1/1408409XXXX-6'
then the output slices 1408409XXXX down to 1408409XXX. This patch just opens
it up to 15 chars so you can see the whole thing.
(closes issue ASTERISK-22918)
Reported by: outtolunc
Patches:
svn_chan_dahdi.c.format12_15.diff.txt uploaded by outtolunc (license 5198)
........
Merged revisions 404784 from http://svn.asterisk.org/svn/asterisk/branches/1.8
........
Merged revisions 404785 from http://svn.asterisk.org/svn/asterisk/branches/11
........
Merged revisions 404786 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404787 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Channel creation in Asterisk is broken up into two steps: requesting and calling.
In some cases a channel may be requested but never called. This happens in the
ChanIsAvail dialplan application for determining if something is reachable or
not. The PJSIP channel driver did not take this situation into account and
attempted to end a session that was never called out on.
The code now checks the session state to determine if the session has been
called out on and if not terminates it instead of ending it.
(closes issue ASTERISK-23074)
Reported by: Kilburn
........
Merged revisions 404652 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404653 65c4cc65-6c06-0410-ace0-fbb531ad65f3
If ignore_failed_channels is set to "true" for a channel, the channel
will continue to be configured even if configuring it has failed.
This allows Asterisk to start before all the DAHDI initialization is
done and thus not force the starting order dahdi -> asterisk.
Review: https://reviewboard.asterisk.org/r/3063/
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404542 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/
........
Merged revisions 404348 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404350 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Moved channel locking into setsubstate so that a process can complete
working on a sub before another starts changing it. The existing code
was causing some Fracks with schedule deletion.
Removed multiple rtp cleanup. Now only cleansup up once, fixing ao2
object cleanup issues.
........
Merged revisions 404306 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404307 65c4cc65-6c06-0410-ace0-fbb531ad65f3
On session registration, if device is already reporting that it is
connected to a device, an innocuous packet (update time) is sent to
the already connected device. If the tcp connection is down, the
device will be unregistered and the new connection allowed.
Without this patch, network issues can see a situation where a device
can not reregister until after 3*timeout.
........
Merged revisions 404292 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404293 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Original commit message by mmichelson (asterisk 12 r403311):
"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."
The above was initially committed and then reverted at r403398. The problem
was found to be in core_local.c in the publish_local_bridge_message function.
The ast_unreal_lock_all function locks and adds a reference to the returned
channels and while they were being unlocked they were not being unreffed when
no longer needed. Fixed by unreffing the channels.
Also in bridge.c a lock was obtained on "other->chan", but then an attempt was
made to unlock "other" and not the previously locked channel. Fixed by
unlocking "other->chan"
(closes issue ASTERISK-22709)
Reported by: John Bigelow
........
Merged revisions 404237 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@404260 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)
........
Merged revisions 403767 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403768 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch was intended to eliminate a deadlock that occurs when
masquerades occur in pjsip channels, but has some potential side
effects. Mark Michelson is currently working on addressing this
problem from another angle.
(issue ASTERISK-22936)
Reported by: Jonathan Rose
........
Merged revisions 403705 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403707 65c4cc65-6c06-0410-ace0-fbb531ad65f3
This patch adds CHANNEL read support for chan_pjsip. This allows the dialplan
to use the CHANNEL function on a chan_pjsip channel to obtain run-time
information about the channel from the PJSIP channel driver and the PJSIP
stack. This includes:
* RTP information, including source/destination media addresses, whether or
not the media is secure, held, and other properties.
* RTCP information. This includes sets of parseable information, as well as
individual statistic attriutes.
* PJSIP information. This includes URIs, local/remote signalling addresses,
whether or not the signalling is secure, and other properties.
* The endpoint name. This can be used in conjunction with the PJSIP_ENDPOINT
function to obtain more detailed endpoint information.
Review: https://reviewboard.asterisk.org/r/3038/
........
Merged revisions 403618 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403619 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.
........
Merged revisions 403311 from http://svn.asterisk.org/svn/asterisk/branches/12
git-svn-id: https://origsvn.digium.com/svn/asterisk/trunk@403314 65c4cc65-6c06-0410-ace0-fbb531ad65f3
Joshua Colp
zuul
Alexei Gradinari
Matt Jordan
Michael Kuron
Timo Teräs
Igor Goncharovskiy
C.J. Collier
Kevin Harwell
Sebastian Gutierrez
Grachev Sergey
Tzafrir Cohen
Corey Farrell
Moises Silva
Alexander Traud
George Joseph
Aaron An
Steve Davies
Walter Doekes
varnav
cjack
Richard Mudgett
Mark Michelson
Vasil Kolev
kkm
Jaco Kroon
George Joseph
Francesco Castellano
Walter Doekes
StefanEng86
Ward van Wanrooij
Dade Brandon
Jonathan Rose
Eugene Voityuk
Filip Jenicek
Christof Lauber
Florian Sauerteig
Debian Amtelco
Scott Griepentrog
Rodrigo Ramírez Norambuena
Patric Marschall
Damian Ivereigh
Yousf Ateya
snuffy
Rodrigo Ramírez Norambuena
Diederik de Groot
David M. Lee
Kinsey Moore
Scott Griepentrog
Michael L. Young
Paul Belanger
Damien Wedhorn
Sean Bright
Rusty Newton
Russell Bryant