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

#include <TelepathyQt4/Channel>

Inherits Tp::AbstractInterface.

List of all members.

Signals

• void ChannelMerged (const QDBusObjectPath &channel, uint channelSpecificHandle, const QVariantMap &properties)
• void ChannelRemoved (const QDBusObjectPath &channel, const QVariantMap &details)

Public Member Functions

• ChannelInterfaceConferenceInterface (const QString &busName, const QString &objectPath, QObject *parent=0)
• ChannelInterfaceConferenceInterface (const QDBusConnection &connection, const QString &busName, const QString &objectPath, QObject *parent=0)
• ChannelInterfaceConferenceInterface (Tp::DBusProxy *proxy)
• ChannelInterfaceConferenceInterface (const Tp::Client::ChannelInterface &mainInterface)
• ChannelInterfaceConferenceInterface (const Tp::Client::ChannelInterface &mainInterface, QObject *parent)
• TELEPATHY_QT4_DEPRECATED
  Tp::ObjectPathList Channels () const
• Tp::PendingVariant * requestPropertyChannels () const
• TELEPATHY_QT4_DEPRECATED
  Tp::ObjectPathList InitialChannels () const
• Tp::PendingVariant * requestPropertyInitialChannels () const
• TELEPATHY_QT4_DEPRECATED
  Tp::UIntList InitialInviteeHandles () const
• Tp::PendingVariant * requestPropertyInitialInviteeHandles () const
• TELEPATHY_QT4_DEPRECATED
  QStringList InitialInviteeIDs () const
• Tp::PendingVariant * requestPropertyInitialInviteeIDs () const
• TELEPATHY_QT4_DEPRECATED QString InvitationMessage () const
• Tp::PendingVariant * requestPropertyInvitationMessage () const
• TELEPATHY_QT4_DEPRECATED
  Tp::ChannelOriginatorMap OriginalChannels () const
• Tp::PendingVariant * requestPropertyOriginalChannels () 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

• Tp::ObjectPathList Channels
• Tp::ObjectPathList InitialChannels
• Tp::UIntList InitialInviteeHandles
• QStringList InitialInviteeIDs
• QString InvitationMessage
• Tp::ChannelOriginatorMap OriginalChannels

---

Detailed Description

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

---

Constructor & Destructor Documentation

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

Creates a ChannelInterfaceConferenceInterface 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::ChannelInterfaceConferenceInterface::ChannelInterfaceConferenceInterface	(	const QDBusConnection &	connection,
		const QString &	busName,
		const QString &	objectPath,
		QObject *	parent = 0
	)

Creates a ChannelInterfaceConferenceInterface 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::ChannelInterfaceConferenceInterface::ChannelInterfaceConferenceInterface

(

Tp::DBusProxy *

proxy

)

Creates a ChannelInterfaceConferenceInterface 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::ChannelInterfaceConferenceInterface::ChannelInterfaceConferenceInterface

(

const Tp::Client::ChannelInterface &

mainInterface

)

[explicit]

Creates a ChannelInterfaceConferenceInterface 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::ChannelInterfaceConferenceInterface::ChannelInterfaceConferenceInterface	(	const Tp::Client::ChannelInterface &	mainInterface,
		QObject *	parent
	)

Creates a ChannelInterfaceConferenceInterface 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::ChannelInterfaceConferenceInterface::staticInterfaceName

(

)

[inline, static]

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

Returns:

The D-Bus interface name.

TELEPATHY_QT4_DEPRECATED Tp::ObjectPathList Tp::Client::ChannelInterfaceConferenceInterface::Channels

(

)

const [inline]

Getter for the remote object property "Channels".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyChannels

(

)

const [inline]

Asynchronous getter for the remote object property "Channels" of type Tp::ObjectPathList.

The individual <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s that are continued by this conference, which have the same <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref> as this one, but with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref> = CONTACT.

This property MUST NOT be requestable; instead, the <tp:member-ref>InitialChannels</tp:member-ref> property may be specified when requesting a channel.

<tp:rationale>

This is consistent with requesting <tp:member-ref>InitialInviteeHandles</tp:member-ref> and <tp:member-ref>InitialInviteeIDs</tp:member-ref>, rather than requesting <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.Members</tp:dbus-ref> and some hypothetical ID version of that property. </tp:rationale>

