Tp::Client::ChannelTypeStreamedMediaInterface Class Reference [Channel proxies]

#include <TelepathyQt4/Channel>

Inherits Tp::AbstractInterface.

List of all members.

Public Slots

• QDBusPendingReply
  < Tp::MediaStreamInfoList > ListStreams ()
• QDBusPendingReply RemoveStreams (const Tp::UIntList &streams)
• QDBusPendingReply RequestStreamDirection (uint streamID, uint streamDirection)
• QDBusPendingReply
  < Tp::MediaStreamInfoList > RequestStreams (uint contactHandle, const Tp::UIntList &types)

Signals

• void StreamAdded (uint streamID, uint contactHandle, uint streamType)
• void StreamDirectionChanged (uint streamID, uint streamDirection, uint pendingFlags)
• void StreamError (uint streamID, uint errorCode, const QString &message)
• void StreamRemoved (uint streamID)
• void StreamStateChanged (uint streamID, uint streamState)

Public Member Functions

• ChannelTypeStreamedMediaInterface (const QString &busName, const QString &objectPath, QObject *parent=0)
• ChannelTypeStreamedMediaInterface (const QDBusConnection &connection, const QString &busName, const QString &objectPath, QObject *parent=0)
• ChannelTypeStreamedMediaInterface (Tp::DBusProxy *proxy)
• ChannelTypeStreamedMediaInterface (const Tp::Client::ChannelInterface &mainInterface)
• ChannelTypeStreamedMediaInterface (const Tp::Client::ChannelInterface &mainInterface, QObject *parent)
• TELEPATHY_QT4_DEPRECATED bool InitialAudio () const
• Tp::PendingVariant * requestPropertyInitialAudio () const
• TELEPATHY_QT4_DEPRECATED bool InitialVideo () const
• Tp::PendingVariant * requestPropertyInitialVideo () const
• TELEPATHY_QT4_DEPRECATED bool ImmutableStreams () const
• Tp::PendingVariant * requestPropertyImmutableStreams () const
• Tp::PendingVariantMap * requestAllProperties () const

Static Public Member Functions

• static const char * staticInterfaceName ()

Protected Member Functions

• virtual void invalidate (Tp::DBusProxy *, const QString &, const QString &)

Properties

• bool InitialAudio
• bool InitialVideo
• bool ImmutableStreams

---

Detailed Description

Proxy class providing a 1:1 mapping of the D-Bus interface "org.freedesktop.Telepathy.Channel.Type.StreamedMedia."

---

Constructor & Destructor Documentation

Tp::Client::ChannelTypeStreamedMediaInterface::ChannelTypeStreamedMediaInterface	(	const QString &	busName,
		const QString &	objectPath,
		QObject *	parent = 0
	)

Creates a ChannelTypeStreamedMediaInterface associated with the given object on the session bus.

Parameters:

	busName	Name of the service the object is on.
	objectPath	Path to the object on the service.
	parent	Passed to the parent class constructor.

Tp::Client::ChannelTypeStreamedMediaInterface::ChannelTypeStreamedMediaInterface	(	const QDBusConnection &	connection,
		const QString &	busName,
		const QString &	objectPath,
		QObject *	parent = 0
	)

Creates a ChannelTypeStreamedMediaInterface associated with the given object on the given bus.

Parameters:

	connection	The bus via which the object can be reached.
	busName	Name of the service the object is on.
	objectPath	Path to the object on the service.
	parent	Passed to the parent class constructor.

Tp::Client::ChannelTypeStreamedMediaInterface::ChannelTypeStreamedMediaInterface

(

Tp::DBusProxy *

proxy

)

Creates a ChannelTypeStreamedMediaInterface associated with the same object as the given proxy.

Parameters:

proxy

The proxy to use. It will also be the QObject::parent() for this object.

Tp::Client::ChannelTypeStreamedMediaInterface::ChannelTypeStreamedMediaInterface

(

const Tp::Client::ChannelInterface &

mainInterface

)

