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.
org.freedesktop.Telepathy.ConnectionManagerorg.freedesktop.Telepathy.Connectionorg.freedesktop.Telepathy.Connection.Interface.Aliasingorg.freedesktop.Telepathy.Connection.Interface.Avatarsorg.freedesktop.Telepathy.Connection.Interface.Capabilitiesorg.freedesktop.Telepathy.Connection.Interface.ContactInfoorg.freedesktop.Telepathy.Connection.Interface.Forwardingorg.freedesktop.Telepathy.Connection.Interface.Presenceorg.freedesktop.Telepathy.Connection.Interface.Privacyorg.freedesktop.Telepathy.Connection.Interface.Renamingorg.freedesktop.Telepathy.Channelorg.freedesktop.Telepathy.Channel.Type.ContactListorg.freedesktop.Telepathy.Channel.Type.ContactSearchorg.freedesktop.Telepathy.Channel.Type.StreamedMediaorg.freedesktop.Telepathy.Channel.Type.RoomListorg.freedesktop.Telepathy.Channel.Type.Textorg.freedesktop.Telepathy.Channel.Type.Tubesorg.freedesktop.Telepathy.Channel.Interface.CallMergingorg.freedesktop.Telepathy.Channel.Interface.ChatStateorg.freedesktop.Telepathy.Channel.Interface.DTMForg.freedesktop.Telepathy.Channel.Interface.Grouporg.freedesktop.Telepathy.Channel.Interface.Holdorg.freedesktop.Telepathy.Channel.Interface.Passwordorg.freedesktop.Telepathy.Channel.Interface.Transferorg.freedesktop.Telepathy.Channel.Interface.MediaSignallingorg.freedesktop.Telepathy.Media.SessionHandlerorg.freedesktop.Telepathy.Media.StreamHandlerorg.freedesktop.Telepathy.Propertiesorg.freedesktop.Telepathy.ChannelHandlerA D-Bus service which allows connections to be created. The manager processes are intended to be started by D-Bus service activation.
For service discovery, each Telepathy connection manager must have a connection manager name, which is a non-empty string of ASCII letters, digits and underscores, starting with a letter. This is typically the name of the executable with any "telepathy-" prefix removed.
The connection manager must then provide a well-known bus name of
org.freedesktop.Telepathy.ConnectionManager.cmname
where cmname is its connection manager name. If it makes sense
to start the connection manager using D-Bus service activation, it
must register that well-known name for service activation by installing
a .service file.
Clients can list the running connection managers by calling the ListNames method on the D-Bus daemon's org.freedesktop.DBus interface and looking for names matching the above pattern; they can list the activatable connection managers by calling ListActivatableNames, and they should usually combine the two lists to get a complete list of running or activatable connection managers.
When the connection manager is running, it must have an object
implementing the ConnectionManager interface at the object path
/org/freedesktop/Telepathy/ConnectionManager/cmname.
Connection managers' capabilities can be determined dynamically by calling their ListProtocols method, then for each protocol of interest, calling GetParameters to discover the required and optional parameters. However, since it is inefficient to activate all possible connection managers on the system just to find out what they can do, there is a standard mechanism to store static information about CMs in ".manager files".
To look up a connection manager's supported protocols, clients
should search the data directories specified by
the
freedesktop.org XDG Base Directory Specification ($XDG_DATA_HOME,
defaulting to $HOME/.local/share if unset, followed by
colon-separated paths from $XDG_DATA_DIRS, defaulting to
/usr/local/share:/usr/share if unset) for the first file named
telepathy/managers/cmname.manager that can be
read without error. This file has the same syntax as a
freedesktop.org Desktop Entry file.
For each protocol name proto that would be returned by
ListProtocols, the .manager file contains a group
headed [Protocol proto]. For each parameter
p that would be returned by GetParameters(proto), the
.manager file contains a key param-p with a value
consisting of a D-Bus signature (a single complete type), optionally
followed by a space and a space-separated list of flags. The supported
flags are required, corresponding to
Conn_Mgr_Param_Flag_Required, and register, corresponding
to Conn_Mgr_Param_Flag_Register.
The group may also contain a key default-p
whose value is a string form of the default value for the parameter.
If this key exists, it sets the default, and also sets the flag
Conn_Mgr_Param_Flag_Has_Default. The default value is formatted
according to the D-Bus signature as follows:
Currently, no other D-Bus signatures are allowed to have default values,
but clients parsing the .manager file MUST ignore defaults
that they cannot parse, and treat them as if the
default-p key was not present at all.
It is not required that a connection manager be able to support multiple protocols, or even multiple connections. When a connection is made, a service name where the connection object can be found is returned. A manager which can only make one connection may then remove itself from its well-known bus name, causing a new connection manager to be activated when somebody attempts to make a new connection.
proto -
s
(Protocol)
a(susv)
(Param_Spec[])
org.freedesktop.Telepathy.Error.NotImplementedas
(Protocol[])
Request a Connection object representing a given account on a given protocol with the given parameters. The method returns the bus name and the object path where the new Connection object can be found, which should have the status of Connection_Status_Disconnected, to allow signal handlers to be attached before connecting is started with the Connect method.
In order to allow Connection objects to be discovered by new clients,
the object path and well-known bus name must be of the form
/org/freedesktop/Telepathy/Connection/cmname/proto/account
and
org.freedesktop.Telepathy.Connection.cmname.proto.account
where:
Clients MUST NOT attempt to parse the account part of the bus name. Connection managers MAY use any unique string for this part.
The parameters which must and may be provided in the parameters dictionary can be discovered with the GetParameters method. These parameters, their types, and their default values may be cached in files so that all available connection managers do not need to be started to discover which protocols are available.
To request values for these parameters from the user, a client must have prior knowledge of the meaning of the parameter names, so the following well-known names and types should be used where appropriate:
Every successful RequestConnection call will cause the emission of a NewConnection signal for the same newly created connection. The requester can use the returned object path and service name independently of the emission of that signal. In that case this signal emission is most useful for, e.g. other processes that are monitoring the creation of new connections.
proto -
s
(Protocol)
parameters -
a{sv}
(String_Variant_Map)
soorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentbus_name -
s
(DBus_Bus_Name)
object_path -
oproto -
s
(Protocol)
Interface has no properties.
An instant messaging protocol. It must consist only of ASCII letters, digits and hyphen/minus signs (U+002D "-"), and must start with a letter. Where possible, this SHOULD be chosen from the following well-known values:
Conn_Mgr_Param_Flag_Required = 1Conn_Mgr_Param_Flag_Register = 2Conn_Mgr_Param_Flag_Has_Default = 4In bindings that need a separate name, arrays of Param_Spec should be called Param_Spec_List.
Name -
sFlags -
u
(Conn_Mgr_Param_Flags)
Signature -
s
(DBus_Signature)
Default_Value -
vThis models a connection to a single user account on a communication service. Its basic capability is to provide the facility to request and receive channels of differing types (such as text channels or streaming media channels) which are used to carry out further communication.
As well as the methods and signatures below, arbitrary interfaces may be provided by the Connection object to represent extra connection-wide functionality, such as the Connection.Interface.Presence for receiving and reporting presence information, and Connection.Interface.Aliasing for connections where contacts may set and change an alias for themselves. These interfaces can be discovered using GetInterfaces after the connection, has been established and must not change subsequently at runtime.
Contacts, rooms, and server-stored lists (such as subscribed contacts, block lists, or allow lists) on a service are all represented by immutable handles, which are unsigned non-zero integers which are valid only for the lifetime of the connection object, and are used throughout the protocol where these entities are represented, allowing simple testing of equality within clients.
Zero as a handle value is sometimes used as a "null" value to mean the absence of a contact, room, etc.
Handles have per-type uniqueness, meaning that every (handle type, handle number) tuple is guaranteed to be unique within a connection and that a handle alone (without its type) is meaningless or ambiguous. Connection manager implementations should reference count these handles to determine if they are in use either by any active clients or any open channels, and may deallocate them when this ceases to be true. Clients may request handles of a given type and name with the RequestHandles method, inspect the entity name of handles with the InspectHandles method, keep handles from being released with HoldHandles, and notify that they are no longer storing handles with ReleaseHandles.
org.freedesktop.Telepathy.Error.NotAvailableas
(DBus_Interface[])
org.freedesktop.Telepathy.Error.Disconnectedsuorg.freedesktop.Telepathy.Error.Disconnectedu
(Connection_Status)
Notify the connection manger that your client is holding a copy of handles which may not be in use in any existing channel or list, and were not obtained by using the RequestHandles method. For example, a handle observed in an emitted signal, or displayed somewhere in the UI that is not associated with a channel. The connection manager must not deallocate a handle where any clients have used this method to indicate it is in use until the ReleaseHandle method is called, or the clients disappear from the bus.
Note that HoldHandles is idempotent - calling it multiple times is equivalent to calling it once. If a handle is "referenced" by several components which share a D-Bus unique name, the client should perform reference counting internally, and only call ReleaseHandles when none of the cooperating components need the handle any longer.
handle_type -
u
(Handle_Type)
handles -
au
(Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandlehandle_type -
u
(Handle_Type)
handles -
au
(Handle[])
asorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandlea(osuu)
(Channel_Info[])
org.freedesktop.Telepathy.Error.Disconnectedhandle_type -
u
(Handle_Type)
handles -
au
(Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableRequest a channel satisfying the specified type and communicating with the contact, room, list etc. indicated by the given handle_type and handle. The handle_type and handle may both be zero to request the creation of a new, empty channel, which may or may not be possible, depending on the protocol and channel type.
On success, the returned channel will always be of the requested type (i.e. implement the requested channel-type interface).
If a new, empty channel is requested, on success the returned channel will always be an "anonymous" channel for which the type and handle are both zero.
If a channel to a contact, room etc. is requested, on success, the returned channel may either be a new or existing channel to the requested entity (i.e. its GetHandle() returns the requested handle type and handle), or a newly created "anonymous" channel associated with the requested handle in some implementation-specific way.
For example, for a contact handle, the returned channel might be "anonymous", but implement the groups interface and have the requested contact already present among the members.
If the request cannot be satisfied, an error is raised and no channel is created.
type -
s
(DBus_Interface)
handle_type -
u
(Handle_Type)
handle -
u
(Handle)
suppress_handler -
boorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.Channel.Bannedorg.freedesktop.Telepathy.Error.Channel.Fullorg.freedesktop.Telepathy.Error.Channel.InviteOnlyhandle_type -
u
(Handle_Type)
names -
asau
(Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableobject_path -
ochannel_type -
s
(DBus_Interface)
handle_type -
u
(Handle_Type)
handle -
u
(Handle)
suppress_handler -
bstatus -
u
(Connection_Status)
reason -
u
(Connection_Status_Reason)
Interface has no properties.
Handle_Type_None = 0Handle_Type_Contact = 1Handle_Type_Room = 2Handle_Type_List = 3Handle_Type_Group = 4Connection_Status_Connected = 0Connection_Status_Connecting = 1Connection_Status_Disconnected = 2Connection_Status_Reason_None_Specified = 0Connection_Status_Reason_Requested = 1Connection_Status_Reason_Network_Error = 2Connection_Status_Reason_Authentication_Failed = 3Connection_Status_Reason_Encryption_Error = 4Connection_Status_Reason_Name_In_Use = 5Connection_Status_Reason_Cert_Not_Provided = 6Connection_Status_Reason_Cert_Untrusted = 7Connection_Status_Reason_Cert_Expired = 8Connection_Status_Reason_Cert_Not_Activated = 9Connection_Status_Reason_Cert_Hostname_Mismatch = 10Connection_Status_Reason_Cert_Fingerprint_Mismatch = 11Connection_Status_Reason_Cert_Self_Signed = 12Connection_Status_Reason_Cert_Other_Error = 13In bindings that need a separate name, arrays of Channel_Info should be called Channel_Info_List.
Channel -
oChannel_Type -
s
(DBus_Interface)
Handle_Type -
u
(Handle_Type)
Handle -
u
(Handle)
Implementations of this interface must also implement:
An interface on connections to support protocols where contacts have an alias which they can change at will. Provides a method for the user to set their own alias, and a signal which should be emitted when a contact's alias is changed or first discovered.
On connections where the user is allowed to set aliases for contacts and store them on the server, the GetAliasFlags method will have the CONNECTION_ALIAS_FLAG_USER_SET flag set, and the SetAliases method may be called on contact handles other than the user themselves.
Aliases are intended to be used as the main displayed name for the contact, where available.
u
(Connection_Alias_Flags)
org.freedesktop.Telepathy.Error.Disconnectedcontacts -
au
(Contact_Handle[])
asorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidHandlealiases -
a{us}
(Alias_Map)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedaliases -
a(us)
(Alias_Pair[])
Interface has no properties.
Connection_Alias_Flag_User_Set = 1The aliases of contacts on this connection may be changed by the user of the service, not just by the contacts themselves. This is the case on Jabber, for instance.
It is possible that aliases can be changed by the contacts too - which alias takes precedence is not defined by this specification, and depends on the server and/or connection manager implementation.
This flag only applies to the aliases of "globally valid" contact handles. At this time, clients should not expect to be able to change the aliases corresponding to any channel-specific handles. If this becomes possible in future, a new flag will be defined.
In bindings that need a separate name, arrays of Alias_Pair should be called Alias_Pair_List.
Handle -
u
(Contact_Handle)
Alias -
sHandle -
u
(Contact_Handle)
Alias -
sImplementations of this interface must also implement:
An interface for requesting avatars for contacts on a given connection, receiving notification when avatars are changed, and publishing your own avatar.
Avatars are identified by a unique (per contact) token which represents a hash or timestamp (depending on the protocol) of the contacts' avatar data. An empty token means that an avatar has not been set for this contact, and a changed token implies the contact's avatar has changed, but the strings should otherwise be considered opaque by clients.
A client should use GetKnownAvatarTokens to request the tokens for the avatars of all the contacts it is interested in when it connects. The avatars can then be requested using RequestAvatars for the contacts. Clients should bind to the AvatarChanged signal and request a new copy of the avatar when a contacts' avatar token changes. Clients should cache the token and data of each contact's avatar between connections, to avoid repeatedly retrieving the same avatar.
To publish an avatar, a client should use SetAvatar to provide an image which meets the requirements returned by the GetAvatarRequirements function. On some protocols the avatar is stored on the server, so setting the avatar is persistent, but on others it is transferred via a peer to peer mechanism, so needs to be set every connection. Hence, on every connection, clients should inspect the avatar token of the connection's self handle, and set the avatar if it is an empty string (and may optionally replace it if the token corresponds to a different avatar).
To remove the published avatar on protocols which have persistent avatars, a client should use the ClearAvatar method. This method can safely be used even if there is no avatar for this connection.
asqqqquorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
au
(Contact_Handle[])
asorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
au
(Contact_Handle[])
a{us}
(Avatar_Token_Map)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontact -
u
(Contact_Handle)
aysorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontacts -
au
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleavatar -
aymime_type -
ssorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorcontact -
u
(Contact_Handle)
new_avatar_token -
scontact -
u
(Contact_Handle)
token -
savatar -
aytype -
sInterface has no properties.
Handle -
u
(Contact_Handle)
Token -
sImplementations of this interface must also implement:
An interface for connections where it is possible to know what channel types may be requested before the request is made to the connection object. Each capability represents a commitment by the connection manager that it will ordinarily be able to create a channel when given a request with the given type and handle.
Capabilities can pertain to a certain contact handle, representing activities such as having a text chat or a voice call with the user, or can be on the connection itself (where the handle will be zero), where they represent the ability to create channels for chat rooms or activities such as searching and room listing. The activities are represented by the D-Bus interface name of the channel type for that activity.
The generic capability flags are defined by ConnectionCapabilityFlag.
In addition, channel types may have type specific capability flags of their own, which are described in the documentation for each channel type.
This interface also provides for user interfaces notifying the connection manager of what capabilities to advertise for the user. This is done by using the AdvertiseCapabilities method, and deals with the interface names of channel types and the type specific flags pertaining to them which are implemented by available client processes.
Used by user interfaces to indicate which channel types they are able to handle on this connection. Because these may be provided by different client processes, this method accepts channel types to add and remove from the set already advertised on this connection. The type of advertised capabilities (create versus invite) is protocol-dependent and hence cannot be set by the this method. In the case of a client adding an already advertised channel type but with new channel type specific flags, the connection manager should simply add the new flags to the set of advertised capabilities.
Upon a successful invocation of this method, the CapabilitiesChanged signal will be emitted for the user's own handle (as returned by GetSelfHandle) the by the connection manager to indicate the changes that have been made. This signal should also be monitored to ensure that the set is kept accurate - for example, a client may remove capabilities or type specific capability flags when it exits which are still provided by another client.
add -
a(su)
(Capability_Pair[])
remove -
as
(DBus_Interface[])
a(su)
(Capability_Pair[])
org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.Disconnectedhandles -
au
(Contact_Handle[])
a(usuu)
(Contact_Capability[])
org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedcaps -
a(usuuuu)
(Capability_Change[])
Interface has no properties.
In bindings that need a separate name, arrays of Capability_Pair should be called Capability_Pair_List.
Channel_Type -
s
(DBus_Interface)
Type_Specific_Flags -
uIn bindings that need a separate name, arrays of Contact_Capability should be called Contact_Capability_List.
Handle -
u
(Contact_Handle)
Channel_Type -
s
(DBus_Interface)
Generic_Flags -
u
(Connection_Capability_Flags)
Type_Specific_Flags -
uIn bindings that need a separate name, arrays of Capability_Change should be called Capability_Change_List.
Handle -
u
(Contact_Handle)
Channel_Type -
s
(DBus_Interface)
Old_Generic_Flags -
u
(Connection_Capability_Flags)
New_Generic_Flags -
u
(Connection_Capability_Flags)
Old_Type_Specific_Flags -
uNew_Type_Specific_Flags -
uConnection_Capability_Flag_Create = 1Connection_Capability_Flag_Invite = 2This interface is obsolete and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
THIS INTERFACE IS DEPRECATED AND SHOULD NOT BE USED. A new version will be proposed in the 0.13 specification branch.
An interface for requesting information about a contact on a given connection. Information is returned as a vCard represented as an XML string, in the format defined by JEP-0054: vcard-temp specifiation from the Jabber Software Foundation (this is derived from the aborted IETF draft draft-dawson-vcard-xml-dtd-01).
Implementations using PHOTO or SOUND elements should use the URI encoding where possible, and not provide base64 encoded data to avoid unnecessary bus traffic. Clients should not implement support for these encoded forms. A separate interface will be provided for transferring user avatars.
The following extended element names are also added to represent information from other systems which are not based around vCards:
contact -
u
(Contact_Handle)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailablecontact -
u
(Contact_Handle)
vcard -
sInterface has no properties.
This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
A connection interface for services which can signal to contacts that they should instead contact a different user ID, effectively forwarding all incoming communication channels to another contact on the service.u
(Contact_Handle)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableforward_to -
u
(Contact_Handle)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidHandleforward_to -
u
(Contact_Handle)
Interface has no properties.
Implementations of this interface must also implement:
This interface is for services which have a concept of presence which can be published for yourself and monitored on your contacts. Telepathy's definition of presence is based on that used by the Galago project (see http://www.galago-project.org/).
Presence on an individual (yourself or one of your contacts) is modelled as a last activity time along with a set of zero or more statuses, each of which may have arbitrary key/value parameters. Valid statuses are defined per connection, and a list of them can be obtained with the GetStatuses method.
Each status has an arbitrary string identifier which should have an agreed meaning between the connection manager and any client which is expected to make use of it. The following well-known values (in common with those in Galago) should be used where possible to allow clients to identify common choices:
As well as these well-known status identifiers, every status also has a numerical type value chosen from ConnectionPresenceType which can be used by the client to classify even unknown statuses into different fundamental types.
These numerical types exist so that even if a client does not understand the string identifier being used, and hence cannot present the presence to the user to set on themselves, it may display an approximation of the presence if it is set on a contact.
The dictionary of variant types allows the connection manager to exchange further protocol-specific information with the client. It is recommended that the string (s) argument 'message' be interpreted as an optional message which can be associated with a presence status.
If the connection has a 'subscribe' contact list, PresenceUpdate signals should be emitted to indicate changes of contacts on this list, and should also be emitted for changes in your own presence. Depending on the protocol, the signal may also be emitted for others such as people with whom you are communicating, and any user interface should be updated accordingly.
On some protocols, RequestPresence may only succeed on contacts on your 'subscribe' list, and other contacts will cause a PermissionDenied error. On protocols where there is no 'subscribe' list, and RequestPresence succeeds, a client may poll the server intermittently to update any display of presence information.
status -
sparms -
a{sv}
(String_Variant_Map)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedcontacts -
au
(Contact_Handle[])
presence -
a{u(ua{sa{sv}})}
(Contact_Presences)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailablea{s(ubba{ss})}
(Status_Spec_Map)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorstatus -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidArgumentcontacts -
au
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NotAvailabletime -
u
(Unix_Timestamp)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedstatuses -
a{sa{sv}}
(Multiple_Status_Map)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedpresence -
a{u(ua{sa{sv}})}
(Contact_Presences)
Interface has no properties.
Connection_Presence_Type_Unset = 0Connection_Presence_Type_Offline = 1Connection_Presence_Type_Available = 2Connection_Presence_Type_Away = 3Connection_Presence_Type_Extended_Away = 4Connection_Presence_Type_Hidden = 5Connection_Presence_Type_Busy = 6Arrays of Last_Activity_And_Statuses don't generally make sense.
Last_Activity -
u
(Unix_Timestamp)
Statuses -
a{sa{sv}}
(Multiple_Status_Map)
Arrays of Status_Spec don't generally make sense.
Type -
u
(Connection_Presence_Type)
May_Set_On_Self -
bExclusive -
bParameter_Types -
a{ss}
(String_String_Map)
Status -
sParameters -
a{sv}
(String_Variant_Map)
Contact -
u
(Contact_Handle)
Presence -
(ua{sa{sv}})
(Last_Activity_And_Statuses)
Identifier -
sSpec -
(ubba{ss})
(Status_Spec)
This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface to support getting and setting privacy modes to configure situations such as not being contactable by people who are not on your subscribe list. If this interface is not implemented, the default can be presumed to be allow-all (as defined in GetPrivacyModes).sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorasmode -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidArgumentmode -
sInterface has no properties.
This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface on connections to support protocols where the unique identifiers of contacts can change. Because handles are immutable, this is represented by a pair of handles, that representing the old name, and that representing the new one.Request that the user's own identifier is changed on the server. If successful, a Renamed signal will be emitted for the current "self handle" as returned by GetSelfHandle.
It is protocol-dependent how the identifier that's actually used will be derived from the supplied identifier; some sort of normalization might take place.
name -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedEmitted when the unique identifier of a contact on the server changes.
Any channels associated with the contact's original handle will continue to be to that handle, and so are no longer useful (unless the contact renames back, or another contact connects with that unique ID). Clients may open a similar channel associated with the new handle to continue communicating with the contact.
For example, if a GUI client associates text channels with chat windows, it should detach the old channel from the chat window, closing it, and associate a channel to the new handle with the same window.
If the contact's old handle is in any of the member lists of a channel which has the groups interface, it will be removed from the channel and the new handle will be added. The resulting MembersChanged signal must be emitted after the Renamed signal; the reason should be RENAMED.
The handles may be either general-purpose or channel-specific. If the original handle is general-purpose, the new handle must be general-purpose; if the original handle is channel-specific, the new handle must be channel-specific in the same channel.
original -
u
(Contact_Handle)
new -
u
(Contact_Handle)
Interface has no properties.
All communication in the Telepathy framework is carried out via channel objects which are created and managed by connections. This interface must be implemented by all channel objects, along with one single channel type, such as Channel.Type.ContactList which represents a list of people (such as a buddy list) or a Channel.Type.Text which represents a channel over which textual messages are sent and received.
Each channel may have an immutable handle associated with it, which may be any handle type, such as a contact, room or list handle, indicating that the channel is for communicating with that handle. There can be at most one channel for each combination of (channel type, handle type, handle) with nonzero handle type.
If a channel does not have a handle (an "anonymous channel"), it means that the channel is defined by some other terms, such as it may be a transient group defined only by its members as visible through the Channel.Interface.Group interface. There can be any number of anonymous channels of the same channel type.
Other optional interfaces can be implemented to indicate other available functionality, such as Channel.Interface.Group if the channel contains a number of contacts, Channel.Interface.Password to indicate that a channel may have a password set to require entry, and Properties for extra data about channels which represent chat rooms or voice calls. The interfaces implemented may not vary after the channel's creation has been signalled to the bus (with the connection's NewChannel signal).
Specific connection manager implementations may implement channel types and interfaces which are not contained within this specification in order to support further functionality. To aid interoperability between client and connection manager implementations, the interfaces specified here should be used wherever applicable, and new interfaces made protocol-independent wherever possible. Because of the potential for 3rd party interfaces adding methods or signals with conflicting names, the D-Bus interface names should always be used to invoke methods and bind signals.
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotImplementedorg.freedesktop.Telepathy.Error.NotAvailables
(DBus_Interface)
u
(Handle_Type)
u
(Handle)
as
(DBus_Interface[])
Interface has no properties.
Implementations of this interface must also implement:
A channel type for representing a list of people on the server which is not used for communication. This is intended for use with the interface Channel.Interface.Group for managing buddy lists and privacy lists on the server. This channel type has no methods because all of the functionality it represents is available via the group interface.
There are currently two types of contact list: HANDLE_TYPE_LIST is a "magic" server-defined list, and HANDLE_TYPE_GROUP is a user-defined contact group.
For server-defined lists like the subscribe list, singleton instances of this channel type should be created by the connection manager at connection time if the list exists on the server, or may be requested by using the appropriate handle. These handles can be obtained using RequestHandle with a handle type of HANDLE_TYPE_LIST and one of the following identifiers:
These contact list channels may not be closed.
For user-defined contact groups, instances of this channel type should be created by the connection manager at connection time for each group that exists on the server. New, empty groups can be created by calling RequestHandle with a handle type of HANDLE_TYPE_GROUP and with the name set to the human-readable UTF-8 name of the group.
User-defined groups may be deleted by closing the channel, but only if the group is already empty. Closing a channel to a non-empty group is not allowed; its members must be set to the empty set first.
On some protocols (e.g. XMPP) empty groups are not represented on the server, so disconnecting from the server and reconnecting might cause empty groups to vanish.
Interface has no methods.
Interface has no signals.
Interface has no properties.
This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
A channel type for searching server-stored user directories. A new channel should be requested by a client for each search attempt, and it should be closed when the search is completed or the required result has been found in order to free unused handles. The search can be cancelled at any time by calling the channel Close method, although depending upon the protocol the connection manager may not be able to prevent the server from sending further results.
Before searching, the GetSearchKeys method should be used to discover any instructions sent by the server, and the valid search keys which can be provided to the Search method. A search request is then started by providing some of these terms to the Search method, and the search status will be set to CHANNEL_CONTACT_SEARCH_STATE_DURING. When results are returned by the server, the SearchResultReceived signal is emitted for each contact found, and when the search is complete, the search status will be set to CHANNEL_SEARCH_STATE_AFTER.
Returns any instructions from the server along with a dictionary of search key names to their types, and a boolean indicating if the key is mandatory. The following well-known search key names should be used where appropriate:
sa{s(bg)}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableu
(Channel_Contact_Search_State)
terms -
a{sv}org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentcontact -
u
(Contact_Handle)
values -
a{sv}state -
u
(Channel_Contact_Search_State)
Interface has no properties.
Channel_Contact_Search_State_Before = 0Channel_Contact_Search_State_During = 1Channel_Contact_Search_State_After = 2Implementations of this interface must also implement:
A channel that can send and receive streamed media such as audio or video. Provides a number of methods for listing and requesting new streams, and signals to indicate when streams have been added, removed and changed status.
Channels of this type are expected to provide the Group interface and be "anonymous" (have no associated handle). To make a media call to a contact, clients should request a new, empty streamed media channel, then call AddMembers to add the contact to the channel. The local user should be in the group's members, while the contact should be in "remote pending" until the call is accepted, then move to the group's members.
Similarly, incoming calls should be signalled as having handle type 0 and handle 0. The remote contact should be in the group's members, with the local user in the "local pending" members; to accept the call, AddMembers can be used to move the local user to the group's members.
In general this should be used in conjunction with the MediaSignalling interface to exchange connection candidates and codec choices with whichever component is responsible for the streams. However, in certain applications where no candidate exchange is necessary (eg the streams are handled by specialised hardware which is controlled directly by the connection manager), the signalling interface can be omitted and this channel type used simply to control the streams.
a(uuuuuu)
(Media_Stream_Info[])
streams -
auorg.freedesktop.Telepathy.Error.InvalidArgumentRequest 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 StreamRemoved 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 StreamDirectionChanged signal, and the signal emitted again without the flag to indicate the resulting direction when the remote end has accepted or rejected the change.
stream_id -
ustream_direction -
u
(Media_Stream_Direction)
org.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableRequest 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 StreamDirectionChanged 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.
contact_handle -
u
(Contact_Handle)
types -
aua(uuuuuu)
(Media_Stream_Info[])
org.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailablestream_id -
ucontact_handle -
u
(Contact_Handle)
stream_type -
u
(Media_Stream_Type)
stream_id -
ustream_direction -
u
(Media_Stream_Direction)
pending_flags -
u
(Media_Stream_Pending_Send)
stream_id -
uerrno -
umessage -
sstream_id -
ustream_id -
ustream_state -
u
(Media_Stream_State)
Interface has no properties.
Media_Stream_Type_Audio = 0Media_Stream_Type_Video = 1Media_Stream_State_Disconnected = 0Media_Stream_State_Connecting = 1Media_Stream_State_Connected = 2Media_Stream_Direction_None = 0Media_Stream_Direction_Send = 1Media_Stream_Direction_Receive = 2Media_Stream_Direction_Bidirectional = 3Media_Stream_Pending_Local_Send = 1Media_Stream_Pending_Remote_Send = 2Channel_Media_Capability_Audio = 1Channel_Media_Capability_Video = 2Channel_Media_Capability_NAT_Traversal_STUN = 4Channel_Media_Capability_NAT_Traversal_GTalk_P2P = 8In bindings that need a separate name, arrays of Media_Stream_Info should be called Media_Stream_Info_List.
Identifier -
uContact -
u
(Contact_Handle)
Type -
u
(Media_Stream_Type)
State -
u
(Media_Stream_State)
Direction -
u
(Media_Stream_Direction)
Pending_Send_Flags -
u
(Media_Stream_Pending_Send)
Implementations of this interface must also implement:
A channel type for listing named channels available on the server. Once the ListRooms method is called, it emits signals for rooms present on the server, until you Close this channel. In some cases, it may not be possible to stop the deluge of information from the server. This channel should be closed when the room information is no longer being displayed, so that the room handles can be freed.
This channel type may be implemented as a singleton on some protocols, so clients should be prepared for the eventuality that they are given a channel that is already in the middle of listing channels. The ListingRooms signal, or GetListingRooms method, can be used to check this.
borg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedEmitted when information about rooms on the server becomes available. The array contains the room handle (as can be passed to the RequestChannel method with HANDLE_TYPE_ROOM), the channel type, and a dictionary containing further information about the room as available. The following well-known keys and types are recommended for use where appropriate:
rooms -
a(usa{sv})
(Room_Info[])
listing -
bInterface has no properties.
In bindings that need a separate name, arrays of Room_Info should be called Room_Info_List.
Handle -
u
(Room_Handle)
Channel_Type -
s
(DBus_Interface)
Info -
a{sv}
(String_Variant_Map)
Implementations of this interface must also implement:
A channel type for sending and receiving messages in plain text, with no formatting.
When a message is received, an identifier is assigned and a Received signal emitted, and the message placed in a pending queue which can be inspected with ListPendingMessages. A client which has handled the message by showing it to the user (or equivalent) should acknowledge the receipt using the AcknowledgePendingMessage method, and the message will then be removed from the pending queue. Numeric identifiers for received messages may be reused over the lifetime of the channel.
Each message has an associated 'type' value, which should be one of the values allowed by ChannelTextMessageType.
Each message also has a flags value, which is a bitwise OR of the flags given in ChannelTextMessageFlags.
Sending messages can be requested using the Send method, which will return and cause the Sent signal to be emitted when the message has been delivered to the server, or SendError if there is a failure.
On protocols where additional contacts cannot be invited into a one-to-one chat, or where a one-to-one chat is just a series of individual personal messages rather than being represented by some object on the server (i.e. most protocols), one-to-one chats should be represented by a Text channel with handle type CONTACT.
Named chat rooms whose identity can be saved and used again later (IRC channels, Jabber MUCs) are expected to be represented by Text channels with handle type ROOM and the Group interface; they should usually also have the Properties interface.
Unnamed, transient chat rooms defined only by their members (e.g. on MSN) are expected to be represented by Text channels with handle type 0, handle 0, the Group interface, and optionally the Properties interface.
On protocols where a conversation with a user is actually just a nameless chat room starting with exactly two members, to which more members can be invited, calling RequestChannel with type Text and handle type CONTACT should continue to succeed, but may return a channel with handle type 0, handle 0, the group interface, and the local and remote contacts in its members.
ids -
auorg.freedesktop.Telepathy.Error.InvalidArgumentau
(Channel_Text_Message_Type[])
clear -
ba(uuuuus)
(Pending_Text_Message[])
type -
u
(Channel_Text_Message_Type)
text -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDeniedid -
utimestamp -
u
(Unix_Timestamp)
sender -
u
(Contact_Handle)
type -
u
(Channel_Text_Message_Type)
flags -
u
(Channel_Text_Message_Flags)
text -
serror -
utimestamp -
u
(Unix_Timestamp)
type -
u
(Channel_Text_Message_Type)
text -
stimestamp -
u
(Unix_Timestamp)
type -
u
(Channel_Text_Message_Type)
text -
sanonymous -
binvite-only -
blimit -
ulimited -
bmoderated -
bname -
sdescription -
spassword -
spassword-required -
bpersistent -
bprivate -
bsubject -
ssubject-contact -
usubject-timestamp -
uChannel_Text_Send_Error_Unknown = 0Channel_Text_Send_Error_Offline = 1Channel_Text_Send_Error_Invalid_Contact = 2Channel_Text_Send_Error_Permission_Denied = 3Channel_Text_Send_Error_Too_Long = 4Channel_Text_Send_Error_Not_Implemented = 5Channel_Text_Message_Type_Normal = 0Channel_Text_Message_Type_Action = 1Channel_Text_Message_Type_Notice = 2Channel_Text_Message_Type_Auto_Reply = 3Channel_Text_Message_Flag_Truncated = 1In bindings that need a separate name, arrays of Pending_Text_Message should be called Pending_Text_Message_List.
Message_ID -
uUnix_Timestamp -
uSender -
u
(Contact_Handle)
Message_Type -
u
(Channel_Text_Message_Type)
Flags -
u
(Channel_Text_Message_Flags)
Text -
sImplementations of this interface must also implement:
A "tube" is a mechanism for arbitrary data transfer. Two types of data transfer are currently specified: D-Bus messages, and streams of bytes. Each tube has a service name, which is a string specifying the kind of communication that takes place over it, and a dictionary of arbitrary parameters. Tube parameters are commonly used for bootstrap information such as usernames and passwords. Each tube is identified by a locally unique identifier.
The Tubes channel type may be requested for handles of type HANDLE_TYPE_CONTACT and HANDLE_TYPE_ROOM.
Stream tubes specify listening addresses using pairs of parameters with signature 'u', 'v', where the integer 'u' is a member of Socket_Address_Type and the v is dependent on the type of address.
a{uau}
(Supported_Socket_Map)
A mapping from address types (members of Socket_Address_Type) to arrays of access-control type (members of Socket_Access_Control) that the connection manager supports for stream tubes with that address type. For simplicity, if a CM supports offering a particular type of tube, it is assumed to support accepting it.
A typical value for a host without IPv6 support:
{
Socket_Address_Type_IPv4:
[Socket_Access_Control_Localhost, Socket_Access_Control_Port,
Socket_Access_Control_Netmask],
Socket_Address_Type_Unix:
[Socket_Access_Control_Localhost, Socket_Access_Control_Credentials]
}
If stream tubes are not supported, this will be an empty dictionary.
au
(Tube_Type[])
a(uuusa{sv}u)
(Tube_Info[])
service -
sparameters -
a{sv}
(String_Variant_Map)
uorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.NotImplementedservice -
sparameters -
a{sv}
(String_Variant_Map)
A dictionary of properties for the new tube; the allowable keys, types and values are defined by the service. Connection managers must support the value being any primitive (non-container) D-Bus type, or a byte array 'ay'.
These should usually be the same key-value pairs specified for use in the DNS-SD TXT record for that service.
address_type -
u
(Socket_Address_Type)
address -
vaccess_control -
u
(Socket_Access_Control)
access_control_param -
vuorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.NotImplementedid -
u
(Tube_ID)
address -
sorg.freedesktop.Telepathy.Error.InvalidArgumentid -
u
(Tube_ID)
address_type -
u
(Socket_Address_Type)
access_control -
u
(Socket_Access_Control)
access_control_param -
vaddress -
vorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotImplementedid -
u
(Tube_ID)
org.freedesktop.Telepathy.Error.InvalidArgumentid -
u
(Tube_ID)
sorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableid -
u
(Tube_ID)
a(us)
(DBus_Tube_Member[])
org.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableid -
u
(Tube_ID)
address_type -
u
(Socket_Address_Type)
address -
vorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableid -
u
(Tube_ID)
initiator -
u
(Contact_Handle)
type -
u
(Tube_Type)
service -
sparameters -
a{sv}
(String_Variant_Map)
state -
u
(Tube_State)
id -
u
(Tube_ID)
state -
u
(Tube_State)
id -
u
(Tube_ID)
id -
u
(Tube_ID)
added -
a(us)
(DBus_Tube_Member[])
removed -
au
(Contact_Handle[])
id -
u
(Tube_ID)
handle -
u
(Contact_Handle)
Interface has no properties.
Tube_Type_DBus = 0An ordered reliable transport, for transporting D-Bus traffic.
For each D-Bus tube, the connection manager listens on a D-Bus server address, as detailed in the D-Bus specification. On this address, it emulates a bus upon which each tube participant appears as an endpoint.
The objects and interfaces which are expected to exist on the emulated bus depend on the well-known name; typically, either the participant who initiated the tube is expected to export the same objects/interfaces that would be exported by a service of that name on a bus, or all participants are expected to export those objects/interfaces.
In a multi-user context (Handle_Type_Room) the tube behaves like the D-Bus bus daemon, so participants can send each other private messages, or can send broadcast messages which are received by everyone in the tube (including themselves). Each participant has a D-Bus unique name; connection managers must prevent participants from sending messages with the wrong sender unique name, and should attempt to avoid participants receiving messages not intended for them.
In a 1-1 context (Handle_Type_Contact) the tube behaves like a peer-to-peer D-Bus connection - arbitrary D-Bus messages with any sender and/or destination can be sent by each participant, and each participant receives all messages sent by the other participant.
Tube_Type_Stream = 1A transport for ordered, reliable data transfer, similar to SOCK_STREAM sockets.
When accepting a Stream Unix tube, a new listening local socket is created. Each time the client connects to this socket, the connection manager of the initiator of the tube opens a new connection to its local socket. Both sides can then use this pair of sockets to communicate together.
Tube_State_Local_Pending = 0Tube_State_Remote_Pending = 1Tube_State_Open = 2Socket_Address_Type_Unix = 0Socket_Address_Type_Abstract_Unix = 1Socket_Address_Type_IPv4 = 2Socket_Address_Type_IPv6 = 3Socket_Access_Control_Localhost = 0Socket_Access_Control_Port = 1Socket_Access_Control_Netmask = 2Socket_Access_Control_Credentials = 3The connecting process must send a single zero (NUL) byte when it first connects, which is not considered to be part of the data stream. If the operating system uses sendmsg() with SCM_CREDS or SCM_CREDENTIALS to pass credentials over sockets, the connecting process must do so if possible; if not, it must still send the byte.
The listening process will disconnect the connection unless it can determine by OS-specific means that the connecting process has the same user ID as the listening process.
The associated variant must be ignored.
In bindings that need a separate name, arrays of Tube_Info should be called Tube_Info_List.
Tube_ID -
uInitiator -
u
(Contact_Handle)
Type -
u
(Tube_Type)
Service -
sParameters -
a{sv}
(String_Variant_Map)
State -
u
(Tube_State)
In bindings that need a separate name, arrays of DBus_Tube_Member should be called DBus_Tube_Member_List.
Handle -
u
(Contact_Handle)
Unique_Name -
s
(DBus_Unique_Name)
Arrays of Socket_Address_IPv4 don't generally make sense.
Address -
sPort -
qArrays of Socket_Address_IPv6 don't generally make sense.
Address -
sPort -
qArrays of Socket_Netmask_IPv4 don't generally make sense.
Address -
sPrefix_Length -
yArrays of Socket_Netmask_IPv6 don't generally make sense.
Address -
sPrefix_Length -
yAddress_Type -
u
(Socket_Address_Type)
Access_Control -
au
(Socket_Access_Control[])
This interface is not yet API-stable and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Interface for streamed media channels that can be merged and split in the same sort of way as in GSM or PBX telephony.
Other -
oorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableContact -
u
(Contact_Handle)
Channel -
oorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableInterface has no signals.
Interface has no properties.
Implementations of this interface must also implement:
An interface for channels for receiving notifications of remote contacts' state, and for notifying remote contacts of the local state.
Clients should assume that a contact's state is Channel_Chat_State_Inactive unless they receive a notification otherwise.
The Channel_Chat_State_Gone state is treated differently to other states:
The different states are defined by XEP-0085, but may be applied to any suitable protocol.
state -
u
(Channel_Chat_State)
org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentcontact -
u
(Contact_Handle)
state -
u
(Channel_Chat_State)
Interface has no properties.
Channel_Chat_State_Gone = 0Channel_Chat_State_Inactive = 1Channel_Chat_State_Active = 2Channel_Chat_State_Paused = 3Channel_Chat_State_Composing = 4Implementations of this interface must also implement:
An interface that gives a Channel the ability to send DTMF events over audio streams which have been established using the StreamedMedia channel type. The event codes used are in common with those defined in RFC4733, and are listed in the DTMF_Event enumeration.stream_id -
uevent -
y
(DTMF_Event)
org.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailablestream_id -
uorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableInterface has no signals.
Interface has no properties.
DTMF_Event_Digit_0 = 0DTMF_Event_Digit_1 = 1DTMF_Event_Digit_2 = 2DTMF_Event_Digit_3 = 3DTMF_Event_Digit_4 = 4DTMF_Event_Digit_5 = 5DTMF_Event_Digit_6 = 6DTMF_Event_Digit_7 = 7DTMF_Event_Digit_8 = 8DTMF_Event_Digit_9 = 9DTMF_Event_Asterisk = 10DTMF_Event_Hash = 11DTMF_Event_Letter_A = 12DTMF_Event_Letter_B = 13DTMF_Event_Letter_C = 14DTMF_Event_Letter_D = 15Implementations of this interface must also implement:
Interface for channels which have multiple members, and where the members of the channel can change during its lifetime. Your presence in the channel cannot be presumed by the channel's existence (for example, a channel you may request membership of but your request may not be granted).
This interface implements three lists: a list of current members, and two lists of local pending and remote pending members. Contacts on the remote pending list have been invited to the channel, but the remote user has not accepted the invitation. Contacts on the local pending list have requested membership of the channel, but the local user of the framework must accept their request before they may join. A single contact should never appear on more than one of the three lists. The lists are empty when the channel is created, and the MembersChanged signal should be emitted when information is retrieved from the server, or changes occur.
Addition of members to the channel may be requested by using AddMembers. If remote acknowledgement is required, use of the AddMembers method will cause users to appear on the remote pending list. If no acknowledgement is required, AddMembers will add contacts to the member list directly. If a contact is awaiting authorisation on the local pending list, AddMembers will grant their membership request.
Removal of contacts from the channel may be requested by using RemoveMembers. If a contact is awaiting authorisation on the local pending list, RemoveMembers will refuse their membership request. If a contact is on the remote pending list but has not yet accepted the invitation, RemoveMembers will rescind the request if possible.
It should not be presumed that the requester of a channel implementing this interface is immediately granted membership, or indeed that they are a member at all, unless they appear in the list. They may, for instance, be placed into the remote pending list until a connection has been established or the request acknowledged remotely.
If the local user joins a Group channel whose members or other state cannot be discovered until the user joins (e.g. many chat room implementations), the connection manager should ensure that the channel is, as far as possible, in a consistent state before adding the local contact to the members set; until this happens, the local contact should be in the remote-pending set. For instance, if the connection manager queries the server to find out the initial members list for the channel, it should leave the local contact in the remote-pending set until it has finished receiving the initial members list.
If the protocol provides no reliable way to tell whether the complete initial members list has been received yet, the connection manager should make a best-effort attempt to wait for the full list (in the worst case, waiting for a suitable arbitrary timeout) rather than requiring user interfaces to do so on its behalf.
Invite all the given contacts into the channel, or accept requests for channel membership for contacts on the pending local list.
A message may be provided along with the request, which will be sent to the server if supported. See the CHANNEL_GROUP_FLAG_MESSAGE_ADD and CHANNEL_GROUP_FLAG_MESSAGE_ACCEPT flags to see in which cases this message should be provided.
Attempting to add contacts who are already members is allowed; connection managers must silently accept this, without error.
contacts -
au
(Contact_Handle[])
message -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.Channel.Fullorg.freedesktop.Telepathy.Error.Channel.InviteOnlyorg.freedesktop.Telepathy.Error.Channel.Bannedau
(Contact_Handle[])
au
(Contact_Handle[])
au
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErroru
(Channel_Group_Flags)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorhandles -
au
(Contact_Handle[])
au
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidArgumentau
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrora(uuus)
(Local_Pending_Info[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorau
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorau
(Contact_Handle[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErroru
(Contact_Handle)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorcontacts -
au
(Contact_Handle[])
message -
sorg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidHandlecontacts -
au
(Contact_Handle[])
message -
sreason -
u
(Channel_Group_Change_Reason)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.InvalidArgumentadded -
u
(Channel_Group_Flags)
removed -
u
(Channel_Group_Flags)
message -
sadded -
au
(Contact_Handle[])
removed -
au
(Contact_Handle[])
local_pending -
au
(Contact_Handle[])
remote_pending -
au
(Contact_Handle[])
actor -
u
(Contact_Handle)
reason -
u
(Channel_Group_Change_Reason)
Interface has no properties.
Channel_Group_Change_Reason_None = 0Channel_Group_Change_Reason_Offline = 1Channel_Group_Change_Reason_Kicked = 2Channel_Group_Change_Reason_Busy = 3Channel_Group_Change_Reason_Invited = 4Channel_Group_Change_Reason_Banned = 5Channel_Group_Change_Reason_Error = 6Channel_Group_Change_Reason_Invalid_Contact = 7Channel_Group_Change_Reason_No_Answer = 8Channel_Group_Change_Reason_Renamed = 9Channel_Group_Change_Reason_Permission_Denied = 10Channel_Group_Change_Reason_Separated = 11If members are removed with this reason code, the change is because the group has split into unconnected parts which can only communicate within themselves (e.g. netsplits on IRC use this reason code).
If members are added with this reason code, the change is because unconnected parts of the group have rejoined. If this channel carries messages (e.g. Text or Tubes channels) applications must assume that the contacts being added are likely to have missed some messages as a result of the separation, and that the contacts in the group are likely to have missed some messages from the contacts being added.
Note that from the added contacts' perspective, they have been in the group all along, and the contacts we indicate to be in the group (including the local user) have just rejoined the group with reason Separated. Application protocols in Tubes should be prepared to cope with this situation.
Channel_Group_Flag_Can_Add = 1Channel_Group_Flag_Can_Remove = 2Channel_Group_Flag_Can_Rescind = 4Channel_Group_Flag_Message_Add = 8Channel_Group_Flag_Message_Remove = 16Channel_Group_Flag_Message_Accept = 32Channel_Group_Flag_Message_Reject = 64Channel_Group_Flag_Message_Rescind = 128Channel_Group_Flag_Channel_Specific_Handles = 256The members of this group have handles which are specific to this channel, and are not valid as general-purpose handles on the connection. Depending on the channel, it may be possible to call GetHandleOwners to find the owners of these handles, which should be done if you wish to eg subscribe to the contact's presence.
Connection managers must ensure that any given handle is not simultaneously a general-purpose handle and a channel-specific handle.
Channel_Group_Flag_Only_One_Group = 512Channel_Group_Flag_Handle_Owners_Not_Available = 1024In bindings that need a separate name, arrays of Local_Pending_Info should be called Local_Pending_Info_List.
To_Be_Added -
u
(Contact_Handle)
Actor -
u
(Contact_Handle)
Reason -
u
(Channel_Group_Change_Reason)
Message -
sThis interface is not yet API-stable and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
Interface for channels where you or other members may put the channel on hold. This only makes sense for channels where you are streaming media to or from the members.
If you are placed on hold, this indicates that some or all members of the channel will no longer be receiving media streams from you. If the channel has the MediaSignalling interface, client applications should stop sending media to all members of the channel.
Depending on the protocol, it might not be possible to tell that you're on hold, in which case the connection manager should always indicate that you're not on hold unless it finds out otherwise.
If you place a channel on hold, this indicates that you do not wish to be sent media streams by any of its members and will be ignoring any media streams you continue to receive. It also requests that the connection manager free up any resources that are only needed for an actively used channel (e.g. in a GSM or PBX call, it will be necessary to place an active call on hold before you can start another call).
u
(Channel_Hold_State)
hold -
borg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.NotAvailablestate -
u
(Channel_Hold_State)
Interface has no properties.
Channel_Hold_State_None = 0Channel_Hold_State_Local = 1Channel_Hold_State_Remote = 2Channel_Hold_State_Both = 3Implementations of this interface must also implement:
Interface for channels that may have a password set that users need to provide before being able to join, or may be able to view or change once they have joined the channel.
The GetPasswordFlags method and the associated PasswordFlagsChanged signal indicate whether the channel has a password, whether the user must now provide it to join, and whether it can be viewed or changed by the user.
u
(Channel_Password_Flags)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrorpassword -
sborg.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.InvalidArgumentadded -
u
(Channel_Password_Flags)
removed -
u
(Channel_Password_Flags)
Interface has no properties.
Channel_Password_Flag_Provide = 8This interface is not well-tested and is likely to cause havoc to your API/ABI if bindings are generated. Don't include it in libraries that care about compatibility.
Implementations of this interface must also implement:
An interface for channels where you may request that one of the members connects to somewhere else instead.member -
u
(Contact_Handle)
destination -
u
(Contact_Handle)
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.NetworkErrororg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.InvalidHandleorg.freedesktop.Telepathy.Error.PermissionDeniedInterface has no signals.
Interface has no properties.
Implementations of this interface must also implement:
An interface for signalling a channel containing synchronised media sessions which can contain an arbitrary number of streams. The negotiation interface is based closely around the API of the Farsight library (http://farsight.sourceforge.net/). This in turn is based upon the IETF MMusic ICE drafts where connections are established by signalling potential connection candidates to the peer until a usable connection is found, and codecs are negotiated with an SDP-style offer and answer. However, the principles should be applicable to other media streaming methods and the API re-used without difficulty.a(os)session_handler -
otype -
snat-traversal -
sA string indicating the NAT traversal techniques employed by the streams within this channel. Can be protocol-specific values, but the following values should be used if appropriate:
stun-server -
sstun-port -
qgtalk-p2p-relay-token -
serrno -
umessage -
sstream_handler -
oid -
umedia_type -
u
(Media_Stream_Type)
direction -
u
(Media_Stream_Direction)
Interface has no properties.
codec_id -
uerrno -
u
(Media_Stream_Error)
message -
snative_candidate_id -
sremote_candidate_id -
scandidate_id -
stransports -
a(usuussduss)
(Media_Stream_Handler_Transport[])
codecs -
a(usuuua{ss})codecs -
a(usuuua{ss})state -
u
(Media_Stream_State)
codecs -
a(usuuua{ss})
(Media_Stream_Handler_Codec[])
candidate_id -
stransports -
a(usuussduss)
(Media_Stream_Handler_Transport[])
candidate_id -
snative_candidate_id -
sremote_candidate_id -
sremote_candidates -
a(sa(usuussduss))
(Media_Stream_Handler_Candidate[])
codecs -
a(usuuua{ss})
(Media_Stream_Handler_Codec[])
playing -
bsending -
bevent -
yInterface has no properties.
Media_Stream_Error_Unknown = 0Media_Stream_Error_EOS = 1Media_Stream_Base_Proto_UDP = 0Media_Stream_Base_Proto_TCP = 1Media_Stream_Transport_Type_Local = 0Media_Stream_Transport_Type_Derived = 1Media_Stream_Transport_Type_Relay = 2In bindings that need a separate name, arrays of Media_Stream_Handler_Candidate should be called Media_Stream_Handler_Candidate_List.
Name -
sTransports -
a(usuussduss)
(Media_Stream_Handler_Transport[])
In bindings that need a separate name, arrays of Media_Stream_Handler_Transport should be called Media_Stream_Handler_Transport_List.
Component_Number -
uIP_Address -
sPort -
uProtocol -
u
(Media_Stream_Base_Proto)
Subtype -
sProfile -
sPreference_Value -
dTransport_Type -
u
(Media_Stream_Transport_Type)
Username -
sPassword -
sIn bindings that need a separate name, arrays of Media_Stream_Handler_Codec should be called Media_Stream_Handler_Codec_List.
Codec_ID -
uName -
sMedia_Type -
u
(Media_Stream_Type)
Clock_Rate -
uNumber_Of_Channels -
uParameters -
a{ss}
(String_String_Map)
Interface for channels and other objects, to allow querying and setting properties. ListProperties returns which properties are valid for the given channel, including their type, and an integer handle used to refer to them in GetProperties, SetProperties, and the PropertiesChanged signal. The values are represented by D-Bus variant types, and are accompanied by flags indicating whether or not the property is readable or writable.
Each property also has a flags value to indicate what methods are available. This is a bitwise OR of PropertyFlags values.
properties -
aua(uv)
(Property_Value[])
An array of structs containing:
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.PermissionDenieda(ussu)
(Property_Spec[])
Takes an array of (identifier, value) pairs containing desired values to set the given properties. In the case of any errors, no properties will be changed. When the changes have been acknowledged by the server, the PropertiesChanged signal will be emitted.
All properties given must have the PROPERTY_FLAG_WRITE flag, or PermissionDenied will be returned. If any variants are of the wrong type, NotAvailable will be returned. If any given property identifiers are invalid, InvalidArgument will be returned.
properties -
a(uv)
(Property_Value[])
org.freedesktop.Telepathy.Error.Disconnectedorg.freedesktop.Telepathy.Error.InvalidArgumentorg.freedesktop.Telepathy.Error.NotAvailableorg.freedesktop.Telepathy.Error.PermissionDeniedorg.freedesktop.Telepathy.Error.NetworkErrorproperties -
a(uv)
(Property_Value[])
An array of structs containing:
The array should contain only properties whose values have actually changed.
properties -
a(uu)
(Property_Flags_Change[])
An array of structs containing:
The array should contain only properties whose flags have actually changed.
Interface has no properties.
Property_Flag_Read = 1Property_Flag_Write = 2In bindings that need a separate name, arrays of Property_Spec should be called Property_Spec_List.
Property_ID -
uname -
ssignature -
s
(DBus_Signature)
Flags -
u
(Property_Flags)
In bindings that need a separate name, arrays of Property_Flags_Change should be called Property_Flags_Change_List.
Property_ID -
uNew_Flags -
uIn bindings that need a separate name, arrays of Property_Value should be called Property_Value_List.
Property_ID -
uValue -
vAn interface exported by client applications which are able to handle incoming channels.
Bus_Name -
s
(DBus_Bus_Name)
Connection -
oChannel_Type -
s
(DBus_Interface)
Channel -
oHandle_Type -
u
(Handle_Type)
Handle -
u
(Handle)
Interface has no signals.
Interface has no properties.
Key -
sValue -
vKey -
sValue -
sorg.freedesktop.Telepathy.ConnectionManagerorg.freedesktop.Telepathy.Connectionorg.freedesktop.Telepathy.Connection.Interface.Aliasingorg.freedesktop.Telepathy.Connection.Interface.Avatarsorg.freedesktop.Telepathy.Connection.Interface.Capabilitiesorg.freedesktop.Telepathy.Connection.Interface.ContactInfoorg.freedesktop.Telepathy.Connection.Interface.Forwardingorg.freedesktop.Telepathy.Connection.Interface.Presenceorg.freedesktop.Telepathy.Connection.Interface.Privacyorg.freedesktop.Telepathy.Connection.Interface.Renamingorg.freedesktop.Telepathy.Channelorg.freedesktop.Telepathy.Channel.Type.ContactListorg.freedesktop.Telepathy.Channel.Type.ContactSearchorg.freedesktop.Telepathy.Channel.Type.StreamedMediaorg.freedesktop.Telepathy.Channel.Type.RoomListorg.freedesktop.Telepathy.Channel.Type.Textorg.freedesktop.Telepathy.Channel.Type.Tubesorg.freedesktop.Telepathy.Channel.Interface.CallMergingorg.freedesktop.Telepathy.Channel.Interface.ChatStateorg.freedesktop.Telepathy.Channel.Interface.DTMForg.freedesktop.Telepathy.Channel.Interface.Grouporg.freedesktop.Telepathy.Channel.Interface.Holdorg.freedesktop.Telepathy.Channel.Interface.Passwordorg.freedesktop.Telepathy.Channel.Interface.Transferorg.freedesktop.Telepathy.Channel.Interface.MediaSignallingorg.freedesktop.Telepathy.Media.SessionHandlerorg.freedesktop.Telepathy.Media.StreamHandlerorg.freedesktop.Telepathy.Propertiesorg.freedesktop.Telepathy.ChannelHandlerAlias_Map
- a{ u → s }
Alias_Pair
- ( u, s )
Avatar_Token_Map
- a{ u → s }
Capability_Change
- ( u, s, u, u, u, u )
Capability_Pair
- ( s, u )
Channel_Chat_State
- uChannel_Contact_Search_State
- uChannel_Group_Change_Reason
- uChannel_Group_Flags
- uChannel_Hold_State
- uChannel_Info
- ( o, s, u, u )
Channel_Media_Capabilities
- uChannel_Password_Flags
- uChannel_Text_Message_Flags
- uChannel_Text_Message_Type
- uChannel_Text_Send_Error
- uConn_Mgr_Param_Flags
- uConnection_Alias_Flags
- uConnection_Capability_Flags
- uConnection_Presence_Type
- uConnection_Status
- uConnection_Status_Reason
- uContact_Capability
- ( u, s, u, u )
Contact_Handle
- uContact_Presences
- a{ u → (ua{sa{sv}}) }
DBus_Bus_Name
- sDBus_Interface
- sDBus_Signature
- sDBus_Tube_Member
- ( u, s )
DBus_Unique_Name
- sDTMF_Event
- yGroup_Handle
- uHandle
- uHandle_Type
- uLast_Activity_And_Statuses
- ( u, a{sa{sv}} )
List_Handle
- uLocal_Pending_Info
- ( u, u, u, s )
Media_Stream_Base_Proto
- uMedia_Stream_Direction
- uMedia_Stream_Error
- uMedia_Stream_Handler_Candidate
- ( s, a(usuussduss) )
Media_Stream_Handler_Codec
- ( u, s, u, u, u, a{ss} )
Media_Stream_Handler_Transport
- ( u, s, u, u, s, s, d, u, s, s )
Media_Stream_Info
- ( u, u, u, u, u, u )
Media_Stream_Pending_Send
- uMedia_Stream_State
- uMedia_Stream_Transport_Type
- uMedia_Stream_Type
- uMultiple_Status_Map
- a{ s → a{sv} }
Param_Spec
- ( s, u, s, v )
Pending_Text_Message
- ( u, u, u, u, u, s )
Property_Flags
- uProperty_Flags_Change
- ( u, u )
Property_Spec
- ( u, s, s, u )
Property_Value
- ( u, v )
Protocol
- sRoom_Handle
- uRoom_Info
- ( u, s, a{sv} )
Socket_Access_Control
- uSocket_Address_IPv4
- ( s, q )
Socket_Address_IPv6
- ( s, q )
Socket_Address_Type
- uSocket_Netmask_IPv4
- ( s, y )
Socket_Netmask_IPv6
- ( s, y )
Status_Spec
- ( u, b, b, a{ss} )
Status_Spec_Map
- a{ s → (ubba{ss}) }
String_String_Map
- a{ s → s }
String_Variant_Map
- a{ s → v }
Supported_Socket_Map
- a{ u → au }
Tube_ID
- uTube_Info
- ( u, u, u, s, a{sv}, u )
Tube_State
- uTube_Type
- uUnix_Timestamp
- u