Change notification is via the <tp:member-ref>ChannelMerged</tp:member-ref> and <tp:member-ref>ChannelRemoved</tp:member-ref> signals.

Returns:

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

TELEPATHY_QT4_DEPRECATED Tp::ObjectPathList Tp::Client::ChannelInterfaceConferenceInterface::InitialChannels

(

)

const [inline]

Getter for the remote object property "InitialChannels".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyInitialChannels

(

)

const [inline]

Asynchronous getter for the remote object property "InitialChannels" of type Tp::ObjectPathList.

The initial value of <tp:member-ref>Channels</tp:member-ref>.

This property SHOULD be requestable. Omitting it from a request is equivalent to providing it with an empty list as value. Requests where its value has at least two channel paths SHOULD be expected to succeed on any implementation of this interface. If <tp:member-ref>InitialInviteeHandles</tp:member-ref> and <tp:member-ref>InitialInviteeIDs</tp:member-ref> are Allowed_Properties in <tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>, then requests with zero or one channel paths SHOULD also succeed; otherwise, clients SHOULD NOT make requests with zero or one paths for this property.

<tp:rationale>

In GSM, a pair of calls can be merged into a conference, but you can't start a conference call from zero or one existing calls. In XMPP and MSN, you can create a new chatroom, or upgrade one 1-1 channel into a chatroom; however, on these protocols, it is also possible to fake GSM-style merging by upgrading the first channel, then inviting the targets of all the other channels into it. </tp:rationale>

If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD NOT be altered by merging them into a conference. However, depending on the protocol, the Channels MAY be placed in a "frozen" state by placing them in this property's value or by calling <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.

<tp:rationale>

In Jingle, nothing special will happen to merged calls. UIs MAY automatically place calls on hold before merging them, if that is the desired behaviour; this SHOULD always work. Not doing an implicit hold/unhold seems to preserve least-astonishment.

In GSM, the calls that are merged go into a state similar to Hold, but they cannot be unheld, only split from the conference call using <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Splittable.DRAFT.Split</tp:dbus-ref>. </tp:rationale>

Depending on the protocol, it might be signalled to remote users that this channel is a continuation of all the requested channels, or that it is only a continuation of the first channel in the list.

<tp:rationale>

In MSN, the conference steals the underlying switchboard (protocol construct) from one of its component channels, so the conference appears to remote users to be a continuation of that channel and no other. The connection manager has to make some arbitrary choice, so we arbitrarily mandate that it SHOULD choose the first channel in the list as the one to continue. </tp:rationale>

This property is immutable.

Returns:

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

TELEPATHY_QT4_DEPRECATED Tp::UIntList Tp::Client::ChannelInterfaceConferenceInterface::InitialInviteeHandles

(

)

const [inline]

Getter for the remote object property "InitialInviteeHandles".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyInitialInviteeHandles

(

)

const [inline]

Asynchronous getter for the remote object property "InitialInviteeHandles" of type Tp::UIntList.

A list of additional contacts invited to this conference when it was created.

If it is possible to invite new contacts when creating a conference (as opposed to merging several channels into one new conference channel), this property SHOULD be requestable, and appear in the allowed properties in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property SHOULD NOT be requestable, and its value SHOULD always be the empty list.

<tp:rationale>

On GSM you have to place a 1-1 call before you can merge it into a conference; on the other hand, you can invite new contacts to XMPP Muji calls and XMPP/MSN/Skype ad-hoc chat rooms without starting a 1-1 channel with them first. </tp:rationale>

If included in a request, the given contacts are automatically invited into the new channel, as if they had been added with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.AddMembers</tp:dbus-ref>(InitialInviteeHandles, <tp:member-ref>InvitationMessage</tp:member-ref>) immediately after the channel was created.

<tp:rationale>

This is a simple convenience API for the common case that a UI upgrades a 1-1 chat to a multi-user chat solely in order to invite someone else to participate. </tp:rationale>

If the local user was not the initiator of this channel, the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref> SHOULD appear in the value of this property, together with any other contacts invited at the same time (if that information is known).

