It is possible to modify the dialmode setting in the chan_dahdi/sig_analog
private using the CHANNEL function, to modify it during calls. However,
it was not being reset between calls, meaning that if, for example, tone
dialing was disabled, it would never work again unless explicitly enabled.
This fixes the setting by pairing it with a "perm" version of the setting,
as a few other features have, so that it can be reset to the permanent
setting between calls. The documentation is also clarified to explain
the interaction of this setting and the digitdetect setting more clearly.
Resolves: #1378
* Added a new option to the WebSocket dial string to capture the additional
URI parameters.
* Added a new API ast_uri_verify_encoded() that verifies that a string
either doesn't need URI encoding or that it has already been encoded.
* Added a new API ast_websocket_client_add_uri_params() to add the params
to the client websocket session.
* Added XML documentation that will show up with `core show application Dial`
that shows how to use it.
Resolves: #1352
UserNote: A new WebSocket channel driver option `v` has been added to the
Dial application that allows you to specify additional URI parameters on
outgoing connections. Run `core show application Dial` from the Asterisk CLI
to see how to use it.
ast_websocket_read() receives data into a fixed 64K buffer then continually
reallocates a final buffer that, after all continuation frames have been
received, is the exact length of the data received and returns that to the
caller. process_text_message() in chan_websocket was attempting to set a
NULL terminator on the received payload assuming the payload buffer it
received was the large 64K buffer. The assumption was incorrect so when it
tried to set a NULL terminator on the payload, it could, depending on the
state of the heap at the time, cause heap corruption.
process_text_message() now allocates its own payload_len + 1 sized buffer,
copies the payload received from ast_websocket_read() into it then NULL
terminates it prevent the possibility of the overrun and corruption.
Resolves: #1384
Previously, we were only using # (ST) as a terminator, and not handling
A (STP), B (ST2P), or C (ST3P), which erroneously led to it being
treated as part of the dialed number. Parse any of these as the start
digit.
Resolves: #1301
In the WebSocket channel driver, the FLUSH_MEDIA command clears all frames from
the queue but does not reset the frame_queue_length counter.
As a result, the driver incorrectly thinks the queue is full after flushing,
which prevents new multimedia frames from being sent, especially after multiple
flush commands.
This fix sets frame_queue_length to 0 after flushing, ensuring the queue state
is consistent with its actual content.
Fixes: #1304
When the RTP media source changes, such as after a blind transfer, the new source introduces a discontinuous timestamp. According to RFC 3550, Section 5.1, an RTP stream's timestamp for a given SSRC must increment monotonically and linearly.
To comply with the standard and avoid a large timestamp jump on the existing SSRC, a new SSRC is generated for the new media stream.
This change resolves known interoperability issues with certain SBCs (like Sonus/Ribbon) that stop forwarding media when they detect such a timestamp violation. This code uses the existing implementation from chan_sip.
Resolves: #927
users.conf was deprecated in Asterisk 21 and is now being removed
for Asterisk 23, in accordance with the Asterisk deprecation policy.
This consists of:
* Removing integration with app_directory, app_voicemail, chan_dahdi,
chan_iax2, and AMI.
* users.conf was also partially used for res_phoneprov, and this remaining
functionality is consolidated to a separate phoneprov_users.conf,
used only by res_phoneprov.
Resolves: #1292
UpgradeNote: users.conf has been removed and all channel drivers must
be configured using their specific configuration files. The functionality
previously in users.conf for res_phoneprov is now in phoneprov_users.conf.
* Created chan_websocket which can exchange media over both inbound and
outbound websockets which the driver will frame and time.
See http://s.asterisk.net/mow for more information.
* res_http_websocket: Made defines for max message size public and converted
a few nuisance verbose messages to debugs.
* main/channel.c: Changed an obsolete nuisance error to a debug.
* ARI channels: Updated externalMedia to include chan_websocket as a supported
transport.
UserNote: A new channel driver "chan_websocket" is now available. It can
exchange media over both inbound and outbound websockets and will both frame
and re-time the media it receives.
See http://s.asterisk.net/mow for more information.
UserNote: The ARI channels/externalMedia API now includes support for the
WebSocket transport provided by chan_websocket.
When a call is transfered via DTMF feature code, the Transfer Target and
Transferer are bridged immediately. This opens the possibilty of a race
condition between the creation of an INVITE and the bridge induced colp
update that can result in the set caller ID being over-written with the
transferer's default info.
Fixes: #1234
Adds support for Call Waiting Deluxe options to enhance
the current call waiting feature.
As part of this change, a mechanism is also added that
allows a channel driver to queue an audio file for Dial()
to play, which is necessary for the announcement function.
ASTERISK-30373 #close
Resolves: #271
UserNote: Call Waiting Deluxe can now be enabled for FXS channels
by enabling its corresponding option.
* Update Dial() documentation for IAX2 to include syntax for RSA
public key names.
* Add additional details to a couple warnings to provide more context
when an undecodable frame is received.
Resolves: #1206
Updated the AudioSocket protocol to allow sending DTMF frames.
AST_FRAME_DTMF frames are now forwarded to the server, in addition to
AST_FRAME_AUDIO frames. A new payload type AST_AUDIOSOCKET_KIND_DTMF
with value 0x03 was added to the protocol. The payload is a 1-byte
ascii representing the DTMF digit (0-9,*,#...).
UserNote: The AudioSocket protocol now forwards DTMF frames with
payload type 0x03. The payload is a 1-byte ascii representing the DTMF
digit (0-9,*,#...).
- Correct wait timeout logic in the dialplan application.
- Include server address in log messages for better traceability.
- Allow dialplan app to exit gracefully on hangup messages and socket closure.
- Optimize I/O by reducing redundant read()/write() operations.
Co-authored-by: Florent CHAUVEAU <florentch@pm.me>
1. When one channel is placed on hold, the device state is set to ONHOLD
without checking other channels states.
In case of AST_CONTROL_HOLD set the device state as AST_DEVICE_UNKNOWN
to calculate aggregate device state of all active channels.
2. The current implementation incorrectly classifies channels in use.
The only channels that has the states: UP, RING and BUSY are considered as "in use".
A channel should be considered "in use" if its state is anything other than
DOWN or RESERVED.
3. Currently, if the number of channels "in use" is greater than device_state_busy_at,
the system does not set the state to BUSY. Instead, it incorrectly assigns an aggregate
device state.
The endpoint device state should be BUSY if the number of channels "in use" is greater
than or equal to device_state_busy_at.
Fixes: #1181
Found via `codespell -q 3 -S "./CREDITS,*.po" -L abd,asent,atleast,cachable,childrens,contentn,crypted,dne,durationm,enew,exten,inout,leapyear,mye,nd,oclock,offsetp,ot,parm,parms,preceeding,pris,ptd,requestor,re-use,re-used,re-uses,ser,siz,slanguage,slin,thirdparty,varn,varns,ues`
Introduce a ChannelTransfer event and the ability to notify progress to
ARI. Implement emitting this event from the PJSIP channel instead of
handling the transfer in Asterisk when configured.
Introduce a dialplan function to the PJSIP channel to switch between the
"core" and "ari-only" behavior.
UserNote: Call transfers on the PJSIP channel can now be controlled by
ARI. This can be enabled by using the PJSIP_TRANSFER_HANDLING(ari-only)
dialplan function.
* Do a git blame on the embedded XML application or function element.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The applications and functions defined in the following files were done by
hand because the XML was extracted from the C source file relatively recently.
* channels/pjsip/dialplan_functions_doc.xml
* main/logger_doc.xml
* main/manager_doc.xml
* res/res_geolocation/geoloc_doc.xml
* res/res_stir_shaken/stir_shaken_doc.xml
* Do a git blame on the embedded XML managerEvent elements.
* From the commit hash, grab the summary line.
* Do a git log --grep <summary> to find the cherry-pick commits in all
branches that match.
* Do a git patch-id to ensure the commits are all related and didn't get
a false match on the summary.
* Do a git tag --contains <commit> to find the tags that contain each
commit.
* Weed out all tags not ..0.
* Sort and discard any .0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the application or function
was defined.
The events defined in res/res_pjsip/pjsip_manager.xml were done by hand
because the XML was extracted from the C source file relatively recently.
Two bugs were fixed along the way...
* The get_documentation awk script was exiting after it processed the first
DOCUMENTATION block it found in a file. We have at least 1 source file
with multiple DOCUMENTATION blocks so only the first one in them was being
processed. The awk script was changed to continue searching rather
than exiting after the first block.
* Fixing the awk script revealed an issue in logger.c where the third
DOCUMENTATION block contained a XML fragment that consisted only of
a managerEventInstance element that wasn't wrapped in a managerEvent
element. Since logger_doc.xml already existed, the remaining fragments
in logger.c were moved to it and properly organized.
Most of the configObjects and configOptions that are implemented with
ACO or Sorcery now have `<since>/<version>` elements added. There are
probably some that the script I used didn't catch. The version tags were
determined by the following...
* Do a git blame on the API call that created the object or option.
* From the commit hash, grab the summary line.
* Do a `git log --grep <summary>` to find the cherry-pick commits in all
branches that match.
* Do a `git patch-id` to ensure the commits are all related and didn't get
a false match on the summary.
* Do a `git tag --contains <commit>` to find the tags that contain each
commit.
* Weed out all tags not <major>.<minor>.0.
* Sort and discard any <major>.0.0 and following tags where the commit
appeared in an earlier branch.
* The result is a single tag for each branch where the API was last touched.
configObjects and configOptions elements implemented with the base
ast_config APIs were just not possible to find due to the non-deterministic
way they are accessed.
Also note that if the API call was on modified after it was added, the
version will be the one it was last modified in.
Final note: The configObject and configOption elements were introduced in
12.0.0 so options created before then may not have any XML documentation.
Currently, when receiving an unauthenticated call, we keep track
of the negotiated format in the chosenformat, which allows us
to later create the channel using the right format. However,
this was not done for authenticated calls. This meant that in
certain circumstances, if we had not yet received a voice frame
from the peer, only certain other types of frames (e.g. text),
there were no variables containing the appropriate frame.
This led to problems in the jitterbuffer callback where we
unnecessarily bailed out of retrieving a frame from the jitterbuffer.
This was logic intentionally added in commit 73103bdcd5
in response to an earlier regression, and while this prevents
crashes, it also backlogs legitimate frames unnecessarily.
The abort logic was initially added because at this point in the
code, we did not have the negotiated format available to us.
However, it should always be available to us as a last resort
in chosenformat, so we now pull it from there if needed. This
allows us to process frames the jitterbuffer even if voicefmt
and peerfmt aren't set and still avoid the crash. The failsafe
logic is retained, but now it shouldn't be triggered anymore.
Resolves: #1054
This adds the Last Number Redial feature to
simple switch.
UserNote: Users can now redial the last number
called if the lastnumredial setting is set to yes.
Resolves: #437
* channels/pjsip/dialplan_functions_doc.xml: Added xmlns:xi to docs element.
* main/bucket.c: Removed XML completely since the "bucket" and "file" objects
are internal only with no config file.
* main/named_acl.c: Fixed the configFile element name. It was "named_acl.conf"
and should have been "acl.conf"
* res/res_geolocation/geoloc_doc.xml: Added xmlns:xi to docs element.
* res/res_http_media_cache.c: Fixed the configFile element name. It was
"http_media_cache.conf" and should have been "res_http_media_cache.conf".
Previously, when AST_CONTROL_RINGING was received by
a DAHDI device, it would set its channel state to
AST_STATE_RINGING. However, an analysis of the codebase
and other channel drivers reveals RINGING corresponds to
physical power ringing, whereas AST_STATE_RING should be
used for audible ringback on the channel. This also ensures
the correct device state is returned by the channel state
to device state conversion.
Since there seems to be confusion in various places regarding
AST_STATE_RING vs. AST_STATE_RINGING, some documentation has
been added or corrected to clarify the actual purposes of these
two channel states, and the associated device state mapping.
An edge case that prompted this fix, but isn't explicitly
addressed here, is that of an incoming call to an FXO port.
The channel state will be "Ring", which maps to a device state
of "In Use", not "Ringing" as would be more intuitive. However,
this is semantic, since technically, Asterisk is treating this
the same as any other incoming call, and so "Ring" is the
semantic state (put another way, Asterisk isn't ringing anything,
like in the cases where channels are in the "Ringing" state).
Since FXO ports don't currently support Call Waiting, a suitable
workaround for the above would be to ignore the device state and
instead check the channel state (e.g. IMPORT(DAHDI/1-1,CHANNEL(state)))
since it will be Ring if the FXO port is idle (but a call is ringing
on it) and Up if the FXO port is actually in use. (In both cases,
the device state would misleadingly be "In Use".)
Resolves: #1029
Currently, when a chan_pjsip channel receives a VIDUPDATE indication,
an RTP VIDUPDATE frame is only queued on a H.264 stream if WebRTC is
enabled on that endpoint. This restriction does not really make sense.
Now, a VIDUPDATE RTP frame is written even if WebRTC is not enabled (as
is the case with VP8, VP9, and H.265 streams).
Resolves: #1013
Commit 466eb4a52b introduced a regression
which completely broke Feature Group D and E911 signaling, by removing
the call to analog_my_getsigstr, which affected multiple switch cases.
Restore the original behavior for all protocols except Feature Group C
CAMA (MF), which is all that patch was attempting to target.
Resolves: #993
In some circumstances, it is possible for the do_monitor thread to
erroneously think that a line is on-hook and send an MWI FSK spill
to it when the line is really off-hook and no MWI should be sent.
Commit 0a8b3d3467 previously fixed this
issue in a more readily encountered scenario, but it has still been
possible for MWI to be sent when it shouldn't be. To robustly fix
this issue, query DAHDI for the hook status to ensure we don't send
MWI on a line that is actually still off hook.
Resolves: #928
Add dialplan application PJSIPNOTIFY to send either pre-configured
NOTIFY messages from pjsip_notify.conf or with headers defined in
dialplan.
Also adds the ability to send pre-configured NOTIFY commands to a
channel via the CLI.
Resolves: #799
UserNote: A new dialplan application PJSIPNotify is now available
which can send SIP NOTIFY requests from the dialplan.
The pjsip send notify CLI command has also been enhanced to allow
sending NOTIFY messages to a specific channel. Syntax:
pjsip send notify <option> channel <channel>
This patch introduces a new identifier for channels: tenantid. It's
a stringfield on the channel that can be used for general purposes. It
will be inherited by other channels the same way that linkedid is.
You can set tenantid in a few ways. The first is to set it in the
dialplan with the Set and CHANNEL functions:
exten => example,1,Set(CHANNEL(tenantid)=My tenant ID)
It can also be accessed via CHANNEL:
exten => example,2,NoOp(CHANNEL(tenantid))
Another method is to use the new tenantid option for pjsip endpoints in
pjsip.conf:
[my_endpoint]
type=endpoint
tenantid=My tenant ID
This is considered the best approach since you will be able to see the
tenant ID as early as the Newchannel event.
It can also be set using set_var in pjsip.conf on the endpoint like
setting other channel variable:
set_var=CHANNEL(tenantid)=My tenant ID
Note that set_var will not show tenant ID on the Newchannel event,
however.
Tenant ID has also been added to CDR. It's read-only and can be accessed
via CDR(tenantid). You can also get the tenant ID of the last channel
communicated with via CDR(peertenantid).
Tenant ID will also show up in CEL records if it has been set, and the
version number has been bumped accordingly.
Fixes: #740
UserNote: tenantid has been added to channels. It can be read in
dialplan via CHANNEL(tenantid), and it can be set using
Set(CHANNEL(tenantid)=My tenant ID). In pjsip.conf, it is recommended to
use the new tenantid option for pjsip endpoints (e.g., tenantid=My
tenant ID) so that it will show up in Newchannel events. You can set it
like any other channel variable using set_var in pjsip.conf as well, but
note that this will NOT show up in Newchannel events. Tenant ID is also
available in CDR and can be accessed with CDR(tenantid). The peer tenant
ID can also be accessed with CDR(peertenantid). CEL includes tenant ID
as well if it has been set.
UpgradeNote: A new versioned struct (ast_channel_initializers) has been
added that gets passed to __ast_channel_alloc_ap. The new function
ast_channel_alloc_with_initializers should be used when creating
channels that require the use of this struct. Currently the only value
in the struct is for tenantid, but now more fields can be added to the
struct as necessary rather than the __ast_channel_alloc_ap function. A
new option (tenantid) has been added to endpoints in pjsip.conf as well.
CEL has had its version bumped to include tenant ID.
Various SIP headers permit a URI to be prefaced with a `display-name`
production that can include characters (like commas and parentheses)
that are problematic for Asterisk's dialplan parser and, specifically
in the case of this patch, the PJSIP_PARSE_URI function.
This patch introduces a new function - `PJSIP_PARSE_URI_FROM` - that
behaves identically to `PJSIP_PARSE_URI` except that the first
argument is now a variable name and not a literal URI.
Fixes#756
Commit f2f397c1a8 previously
made it possible to send Caller ID parameters to FXS stations
which, prior to that, could not be sent.
This change is complementary in that we now handle receiving
all these parameters on FXO lines and provide these up to
the dialplan, via chan_dahdi. In particular:
* If a redirecting reason is provided, the channel's redirecting
reason is set. No redirecting number is set, since there is
no parameter for this in the Caller ID protocol, but the reason
can be checked to determine if and why a call was forwarded.
* If the Call Qualifier parameter is received, the Call Qualifier
variable is set.
* Some comments have been added to explain why some of the code
is the way it is, to assist other people looking at it.
With this change, Asterisk's Caller ID implementation is now
reasonably complete for both FXS and FXO operation.
Resolves: #681
* Add an AMI action to correspond to the "dahdi show status"
command, allowing span information to be retrieved via AMI.
* Show span number and sig type in "dahdi show channels".
Resolves: #673
There were a few references in the embedded documentation XML
where the case didn't match or where the referenced app or function
simply didn't exist any more. These were causing 404 responses
in docs.asterisk.org.
Commit 729cb1d390 added logic to retry
opening DAHDI channels on "dahdi restart" if they failed initially,
up to 1,000 times in a loop, to address cases where the channel was
still in use. However, this retry loop does not use the actual error,
which means chan_dahdi will also retry opening nonexistent channels
1,000 times per channel, causing a flood of unnecessary warning logs
for an operation that will never succeed, with tens or hundreds of
thousands of open attempts being made.
The original patch would have been more targeted if it only retried
on the specific relevant error (likely EBUSY, although it's hard to
say since the original issue is no longer available).
To avoid the problem above while avoiding the possibility of breakage,
this skips the retry logic if the error is ENXIO (No such device or
address), since this will never succeed.
Resolves: #669
The existing "waitfordialtone" setting in chan_dahdi.conf
applies permanently to a specific channel, regardless of
how it is being used. This rather restrictively prevents
a system from simultaneously being able to pick free lines
for outgoing calls while also allowing barge-in to a trunk
by some other arrangement.
This allows specifying "waitfordialtone" using the CHANNEL
function for only the next call that will be placed, allowing
significantly more flexibility in the use of trunk interfaces.
Resolves: #472
UserNote: "waitfordialtone" may now be specified for DAHDI
trunk channels on a per-call basis using the CHANNEL function.
Under rare circumstances, it's possible for the original audio
session in the active_media_state default_session to be corrupted
instead of removed when switching to the t38/image media session
during fax negotiation. This can cause a segfault when a "pjsip
show channelstats" attempts to print that audio media session's
rtp statistics. In these cases, the active_media_state
topology is correctly showing only a single t38/image stream
so we now check that there's an audio stream in the topology
before attempting to use the audio media session to get the rtp
statistics.
Resolves: #592
This adds a CLI command to manually toggle the MWI status
of a channel, useful for troubleshooting or resetting
MWI devices, similar to the capabilities offered with
SIP messaging to manually control MWI status.
UserNote: The 'dahdi set mwi' now allows MWI on channels
to be manually toggled if needed for troubleshooting.
Resolves: #440
Commit 008731b0a4
caused a regression by resulting in logger.xml
being compiled and linked into the asterisk
binary in lieu of logger.c on certain platforms
if Asterisk was compiled in dev mode.
To fix this, we ensure the file has a unique
name without the extension. Most existing .xml
files have been named differently from any
.c files in the same directory or did not
pose this issue.
channels/pjsip/dialplan_functions.xml does not
pose this issue but is also being renamed
to adhere to this policy.
Resolves: #539
When mwimonitor=yes is enabled for an FXO port,
the do_monitor thread will launch mwi_thread if it thinks
there could be MWI on an FXO channel, due to the noise
threshold being satisfied. This, in turns, calls
analog_ss_thread_start in sig_analog. However, unlike
all other instances where __analog_ss_thread is called
in sig_analog, this call path does not properly set
pvt->ss_astchan to the Asterisk channel, which means
that the Asterisk channel is NULL when __analog_ss_thread
starts executing. As a result, the thread exits and the
channel is never properly cleaned up by calling ast_hangup.
This caused issues with do_monitor on incoming calls,
as it would think the channel was still owned even while
receiving events, leading to an infinite barrage of
warning messages; additionally, the channel would persist
improperly.
To fix this, the assignment is added to the call path
where it is missing (which is only used for mwi_thread).
A warning message is also added since previously there
was no indication that __analog_ss_thread was exiting
abnormally. This resolves both the channel leak and the
condition that led to the warning messages.
Resolves: #458
Certain channel options are not set anywhere or
exposed in any way to users, making them unusable.
This exposes some of these options which make sense
for users to manipulate at runtime.
Resolves: #442
See UserNote below.
Exposed the existing Hangup AMI action in manager.c so we can use
all of it's channel search and AMI protocol handling without
duplicating that code in dialplan_functions.c.
Added a lookup function to res_pjsip.c that takes in the
string represenation of the pjsip_status_code enum and returns
the actual status code. I.E. ast_sip_str2rc("DECLINE") returns
603. This allows the caller to specify PJSIPHangup(decline) in
the dialplan, just like Hangup(call_rejected).
Also extracted the XML documentation to its own file since it was
almost as large as the code itself.
UserNote: A new dialplan app PJSIPHangup and AMI action allows you
to hang up an unanswered incoming PJSIP call with a specific SIP
response code in the 400 -> 699 range.
When IAX2 debugging was enabled (`iax2 set debug on`), if the last IE
in a frame was one that may not have any data - such as the CALLTOKEN
IE in an NEW request - it was not getting displayed.
