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.

Information about a codec supported by a client or a peer's client. The codec's payload identifier, as per RFC 3551 (static or dynamic) The codec's name Type of stream this codec supports Sampling frequency in Hertz Number of supported channels Codec-specific optional parameters The IP addresses of possible STUN servers to use for NAT traversal, as dotted-quad IPv4 address literals or RFC2373 IPv6 address literals. This property cannot change once the stream has been created, so there is no change notification. 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. True if we were the creator of this stream, false otherwise. This information is needed for some nat traversal mechanisms, such as ICE-UDP, where the creator gets the role of the controlling agent.

The transport (NAT traversal technique) to be used for this stream. Well-known values include:

none: Raw UDP, with or without STUN, should be used. If the STUNServers property is non-empty, STUN SHOULD be used.
stun: A deprecated synonym for 'none'.
gtalk-p2p: Google Talk peer-to-peer connectivity establishment should be used, as implemented in libjingle 0.3.
ice-udp: Interactive Connectivity Establishment should be used, as defined by the IETF MMUSIC working group.
wlm-8.5: The transport used by Windows Live Messenger 8.5 or later, which resembles ICE draft 6, should be used.
wlm-2009: The transport used by Windows Live Messenger 2009 or later, which resembles ICE draft 19, should be used.

This property cannot change once the stream has been created, so there is no change notification.

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. 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 NATTraversal property: if NATTraversal is ice-udp, tls means TLS over TCP as referenced by ICE draft 19, and if NATTraversal 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

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 NATTraversal property. If NATTraversal is ice-udp, this is a TURN server; if NATTraversal 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.

This property cannot change once the stream has been created, so there is no change notification.

String identifier for this candidate Array of transports for this candidate with fields, as defined in NewNativeCandidate Signal emitted when the connection manager wishes to inform the client of a new remote candidate. Signal emitted when the connection manager wishes the stream to be closed. Inform the connection manager of codec used to receive data. ID of error, from the MediaStreamError enumeration String describing the error Inform the connection manager that an error occured in this stream. The connection manager should emit the StreamError signal for the stream on the relevant channel, and remove the stream from the session. An unknown error occured. The end of the stream was reached. This error has no use anywhere. In Farsight 1 times, it was used to indicate a GStreamer EOS (when the end of a file is reached). But since this is for live calls, it makes no sense. There are no common codecs between the local side and the other particpants in the call. The possible codecs are not signalled here: the streaming implementation is assumed to report them in an implementation-dependent way, e.g. Farsight should use GstMissingElement. A network connection for the Media could not be established or was lost. There was an error in the networking stack (other than the connection failure). There are no installed codecs for this media type. The CM is doing something wrong. There was an error in the media processing stack. Informs the connection manager that all possible native candisates have been discovered for the moment. Informs the connection manager that a valid candidate pair has been discovered and streaming is in progress. UDP (User Datagram Protocol) TCP (Transmission Control Protocol) String identifier for this candidate Array of transports for this candidate, with fields:

component number
IP address (as a string)
port
base network protocol (one of the values of MediaStreamBaseProto)
proto subtype (e.g. RTP)
proto profile (e.g. AVP)
our preference value of this transport (double in range 0.0-1.0 inclusive); 1 signals the most preferred transport
transport type, one of the values of MediaStreamTransportType
username if authentication is required
password if authentication is required

Inform this MediaStreamHandler that a new native transport candidate has been ascertained. A local address An external address derived by a method such as STUN An external stream relay Locally-supported codecs. Inform the connection manager that a client is ready to handle this StreamHandler. Also provide it with info about all supported codecs. Locally-supported codecs

Used to provide codecs after Ready(), so the media client can go ready for an incoming call and exchange candidates/codecs before knowing what local codecs are available.

This is useful for gatewaying calls between two connection managers. Given an incoming call, you need to call Ready to get the remote codecs before you can use them as the "local" codecs to place the outgoing call, and hence receive the outgoing call's remote codecs to use as the incoming call's "local" codecs.

In this situation, you would pass an empty list of codecs to the incoming call's Ready method, then later call SetLocalCodecs on the incoming call in order to respond to the offer.

String identifier for remote candidate to drop There is no case where you want to release candidates (except for an ICE reset, and there you'd want to replace then all, using SetRemoteCandidateList). Signal emitted when the connection manager wishes to inform the client that the remote end has removed a previously usable candidate. It seemed like a good idea at the time, but wasn't. Emitted by the connection manager to inform the client that a valid candidate pair has been discovered by the remote end and streaming is in progress. A list of candidate id and a list of transports as defined in NewNativeCandidate Signal emitted when the connection manager wishes to inform the client of all the available remote candidates at once. Codecs supported by the remote peer. Signal emitted when the connection manager wishes to inform the client of the codecs supported by the remote end. If these codecs are compatible with the remote codecs, then the client must call SupportedCodecs, otherwise call Error. If emitted with argument TRUE, this means that the connection manager wishes to set the stream playing; this means that the streaming implementation should expect to receive data. If emitted with argument FALSE this signal is basically meaningless and should be ignored. We're very sorry. Signal emitted when the connection manager wishes to set whether or not the stream sends to the remote end. A telephony event code as defined by RFC 4733. Request that a telephony event (as defined by RFC 4733) is transmitted over this stream until StopTelephonyEvent is called. Request that any ongoing telephony events (as defined by RFC 4733) being transmitted over this stream are stopped. Informs the connection manager of the stream's current state, as as specified in Channel.Type.StreamedMedia::ListStreams. Locally supported codecs. Inform the connection manager of the supported codecs for this session. This is called after the connection manager has emitted SetRemoteCodecs to notify what codecs are supported by the peer, and will thus be an intersection of all locally supported codecs (passed to Ready) and those supported by the peer. Locally supported codecs, which SHOULD be the same as were previously in effect, but possibly with different parameters. Inform the connection manager that the parameters of the supported codecs for this session have changed. The connection manager should send the new parameters to the remote contact. This is required for H.264 and Theora, for example.

Emitted when the connection manager wishes to place the stream on hold (so the streaming client should free hardware or software resources) or take the stream off hold (so the streaming client should reacquire the necessary resources).

When placing a channel's streams on hold, the connection manager SHOULD notify the remote contact that this will be done (if appropriate in the protocol) before it emits this signal.

It is assumed that relinquishing a resource will not fail. If it does, the call is probably doomed anyway.

When unholding a channel's streams, the connection manager SHOULD emit this signal and wait for success to be indicated via HoldState before it notifies the remote contact that the channel has been taken off hold.

This means that if a resource is unavailable, the remote contact will never even be told that we tried to acquire it.

If true, the stream is to be placed on hold. Notify the connection manager that the stream's hold state has been changed successfully in response to SetStreamHeld. If true, the stream is now on hold. Notify the connection manager that an attempt to reacquire the necessary hardware or software resources to unhold the stream, in response to SetStreamHeld, has failed. Handles signalling the information pertaining to a specific media stream. A client should provide information to this handler as and when it is available.