This property is immutable.

InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be combined in a single request.

<tp:rationale>

For example, if you have a 1-1 channel C1 with Rob, and you want to invite Sjoerd to join the discussion, you can do so by requesting a channel with InitialChannels=[C1] and InitialInviteeHandles=[sjoerd], or InitialChannels=[C1] and InitialInviteeIDs=["sjoerd@example.com"]. </tp:rationale>

If a request includes some combination of InitialInviteeHandles, InitialInviteeIDs and InitialChannels, then the value of InitialInviteeHandles on the resulting channel SHOULD be the union of the handles from InitialInviteeHandles, the handles corresponding to the InitialInviteeIDs, and the target handles of the InitialChannels, with any duplicate handles removed. Because this property is immutable, its value SHOULD be computed before the channel is announced via the NewChannels signal.

<tp:rationale>

This simplifies identification of new channels in clients - they only have to look at one of the properties, not both. For example, after either of the requests mentioned above, the NewChannels signal would announce the channel with InitialChannels=[C1], InitialInviteeHandles=[rob, sjoerd], and InitialInviteeIDs=["rob@example.net", "sjoerd.example.com"]. </tp:rationale>

Returns:

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

TELEPATHY_QT4_DEPRECATED QStringList Tp::Client::ChannelInterfaceConferenceInterface::InitialInviteeIDs

(

)

const [inline]

Getter for the remote object property "InitialInviteeIDs".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyInitialInviteeIDs

(

)

const [inline]

Asynchronous getter for the remote object property "InitialInviteeIDs" of type QStringList.

A list of additional contacts invited to this conference when it was created.

This property SHOULD be requestable if and only if <tp:member-ref>InitialInviteeHandles</tp:member-ref> is requestable. Its semantics are the same, except that it takes a list of the string representations of contact handles; invitations are sent to any contact present in either or both of these properties.

When a channel is created, the values of InitialInviteeHandles and InitialInviteeIDs MUST correspond to each other. In particular, this means that the value of InitialInviteeIDs will include the TargetID of each channel in InitialChannels, and the ID corresponding to each handle in InitialInviteeHandles.

This property is immutable.

Returns:

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

TELEPATHY_QT4_DEPRECATED QString Tp::Client::ChannelInterfaceConferenceInterface::InvitationMessage

(

)

const [inline]

Getter for the remote object property "InvitationMessage".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyInvitationMessage

(

)

const [inline]

Asynchronous getter for the remote object property "InvitationMessage" of type QString.

The message that was sent to the <tp:member-ref>InitialInviteeHandles</tp:member-ref> when they were invited.

This property SHOULD be requestable, and appear in the allowed properties in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>, in protocols where invitations can have an accompanying text message.

<tp:rationale>

This allows invitations with a message to be sent when using <tp:member-ref>InitialInviteeHandles</tp:member-ref> or <tp:member-ref>InitialInviteeIDs</tp:member-ref>. </tp:rationale>

If the local user was not the initiator of this channel, the message with which they were invited (if any) SHOULD appear in the value of this property.

This property is immutable.

Returns:

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

TELEPATHY_QT4_DEPRECATED Tp::ChannelOriginatorMap Tp::Client::ChannelInterfaceConferenceInterface::OriginalChannels

(

)

const [inline]

Getter for the remote object property "OriginalChannels".

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

Returns:

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

Tp::PendingVariant* Tp::Client::ChannelInterfaceConferenceInterface::requestPropertyOriginalChannels

(

)

const [inline]

Asynchronous getter for the remote object property "OriginalChannels" of type Tp::ChannelOriginatorMap.

On GSM conference calls, it is possible to have the same phone number in a conference twice; for instance, it could be the number of a corporate switchboard. This is represented using channel-specific handles; whether or not a channel uses channel-specific handles is reported in <tp:dbus-ref namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>. The <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref> property specifies the mapping from opaque channel-specific handles to actual numbers; this property specifies the original 1-1 channel corresponding to each channel-specific handle in the conference.

In protocols where this situation cannot arise, such as XMPP, this property MAY remain empty.

For example, consider this situation:

