| Age | Commit message (Collapse) | Author |
|---|
|
This function is a replica of SIPDtmfMode, allowing the DTMF mode of a
PJSIP call to be modified on a per-call basis
ASTERISK-27085 #close
Change-Id: I20eef5da3e5d1d3e58b304416bc79683f87e7612
|
|
Change-Id: Ia578ede1a55b21014581793992a429441903278b
|
|
issues." into 15
|
|
This change does a few things to improve packet loss and renegotiation:
1. On outgoing RTP streams we will now properly reflect out of order
packets and packet loss in the sequence number. This allows the
remote jitterbuffer to better reorder things.
2. Video updates can now be discarded for a period of time
after one has been sent to prevent flooding of clients.
3. For declined and removed streams we will now release any
media session resources associated with them. This was not
previously done and caused an issue where old state was being
used for a new stream.
4. RTP bundling was not actually removing bundled RTP instances
from the parent. This has been resolved by removing based on
the RTP instance itself and not the SSRC.
5. The code did not properly handle explicitly unbundling an
RTP instance from its parent. This now works as expected.
ASTERISK-27143
Change-Id: Ibd91362f0e4990b6129638e712bc8adf0899fd45
|
|
Case scenario with Applications ARI:
* Once you subscribe to deviceState with Applications REST API, it will be
added into subscription pool.
* When you unsubscribe it will remove from the device_state_subscription
hash table but not from the subscription pool.
* When you subscribe again, it will add it to pool again.
* Now you will have two subscriptions and you will receive same event
twice.
This fix should now remove deviceState subscription from pool and it
should fix unsubscribe on deviceState.
ASTERISK-27130 #close
Change-Id: I718b70d770a086e39b4ddba4f69a3c616d4476c4
|
|
|
|
|
|
|
|
|
|
This change makes it so that if an RTCP packet is being sent
the RTP ICE component is used for sending if RTCP-MUX is in use.
ASTERISK-27133
Change-Id: I6200f611ede709602ee9b89501720c29545ed68b
|
|
|
|
This patch creates a new configuration option called "webrtc". When enabled it
defaults and enables the following options that are needed in order for webrtc
to work in Asterisk:
rtcp-mux, use_avpf, ice_support, and use_received_transport=enabled
media_encryption=dtls
dtls_verify=fingerprint
dtls_setup=actpass
When "webrtc" is enabled, this patch also parses the "msid" media level
attribute from an SDP. It will also appropriately add it onto the outgoing
session when applicable.
Lastly, when "webrtc" is enabled h264 RTCP FIR feedback frames are now sent.
ASTERISK-27119 #close
Change-Id: I5ec02e07c5d5b9ad86a34fdf31bf2f9da9aac6fd
|
|
|
|
BUNDLE is a specification used in WebRTC to allow multiple
streams to use the same underlying transport. This reduces
the number of ICE and DTLS negotiations that has to occur
to 1 normally.
This change implements this by adding support for it to
the RTP SDP module in PJSIP. BUNDLE can be turned on using
the "bundle" option and on an offer we will offer to
bundle streams together. On an answer we will accept any
bundle groups provided. Once accepted each stream is bundled
to another RTP instance for transport.
For the res_rtp_asterisk changes the ability to bundle
an RTP instance to another based on the SSRC received
from the remote side has been added. For outgoing traffic
if an RTP instance is bundled to another we will use the
other RTP instance for any transport related things. For
incoming traffic received from the transport instance we
look up the correct instance based on the SSRC and use it
for any non-transport related data.
ASTERISK-27118
Change-Id: I96c0920b9f9aca7382256484765a239017973c11
|
|
Currently when rtp is paused, no packets are written to the
recorded audio file, causing the silence to be skipped and recording
not properly time aligned. The read handler as been adapted to
return a silence frame of the correct size.
ASTERISK-27128 #close
Change-Id: I2d7f60650457860b9c70907b14426756b058a844
|
|
arm the t38 webhook always, so we can correctly reject a
T38 negotiation request when t38 is disabled on a channel
Change-Id: Ib1ffe35aee145d4e0fe61dd012580be11aae079d
|
|
This adds a parameter to ast_waitfordigit_full which can be used to only
stop waiting when certain expected digits are received. Any unexpected
DTMF digits are simply ignored.
This also creates a new dialplan application WaitDigit.
ASTERISK-27129 #close
Change-Id: Id233935ea3d13e71c75a0861834c5936c3700ef9
|
|
established"
|
|
By default, when res_musiconhold reloads or unloads, it sends a HUP
signal to custom applications (and all descendants), waits 100ms,
then sends a TERM signal, waits 100ms, then finally sends a KILL
signal. An application which is interacting with an external
device and/or spawns children of its own may not be able to exit
cleanly in the default times, expecially if sent a KILL signal, or
if it's children are getting signals directly from
res_musiconhoild.
* To allow extra time, the 'kill_escalation_delay'
class option can be used to set the number of milliseconds
res_musiconhold waits before escalating kill signals, with the
default being the current 100ms.
* To control to whom the signals are sent, the "kill_method" class
option can be set to "process_group" (the default, existing
behavior), which sends signals to the application and its
descendants directly, or "process" which sends signals only to the
application itself.
Change-Id: Iff70a1a9405685a9021a68416830c0db5158603b
|
|
|
|
|
|
If the from_user field contains certain characters (like @, {, ^, etc.),
PJSIP will return a null value for the URI when attempting to parse it.
This causes a crash when trying to dial out through a trunk that contains
these invalid characters in its from_user field.
This change checks the configuration and ensures that an endpoint will
not be created if the from_user contains an invalid character. It also
adds a null check to the PJSIP URI parsing as a backup.
ASTERISK-27036 #close
Reported by: Maxim Vasilev
Change-Id: I0396fdb5080604e0bdf1277464d5c8a85db913d0
|
|
|
|
When a message is received on the TURN socket, the code processing the
message needs to call into the ICE/STUN session for further processing.
This code path locks the TURN group lock then the ICE/STUN group lock. In
another thread an ICE/STUN timer can fire off to send a keep alive message
over the TURN socket. In this code path, the ICE/STUN group lock is
obtained then the TURN group lock is obtained to send the packet. A
classic deadlock case if the group locks are not the same.
* Made TURN get created using the ICE/STUN session's group lock.
NOTE: I was originally concerned that the ICE/STUN session can get
recreated by ice_reset_session() for an event like RTCP multiplexing
causing a change during SDP negotiation. In this case the TURN group lock
would become different. However, TURN is also recreated as part of the
ICE/STUN recreation in ice_create() when all known ICE candidates are
added to the new ICE session. While the ICE/STUN and TURN sessions are
being recreated there is a period where the group locks could be
different.
ASTERISK-27023 #close
Patches:
res_rtp_asterisk-turn-deadlock-fix.patch (license #6502)
patch uploaded by Michael Walton (modified)
Change-Id: Ic870edb99ce4988a8c8eb6e678ca7f19da1432b9
|
|
|
|
|
|
|
|
This API was not actively maintained, was not added to new modules
(such as res_pjsip), and there exist better alternatives to acquire the
same information, such as the ARI.
Change-Id: I4b2185a83aeb74798b4ad43ff8f89f971096aa83
|
|
When a SIP message comes in on a transport, pjproject obtains the lock on
the transport and pulls the data out of the socket. Unlike UDP, the TCP
transport does not allow concurrent access. Without concurrency the
transport lock is not released when the transport's message complete
callback is called. The processing continues and eventually Asterisk
starts processing the SIP message. The first thing Asterisk tries to do
is determine the associated dialog of the message to determine the
associated serializer. To get the associated serializer safely requires
us to get the dialog lock.
To send a request or response message for a dialog, pjproject obtains the
dialog lock and then obtains the transport lock. Deadlock can result
because of the opposite order the locks are obtained.
* Fix the deadlock by obtaining the serializer associated with the dialog
another way that doesn't involve obtaining the dialog lock. In this case,
we use an ao2 container to hold the associated endpoint and serializer.
The new locks are held a brief time and won't overlap other existing lock
times.
ASTERISK-27090 #close
Change-Id: I9ed63f4da9649e9db6ed4be29c360968917a89bd
|
|
The OBJ_SEARCH_xxx defines should not be used as if they were individual
bits. They represent a multi-bit enumeration value field.
Change-Id: I32abc9a475396dab02402a7014357dd94284e17b
|
|
|
|
|
|
There needed to be a way to notify handlers upstream that DTLS had been
established. This patch makes it so once DTLS has been estalished a source
change control frame is put into the read queue. Any handlers can then watch
for that frame and trigger off of it.
ASTERISK-27096 #close
Change-Id: I27ff344f5a8c691a1890dfe3254a4b1a49e7f4a0
|
|
When connected_line_method is "invite", we're supposed to determine
if the client can support UPDATE and if it can, send UPDATE instead
of INVITE to avoid the SDP renegotiation. Not only was pjproject
not setting the PJSIP_INV_SUPPORT_UPDATE flag, we were testing
that invite_tsx wasn't NULL which isn't always the case.
* Updated chan_pjsip/update_connected_line_information to drop the
requirement that invite_tsx isn't NULL.
* Submitted patch to pjproject sip_inv.c that sets the
PJSIP_INV_SUPPORT_UPDATE flag correctly.
* Updated pjsip.conf.sample to clarify what happens when "invite"
is specified.
ASTERISK-27095
Change-Id: Ic2381b3567b8052c616d96fbe79564c530e81560
|
|
The existing auto dtmf mode reverts to inband if 4733 fails to be
negotiated. This patch adds a new mode auto_info which will
switch to INFO instead of inband if 4733 is not available.
ASTERISK-27066 #close
Change-Id: Id185b11e84afd9191a2f269e8443019047765e91
|
|
The stream topology (list of streams and order) is now stored with the
configured PJSIP endpoints and used during the negotiation process.
Media negotiation state information has been changed to be stored
in a separate object. Two of these objects exist at any one time
on a session. The active media state information is what was previously
negotiated and the pending media state information is what the
media state will become if negotiation succeeds. Streams and other
state information is stored in this object using the index (or
position) of each individual stream for easy lookup.
The ability for a media type handler to specify a callback for
writing has been added as well as the ability to add file
descriptors with a callback which is invoked when data is available
to be read on them. This allows media logic to live outside of
the chan_pjsip module.
Direct media has been changed so that only the first audio and
video stream are directly connected. In the future once the RTP
engine glue API has been updated to know about streams each individual
stream can be directly connected as appropriate.
Media negotiation itself will currently answer all the provided streams
on an offer within configured limits and on an offer will use the
topology created as a result of the disallow/allow codec lines.
If a stream has been removed or declined we will now mark it as such
within the resulting SDP.
Applications can now also request that the stream topology change.
If we are told to do so we will limit any provided formats to the ones
configured on the endpoint and send a re-invite with the new topology.
Two new configuration options have also been added to PJSIP endpoints:
max_audio_streams: determines the maximum number of audio streams to
offer/accept from an endpoint. Defaults to 1.
max_video_streams: determines the maximum number of video streams to
offer/accept from an endpoint. Defaults to 1.
ASTERISK-27076
Change-Id: I8afd8dd2eb538806a39b887af0abd046266e14c7
|
|
When re-inviting to add more streams it is possible for
the role of existing ICE sessions to be changed to the
incorrect value. This results in subsequent refreshes
within the sessions getting a role conflict and the ICE
session breaking down. This change only sets the role to
be the new value if an ICE renegotiation is actually
going to happen, otherwise the existing role is preserved.
As well if we encounter a situation where a unidirectional
ICE negotiation happens and the other side does not send us
candidates we will not store any information for sending
traffic, even though we know where they are reachable. This
change fixes this by using the source of the ICE traffic
itself as the target if no candidates are known and we
receive some ICE traffic.
ASTERISK-27088
Change-Id: I71228181e358917fcefc3100fad21b2fc02a59a9
|
|
The T38 sdp callback incorrectly has a side effect of incrementing
the media_count. This can lead to core dumps.
Change-Id: I7bb2f4987de4046ec52cfc34e5ea0662dae32af8
|
|
|
|
Change-Id: I0bc97c6608de1d1a4228826b3b3be43f162f05f3
|
|
Do not need to unsubscribe/subscribe on creating the ednpoint's contact.
The modified function create_mwi_subscriptions_for_endpoint adds
the subscription only if it does not exist.
The subscriptions aren't added for active contacts
which are retrieved on startup from realtime
if mwi_disable_initial_unsolicited=yes.
Because the mwi_contact_added is not called.
So the subscriptions also should be created on updating contact.
ASTERISK-26230 #close
Change-Id: I47e265af9296ca09aa42a316fdacac104148cee4
|
|
|
|
contact"
|
|
|
|
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
|
|
|
