This library is free software; you can redistribute it and/or modify it under the terms of the GNU Lesser General Public License as published by the Free Software Foundation; either version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Lesser General Public License for more details.

You should have received a copy of the GNU Lesser General Public License along with this library; if not, write to the Free Software Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.

(as stable API)

This object represents an endpoint for a stream. In a one-to-one call, there will be one (bidirectional) stream per content and one endpoint per stream (as there is only one remote contact). In a multi-user call there is a stream for each remote contact and each stream has one endpoint as it refers to the one physical machine on the other end of the stream.

The multiple endpoint use case appears when SIP call forking is used. Unlike jingle call forking (which is just making multiple jingle calls to different resources appear as one call), SIP call forking is actually done at the server so you have one stream to the remote contact and then and endpoint for each SIP client to be called.

The ICE credentials used for all candidates. If each candidate has different credentials, then this property SHOULD be ("", ""). Per-candidate credentials are set in the Candidate's Candidate_Info a{sv}. The username set. The password set. Emitted when the remote ICE credentials for the endpoint are set. If each candidate has different credentials, then this signal will never be fired. A list of candidates for this endpoint. Emitted when remote candidates are added to the RemoteCandidates property. The candidates that were added. A Pair of candidates. The local candidate. The remote candidate. Emitted when a candidate is selected for use in the stream by the controlling side of an ICE session. The controlled side should call AcceptSelectedCandidatePair or RejectSelectedCandidatePair when connectivity checks have either succeeded or failed for this candidate pair. See also: SelectedCandidatePairs. The local candidate that has been selected. The remote candidate that has been selected.

The candidates that have been selected for use to stream packets to the remote contact for each component of the stream. Change notification is given via the the CandidatePairSelected signal.

Note to client implementors (from RFC 5245 section 9.2.2.3):

If at least one of the pairs is In-Progress, the agent SHOULD wait for those checks to complete, and as each completes, redo the processing in this section until there are no losing pairs.

Also note that some or all of the local candidates in this list may represent a peer-reflexive candidate that do not appear in LocalCandidates.

See RFC 5245 Appendix B.6. for more details about why this is.

Update the entry in SelectedCandidatePairs for a particular component, and signal it to the remote side.

This method should only be called by the controlling side of an ICE session. See CandidatePairSelected for details.

In the SDP offer/answer model, this signalling will take place as generating an updated offer. Note that updates may be queued up until information about all components of all streams is gathered.

The local candidate that has been selected. The remote candidate that has been selected.

Represents the state of ICE negotiation for a single component of a stream to an endpoint. Candidate gathering and connectivity checks are in progress. The streaming implementation has found at least one working candidate pair. It is possible to send media at this point, but the controlling side has yet to negotiate the final candidates for use in this call. This component of the stream is connected, and an updated offer has been sent and accepted (finalising the candidates to be used for the call). This should be set by the CM in response to AcceptSelectedCandidatePair. The streaming implementation has tried connecting to all of the available candidates and none of them have connected. This is distinct from Failed, because the CM might be able to provide more candidates later (more likely in XMPP than SIP). The CM and streaming implementation are in agreement that it is impossible to connect to this endpoint. This value should only be set by the CM. The state of ICE negotiation with this Endpoint for each component of the stream. Emitted when the EndpointState property changes. The component whose state has changed. The new state of this component. Change the EndpointState of the endpoint. The component whose state needs updating. The new state of this component.

Called in response to CandidatePairSelected if/when this candidate pair is known to have passed its connectivity checks. The local candidate that has been selected. The remote candidate that has been selected.

Called in response to CandidatePairSelected if/when this candidate pair is known to have failed its connectivity checks. The local candidate that has been selected. The remote candidate that has been selected.

The transport type for the stream endpoint. This can be different from the transport of the Stream in the case where of falling back from ICE to Raw_UDP.

The local side is taking the controlling role (as defined by ICE RFC 5245). Change notification is given via the ControllingChanged signal.

In ICE, the Caller is normally in controlling mode (and the Callee in controlled-mode), except if the Caller is doing ICE-Lite, in which case it's reversed. The Controlling side is responsible for selecting nominated pairs, and generating updated offers upon conclusion of ICE. Set whether the local side is taking the Controlling role. Note that if there are multiple endpoints (e.g. SIP call forking) it may be the case that all endpoints need to have the same controlling/controlled orientation. The new value of Controlling. The value of Controlling has changed. The new value of Controlling. The Remote side is an ICE Lite endpoint. (The local side is assumed to always be an ICE Full implementation.)