1. Place a call (with path /call/to/simon) to the contact +441234567890 (which is assigned the handle h, say), and ask to be put through to Simon McVittie;
2. Put that call on hold;
3. Place another call (with path /call/to/jonny) to +441234567890, and ask to be put through to Jonny Lamb;
4. Request a new channel with <tp:member-ref>InitialChannels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'].

The new channel will have the following properties, for some handles s and j:

<blockquote> {
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>: Channel_Specific_Handles | (other flags),
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>: [self_handle, s, j],
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>: { s: h, j: h },
...<tp:member-ref>InitialChannels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'],
...<tp:member-ref>Channels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'],
...<tp:member-ref>OriginalChannels</tp:member-ref>: { s: '/call/to/simon', j: '/call/to/jonny' },
# ...standard properties like ChannelType: Group elided...
} </blockquote>

Change notification is via the <tp:member-ref>ChannelMerged</tp:member-ref> and <tp:member-ref>ChannelRemoved</tp:member-ref> signals: if Channel_Specific_Handle in the former is non-zero, this property SHOULD be updated to map that handle to the merged channel's path.

Returns:

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

Tp::PendingVariantMap* Tp::Client::ChannelInterfaceConferenceInterface::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.

void Tp::Client::ChannelInterfaceConferenceInterface::ChannelMerged	(	const QDBusObjectPath &	channel,
		uint	channelSpecificHandle,
		const QVariantMap &	properties
	)			[signal]

Represents the signal "ChannelMerged" on the remote object.

Emitted when a new channel is added to the value of <tp:member-ref>Channels</tp:member-ref>.

Parameters:

	channel	The channel that was added to Channels.
	channelSpecificHandle	A new channel-specific handle for the TargetHandle of Channel, as will appear in OriginalChannels, or 0 if a global handle is used for Channel's TargetHandle on the Group interface of this channel.
	properties	Channel's immutable properties.

void Tp::Client::ChannelInterfaceConferenceInterface::ChannelRemoved	(	const QDBusObjectPath &	channel,
		const QVariantMap &	details
	)			[signal]

Represents the signal "ChannelRemoved" on the remote object.

Emitted when a channel is removed from the value of <tp:member-ref>Channels</tp:member-ref>, either because it closed or because it was split using the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Splittable.DRAFT.Split</tp:dbus-ref> method.

If a channel is removed because it was closed, <tp:dbus-ref namespace="ofdT.Channel">Closed</tp:dbus-ref> should be emitted before this signal.

Parameters:

	channel	The channel that was removed from Channels.
	details	Additional information about the removal, which may include the same well-known keys as the Details argument of <tp:dbus-ref namespace="ofdT.Channel.Interface.Group">MembersChangedDetailed</tp:dbus-ref>, with the same semantics.

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

Reimplemented from Tp::AbstractInterface.

---

Property Documentation

Tp::ObjectPathList Tp::Client::ChannelInterfaceConferenceInterface::Channels [read]

Represents property "Channels" on the remote object.

The individual <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel</tp:dbus-ref>s that are continued by this conference, which have the same <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">ChannelType</tp:dbus-ref> as this one, but with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel">TargetHandleType</tp:dbus-ref> = CONTACT.

This property MUST NOT be requestable; instead, the <tp:member-ref>InitialChannels</tp:member-ref> property may be specified when requesting a channel.

<tp:rationale>

This is consistent with requesting <tp:member-ref>InitialInviteeHandles</tp:member-ref> and <tp:member-ref>InitialInviteeIDs</tp:member-ref>, rather than requesting <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.Members</tp:dbus-ref> and some hypothetical ID version of that property. </tp:rationale>

Change notification is via the <tp:member-ref>ChannelMerged</tp:member-ref> and <tp:member-ref>ChannelRemoved</tp:member-ref> signals.

Tp::ObjectPathList Tp::Client::ChannelInterfaceConferenceInterface::InitialChannels [read]

Represents property "InitialChannels" on the remote object.

The initial value of <tp:member-ref>Channels</tp:member-ref>.

