| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Change-Id: I873c1c6d00f447269bd841494459efccdd2c19c0
|
|
Fix instances of:
* Retreive
* Recieve
* other then
* different then
* Repeated words ("the the", "an an", "and and", etc).
* othterwise, teh
ASTERISK-24198 #close
Change-Id: I3809a9c113b92fd9d0d9f9bac98e9c66dc8b2d31
|
|
Change-Id: I84a83ae69daba5d185cc1d939b133a4c23565497
|
|
* Update SDP unit tests to test negotiating with declined streams.
Generation of declined m= lines created and responded tested.
Change-Id: I5cb99f5010994ab0c7d9cf2d395eca23fab37b98
|
|
The SDP offer/answer model requires an answer to an offer before a new SDP
can be processed. This allows our local SDP creation to be deferred until
we know that we need to create an offer or an answer SDP. Once the local
SDP is created it won't change until the SDP negotiation is restarted.
An offer SDP in an initial SIP INVITE can receive more than one answer
SDP. In this case, we need to merge each answer SDP with our original
offer capabilities to get the currently negotiated capabilities. To
satisfy this requirement means that we cannot update our proposed
capabilities until the negotiations are restarted.
Local topology updates from ast_sdp_state_update_local_topology() are
merged together until the next offer SDP is created. These accumulated
updates are then merged with the current negotiated capabilities to create
the new proposed capabilities that the offer SDP is built.
Local topology updates are merged in several passes to attempt to be smart
about how streams from the system are matched with the previously
negotiated stream slots. To allow for T.38 support when merging, type
matching considers audio and image types to be equivalent. First streams
are matched by stream name and type. Then streams are matched by stream
type only. Any remaining unmatched existing streams are declined. Any
new active streams are either backfilled into pre-merge declined slots or
appended onto the end of the merged topology. Any excess new streams
above the maximum supported number of streams are simply discarded.
Remote topology negotiation merges depend if the topology is an offer or
answer. An offer remote topology negotiation dictates the stream slot
ordering and new streams can be added. A remote offer can do anything to
the previously negotiated streams except reduce the number of stream
slots. An answer remote topology negotiation is limited to what our offer
requested. The answer can only decline streams, pick codecs from the
offered list, or indicate the remote's stream hold state.
I had originally kept the RTP instance if the remote offer SDP changed a
stream type between audio and video since they both use RTP. However, I
later removed this support in favor of simply creating a new RTP instance
since the stream's purpose has to be changing anyway. Any RTP packets
from the old stream type might cause mischief for the bridged peer.
* Added ast_sdp_state_restart_negotiations() to restart the SDP
offer/answer negotiations. We will thus know to create a new local SDP
when it is time to create an offer or answer.
* Removed ast_sdp_state_reset(). Save the current topology before
starting T.38. To recover from T.38 simply update the local topology to
the saved topology and restart the SDP negotiations to get the offer SDP
renegotiating the previous configuration.
* Allow initial topology for ast_sdp_state_alloc() to be NULL so an
initial remote offer SDP can dictate the streams we start with. We can
always update the local topology later if it turns out we need to offer
SDP first because the remote chose to defer sending us a SDP.
* Made the ast_sdp_state_alloc() initial topology limit to max_streams,
limit to configured codecs, handle declined streams, and discard
unsupported types.
* Convert struct ast_sdp to ao2 object. Needed to easily save off a
remote SDP to refer to later for various reasons such as generating
declined m= lines in the local SDP.
* Improve converting remote SDP streams to a topology including stream
state. A stream state of AST_STREAM_STATE_REMOVED indicates the stream is
declined/dead.
* Improve merging streams to take into account the stream state.
* Added query for remote hold state.
* Added maximum streams allowed SDP config option.
* Added ability to create new streams as needed. New streams are created
with configured default audio, video, or image codecs depending on stream
type.
* Added global locally_held state along with a per stream local hold
state. Historically, Asterisk only has a global locally held state
because when the we put the remote on hold we do it for all active
streams.
* Added queries for a rejected offer and current SDP negotiation role.
The rejected query allows the using module to know how to respond to a
failed remote SDP set. Should the using module respond with a 488 Not
Acceptable Here or 500 Internal Error to the offer SDP?
* Moved sdp_state_capabilities.connection_address to ast_sdp_state. There
seems no reason to keep it in the sdp_state_capabilities struct since it
was only used by the ast_sdp_state.proposed_capabilities instance.
* Callbacks are now available to allow the using module some customization
of negotiated streams and to complete setting up streams for use. See the
typedef doxygen for each callback for what is allowable and when they are
called.
* Added topology answerer modify callback.
* Added topology pre and post apply callbacks.
* Added topology offerer modify callback.
* Added topology offerer configure callback.
* Had to rework the unit tests because I changed how SDP topologies are
merged. Replaced several unit tests with new negotiation tests.
Change-Id: If07fe6d79fbdce33968a9401d41d908385043a06
|
|
Change-Id: I82dc75c63c48904e9e5a49e2205dcc06e88487e4
|
|
* Pulled finding the rtcp-mux attribute flag out of the ICE candidate for
loop. Also ordered the RTCP ICE candidate skip test to fail earlier.
Change-Id: I8905d9c68563027a46cd3ae14dbcc27e9c814809
|
|
Change-Id: I23b646392082deab65bedeb19b12dcbcb9216d0c
|
|
Change-Id: I4060391328a893101ed87d0d9bacbbab4fd8b141
|
|
This sets up the "plumbing" in bridge_softmix to
be able to accommodate Asterisk asking as an SFU
(selective forwarding unit) for conferences.
The way this works is that whenever a channel enters or leaves a
conference, all participants in the bridge get sent a stream topology
change request. The topologies consist of the channels' original
topology, along with video destination streams corresponding to each
participants' source video streams. So for instance, if Alice, Bob, and
Carol are in the conference, and each supplies one video stream, then
the topologies for each would look like so:
Alice:
Audio,
Source video(Alice),
Destination Video(Bob),
Destination video (Carol)
Bob:
Audio,
Source video(Bob)
Destination Video(Alice),
Destination video (Carol)
Carol:
Audio,
Source video(Carol)
Destination Video(Alice),
Destination video (Bob)
This way, video that arrives from a source video stream can then be
copied out to the destination video streams on the other participants'
channels.
Once the bridge gets told that a topology on a channel has changed, the
bridge constructs a map in order to get the video frames routed to the
proper destination streams. This is done using the bridge channel's
stream_map.
This change is bare-bones with regards to SFU support. Some key features
are missing at this point:
* Stream limits. This commit makes no effort to limit the number of
streams on a specific channel. This means that if there were 50 video
callers in a conference, bridge_softmix will happily send out topology
change requests to every channel in the bridge, requesting 50+
streams.
* Configuration. The plumbing has been added to bridge_softmix, but
there has been nothing added as of yet to app_confbridge to enable SFU
video mode.
* Testing. Some functions included here have unit tests.
However, the functionality as a whole has only been verified by
hand-tracing the code.
* Selectivenss. For a "selective" forwarding unit, this does not
currently have any means of being selective.
* Features. Presumably, someone might wish to only receive video from
specific sources. There are no external-facing functions at the moment
that allow for users to select who they receive video from.
* Efficiency. The current scheme treats all video streams as being
unidirectional. We could be re-using a source video stream as a
desetnation, too. But to simplify things on this first round, I did it
this way.
Change-Id: I7c44a829cc63acf8b596a337b2dc3c13898a6c4d
|
|
* Made sdp_add_m_from_rtp_stream() and sdp_add_m_from_udptl_stream()
handle generating disabled/declined streams.
* Added /main/sdp/sdp_merge_asymmetric unit test. It currently does not
check the offerer side negotiated SDP because that isn't the purpose of
this patch and there is much to be done to handle declined/dummy streams.
* Added T.38 image streams to the /main/sdp/sdp_merge_symmetric and
/main/sdp/sdp_merge_crisscross unit tests.
Change-Id: Ib4dcb3ca4f9a9133b376f4e3302f9a1f963f2b31
|
|
* Tried to give better variable names.
* Made our SDP answer use the offer's RTP payload types as the SDP RFC
says we SHOULD.
* Updating the local topology now takes the stream format caps. We are
likely preparing to send an offer.
Change-Id: I34d3be8e3036402a8575ffcae3eebc5ce348d7c0
|
|
* Add failure exits to ast_get_topology_from_sdp().
Change-Id: I4cc85c1ede8d712766ed20f544dbcef04c8c1049
|
|
The sdp_state.remote_capabilities was only used inside merge_sdps() and
subsequent calls to merge_sdps() by re-INVITE's would leak them.
Change-Id: I0ceb7838ea044cc913e8ad4a255c39c9740ae0ce
|
|
When we optionally set the interface_address we are forcing the media to
go out a specific interface address. This allows us to optionally have
the media go out the interface that SIP signalling came in on or if we are
configured to have the media always go out a specific address.
Change-Id: I160d9fac322a075bd2557b430632544178196189
|
|
The telephone_event option was used as a flag and a bit mapped value in
different places when it is a boolean. It is also inadequate to configure
the DTMF operation of the RTP instance created for the stream.
Change-Id: Ib1addeaf0ce86f07039f2f979cab29405dc5239b
|
|
|
|
|
|
|
|
Change-Id: I473a174b869728604b37c60853896b0c458bc504
|
|
Change-Id: I7707c9d872c476d897ff459008652b35142a35e1
|
|
Change-Id: I74431b385da333f2c5f5a6d7c55e70b69a4f05d2
|
|
RFC 5576 defines how SSRC-level attributes may be added to SDP media
descriptions. In general, this is useful for grouping related SSRCes,
indicating SSRC-level format attributes, and resolving collisions in RTP
SSRC values. These attributes are used widely by browsers during WebRTC
communications, including attributes defined by documents outside of RFC
5576.
This commit introduces the addition of SSRC-level attributes into SDPs
generated by Asterisk. Since Asterisk does not tend to use multiple
SSRCs on a media stream, the initial support is minimal. Asterisk
includes an SSRC-level CNAME attribute if configured to do so. This at
least gives browsers (and possibly others) the ability to resolve SSRC
collisions at offer-answer time.
In order to facilitate this, the RTP engine API has been enhanced to be
able to retrieve the SSRC and CNAME on a given RTP instance.
res_rtp_asterisk currently does not provide meaningful CNAME values in
its RTCP SDES items, and therefore it currently will always return an
empty string as the CNAME value. A task in the near future will result
in res_rtp_asterisk generating more meaningful CNAMEs.
Change-Id: I29e7f23e7db77524f82a3b6e8531b1195ff57789
|
|
This change adds a T.38 format which can be used in a stream
topology to specify that a UDPTL stream needs to be created.
The SDP API has been changed to understand T.38 and create
the UDPTL session, add the attributes, and parse the attributes.
This change does not change the boundary of the T.38 state
machine. It is still up to the channel driver to implement and
act on it (such as queueing control frames or reacting to them).
ASTERISK-26949
Change-Id: If28956762ccb8ead562ac6c03d162d3d6014f2c7
|
|
The gist of this work ensures that when a remote SDP is received, it is
merged properly with the local capabilities. The remote SDP is converted
into a stream topology. That topology is then merged with the current
local topology on the SDP state. That new merged topology is then used
to create an SDP. Finally, adjustments are made to RTP instances based
on knowledge gained from the remote SDP.
There are also a battery of tests in this commit that ensure that some
basic SDP merges work as expected.
While this may not sound like a big change, it has the property that it
caused lots of ancillary changes.
* The remote SDP is no longer stored on the SDP state. Biggest reason:
there's no need for it. The remote SDP is used at the time it is being
set and nowhere else.
* Some new SDP APIs were added in order to find attributes and convert
generic SDP attributes into rtpmap structures.
* Writing tests made me realize that retrieving a value from an SDP
options structure, the SDP options needs to be made const.
* The SDP state machine was essentially gutted by a previous commit.
Initially, I attempted to reinstate it, but I found that as it had
been defined, it was not all that useful. What was more useful was
knowing the role we play in SDP negotiation, so the SDP state machine
has been transformed into an indicator of role.
* Rather than storing separate local and joint stream state
capabilities, it makes more sense to keep track of current stream
state and update it as things change.
Change-Id: I5938c2be3c6f0a003aa88a39a59e0880f8b2df3d
|
|
This change cleans up state management for media streams by moving
RTP instances into their own session structure and adding additional
details that are not relevant to the core (such as connection address).
These can live either in the local capabilities or joint capabilities.
The ability to set explicit connection address information for
the purposes of direct media and NAT has also been added at the
global and stream specific level.
ASTERISK-26900
Change-Id: If7e5307239a9534420732de11c451a2705b6b681
|
|
* Added additional fields to ast_sdp_options.
* Re-organized ast_sdp.
* Updated field names to correspond to RFC4566 terminology.
* Created allocs/frees for SDP children.
* Created getters/setters for SDP children where appropriate.
* Added ast_sdp_create_from_state.
* Refactored res_sdp_translator_pjmedia for changes.
Change-Id: Iefbd877af7f5a4d3c74deead1bff8802661b0d48
|
|
This introduces and documents the various states in the state machine.
This also introduces API functions that induce state changes, and places
TODO comments telling what needs to be done in addition to what is
already there. Those TODOs will be replaced with real code in upcoming
changes.
Change-Id: I871c0eb480b4c84d83e91ac5628e7a673e8b89ed
|
|
This establishes the basic allocation/destruction of an SDP state
object, plus some of the simpler getter methods involved. Subsequent
tasks will deal with adding a state machine, creating SDPs from
capabilities and options, and merging SDPs into a joint SDP.
Change-Id: Ie3757ce186f04b65e9d1883f5aace53f24e53709
|
