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.

(draft 1)

This interface deals with how to connect a stream to an endpoint. It contains all that is required to describe the local endpoint, to succesfully establish a connection. While a call is established, one may try to connect to multiple remote endpoints at the same time. This is called forking in the SIP jargon. Informations related to the connections are on the Endpoint objects. Once the call is established, there MUST be a single endpoint left.

ICE restarts

If the CM wants to do an ICE restart, then the ICERestartPending property is set, and the ICERestartRequested signal is emitted. The streaming implementation should then call SetCredentials again. This will trigger the actual ICE restart, and cause LocalCandidates to be cleared.

For more information on ICE restarts see RFC 5245 section 9.1.1.1

The type of SendingState and ReceivingState. No data is flowing (or expected to be flowing) at this time. The streaming implementation has been told to start or receiving, but has not yet indicated that it is doing so. The streaming implementation has been told to stop sending or receiving data, but it has not yet indicated that it has done so. The streaming implementation is successfully sending or receiving data, and everything is going swimmingly. The streaming implementation has been told to mute sending, but it has not yet indicated that it has done so. The streaming implementation has successfully muted sending, and the local user's privacy is protected. Indicates whether the streaming implementation is/should be sending media for this stream. The streaming implementation should be able to rely on reading this value and listening to SendingStateChanged to determine whether it should be sending media or not. It should not need to listen to the Mute/Hold interfaces on the Call/Content. Feedback on success should be given via CompleteSendingStateChange. Failures should be reported via ReportSendingFailure. Change notification for SendingState. Note that this information is duplicated onto the Stream interface, so that UIs can ignore the Media interface, and streaming implementations can ignore everything but the media interface. The new value of SendingState.

Called in response to SendingStateChanged(Pending_*, *) to indicate that the media state has successfully progressed from Pending_{Start, Stop, Pause} to the corresponding non-pending state.

The new (non-pending) value of SendingState.

The state change made no sense, and was ignored by the CM. The most likely cause for this is a race-condition between the CM emitting a new state change and the streaming implementation responding to the previous state change.

Can be called at any point to indicate a failure in the outgoing portion of the stream. The counterpart of SendingState. Indicates whether the streaming implementation is/should be expecting to receive media for this stream. The CM should only tell the streaming implementation to stop receiving if it has been told to put the stream on hold, or the stream has been removed from the call. Change notification for ReceivingState. The new value of ReceivingState.

Called in response to ReceivingStateChanged(Pending_*, *) to indicate that the media state has successfully progressed from Pending_{Start, Stop, Pause} to the corresponding non-pending state.

The new (non-pending) value of ReceivingState.

Can be called at any point to indicate a failure in the incoming portion of the stream.

Used to set the username fragment and password for streams that have global credentials.

The username to use when authenticating on the stream. The password to use when authenticating on the stream. The network topology that an IP candidate represents. This can sometimes be used to infer what kind of performance characteristics (latency, bandwith, etc) can be expected of connections made to this candidate. This is not an IP candidate. This is a reserved value, and should not be seen on the bus. This candidate represents a direct connection to the host, as its address is taken directly the host's IP stack. This candidate probably represents a connection to the host through a NAT device, as its address was discovered by sending a binding request to a STUN server or similar. This candidate probably represents a good route between the host and its peer, as its address was discovered by sending a STUN binding request to one of the candidates advertised by the peer. This candidate represents the address of a relay server (usually somewhere on the public internet). This candidate is the most likely to work, but all media will go via a relay server, so latency is likely to be higher than other types of candidate. This candidate represents a Multicast group. This value should only appear if the Stream's Transport is set to Multicast. UDP (User Datagram Protocol) TCP (Transmission Control Protocol)

Extra information about the candidate. Allowed and mandatory keys depend on the transport protocol used. The following keys are commenly used:

type - u: The type of candidate (Call_Stream_Candidate_Type)
foundation - s: The foundation of this candidate
protocol - u: Underlying protocol of the candidate (Media_Stream_Base_Proto)
priority - u: Priority of the candidate (should be a number between 0 and 65535). Most ICE implementations will prefer the highest priority candidate pair that manages to connect. For backwards compatibility with non-ICE SIP clients, the lowest priority candidate may be sent as a raw UDP fallback candidate. It is recommended that a relay candidate is used as the lowest priority candidate if possible. If both IPv4 and IPv6 raw udp fallback candidates are available, they should be set to the same priority and advertised to the CM at the same time. The CM will decide which to advertise to the remote end.
base-ip - s: The underlying Host address where media sent to this (non-host-type) candidate will eventually arrive.
base-port - u: The underlying Host port where media sent to this (non-host-type) candidate will eventually arrive.
username - s: Username of this candidate (only if credentials are per candidate)
password - s: Password of this candidate (only if credentials are per candidate)
ttl - u: The TTL mandated for RTP/RTCP packets sent to a multicast group (only valid for Multicast Streams)