This property SHOULD be requestable. Omitting it from a request is equivalent to providing it with an empty list as value. Requests where its value has at least two channel paths SHOULD be expected to succeed on any implementation of this interface. If <tp:member-ref>InitialInviteeHandles</tp:member-ref> and <tp:member-ref>InitialInviteeIDs</tp:member-ref> are Allowed_Properties in <tp:dbus-ref namespace="ofdT.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>, then requests with zero or one channel paths SHOULD also succeed; otherwise, clients SHOULD NOT make requests with zero or one paths for this property.

<tp:rationale>

In GSM, a pair of calls can be merged into a conference, but you can't start a conference call from zero or one existing calls. In XMPP and MSN, you can create a new chatroom, or upgrade one 1-1 channel into a chatroom; however, on these protocols, it is also possible to fake GSM-style merging by upgrading the first channel, then inviting the targets of all the other channels into it. </tp:rationale>

If possible, the <tp:member-ref>Channels</tp:member-ref>' states SHOULD NOT be altered by merging them into a conference. However, depending on the protocol, the Channels MAY be placed in a "frozen" state by placing them in this property's value or by calling <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">MergeableConference.DRAFT.Merge</tp:dbus-ref> on them.

<tp:rationale>

In Jingle, nothing special will happen to merged calls. UIs MAY automatically place calls on hold before merging them, if that is the desired behaviour; this SHOULD always work. Not doing an implicit hold/unhold seems to preserve least-astonishment.

In GSM, the calls that are merged go into a state similar to Hold, but they cannot be unheld, only split from the conference call using <tp:dbus-ref namespace="org.freedesktop.Telepathy">Channel.Interface.Splittable.DRAFT.Split</tp:dbus-ref>. </tp:rationale>

Depending on the protocol, it might be signalled to remote users that this channel is a continuation of all the requested channels, or that it is only a continuation of the first channel in the list.

<tp:rationale>

In MSN, the conference steals the underlying switchboard (protocol construct) from one of its component channels, so the conference appears to remote users to be a continuation of that channel and no other. The connection manager has to make some arbitrary choice, so we arbitrarily mandate that it SHOULD choose the first channel in the list as the one to continue. </tp:rationale>

This property is immutable.

Tp::UIntList Tp::Client::ChannelInterfaceConferenceInterface::InitialInviteeHandles [read]

Represents property "InitialInviteeHandles" on the remote object.

A list of additional contacts invited to this conference when it was created.

If it is possible to invite new contacts when creating a conference (as opposed to merging several channels into one new conference channel), this property SHOULD be requestable, and appear in the allowed properties in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>. Otherwise, this property SHOULD NOT be requestable, and its value SHOULD always be the empty list.

<tp:rationale>

On GSM you have to place a 1-1 call before you can merge it into a conference; on the other hand, you can invite new contacts to XMPP Muji calls and XMPP/MSN/Skype ad-hoc chat rooms without starting a 1-1 channel with them first. </tp:rationale>

If included in a request, the given contacts are automatically invited into the new channel, as if they had been added with <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.AddMembers</tp:dbus-ref>(InitialInviteeHandles, <tp:member-ref>InvitationMessage</tp:member-ref>) immediately after the channel was created.

<tp:rationale>

This is a simple convenience API for the common case that a UI upgrades a 1-1 chat to a multi-user chat solely in order to invite someone else to participate. </tp:rationale>

If the local user was not the initiator of this channel, the <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.SelfHandle</tp:dbus-ref> SHOULD appear in the value of this property, together with any other contacts invited at the same time (if that information is known).

This property is immutable.

InitialInviteeHandles, InitialInviteeIDs and InitialChannels MAY be combined in a single request.

<tp:rationale>

For example, if you have a 1-1 channel C1 with Rob, and you want to invite Sjoerd to join the discussion, you can do so by requesting a channel with InitialChannels=[C1] and InitialInviteeHandles=[sjoerd], or InitialChannels=[C1] and InitialInviteeIDs=["sjoerd@example.com"]. </tp:rationale>

If a request includes some combination of InitialInviteeHandles, InitialInviteeIDs and InitialChannels, then the value of InitialInviteeHandles on the resulting channel SHOULD be the union of the handles from InitialInviteeHandles, the handles corresponding to the InitialInviteeIDs, and the target handles of the InitialChannels, with any duplicate handles removed. Because this property is immutable, its value SHOULD be computed before the channel is announced via the NewChannels signal.

