If the endpoint's last contact is deleted unsolicited MWI has to be
unsubscribed.
ASTERISK-27051 #close
Change-Id: I33e174e0b9dba0998927d16d6d100fda5c7254e0
When a stasis channel is stolen by another app, the control
structure is unreffed but never unlinked from the app_controls
container. This causes the channel reference to leak.
Added OBJ_UNLINK to the callback in channel_stolen_cb.
Also added some additional channel lifecycle debug messages to
channel.c.
ASTERISK-27059 #close
Repoorted-by: George Joseph
Change-Id: Ib820936cd49453f20156971785e7f4f182c56e14
This option was added to control whether to notify dialog-info state
'early' or 'confirmed' on Ringing when already INUSE.
The value "yes" is useful for some SIP phones (Cisco SPA)
to be able to indicate and pick up ringing devices.
ASTERISK-26919 #close
Change-Id: Ie050bc30023543c7dfb4365c5be3ce58c738c711
In Corosync 2.x libraries were changed to use LibQB IPC.
Sadly LibQB IPC doesn't support copy-free access to received buffer, so
Corosync libraries were rewritten to use stack as buffer. Mostly the
needed stack size is quite small, but for all *_dispatch functions, 1MiB
is needed.
Asterisk function ast_pthread_create_background set stack size for new
thread to much smaller AST_BACKGROUND_STACKSIZE (~500KiB).
This results in Asterisk crash when running with Corosync 2.x.
Patch solves this issue by creating it's own version of
ast_pthread_create_background which sets stack size to much higher value
(actually it's AST_BACKGROUND_STACKSIZE + 3MiB).
Another problem may appear when "corosync show members" netconsole
command is executed. It is also executed in thread and also has only
500KiB stack size. Sadly it calls corosync_cfg_get_node_addrs which
again needs at least 1MiB stack.
Solution is to use HAVE_COROSYNC_CFG_STATE_TRACK as a discriminator
between Corosync 1.x and 2.x. If 1.x is found, nothing changes. If 2.x
is found, NodeID is displayed instead of IP address.
ASTERISK-25370 #close
Reported by: mdu113
Change-Id: Id95b0d21ab6e708e7d74ad8786c587211676fa08
The recent change to make the use of LOAD_DECLINE more consistent
caused res_ari to unload itself before declining if the ari.conf
file wasn't found. The ari stubs though still tried to use the
configuration resulting in segfaults.
This patch creates a new CHECK_ARI_MODULE_LOADED macro which tests
to see if res_ari is actually loaded and causes the stubs to also
decline if it isn't. The macro was then added to the mustache
template's "load_module" function.
ASTERISK-27026 #close
Reported-by: Ronald Raikes
Change-Id: I263d56efa628ee3c411bdcd16d49af6260c6c91d
destroy_subscription was attempting to get the id of the
subscription tree's endpoint after we'd already called ao2_cleanup
on it causing a segfault.
Moved the cleanup until after the debug statement and since
endpoint could also be NULL at this point, check for that as well.
ASTERISK-27057 #close
Reported-by: Ryan Smith
Change-Id: Ice0a7727f560cf204d870a774c6df71e159b1678
There was a typo introduced in commit 776ffd77 which was preventing
the transport's external media address from being used.
ASTERISK-27024 #close
Reported-by: Christopher van de Sande
patches:
patch.diff submitted by Florian Floimair (license 6892)
Change-Id: I7ec617171eaa2d86d2680b00cf37d5088adafc27
It looks like there was a copy/paste error in ast_rtp_change_source
where if there was a rtcp srtp instance, instead of updating its
ssrc we were updating the srtp instance ssrc twice.
ASTERISK-27022 #close
Reported-by: Michael Walton
Change-Id: Ic88f3aee7227b401c58745ac265ff92c19620095
When doing an attended transfer it's possible for the transferer, after
receiving an accepted response from Asterisk, to send a BYE to Asterisk,
which can then be processed before Asterisk has time to start and/or
complete the transfer process. This of course causes the transfer to not
complete successfully, thus dropping the call.
This patch makes it so any BYEs received from the transferer, after the REFER,
that initiate a session end are deferred until the transfer is complete. This
allows the channel that would have otherwise been hung up by Asterisk to
remain available throughout the transfer process.
ASTERISK-27053 #close
Change-Id: I43586db79079457d92d71f1fd993be9a3b409d5a
If sending unsolicited mwi to all endpoints on startup is disabled
(mwi_disable_initial_unsolicited=yes) do not need to create subscriptions.
If there are many (thousands) realtime endpoints configured with unsolicited mwi
and Vociemail Storage configured as ODBC or IMAP there will be huge number of
DB/IMAP requests on startup.
ASTERISK-26230 #close
Change-Id: I50ae909639e3ee298b931a54def4b2b9e0fb86c5
Added check for NULL return value when calling
ast_sorcery_retrieve_by_id in function get_write_timeout
ASTERISK-27046
Change-Id: I9357717278da631c3a1cb502c412693929b0cb41
PJSIP support in Asterisk differs from chan_sip in that it
allows media to be sent as-is without transcoding provided
the codecs were negotiated in the SDP. This is allowed
according to the RFC. Support for this differs quite a lot
though and some endpoints do not handle it well.
This change extends the 'asymmetric_rtp_codec' option to
also cover this case. When set to no (the default) the code
behaves as chan_sip does - the best codec is selected and
we will only ever send that, unless we change what we are
sending if the remote side changes. When set to yes we
will send media as-is without transcoding if the codec
has been negotiated in the SDP.
ASTERISK-26996
Change-Id: Ib1647f6902a0843e8c435946f831c2159e8d1d51
When a frame destined for a MulticastRTP channel does not have timing
information (such as when an 'originate' is done), we generate the RTP
timestamps ourselves without regard to the number of samples we are
about to send.
Instead, use the same method as res_rtp_asterisk and 'predict' a
timestamp given the number of samples. If the difference between the
timestamp that we generate and the one we predict is within a specific
threshold, use the predicted timestamp so that we end up with timestamps
that are consistent with the number of samples we are actually sending.
Change-Id: I2bf0db3541b1573043330421cbb114ff0f22ec1f
This introduces the ability for PJSIP code to specify filtering flags
when retrieving PJSIP contacts. The first flag for use causes the
query code to only retrieve contacts that are not unreachable. This
change has been leveraged by both the Dial() process and the
PJSIP_DIAL_CONTACTS dialplan function so they will now only attempt
calls to contacts which are not unreachable.
ASTERISK-26281
Change-Id: I8233b4faa21ba3db114f5a42e946e4b191446f6c
In review 4843 (ASTERISK-24858), we added a hack that forced a smoother
creation when sending signed linear so that the byte order was adjusted
during transmission. This was needed because smoother flags were lost
during the new format work that was done in Asterisk 13.
Rather than rolling that same hack into res_rtp_multicast, re-introduce
smoother flags so that formats can dictate their own options.
Change-Id: I77b835fba0e539c6ce50014a984766f63cab2c16
This change allows the format of the EAGI audio pipe to be changed by
setting the dialplan variable 'EAGI_AUDIO_FORMAT' to the name of one of
the loaded formats.
ASTERISK-26124 #close
Change-Id: I7a10fad401ad2a21c68c2e7246fa357d5cee5bbd
Documented the 'beep' option in both the parameters list and the command
description.
ASTERISK-23839 #close
Change-Id: I4970395c922dbdce3f7cf0f56d5b065ec9aa53ea
Explicitly check that the appropriate number of arguments were passed to
SET VARIABLE before attempting to reference them. Also initialize the
arguments array to zeroes before populating it.
ASTERISK-22432 #close
Change-Id: I5143607d80a2724f749c1674f3126b04ed32ea97
If the generated XML documentation for a command does not end with a \n,
the postamble of the usage message does not appear on its own line.
ASTERISK-25662 #close
Change-Id: If190f1e9e37fe215fed95897d78d4a6e142b0020
Some devices separate format attributes with a semicolon followed by a
space, so trim blanks before trying to match them.
ASTERISK-27008 #close
Change-Id: Ia44cb2e4fef5c73dc541a29da79cb0e19c22d9cc
When using rtcp mux if an rtcp payload came in it would still use the srtp
unprotect algorithm instead of the srtp unprotect rtcp method. Since rtcp
data was being passed to the rtp unprotect method this would result in an
error.
This patch ensures that the correct unprotect method is chosen by making
sure the passed in rtcp flag is appropriately set when rtcp mux is enabled
and an rtcp payload is received.
ASTERISK-26979 #close
Change-Id: Ic5409f9d1a267f1d4785fc5aed867daaecca6241
When manipulating flags on a channel the channel has to be
locked to guarantee that nothing else is also manipulating
the flags. This change introduces locking where necessary to
guarantee this. It also adds helper functions that manipulate
channel flags and lock to reduce repeated code.
ASTERISK-26789
Change-Id: I489280662dba0f4c50981bfc5b5a7073fef2db10
Retransmissions of an initial INVITE could be queued in the serializer
before we have processed the first INVITE message. If the first INVITE
message doesn't get completely processed before the retransmissions are
seen then we could try to setup the same call from the retransmissions. A
symptom of this is seeing a (key exists) message associated with an
INVITE. An earlier change attempted to address this kind of problem by
calculating a distributor serializer to use for unassociated messages.
Part of that change also made incoming calls keep using that distributor
serializer. (ASTERISK-26088) However, some leftover code was still
deferring the INVITE processing to the session's serializer even though we
were already in that serializer. This not only is unnecessary but would
cause the same call resetup problem.
* Removed the code to defer processing the initial INVITE to the session's
serializer because we are already running in that serializer.
ASTERISK-26998 #close
Change-Id: I1e822d82dcc650e508bc2d40d545d5de4f3421f6
This option was added to turn off notifying the progress details
on Blind Transfer. If this option is not set then the chan_pjsip
will send NOTIFY "200 OK" immediately after "202 Accepted".
Some SIP phones like Mitel/Aastra or Snom keep the line busy until
receive "200 OK".
ASTERISK-26333 #close
Change-Id: Id606fbff2e02e967c02138457badc399144720f2
This change adds the required logic to allow the SIP
Call-ID to be placed into the HEP RTCP traffic if the
chan_sip module is used. In cases where the option is
enabled but the channel is not either SIP or PJSIP then
the code will fallback to the channel name as done
previously.
Based on the change on Nir's branch at:
team/nirs/hep-chan-sip-support
ASTERISK-26427
Change-Id: I09ffa5f6e2fdfd99ee999650ba4e0a7aad6dc40d
When a call gets put on hold RTP is temporarily stopped and Asterisk was
setting the remote RTCP address to NULL. Then when RTCP data was received
from the remote endpoint, Asterisk would be missing this information when
publishing the rtcp_message stasis event. Consequently, message subscribers
(in this case res_hep_rtcp) trying to parse the "from" field output the
following error:
"ast_sockaddr_split_hostport: Port missing in (null)"
This patch makes it so the remote RTCP address is no longer set to NULL when
stopping RTP. There was only one place that appeared to check if the remote
RTCP address was NULL as a way to tell if RTCP was running. This patch added
an additional check on the RTCP schedid for that case to make sure RTCP was
truly not running.
ASTERISK-26860 #close
Change-Id: I6be200fb20db647e48b5138ea4b81dfa7962974b