One of the well-known keys documented here, or an implementation-specific key. The value corresponding to that key. Media streams can use more than one UDP socket: one for RTP (data) and one for RTCP (control). Most of the time, they are adjacent to each other, but some protocols (xmpp) signal each port separately. The stream transport type is unknown or not applicable (should not appear over dbus). This is the high-traffic data socket, containing the audio/video data for the stream. This is the low-traffic control socket, usually containing feedback about packet loss etc. A Stream Candidate. The component number. The IP address to use. The port number to use. Additional information about the candidate. Add candidates to the LocalCandidates property and signal them to the remote contact(s). Note that connection managers MAY delay the sending of candidates until FinishInitialCandidates is called. The candidates to be added. This indicates to the CM that the initial batch of candidates has been added, and should now be processed/sent to the remote side. Protocols supporting Raw UDP SHOULD wait for FinishInitialCandidates, and then set the lowest priority candidate as the Raw UDP candidate. WLM_8_5 was removed A transport that can be used for streaming. The stream transport type is unknown or not applicable (for streams that do not have a configurable transport). Raw UDP, with or without STUN. All streaming clients are assumed to support this transport, so there is no handler capability token for it in the Call1 interface. [This corresponds to "none" or "stun" in the old Media.StreamHandler interface.] Interactive Connectivity Establishment, as defined by RFC 5245. Note that this value covers ICE-UDP only. [This corresponds to "ice-udp" in the old Media.StreamHandler interface.] Google Talk peer-to-peer connectivity establishment, as implemented by libjingle 0.3. [This corresponds to "gtalk-p2p" in the old Media.StreamHandler interface.] The transport used by Windows Live Messenger 2009 or later, which resembles ICE draft 19. [This corresponds to "wlm-2009" in the old Media.StreamHandler interface.] Shared memory transport, as implemented by the GStreamer shmsrc and shmsink plugins. Multicast transport. The transport for this stream. [FIXME]. Change notification is via the LocalCandidatesAdded signal. Emitted when local candidates are added to the LocalCandidates property. Candidates that have been added. A username and password pair. The username. The password. The local credentials are sent to the remote site over the signalling protocol. They are used in ICE to make sure that the connectivity checks come from the right peer. Change notification is via the LocalCredentialsChanged signal. This property will be a pair of empty strings if ICE has not yet been started. renamed from LocalCredentailsSet Emitted when the value of LocalCredentials changes to a non-empty value. This should only happen when the streaming implementation calls SetCredentials, so this signal is mostly useful for debugging. Emitted when the value of RelayInfo changes. Emitted when the value of STUNServers changes.

The IP addresses of possible STUN servers to use for NAT traversal, as dotted-quad IPv4 address literals or RFC2373 IPv6 address literals. Change notification is via the STUNServersChanged signal. The IP addresses MUST NOT be given as DNS hostnames.

High-quality connection managers already need an asynchronous DNS resolver, so they might as well resolve this name to an IP to make life easier for streaming implementations.

A list of mappings describing TURN or Google relay servers available for the client to use in its candidate gathering, as determined from the protocol. Well-known map keys are:

ip - s

The IP address of the relay server as a dotted-quad IPv4 address literal or an RFC2373 IPv6 address literal. This MUST NOT be a DNS hostname. High-quality connection managers already need an asynchronous DNS resolver, so they might as well resolve this name to an IP and make life easier for streaming implementations.

type - s

Either udp for UDP (UDP MUST be assumed if this key is omitted), tcp for TCP, or tls.

The precise meaning of this key depends on the Transport property: if Transport is ICE, tls means TLS over TCP as referenced by ICE draft 19, and if Transport is GTalk_P2P, tls means a fake SSL session over TCP as implemented by libjingle.

port - q

The UDP or TCP port of the relay server as an ASCII unsigned integer

unique-id - s

A string identifying the relay server. If two RelayInfo entries have the same unique-id, but different types, there is usually little point in connecting to both. Use priority to determine which version to prefer in this case. Can also be used by the streaming implementation to avoid connecting to the same relay multiple times if relaying is required for both audio and video.

priority - u

A number determining which version of a server to prefer (if multiple are present with the same unique-id, the one with the highest priority should be used, or the streaming implementation should use the one whose type has the most desirable properties)

username - s

The username to use

password - s

The password to use

component - u

The component number to use this relay server for, as an ASCII unsigned integer; if not included, this relay server may be used for any or all components. In ICE draft 6, as used by Google Talk, credentials are only valid once, so each component needs relaying separately.

An equivalent of the gtalk-p2p-relay-token property on MediaSignalling channels is not included here. The connection manager should be responsible for making the necessary HTTP requests to turn the token into a username and password.

The type of relay server that this represents depends on the value of the Transport property. If Transport is ICE, this is a TURN server; if Transport is GTalk_P2P, this is a Google relay server; otherwise, the meaning of RelayInfo is undefined.

If relaying is not possible for this stream, the list is empty.

Change notification is given via the RelayInfoChanged signal.

Signals that the initial information about STUN and Relay servers has been retrieved, i.e. the HasServerInfo property is now true.

True if all the initial information about STUN servers and Relay servers has been retrieved. Change notification is via the ServerInfoRetrieved signal.

Streaming implementations that can't cope with STUN and relay servers being added later SHOULD wait for this property to become true before proceeding. Emitted when the Endpoints property changes. Endpoints that were added. Endpoints that no longer exist.

The list of Endpoint objects that exist for this stream.

Change notification is via the EndpointsChanged signal.

Emitted when the remote side requests an ICE restart (e.g. third party call control, when the remote endpoint changes). The streaming implementation should call SetCredentials again. State recovery for ICERestartRequested. Set when the signal is emitted, and unset when SetCredentials is called. Useful for debugging. Signal an unrecoverable error for this stream, and remove it. If all streams are removed from a content, then it will also be removed. A structured reason for stream removal.