<tp:rationale>

This simplifies identification of new channels in clients - they only have to look at one of the properties, not both. For example, after either of the requests mentioned above, the NewChannels signal would announce the channel with InitialChannels=[C1], InitialInviteeHandles=[rob, sjoerd], and InitialInviteeIDs=["rob@example.net", "sjoerd.example.com"]. </tp:rationale>

QStringList Tp::Client::ChannelInterfaceConferenceInterface::InitialInviteeIDs [read]

Represents property "InitialInviteeIDs" on the remote object.

A list of additional contacts invited to this conference when it was created.

This property SHOULD be requestable if and only if <tp:member-ref>InitialInviteeHandles</tp:member-ref> is requestable. Its semantics are the same, except that it takes a list of the string representations of contact handles; invitations are sent to any contact present in either or both of these properties.

When a channel is created, the values of InitialInviteeHandles and InitialInviteeIDs MUST correspond to each other. In particular, this means that the value of InitialInviteeIDs will include the TargetID of each channel in InitialChannels, and the ID corresponding to each handle in InitialInviteeHandles.

This property is immutable.

QString Tp::Client::ChannelInterfaceConferenceInterface::InvitationMessage [read]

Represents property "InvitationMessage" on the remote object.

The message that was sent to the <tp:member-ref>InitialInviteeHandles</tp:member-ref> when they were invited.

This property SHOULD be requestable, and appear in the allowed properties in <tp:dbus-ref namespace="org.freedesktop.Telepathy.Connection.Interface.Requests">RequestableChannelClasses</tp:dbus-ref>, in protocols where invitations can have an accompanying text message.

<tp:rationale>

This allows invitations with a message to be sent when using <tp:member-ref>InitialInviteeHandles</tp:member-ref> or <tp:member-ref>InitialInviteeIDs</tp:member-ref>. </tp:rationale>

If the local user was not the initiator of this channel, the message with which they were invited (if any) SHOULD appear in the value of this property.

This property is immutable.

Tp::ChannelOriginatorMap Tp::Client::ChannelInterfaceConferenceInterface::OriginalChannels [read]

Represents property "OriginalChannels" on the remote object.

On GSM conference calls, it is possible to have the same phone number in a conference twice; for instance, it could be the number of a corporate switchboard. This is represented using channel-specific handles; whether or not a channel uses channel-specific handles is reported in <tp:dbus-ref namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>. The <tp:dbus-ref namespace="org.freedesktop.Telepathy.Channel.Interface">Group.HandleOwners</tp:dbus-ref> property specifies the mapping from opaque channel-specific handles to actual numbers; this property specifies the original 1-1 channel corresponding to each channel-specific handle in the conference.

In protocols where this situation cannot arise, such as XMPP, this property MAY remain empty.

For example, consider this situation:

1. Place a call (with path /call/to/simon) to the contact +441234567890 (which is assigned the handle h, say), and ask to be put through to Simon McVittie;
2. Put that call on hold;
3. Place another call (with path /call/to/jonny) to +441234567890, and ask to be put through to Jonny Lamb;
4. Request a new channel with <tp:member-ref>InitialChannels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'].

The new channel will have the following properties, for some handles s and j:

<blockquote> {
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.GroupFlags</tp:dbus-ref>: Channel_Specific_Handles | (other flags),
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.Members</tp:dbus-ref>: [self_handle, s, j],
...<tp:dbus-ref namespace="ofdT.Channel.Interface">Group.HandleOwners</tp:dbus-ref>: { s: h, j: h },
...<tp:member-ref>InitialChannels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'],
...<tp:member-ref>Channels</tp:member-ref>: ['/call/to/simon', '/call/to/jonny'],
...<tp:member-ref>OriginalChannels</tp:member-ref>: { s: '/call/to/simon', j: '/call/to/jonny' },
# ...standard properties like ChannelType: Group elided...
} </blockquote>

Change notification is via the <tp:member-ref>ChannelMerged</tp:member-ref> and <tp:member-ref>ChannelRemoved</tp:member-ref> signals: if Channel_Specific_Handle in the former is non-zero, this property SHOULD be updated to map that handle to the merged channel's path.