3 Commits (4262a5aa6a3d4d74e909e2d1586816bf4d52654c)

Author	SHA1	Message	Date
Mark Michelson	d6535c0080	SDP API: Add SSRC-level attributes ... 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	9 years ago
Joshua Colp	19a79ae12c	sdp: Add support for T.38 ... 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	9 years ago
Mark Michelson	32b3e36c68	SDP: Ensure SDPs "merge" properly. ... 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	9 years ago