When a call is put on hold and it has moh_passthrough and rtp_timeout
set on the endpoint, the wrong timeout will be used. rtp_timeout_hold is
expected to be used, but rtp_timeout is used instead. This change adds a
couple of checks for locally_held to determine if rtp_timeout_hold needs
to be used instead of rtp_timeout.
ASTERISK-30350
Change-Id: I7b106fc244332014216d12bba851cefe884cc25f
This patch adds support for mediasec SIP headers and SDP attributes.
These are defined in RFC 3329, 3GPP TS 24.229 and
draft-dawes-sipcore-mediasec-parameter. The new features are
implemented so that a backbone for RFC 3329 is present to streamline
future work on RFC 3329.
With this patch, Asterisk can communicate with Deutsche Telekom trunks
which require these fields.
ASTERISK-30032
Change-Id: Ia7f5b5ba42db18074fdd5428c4e1838728586be2
When producing an outgoing SDP we iterate through the configured
formats and produce SDP information. It is possible for some
configured formats to not have SDP information available. If this
is the case we skip over them to allow the SDP to still be
produced.
ASTERISK-29185
Change-Id: I3e37569aa4ca341260e6ca5904dc2f75e46a1749
Change RTP timer behavior for detecting RTP only after two-way
SDP channel establishment. Ignore detecting after receiving 183
with SDP or while direct media is used.
Make rtp_timeout and rtp_timeout_hold options consistent to rtptimeout
and rtpholdtimeout options in chan_sip.
ASTERISK-26689 #close
ASTERISK-29929 #close
Change-Id: I07326d5b9c40f25db717fd6075f6f3a8d77279eb
Added two new functions to assist checking media types...
* ast_sip_are_media_types_equal compares two pjsip_media_types.
* ast_sip_is_media_type_in tests if one media type is in a list
of others.
Added static definitions for commonly used media types to
res_pjsip.h.
Changed several modules to use the new functions and static
definitions.
ASTERISK_29813
(not ready to close)
Change-Id: Ief77675235bd3bf00a6b095d4673fd878d0801b9
The ast_rtp_codecs_payloads functions do not preserve the order in which
the payloads were specified on an incoming SDP media line. This leads to
a problem with the codec negotiation functionality, as the format
capabilities of the stream are extracted from the ast_rtp_codecs. This
commit moves the ast_rtp_codec to ast_format conversion to the place
where the order is still known.
ASTERISK-28863
ASTERISK-29320
Change-Id: I3aabcfed3f379c36654f59c1872c313d0cb57e25
With the fix for ASTERISK_28754 channels are no longer put on hold if an
outbound INVITE is answered with a "Session Progress" containing
"inactive" audio.
The previous change moved the evaluation of the media attributes to
`negotiate_incoming_sdp_stream()` to have the `remotely_held` status
available when building the SDP in `create_outgoing_sdp_stream()`.
This however means that an answer to an outbound INVITE, which does not
traverse `negotiate_incoming_sdp_stream()`, cannot set the
`remotely_held` status anymore.
This change moves the check so that both, `negotiate_incoming_sdp_stream()` and
`apply_negotiated_sdp_stream()` can do the checks.
ASTERISK-29479
Change-Id: Icde805a819399d5123b688e1ed1d2bcd9d5b0f75
This change will check is the remote ICE session got reset or not by
checking the offered ufrag and password with session. If the remote ICE
reset session then Asterisk reset its local ufrag and password to reject
binding request with Old ufrag and Password.
ASTERISK-29266
Change-Id: I9c55e79a7af98a8fbb497d336b828ba41bc34eeb
Added debug logging categories that allow a user to output debug
information based on a specified category. This lets the user limit,
and filter debug output to data relevant to a particular context,
or topic. For instance the following categories are now available for
debug logging purposes:
dtls, dtls_packet, ice, rtcp, rtcp_packet, rtp, rtp_packet,
stun, stun_packet
These debug categories can be enable/disable via an Asterisk CLI command.
While this overrides, and outputs debug data, core system debugging is
not affected by this patch. Statements still output at their appropriate
debug level. As well backwards compatibility has been maintained with
past debug groups that could be enabled using the CLI (e.g. rtpdebug,
stundebug, etc.).
ASTERISK-29054 #close
Change-Id: I6e6cb247bb1f01dbf34750b2cd98e5b5b41a1849
Stop advertising RFC2833 support on the rtp_engine when DTMF mode is
auto but no tel_event was found inside SDP file.
On an incoming call create_rtp will be called and when session->dtmf is
set to AST_SIP_DTMF_AUTO, the AST_RTP_PROPERTY_DTMF will be set without
looking at the SDP file.
Once get_codecs gets called we move the DTMF mode from RFC2833 to INBAND
but continued to advertise RFC2833 support.
This meant the native_rtp bridge would falsely consider the two channels
as compatible. In addition to changing the DTMF mode we now set or
remove the AST_RTP_PROPERTY_DTMF.
The property is checked in ast_rtp_dtmf_compatible and called by
native_rtp_bridge_compatible.
ASTERISK-29051 #close
Change-Id: I1e0c1e324598a437932c0b7836bcb626aba8e287
Prior to making any modifications to the pjsip infrastructure
for ACN, I've added the tracing functions to the existing code.
This should make the final commit easier to review, but we can also
now run a "before and after" trace.
No functional changes were made with this commit.
Change-Id: Ia83a1a2687ccb96f2bc8a2a3928a5214c4be775c
Based on this new endpoint setting, a joint list of preferred codecs
between those received from the Asterisk core (remote), and those
specified in the endpoint's "allow" parameter (local) is created and
is used to create the outgoing SDP offer.
* Add outgoing_call_offer_pref to pjsip_configuration (endpoint)
* Add "call_direction" to res_pjsip_session.
* Update pjsip_session_caps.c to make the functions more generic
so they could be used for both incoming and outgoing.
* Update ast_sip_session_create_outgoing to create the
pending_media_state->topology with the results of
ast_sip_session_create_joint_call_stream().
* The endpoint "preferred_codec_only" option now automatically sets
AST_SIP_CALL_CODEC_PREF_FIRST in incoming_call_offer_pref.
* A helper function ast_stream_get_format_count() was added to
streams to return the current count of formats.
ASTERISK-28777
Change-Id: Id4ec0b4a906c2ae5885bf947f101c59059935437
When examining a stream to determine hold/unhold information we
only care about the default audio stream. Other streams aren't
used for hold/unhold.
ASTERISK-28784
Change-Id: I7a1f10f07822c4aee1f98a38b9628849b578afe4
Do not hang up a PJSIP channel on RTP timeout if that channel is in
a direct-media bridge. Also reset the time of the last received RTP packet when
direct-media ends (wait full rtp_timeout period before checking first time after
audio came back to Asterisk).
ASTERISK-28774
Reported-by: Michael Neuhauser
Change-Id: I8b62012be7685849e8fb2b1c5dd39d35313ca2d1
If ICE support is enabled but not negotiated, the rtp->ice structure is
not being destroyed. This leads to Asterisk waiting for ICE to complete
instead of immediately starting the DTLS handshake, resulting in the
call leg having no RTP.
ASTERISK-28769 #close
Change-Id: I17c137546dc9ecfb9583c24dcf4c2ced8bbd7a27
Add a new option, incoming_call_offer_pref, to res_pjsip endpoints that
specifies the preferred order of codecs after receiving an offer.
This patch does the following:
Adds a new enumeration, ast_sip_call_codec_pref, used by the the new
configuration option that's added to the endpoint media structure.
Adds a new ast_sip_session_caps structure that's set for each session media
object.
Creates a new file, res_pjsip_session_caps that "implements" the new
structure and option, and is compiled into the res_pjsip_session library.
ASTERISK-28756 #close
Change-Id: I35e7a2a0c236cfb6bd9cdf89539f57a1ffefc76f
Update the state of remote_hold immediately on receipt of remote
SDP so that the information is available when building the SDP
answer
ASTERISK-28754 #close
Change-Id: I7026032a807e9c95081cb8f060400b05deb4836f
This change adds support to bridge_softmix to allow the addition
and removal of additional video source streams. When such a change
occurs each participant is renegotiated as needed to reflect the
update. If another video source is added then each participant
gets another source. If a video source is removed then it is
removed from each participant. This functionality allows you to
have both your webcam and screenshare providing video if you
desire, or even more streams. Mapping has been changed to use
the topology index on the source channel as a unique identifier
for outgoing participant streams, this will never change and
provides an easy way to establish the mapping.
The bridge_simple and bridge_native_rtp modules have also been
updated to renegotiate when the stream topology of a party changes
allowing the same behavior to occur as added to bridge_softmix.
If a screen share is added then the opposite party is renegotiated.
If that screen share is removed then the opposite party is
renegotiated again.
Some additional fixes are also included in here. Stream state is
now conveyed in SDP so sendonly/recvonly/inactive streams can
be requested. Removed streams now also remove previous state
from themselves so consumers don't get confused.
ASTERISK-28733
Change-Id: I93f41fb41b85646bef71408111c17ccea30cb0c5
When moh_passthrough is used, asterisk is only generating invites
of type sendonly and sendrecv instead of taking fully into account
the on hold state of the local and remote parties
ASTERISK-28738 #close
Change-Id: Iaaad9fbc033cb14803d433b8a4071bc337047761
Somehow it's possible for the srtp session object to be NULL even though the
Asterisk srtp object itself is valid. When this happened it would cause a
crash down in the srtp code when attempting to protect or unprotect data.
After looking at the code there is at least one spot that makes this situation
possible. If Asterisk fails to unprotect the data, and after several retries
it still can't then the srtp->session gets freed, and set to NULL while still
leaving the Asterisk srtp object around. However, according to the original
issue reporter this does not appear to be their situation since they found
no errors logged stating the above happened (which Asterisk does for that
situation).
An issue was found however, where a possible race condition could occur between
the pjsip incoming negotiation, and the receiving of RTP packets. Both places
could attempt to create/setup srtp for the same rtp instance at the same time.
This potentially could be the cause of the problem as well.
Given the above this patch adds locking around srtp setup for a given rtp, or
rtcp instance. NULL checks for the session have also been added within the
protect and unprotect functions as a precaution. These checks should at least
stop Asterisk from crashing if it gets in this situation again.
This patch also fixes one other issue noticed during investigation. When doing
a replace the old object was freed before creating the replacement. If the new
replacement object failed to create then the rtp/rtcp instance would now point
to freed srtp data which could potentially cause a crash as well when the next
attempt to reference it was made. This is now fixed so the old srtp object is
kept upon replacement failure.
Lastly, more logging has been added to help diagnose future issues.
ASTERISK-28472
Change-Id: I240e11cbb1e9ea8083d59d50db069891228fe5cc
The transport-cc draft is a mechanism by which additional information
about packet reception can be provided to the sender of packets so
they can do sender side bandwidth estimation. This is accomplished
by having a transport specific sequence number and an RTCP feedback
message. This change implements this in the receiver direction.
For each received RTP packet where transport-cc is negotiated we store
the time at which the RTP packet was received and its sequence number.
At a 1 second interval we go through all packets in that period of time
and use the stored time of each in comparison to its preceding packet to
calculate its delta. This delta information is placed in the RTCP
feedback message, along with indicators for any packets which were not
received.
The browser then uses this information to better estimate available
bandwidth and adjust accordingly. This may result in it lowering the
available send bandwidth or adjusting how "bursty" it can be.
ASTERISK-28400
Change-Id: I654a2cff5bd5554ab94457a14f70adb71f574afc
apply_negotiated_sdp_stream was returning a "1" when no joint
capabilities were found on an outgoing call instead of a "-1".
This indicated to res_pjsip_session that the handler DID handle
the sdp when in fact it didn't. Without the appropriate setup,
a subsequent media frame coming in would have an invalid stream_num
and cause a seg fault when the stream was attempted to be retrieved.
apply_negotiated_sdp_stream now returns the correct "-1" and any
media is now discarded before it reaches the core stream processing.
ASTERISK-28260
Reported by: Sotiris Ganouris
Change-Id: Ia095cb16b4862f2f6ad6d2d2a77453fa2542371f
When processing SSRC attributes we were iterating through
all of them, even though we only need to know the remote
SSRC once. This was problematic because some browsers group
SSRCs together on a stream, and due to our negotiation only
end up using the first one. Since we set the second one as
the remote SSRC we would drop the received media from them
instead of allowing it through.
In the future this may be extended to allow SSRC groups
and to use information from the attributes.
Change-Id: I4dc87087dbe56a83aa65f0f897bbd4ca75ec1270
To avoid the stream name collide if there're more than one video track
in one client. If client has multi video tracks, the name of ast_stream
which represents each video track may be the same. Use the MSID:LABEL
here because it's identifiable.
ASTERISK-28196 #close
Reported-by: xiemchen
Change-Id: Ib62b2886e8d3a30e481d94616b0ceaeab68a870b
For video streams it was possible for the abs-send-time information
to be placed into RTP streams even if not negotiated. Depending on
the endpoint in use this could cause video to not flow.
We now only enable abs-send-time for negotiation if WebRTC is enabled.
ASTERISK-28230
Change-Id: I0eb682302f8da3a4ea3c42e839208d55f825ed0c
This change brings in PJSIP 2.8, removes all the patches
that were merged upstream, and makes a minor change to
support a breaking change that was done.
ASTERISK-28059
Change-Id: I5097772b11b0f95c3c1f52df6400158666f0a189
If in the initial sdp the caller doesn't include the line
a=rtcp-mux
Then asterisk shoud not include rtcp-mux in the response regardless
of rtcp-mux being enabled on the endpoint
ASTERISK-28007 #close
Change-Id: I58e9b9f40a139afc0da5de41906cc608fb62adc7
Previously, the msid "label" attribute was used to correlate
participant info but because streams could be reused, the msid
wasn't being updated correctly when someone left the bridge and
another joined.
Now, instead of looking for the msid attribute on a channel's streams,
app_confbridge sets an "SDP:LABEL" attribute on the stream which
res_pjsip_sdp_rtp looks for. If it finds it, it adds a "label"
attribute to the current sdp.
Change-Id: I6cbaa87fb59a2e0688d956e72d2d09e4ac20d5a5
Keep track if ICE candidates were in the SDP offer & only put them
in the corresponding SDP answer if the offer condaind ICE candidates
ASTERISK-27957 #close
Change-Id: Idf2597ee48e9a287e07aa4030bfa705430a13a92
ConfBridge can now send events to participants via in-dialog MESSAGEs.
All current Confbridge events are supported, such as ConfbridgeJoin,
ConfbridgeLeave, etc. In addition to those events, a new event
ConfbridgeWelcome has been added that will send a list of all
current participants to a new participant.
For all but the ConfbridgeWelcome event, the JSON message contains
information about the bridge, such as its id and name, and information
about the channel that triggered the event such as channel name,
callerid info, mute status, and the MSID labels for their audio and
video tracks. You can use the labels to correlate callerid and mute
status to specific video elements in a webrtc client.
To control this behavior, the following options have been added to
confbridge.conf:
bridge_profile/enable_events: This must be enabled on any bridge where
events are desired.
user_profile/send_events: This must be set for a user profile to send
events. Different user profiles connected to the same bridge can have
different settings. This allows admins to get events but not normal
users for instance.
user_profile/echo_events: In some cases, you might not want the user
triggering the event to get the event sent back to them. To prevent it,
set this to false.
A change was also made to res_pjsip_sdp_rtp to save the generated msid
to the stream so it can be re-used. This allows participant A's video
stream to appear as the same label to all other participants.
Change-Id: I26420aa9f101f0b2387dc9e2fd10733197f1318e
When RTP was originally created it had the ability to place a single
extension in an RTP packet. In practice people wanted to potentially
put multiple extensions in one and so RFC 5285 (obsoleted by RFC
8285) came into existence. This allows RTP extensions to be negotiated
with a unique identifier to be used in the RTP packet, allowing
multiple extensions to be present in the packet.
This change extends the RTP engine API to add support for this. A
user of it can enable extensions and the API provides the ability to
retrieve the information (to construct SDP for example) and to provide
negotiated information (from SDP). The end result is that the RTP
engine can then query to see if the extension has been negotiated and
what unique identifier is to be used. It is then up to the RTP engine
implementation to construct the packet appropriately.
The first extension to use this support is abs-send-time which is
defined in the REMB draft[1] and is a second timestamp placed in an
RTP packet which is for when the packet has left the sending system.
It is used to more accurately determine the available bandwidth.
ASTERISK-27831
[1] https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
Change-Id: I508deac557867b1e27fc7339be890c8018171588
Adds the ability to receive and handle incoming NACK requests if
retransmissions are enabled. If retransmissions are enabled, a data
buffer is allocated that stores packets being sent. If a NACK request
is received, the packet requested for retransmission is sent if it is
still in the buffer. In the same request, if any of the following 16
packets are marked as not received, those will be sent as well if
available, as outlined in RFC4585.
Also changes RTCP RR and SR to use media source SSRC instead of packet
source SSRC when determining which instance to use for RTCP reports.
For more information, refer to the wiki page:
https://wiki.asterisk.org/wiki/display/AST/WebRTC+User+Experience+Improvements
ASTERISK-27806 #close
Change-Id: I7f7f124af3b9d5d2fd9cffc6ba8cb48a6fff06ec
This change adds a property to RTP instances to indicate that
REMB support is enabled and that sending/receiving should be
passed through.
This also enables it on video RTP instances in PJSIP if
WebRTC support is enabled.
Finally the goog-remb extension is added to the SDP using
the rtcp-fb attribute to indicate our support for it.
Details about REMB can be found on the draft document for it:
https://tools.ietf.org/html/draft-alvestrand-rmcat-remb-03
Change-Id: I1902dda1c0882bd1a0d71b2f120684b44b97e789
A couple of additional properties are needed in rtp_engine to enable
support for packet retransmission: AST_RTP_PROPERTY_RETRANS_RECV and
AST_RTP_PROPERTY_RETRANS_SEND. These will both be enabled automatically
if an endpoint has the webrtc option enabled. While this adds no
functionality currently, it will serve as a building block for future
changes for RTP retransmission support.
For more information, refer to the wiki page:
https://wiki.asterisk.org/wiki/display/AST/WebRTC+User+Experience+Improvements
Change-Id: Ic598acd042a045f9d10e5bdccb66f4efc9e587cc
This removes references that are no longer needed due to automatic
references created by module dependencies.
In addition this removes most calls to ast_module_check as they were
checking modules which are listed as dependencies.
Change-Id: I332a6e8383d4c72c8e89d988a184ab8320c4872e
* Declare 'requires' and 'enhances' text fields on module info structure.
* Rename 'nonoptreq' to 'optional_modules'.
* Update doxygen comments.
Still need to investigate dependencies among modules I cannot compile.
Change-Id: I3ad9547a0a6442409ff4e352a6d897bef2cc04bf
Per RFC 5245, the foundation specified with an ICE candidate can be up
to 32 characters but we are only allowing for 31.
ASTERISK-27498 #close
Reported by: Michele Prà
Change-Id: I05ce7a5952721a76a2b4c90366168022558dc7cf
add_crypto_to_stream wasn't checking for a NULL
session->inv_session->neg before calling pjmedia_sdp_neg_get_state.
This was causing a crash if the negotiation hadn't already been
completed and asterisk was compiled with --enable-dev-mode.
Change-Id: I57c6229954a38145da9810fc18657bfcc4d9d0c9
In WebRTC streams (or media tracks in their world) can be grouped
together using the mslabel. This informs the browser that each
should be synchronized with each other.
This change extends the stream API so this information can
be stored with streams. The PJSIP support has been extended
to use the mslabel to determine grouped streams and store
this association on the streams. Finally when creating the
SDP the group information is used to cause each media stream
to use the same mslabel.
ASTERISK-27379
Change-Id: Id6299aa031efe46254edbdc7973c534d54d641ad
create_outgoing_sdp_stream was setting "addr_type = STR_IP6" only
when an ipv6 media_address was specified on the endpoint. If
rtp_ipv6 was set and ast_sip_get_host_ip_string returned an ipv6
address, we were leaving the addr_type set at the default of
STR_IP4. This caused the address type to be set incorrectly on the
"o" and "c" SDP attributes even though the address was set
correctly. Some clients don't like the mismatch.
* Removed the test for endpoint/media_address and now check all
addresses for ipv6.
ASTERISK-27198
Reported by: Martin Cisárik
Change-Id: I5214fc31b728117842243807e7927a319cf77592
Some endpoints do not like a stream being reused for a new
media stream. The frame/jitterbuffer can rely on underlying
attributes of the media stream in order to order the packets.
When a new stream takes its place without any notice the
buffer can get confused and the media ends up getting dropped.
This change uses the SSRC change to determine that a new source
is reusing an existing stream and then bridge_softmix renegotiates
each participant such that they see a new media stream. This
causes the frame/jitterbuffer to start fresh and work as expected.
ASTERISK-27277
Change-Id: I30ccbdba16ca073d7f31e0e59ab778c153afae07
When a sip session is refreshed, the stream topology is looped
through, checking each stream for compatible formats. This would
cause a crash if the stream state was AST_STREAM_STATE_REMOVED,
since the formats would never be set for this stream, causing
a NULL value to be returned from ast_stream_get_formats. This
commit adds a check for streams with removed states.
Also removed a stray semicolon.
Change-Id: Ic86f8b65a4a26a60885b28b8b1a0b22e1b471d42
Ben Ford
Maximilian Fridrich
Joshua C. Colp
Boris P. Korzun
Luke Escude
George Joseph
Florentin Mayer
Alexander Traud
Bernd Zobl
Salah Ahmed
Kevin Harwell
Holger Hans Peter Freyther
DanielYK
Michael Neuhauser
Torrey Searle
Joshua Colp
Xiemin Chen
Corey Farrell
Sean Bright