[explicit]

Creates a ChannelTypeStreamedMediaInterface associated with the same object as the given proxy. Additionally, the created proxy will have the same parent as the given proxy.

Parameters:

mainInterface

The proxy to use.

Tp::Client::ChannelTypeStreamedMediaInterface::ChannelTypeStreamedMediaInterface	(	const Tp::Client::ChannelInterface &	mainInterface,
		QObject *	parent
	)

Creates a ChannelTypeStreamedMediaInterface associated with the same object as the given proxy. However, a different parent object can be specified.

Parameters:

	mainInterface	The proxy to use.
	parent	Passed to the parent class constructor.

---

Member Function Documentation

static const char* Tp::Client::ChannelTypeStreamedMediaInterface::staticInterfaceName

(

)

[inline, static]

Returns the name of the interface "org.freedesktop.Telepathy.Channel.Type.StreamedMedia", which this class represents.

Returns:

The D-Bus interface name.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ChannelTypeStreamedMediaInterface::InitialAudio

(

)

const [inline]

Getter for the remote object property "InitialAudio".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyInitialAudio() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ChannelTypeStreamedMediaInterface::requestPropertyInitialAudio

(

)

const [inline]

Asynchronous getter for the remote object property "InitialAudio" of type bool.

If set to true in a channel request that will create a new channel, the connection manager should immediately attempt to establish an audio stream to the remote contact, making it unnecessary for the client to call <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">RequestStreams</tp:dbus-ref>.

If this property, or InitialVideo, is passed to EnsureChannel (as opposed to CreateChannel), the connection manager SHOULD ignore these properties when checking whether it can return an existing channel as suitable; these properties only become significant when the connection manager has decided to create a new channel.

If true on a requested channel, this indicates that the audio stream has already been requested and the client does not need to call RequestStreams, although it MAY still do so.

If true on an unrequested (incoming) channel, this indicates that the remote contact initially requested an audio stream; this does not imply that that audio stream is still active (as indicated by <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">ListStreams</tp:dbus-ref>).

This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref> signals.

<tp:rationale>

This reduces D-Bus round trips.</tp:rationale>

Connection managers capable of signalling audio calls to contacts SHOULD include a channel class in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref> with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref> = <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref> and <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref> = Contact in the fixed properties dictionary, and InitialAudio (and also InitialVideo, if applicable) in the allowed properties list. Clients wishing to discover whether a connection manager can signal audio and/or video calls SHOULD use this information.

<tp:rationale>

Not all protocols support signalling video calls, and it would be possible (although unlikely) to have a protocol where only video, and not audio, could be signalled. </tp:rationale>

Connection managers that support the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities</tp:dbus-ref> interface SHOULD represent the capabilities of receiving audio and/or video calls by including a channel class in a contact's capabilities with ChannelType = StreamedMedia in the fixed properties dictionary, and InitialAudio and/or InitialVideo in the allowed properties list. Clients wishing to discover whether a particular contact is likely to be able to receive audio and/or video calls SHOULD use this information.

<tp:rationale>

Not all clients support video calls, and it would also be possible (although unlikely) to have a client which could only stream video, not audio. </tp:rationale>

Clients that are willing to receive audio and/or video calls SHOULD include the following among their channel classes if calling <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref> (clients of a <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref> SHOULD instead arrange for the ChannelDispatcher to do this, by including the filters in their <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref> properties):

• { ChannelType = StreamedMedia }
• { ChannelType = StreamedMedia, InitialAudio = true } if receiving calls with audio is supported
• { ChannelType = StreamedMedia, InitialVideo = true } if receiving calls with video is supported

<tp:rationale>

Connection managers for protocols with capability discovery, like XMPP, need this information to advertise the appropriate capabilities for their protocol. </tp:rationale>

Returns:

A pending variant which will emit finished when the property has been retrieved.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ChannelTypeStreamedMediaInterface::InitialVideo

(

)

const [inline]

Getter for the remote object property "InitialVideo".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyInitialVideo() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ChannelTypeStreamedMediaInterface::requestPropertyInitialVideo

(

)

const [inline]

Asynchronous getter for the remote object property "InitialVideo" of type bool.

The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for a video stream. This property is immutable (cannot change).

In particular, note that if this property is false, this does not imply that an active video stream has not been added, only that no video stream was active at the time the channel appeared.

This property is the correct way to discover whether connection managers, contacts etc. support video calls; it appears in capabilities structures in the same way as InitialAudio.

Returns:

A pending variant which will emit finished when the property has been retrieved.

TELEPATHY_QT4_DEPRECATED bool Tp::Client::ChannelTypeStreamedMediaInterface::ImmutableStreams

(

)

const [inline]

Getter for the remote object property "ImmutableStreams".

Don't use this: it blocks the main loop. Use the asynchronous requestPropertyImmutableStreams() instead.

Returns:

The value of the property, or a default-constructed value if the property is not readable.

Tp::PendingVariant* Tp::Client::ChannelTypeStreamedMediaInterface::requestPropertyImmutableStreams

(

)

const [inline]

Asynchronous getter for the remote object property "ImmutableStreams" of type bool.

If True, once streams have been requested for this channel (either by setting <tp:member-ref>InitialAudio</tp:member-ref> or <tp:member-ref>InitialVideo</tp:member-ref> when the channel is requested, or by calling <tp:member-ref>RequestStreams</tp:member-ref> on a channel with no streams), a stream of a different content type cannot be added; subsequent calls to <tp:member-ref>RequestStreams</tp:member-ref> that attempt to do so will fail.

If this property is missing, clients SHOULD assume that it is false, and thus that the channel's streams can be changed once the call has started.

If this property is present in the "allowed" set in all of the StreamedMedia entries in a contact's capabilities, then user interfaces MAY choose to show a separate "call" option for each class of call.

<tp:rationale>

For example, once an audio-only Google Talk call has started, it is not possible to add a video stream; both audio and video must be requested at the start of the call if video is desired. User interfaces may use this pseudo-capability as a hint to display separate "Audio call" and "Video call" buttons, rather than a single "Call" button with the option to add and remove video once the call has started for contacts without this flag. </tp:rationale>

This property is immutable, and therefore SHOULD be announced in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>, etc.

Returns:

A pending variant which will emit finished when the property has been retrieved.

Tp::PendingVariantMap* Tp::Client::ChannelTypeStreamedMediaInterface::requestAllProperties

(

)

const [inline]

Request all of the DBus properties on the interface.

Returns:

A pending variant map which will emit finished when the properties have been retrieved.

QDBusPendingReply<Tp::MediaStreamInfoList> Tp::Client::ChannelTypeStreamedMediaInterface::ListStreams

(

)

[inline, slot]

Begins a call to the D-Bus method "ListStreams" on the remote object.

Returns an array of structs representing the streams currently active within this channel. Each stream is identified by an unsigned integer which is unique for each stream within the channel.

Returns:

An array of structs containing:

• the stream identifier
• the contact handle who the stream is with (or 0 if the stream represents more than a single member)
• the type of the stream
• the current stream state
• the current direction of the stream
• the current pending send flags

QDBusPendingReply Tp::Client::ChannelTypeStreamedMediaInterface::RemoveStreams

(

const Tp::UIntList &

streams

)

[inline, slot]

Begins a call to the D-Bus method "RemoveStreams" on the remote object.

Request that the given streams are removed. If all streams are removed, the channel MAY close.

Clients SHOULD NOT attempt to terminate calls by removing all the streams; instead, clients SHOULD terminate calls by removing the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref> from the channel, using either <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembers</tp:dbus-ref> or <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface.Group">RemoveMembersWithReason</tp:dbus-ref>.

Parameters:

streams

An array of stream identifiers (as defined in ListStreams)

QDBusPendingReply Tp::Client::ChannelTypeStreamedMediaInterface::RequestStreamDirection	(	uint	streamID,
		uint	streamDirection
	)			[inline, slot]

Begins a call to the D-Bus method "RequestStreamDirection" on the remote object.

Request a change in the direction of an existing stream. In particular, this might be useful to stop sending media of a particular type, or inform the peer that you are no longer using media that is being sent to you.

Depending on the protocol, streams which are no longer sending in either direction should be removed and a <tp:member-ref>StreamRemoved</tp:member-ref> signal emitted. Some direction changes can be enforced locally (for example, BIDIRECTIONAL -> RECEIVE can be achieved by merely stopping sending), others may not be possible on some protocols, and some need agreement from the remote end. In this case, the MEDIA_STREAM_PENDING_REMOTE_SEND flag will be set in the <tp:member-ref>StreamDirectionChanged</tp:member-ref> signal, and the signal emitted again without the flag to indicate the resulting direction when the remote end has accepted or rejected the change.

Parameters:

	streamID	The stream identifier (as defined in ListStreams)
	streamDirection	The desired stream direction (a value of MediaStreamDirection)

QDBusPendingReply<Tp::MediaStreamInfoList> Tp::Client::ChannelTypeStreamedMediaInterface::RequestStreams	(	uint	contactHandle,
		const Tp::UIntList &	types
	)			[inline, slot]

Begins a call to the D-Bus method "RequestStreams" on the remote object.

Request that streams be established to exchange the given types of media with the given member. In general this will try and establish a bidirectional stream, but on some protocols it may not be possible to indicate to the peer that you would like to receive media, so a send-only stream will be created initially. In the cases where the stream requires remote agreement (eg you wish to receive media from them), the <tp:member-ref>StreamDirectionChanged</tp:member-ref> signal will be emitted with the MEDIA_STREAM_PENDING_REMOTE_SEND flag set, and the signal emitted again with the flag cleared when the remote end has replied.

If streams of the requested types already exist, calling this method results in the creation of additional streams. Accordingly, clients wishing to have exactly one audio stream or exactly one video stream SHOULD check for the current streams using <tp:member-ref>ListStreams</tp:member-ref> before calling this method.

Parameters:

	contactHandle	A contact handle with whom to establish the streams
	types	An array of stream types (values of MediaStreamType)

Returns:

An array of structs (in the same order as the given stream types) containing:

• the stream identifier
• the contact handle who the stream is with (or 0 if the stream represents more than a single member)
• the type of the stream
• the current stream state
• the current direction of the stream
• the current pending send flags

void Tp::Client::ChannelTypeStreamedMediaInterface::StreamAdded	(	uint	streamID,
		uint	contactHandle,
		uint	streamType
	)			[signal]

Represents the signal "StreamAdded" on the remote object.

Emitted when a new stream has been added to this channel. Clients SHOULD assume that the stream's <tp:type>Media_Stream_State</tp:type> is initially Disconnected.

If a connection manager needs to represent the addition of a stream whose state is already Connecting or Connected, it MUST do this by emitting StreamAdded, closely followed by <tp:member-ref>StreamStateChanged</tp:member-ref> indicating a change to the appropriate state.

<tp:rationale>

Historically, it was not clear from the StreamAdded signal what the state of the stream was. telepathy-spec 0.17.22 clarified this. </tp:rationale>

Similarly, clients SHOULD assume that the initial <tp:type>Media_Stream_Direction</tp:type> of a newly added stream is Receive, and that the initial <tp:type>Media_Stream_Pending_Send</tp:type> is Pending_Local_Send.

If a connection manager needs to represent the addition of a stream whose direction or pending-send differs from those initial values, it MUST do so by emitting StreamAdded, closely followed by <tp:member-ref>StreamDirectionChanged</tp:member-ref> indicating a change to the appropriate direction and pending-send state.

<tp:rationale>

StreamAdded doesn't itself indicate the stream's direction; this is unfortunate, but is preserved for compatibility.

This is the appropriate direction for streams added by a remote contact on existing connection managers, and does not violate user privacy by automatically sending audio or video (audio streams start off muted, video streams start off not sending). For streams added by the local user using the client receiving the signal, the true direction can also be determined from the return value of the <tp:member-ref>RequestStreams</tp:member-ref> method.

Existing clients typically operate by maintaining a separate idea of the directions that they would like the streams to have, and enforcing these intended directions by calling <tp:member-ref>RequestStreamDirection</tp:member-ref> whenever needed. </tp:rationale>

Parameters:

	streamID	The stream identifier (as defined in ListStreams)
	contactHandle	The contact handle who the stream is with (or 0 if it represents more than a single member)
	streamType	The stream type (a value from MediaStreamType)

void Tp::Client::ChannelTypeStreamedMediaInterface::StreamDirectionChanged	(	uint	streamID,
		uint	streamDirection,
		uint	pendingFlags
	)			[signal]

Represents the signal "StreamDirectionChanged" on the remote object.

Emitted when the direction or pending flags of a stream are changed.

If the MEDIA_STREAM_PENDING_LOCAL_SEND flag is set, the remote user has requested that we begin sending on this stream. <tp:member-ref>RequestStreamDirection</tp:member-ref> should be called to indicate whether or not this change is acceptable.

<tp:rationale>

This allows for a MSN-style user interface, "Fred has asked you to enable your webcam. (Accept | Reject)", if desired. </tp:rationale>

Parameters:

	streamID	The stream identifier (as defined in ListStreams)
	streamDirection	The new stream direction (as defined in ListStreams)
	pendingFlags	The new pending send flags (as defined in ListStreams)

void Tp::Client::ChannelTypeStreamedMediaInterface::StreamError	(	uint	streamID,
		uint	errorCode,
		const QString &	message
	)			[signal]

Represents the signal "StreamError" on the remote object.

Emitted when a stream encounters an error.

Parameters:

	streamID	The stream identifier (as defined in ListStreams)
	errorCode	A stream error number, one of the values of MediaStreamError
	message	A string describing the error (for debugging purposes only)

void Tp::Client::ChannelTypeStreamedMediaInterface::StreamRemoved

(

uint

streamID

)

[signal]

Represents the signal "StreamRemoved" on the remote object.

Emitted when a stream has been removed from this channel.

Parameters:

streamID

stream_id - the stream identifier (as defined in ListStreams)

void Tp::Client::ChannelTypeStreamedMediaInterface::StreamStateChanged	(	uint	streamID,
		uint	streamState
	)			[signal]

Represents the signal "StreamStateChanged" on the remote object.

Emitted when a member's stream's state changes.

Parameters:

	streamID	The stream identifier (as defined in ListStreams)
	streamState	The new stream state (as defined in ListStreams)

void Tp::Client::ChannelTypeStreamedMediaInterface::invalidate	(	Tp::DBusProxy *	proxy,
		const QString &	error,
		const QString &	message
	)			[protected, virtual]

Reimplemented from Tp::AbstractInterface.

---

Property Documentation

bool Tp::Client::ChannelTypeStreamedMediaInterface::InitialAudio [read]

Represents property "InitialAudio" on the remote object.

If set to true in a channel request that will create a new channel, the connection manager should immediately attempt to establish an audio stream to the remote contact, making it unnecessary for the client to call <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">RequestStreams</tp:dbus-ref>.

If this property, or InitialVideo, is passed to EnsureChannel (as opposed to CreateChannel), the connection manager SHOULD ignore these properties when checking whether it can return an existing channel as suitable; these properties only become significant when the connection manager has decided to create a new channel.

If true on a requested channel, this indicates that the audio stream has already been requested and the client does not need to call RequestStreams, although it MAY still do so.

If true on an unrequested (incoming) channel, this indicates that the remote contact initially requested an audio stream; this does not imply that that audio stream is still active (as indicated by <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type.StreamedMedia">ListStreams</tp:dbus-ref>).

This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref> signals.

<tp:rationale>

This reduces D-Bus round trips.</tp:rationale>

Connection managers capable of signalling audio calls to contacts SHOULD include a channel class in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref> with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref> = <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Type">StreamedMedia</tp:dbus-ref> and <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref> = Contact in the fixed properties dictionary, and InitialAudio (and also InitialVideo, if applicable) in the allowed properties list. Clients wishing to discover whether a connection manager can signal audio and/or video calls SHOULD use this information.

<tp:rationale>

Not all protocols support signalling video calls, and it would be possible (although unlikely) to have a protocol where only video, and not audio, could be signalled. </tp:rationale>

Connection managers that support the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface">ContactCapabilities</tp:dbus-ref> interface SHOULD represent the capabilities of receiving audio and/or video calls by including a channel class in a contact's capabilities with ChannelType = StreamedMedia in the fixed properties dictionary, and InitialAudio and/or InitialVideo in the allowed properties list. Clients wishing to discover whether a particular contact is likely to be able to receive audio and/or video calls SHOULD use this information.

<tp:rationale>

Not all clients support video calls, and it would also be possible (although unlikely) to have a client which could only stream video, not audio. </tp:rationale>

Clients that are willing to receive audio and/or video calls SHOULD include the following among their channel classes if calling <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.ContactCapabilities">UpdateCapabilities</tp:dbus-ref> (clients of a <tp:dbus-ref namespace="org.freedesktop.Telepathy">ChannelDispatcher</tp:dbus-ref> SHOULD instead arrange for the ChannelDispatcher to do this, by including the filters in their <tp:dbus-ref namespace="org.freedesktop.Telepathy.Client.Handler">HandlerChannelFilter</tp:dbus-ref> properties):

• { ChannelType = StreamedMedia }
• { ChannelType = StreamedMedia, InitialAudio = true } if receiving calls with audio is supported
• { ChannelType = StreamedMedia, InitialVideo = true } if receiving calls with video is supported

<tp:rationale>

Connection managers for protocols with capability discovery, like XMPP, need this information to advertise the appropriate capabilities for their protocol. </tp:rationale>

bool Tp::Client::ChannelTypeStreamedMediaInterface::InitialVideo [read]

Represents property "InitialVideo" on the remote object.

The same as <tp:member-ref>InitialAudio</tp:member-ref>, but for a video stream. This property is immutable (cannot change).

In particular, note that if this property is false, this does not imply that an active video stream has not been added, only that no video stream was active at the time the channel appeared.

This property is the correct way to discover whether connection managers, contacts etc. support video calls; it appears in capabilities structures in the same way as InitialAudio.

bool Tp::Client::ChannelTypeStreamedMediaInterface::ImmutableStreams [read]

Represents property "ImmutableStreams" on the remote object.

If True, once streams have been requested for this channel (either by setting <tp:member-ref>InitialAudio</tp:member-ref> or <tp:member-ref>InitialVideo</tp:member-ref> when the channel is requested, or by calling <tp:member-ref>RequestStreams</tp:member-ref> on a channel with no streams), a stream of a different content type cannot be added; subsequent calls to <tp:member-ref>RequestStreams</tp:member-ref> that attempt to do so will fail.

If this property is missing, clients SHOULD assume that it is false, and thus that the channel's streams can be changed once the call has started.

If this property is present in the "allowed" set in all of the StreamedMedia entries in a contact's capabilities, then user interfaces MAY choose to show a separate "call" option for each class of call.

<tp:rationale>

For example, once an audio-only Google Talk call has started, it is not possible to add a video stream; both audio and video must be requested at the start of the call if video is desired. User interfaces may use this pseudo-capability as a hint to display separate "Audio call" and "Video call" buttons, rather than a single "Call" button with the option to add and remove video once the call has started for contacts without this flag. </tp:rationale>

This property is immutable, and therefore SHOULD be announced in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">NewChannels</tp:dbus-ref>, etc.