|
|
|
telepathy-glib API Reference Manual | |
|---|---|---|---|---|
| Top | Description | ||||
Telepathy protocol enumerationsTelepathy protocol enumerations — Enumerated types and bitfields from the Telepathy spec |
#include <telepathy-glib/telepathy-glib.h>
enum TpHandleType;
#define TP_NUM_HANDLE_TYPES
#define NUM_TP_HANDLE_TYPES
enum TpConnMgrParamFlags;
enum TpConnectionStatus;
#define TP_NUM_CONNECTION_STATUSES
#define NUM_TP_CONNECTION_STATUSES
enum TpConnectionStatusReason;
#define TP_NUM_CONNECTION_STATUS_REASONS
#define NUM_TP_CONNECTION_STATUS_REASONS
enum TpConnectionAliasFlags;
enum TpConnectionCapabilityFlags;
enum TpConnectionPresenceType;
#define TP_NUM_CONNECTION_PRESENCE_TYPES
#define NUM_TP_CONNECTION_PRESENCE_TYPES
enum TpDTMFEvent;
#define TP_NUM_DTMF_EVENTS
#define NUM_TP_DTMF_EVENTS
gchar tp_dtmf_event_to_char (TpDTMFEvent event);
enum TpMediaStreamType;
#define NUM_TP_MEDIA_STREAM_TYPES
#define TP_NUM_MEDIA_STREAM_TYPES
enum TpMediaStreamState;
#define NUM_TP_MEDIA_STREAM_STATES
#define TP_NUM_MEDIA_STREAM_STATES
enum TpMediaStreamDirection;
#define NUM_TP_MEDIA_STREAM_DIRECTIONS
#define TP_NUM_MEDIA_STREAM_DIRECTIONS
enum TpMediaStreamPendingSend;
enum TpChannelMediaCapabilities;
enum TpChannelTextSendError;
#define TP_NUM_CHANNEL_TEXT_SEND_ERRORS
#define NUM_TP_CHANNEL_TEXT_SEND_ERRORS
enum TpChannelTextMessageType;
#define NUM_TP_CHANNEL_TEXT_MESSAGE_TYPES
#define TP_NUM_CHANNEL_TEXT_MESSAGE_TYPES
enum TpChannelTextMessageFlags;
enum TpChannelChatState;
#define NUM_TP_CHANNEL_CHAT_STATES
#define TP_NUM_CHANNEL_CHAT_STATES
enum TpChannelGroupFlags;
enum TpChannelGroupChangeReason;
#define NUM_TP_CHANNEL_GROUP_CHANGE_REASONS
#define TP_NUM_CHANNEL_GROUP_CHANGE_REASONS
enum TpChannelPasswordFlags;
enum TpContactBlockingCapabilities;
enum TpDeliveryReportingSupportFlags;
enum TpDeliveryStatus;
#define NUM_TP_DELIVERY_STATUSES
#define TP_NUM_DELIVERY_STATUSES
enum TpMediaStreamError;
#define NUM_TP_MEDIA_STREAM_ERRORS
#define TP_NUM_MEDIA_STREAM_ERRORS
enum TpMediaStreamBaseProto;
#define NUM_TP_MEDIA_STREAM_BASE_PROTOS
#define TP_NUM_MEDIA_STREAM_BASE_PROTOS
enum TpMediaStreamTransportType;
#define NUM_TP_MEDIA_STREAM_TRANSPORT_TYPES
#define TP_NUM_MEDIA_STREAM_TRANSPORT_TYPES
enum TpPropertyFlags;
enum TpMessagePartSupportFlags;
enum TpMessageSendingFlags;
#define NUM_TP_SOCKET_ACCESS_CONTROLS
#define TP_NUM_SOCKET_ACCESS_CONTROLS
enum TpSocketAccessControl;
#define NUM_TP_SOCKET_ADDRESS_TYPES
#define TP_NUM_SOCKET_ADDRESS_TYPES
enum TpSocketAddressType;
#define NUM_TP_TUBE_STATES
#define TP_NUM_TUBE_STATES
enum TpTubeState;
#define NUM_TP_TUBE_TYPES
#define TP_NUM_TUBE_TYPES
enum TpTubeType;
enum TpChannelCallStateFlags;
#define NUM_TP_LOCAL_HOLD_STATES
#define TP_NUM_LOCAL_HOLD_STATES
enum TpLocalHoldState;
#define NUM_TP_LOCAL_HOLD_STATE_REASONS
#define TP_NUM_LOCAL_HOLD_STATE_REASONS
enum TpLocalHoldStateReason;
enum TpAccessControlType;
#define NUM_TP_ACCESS_CONTROL_TYPES
#define TP_NUM_ACCESS_CONTROL_TYPES
enum TpRichPresenceAccessControlType;
#define NUM_TP_RICH_PRESENCE_ACCESS_CONTROL_TYPES
#define TP_NUM_RICH_PRESENCE_ACCESS_CONTROL_TYPES
enum TpFileHashType;
#define NUM_TP_FILE_HASH_TYPES
#define TP_NUM_FILE_HASH_TYPES
enum TpFileTransferState;
#define NUM_TP_FILE_TRANSFER_STATES
#define TP_NUM_FILE_TRANSFER_STATES
enum TpFileTransferStateChangeReason;
#define NUM_TP_FILE_TRANSFER_STATE_CHANGE_REASONS
#define TP_NUM_FILE_TRANSFER_STATE_CHANGE_REASONS
enum TpTubeChannelState;
#define NUM_TP_TUBE_CHANNEL_STATES
#define TP_NUM_TUBE_CHANNEL_STATES
enum TpDebugLevel;
#define NUM_TP_DEBUG_LEVELS
#define TP_NUM_DEBUG_LEVELS
enum TpContactInfoFlags;
enum TpContactInfoFieldFlags;
enum TpLocationFeatures;
enum TpServicePointType;
#define NUM_TP_SERVICE_POINT_TYPES
#define TP_NUM_SERVICE_POINT_TYPES
enum TpAnonymityModeFlags;
enum TpStorageRestrictionFlags;
enum TpTLSCertificateRejectReason;
#define NUM_TP_TLS_CERTIFICATE_REJECT_REASONS
#define TP_NUM_TLS_CERTIFICATE_REJECT_REASONS
enum TpTLSCertificateState;
#define NUM_TP_TLS_CERTIFICATE_STATES
#define TP_NUM_TLS_CERTIFICATE_STATES
enum TpContactMetadataStorageType;
#define NUM_TP_CONTACT_METADATA_STORAGE_TYPES
#define TP_NUM_CONTACT_METADATA_STORAGE_TYPES
enum TpSubscriptionState;
#define NUM_TP_SUBSCRIPTION_STATES
#define TP_NUM_SUBSCRIPTION_STATES
enum TpContactListState;
#define NUM_TP_CONTACT_LIST_STATES
#define TP_NUM_CONTACT_LIST_STATES
enum TpHTTPMethod;
#define NUM_TP_HTTP_METHODS
#define TP_NUM_HTTP_METHODS
enum TpMailNotificationFlags;
enum TpSASLAbortReason;
#define NUM_TP_SASL_ABORT_REASONS
#define TP_NUM_SASL_ABORT_REASONS
enum TpSASLStatus;
#define NUM_TP_SASL_STATUSES
#define TP_NUM_SASL_STATUSES
enum TpCaptchaStatus;
#define NUM_TP_CAPTCHA_STATUSES
#define TP_NUM_CAPTCHA_STATUSES
enum TpCaptchaCancelReason;
#define NUM_TP_CAPTCHA_CANCEL_REASONS
#define TP_NUM_CAPTCHA_CANCEL_REASONS
enum TpCaptchaFlags;
enum TpCallContentDisposition;
#define NUM_TP_CALL_CONTENT_DISPOSITIONS
#define TP_NUM_CALL_CONTENT_DISPOSITIONS
enum TpCallContentPacketizationType;
#define NUM_TP_CALL_CONTENT_PACKETIZATION_TYPES
#define TP_NUM_CALL_CONTENT_PACKETIZATION_TYPES
enum TpCallState;
#define NUM_TP_CALL_STATES
#define TP_NUM_CALL_STATES
enum TpCallStateChangeReason;
#define NUM_TP_CALL_STATE_CHANGE_REASONS
#define TP_NUM_CALL_STATE_CHANGE_REASONS
enum TpCallStreamCandidateType;
#define NUM_TP_CALL_STREAM_CANDIDATE_TYPES
#define TP_NUM_CALL_STREAM_CANDIDATE_TYPES
enum TpRCPTXRRTTMode;
#define NUM_TP_RCPT_XR_RTT_MODES
#define TP_NUM_RCPT_XR_RTT_MODES
enum TpSendingState;
#define NUM_TP_SENDING_STATES
#define TP_NUM_SENDING_STATES
enum TpStreamComponent;
#define NUM_TP_STREAM_COMPONENTS
#define TP_NUM_STREAM_COMPONENTS
enum TpStreamEndpointState;
#define NUM_TP_STREAM_ENDPOINT_STATES
#define TP_NUM_STREAM_ENDPOINT_STATES
enum TpStreamFlowState;
#define NUM_TP_STREAM_FLOW_STATES
#define TP_NUM_STREAM_FLOW_STATES
enum TpStreamTransportType;
#define NUM_TP_STREAM_TRANSPORT_TYPES
#define TP_NUM_STREAM_TRANSPORT_TYPES
enum TpCallFlags;
enum TpCallMemberFlags;
enum TpRTCPXRStatisticsFlags;
This header exposes the constants from the Telepathy specification as C enums. It is automatically generated from the specification.
The names used in the specification (e.g. Connection_Status_Connected) are converted to upper-case and given a TP_ prefix, e.g. TP_CONNECTION_STATUS_CONNECTED.
Each enum also has a constant for the number of members, named like TP_NUM_CONNECTION_STATUSES. The pluralization is currently hard-coded in the conversion scripts, but should move into the specification in future.
Constants LAST_TP_CONNECTION_STATUS, etc. are also provided. These are deprecated and will be removed in a future release.
typedef enum {
TP_HANDLE_TYPE_NONE = 0,
TP_HANDLE_TYPE_CONTACT = 1,
TP_HANDLE_TYPE_ROOM = 2,
TP_HANDLE_TYPE_LIST = 3,
TP_HANDLE_TYPE_GROUP = 4,
} TpHandleType;
Bitfield/set of flags generated from the Telepathy specification.
| A "null" handle type used to indicate the absence of a handle. When a handle type and a handle appear as a pair, if the handle type is zero, the handle must also be zero. | |
| A contact | |
| A chat room | |
| A server-generated contact list (see Channel.Interface.Group) | |
| A user-defined contact list (see Channel.Interface.Group) |
#define TP_NUM_HANDLE_TYPES (4+1)
1 higher than the highest valid value of TpHandleType.
#define NUM_TP_HANDLE_TYPES TP_NUM_HANDLE_TYPES
1 higher than the highest valid value of TpHandleType. In new code, use TP_NUM_HANDLE_TYPES instead.
typedef enum {
TP_CONN_MGR_PARAM_FLAG_REQUIRED = 1,
TP_CONN_MGR_PARAM_FLAG_REGISTER = 2,
TP_CONN_MGR_PARAM_FLAG_HAS_DEFAULT = 4,
TP_CONN_MGR_PARAM_FLAG_SECRET = 8,
TP_CONN_MGR_PARAM_FLAG_DBUS_PROPERTY = 16,
} TpConnMgrParamFlags;
Bitfield/set of flags generated from the Telepathy specification.
| This parameter is required for connecting to the server. | |
| This parameter is required for registering an account on the server. | |
| This parameter has a default value, which is returned in GetParameters; not providing this parameter is equivalent to providing the default. | |
| This parameter should be considered private or secret; for instance, clients should store it in a "password safe" like gnome-keyring or kwallet, omit it from debug logs, and use a text input widget that hides the value of the parameter. (Clients that support older connection managers may also treat any parameter whose name contains "password" as though it had this flag.) | |
| This parameter is also a D-Bus property on the resulting Connection; a parameter named com.example.Duck.Macaroni with this flag corresponds to the Macaroni property on the com.example.Duck interface. Its value can be queried and possibly changed on an existing Connection using methods on the org.freedesktop.DBus.Properties interface. When a new value for a parameter with this flag is passed to Account.UpdateParameters, the account manager will attempt to update its value on any running connections. Similarly, if the parameter also has the Has_Default flag, and is passed in the second argument to UpdateParameters, the default value will be applied to any running connections. Thus, clients generally do not need to directly access or update the connection property; instead, they SHOULD manipulate Account.Parameters. This allows runtime-configurable options to be stored and maintained by the AccountManager, without needing to invent a separate account preference for “properties that should be set on the connection as soon as it is created”. It was originally invented to manage Cellular preferences. |
typedef enum {
TP_CONNECTION_STATUS_CONNECTED = 0,
TP_CONNECTION_STATUS_CONNECTING = 1,
TP_CONNECTION_STATUS_DISCONNECTED = 2,
} TpConnectionStatus;
Bitfield/set of flags generated from the Telepathy specification.
| The connection is fully connected and all methods are available. | |
| Connect has been called but the connection has not yet been established. Some methods may fail until the connection has been established. | |
| If this is retrieved from GetStatus or Status, it indicates that connection has not yet been attempted. If seen in a StatusChanged signal, it indicates that the connection has failed; the Connection object SHOULD be removed from D-Bus immediately, and all subsequent method calls SHOULD fail. |
#define TP_NUM_CONNECTION_STATUSES (2+1)
1 higher than the highest valid value of TpConnectionStatus.
#define NUM_TP_CONNECTION_STATUSES TP_NUM_CONNECTION_STATUSES
1 higher than the highest valid value of TpConnectionStatus. In new code, use TP_NUM_CONNECTION_STATUSES instead.
typedef enum {
TP_CONNECTION_STATUS_REASON_NONE_SPECIFIED = 0,
TP_CONNECTION_STATUS_REASON_REQUESTED = 1,
TP_CONNECTION_STATUS_REASON_NETWORK_ERROR = 2,
TP_CONNECTION_STATUS_REASON_AUTHENTICATION_FAILED = 3,
TP_CONNECTION_STATUS_REASON_ENCRYPTION_ERROR = 4,
TP_CONNECTION_STATUS_REASON_NAME_IN_USE = 5,
TP_CONNECTION_STATUS_REASON_CERT_NOT_PROVIDED = 6,
TP_CONNECTION_STATUS_REASON_CERT_UNTRUSTED = 7,
TP_CONNECTION_STATUS_REASON_CERT_EXPIRED = 8,
TP_CONNECTION_STATUS_REASON_CERT_NOT_ACTIVATED = 9,
TP_CONNECTION_STATUS_REASON_CERT_HOSTNAME_MISMATCH = 10,
TP_CONNECTION_STATUS_REASON_CERT_FINGERPRINT_MISMATCH = 11,
TP_CONNECTION_STATUS_REASON_CERT_SELF_SIGNED = 12,
TP_CONNECTION_STATUS_REASON_CERT_OTHER_ERROR = 13,
TP_CONNECTION_STATUS_REASON_CERT_REVOKED = 14,
TP_CONNECTION_STATUS_REASON_CERT_INSECURE = 15,
TP_CONNECTION_STATUS_REASON_CERT_LIMIT_EXCEEDED = 16,
} TpConnectionStatusReason;
A reason why the status of the connection changed. Apart from Requested, the values of this enumeration only make sense as reasons why the status changed to Disconnected.
Bitfield/set of flags generated from the Telepathy specification.
| There is no reason set for this state change. Unknown status reasons SHOULD be treated like this reason. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Disconnected. | |
| The change is in response to a user request. Changes to the Connecting or Connected status SHOULD always indicate this reason; changes to the Disconnected status SHOULD indicate this reason if and only if the disconnection was requested by the user. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cancelled. | |
| There was an error sending or receiving on the network socket. When the status changes from Connecting to Disconnected for this reason, the equivalent D-Bus error is either org.freedesktop.Telepathy.Error.NetworkError, org.freedesktop.Telepathy.Error.ConnectionRefused, org.freedesktop.Telepathy.Error.ConnectionFailed or some more specific error. When the status changes from Connected to Disconnected for this reason, the equivalent D-Bus error is either org.freedesktop.Telepathy.Error.NetworkError, org.freedesktop.Telepathy.Error.ConnectionLost or some more specific error. | |
| The username or password was invalid. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.AuthenticationFailed. | |
| There was an error negotiating SSL on this connection, or encryption was unavailable and require-encryption was set when the connection was created. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.EncryptionNotAvailable if encryption was not available at all, or org.freedesktop.Telepathy.Error.EncryptionError if encryption failed. | |
| In general, this reason indicates that the requested account name or other identification could not be used due to conflict with another connection. It can be divided into three cases: If the status change is from Connecting to Disconnected and the 'register' parameter to RequestConnection was present and true, the requested account could not be created on the server because it already exists. The equivalent D-Bus error is org.freedesktop.Telepathy.Error.RegistrationExists. If the status change is from Connecting to Disconnected but the 'register' parameter is absent or false, the connection manager could not connect to the specified account because a connection to that account already exists. The equivalent D-Bus error is org.freedesktop.Telepathy.Error.AlreadyConnected. In some protocols, like XMPP (when connecting with the same JID and resource as an existing connection), the existing connection "wins" and the new one fails to connect. If the status change is from Connected to Disconnected, the existing connection was automatically disconnected because a new connection to the same account (perhaps from a different client or location) was established. The equivalent D-Bus error is org.freedesktop.Telepathy.Error.ConnectionReplaced. In some protocols, like MSNP (when connecting twice with the same Passport), the new connection "wins" and the existing one is automatically disconnected. | |
| The server did not provide a SSL certificate. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.NotProvided. | |
| The server's SSL certificate is signed by an untrusted certifying authority. This error SHOULD NOT be used to represent a self-signed certificate: use the more specific Cert_Self_Signed reason for that. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.Untrusted. | |
| The server's SSL certificate has expired. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.Expired. | |
| The server's SSL certificate is not yet valid. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.NotActivated. | |
| The server's SSL certificate did not match its hostname. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.HostnameMismatch. | |
| The server's SSL certificate does not have the expected fingerprint. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.FingerprintMismatch. | |
| The server's SSL certificate is self-signed. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.SelfSigned. | |
| There was some other error validating the server's SSL certificate. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.Invalid. | |
| The server's SSL certificate has been revoked. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.Revoked. | |
| The server's SSL certificate uses an insecure algorithm, or is cryptographically weak. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.Insecure. | |
| The length in bytes of the server certificate, or the depth of the sever certificate chain exceed the limits imposed by the crypto library. When disconnected for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cert.LimitExceeded |
#define TP_NUM_CONNECTION_STATUS_REASONS (16+1)
1 higher than the highest valid value of TpConnectionStatusReason.
#define NUM_TP_CONNECTION_STATUS_REASONS TP_NUM_CONNECTION_STATUS_REASONS
1 higher than the highest valid value of TpConnectionStatusReason. In new code, use TP_NUM_CONNECTION_STATUS_REASONS instead.
typedef enum {
TP_CONNECTION_ALIAS_FLAG_USER_SET = 1,
} TpConnectionAliasFlags;
Bitfield/set of flags generated from the Telepathy specification.
| The 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. |
typedef enum {
TP_CONNECTION_CAPABILITY_FLAG_CREATE = 1,
TP_CONNECTION_CAPABILITY_FLAG_INVITE = 2,
} TpConnectionCapabilityFlags;
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_CONNECTION_PRESENCE_TYPE_UNSET = 0,
TP_CONNECTION_PRESENCE_TYPE_OFFLINE = 1,
TP_CONNECTION_PRESENCE_TYPE_AVAILABLE = 2,
TP_CONNECTION_PRESENCE_TYPE_AWAY = 3,
TP_CONNECTION_PRESENCE_TYPE_EXTENDED_AWAY = 4,
TP_CONNECTION_PRESENCE_TYPE_HIDDEN = 5,
TP_CONNECTION_PRESENCE_TYPE_BUSY = 6,
TP_CONNECTION_PRESENCE_TYPE_UNKNOWN = 7,
TP_CONNECTION_PRESENCE_TYPE_ERROR = 8,
} TpConnectionPresenceType;
Bitfield/set of flags generated from the Telepathy specification.
| An invalid presence type used as a null value. This value MUST NOT appear in the Statuses property, or in the result of GetStatuses on the deprecated Presence interface. | |
| Offline | |
| Available | |
| Away | |
| Away for an extended time | |
| Hidden (invisible) | |
| Busy, Do Not Disturb. | |
| Unknown, unable to determine presence for this contact, for example if the protocol only allows presence of subscribed contacts. | |
| Error, an error occurred while trying to determine presence. The message, if set, is an error from the server. |
#define TP_NUM_CONNECTION_PRESENCE_TYPES (8+1)
1 higher than the highest valid value of TpConnectionPresenceType.
#define NUM_TP_CONNECTION_PRESENCE_TYPES TP_NUM_CONNECTION_PRESENCE_TYPES
1 higher than the highest valid value of TpConnectionPresenceType. In new code, use TP_NUM_CONNECTION_PRESENCE_TYPES instead.
typedef enum {
TP_DTMF_EVENT_DIGIT_0 = 0,
TP_DTMF_EVENT_DIGIT_1 = 1,
TP_DTMF_EVENT_DIGIT_2 = 2,
TP_DTMF_EVENT_DIGIT_3 = 3,
TP_DTMF_EVENT_DIGIT_4 = 4,
TP_DTMF_EVENT_DIGIT_5 = 5,
TP_DTMF_EVENT_DIGIT_6 = 6,
TP_DTMF_EVENT_DIGIT_7 = 7,
TP_DTMF_EVENT_DIGIT_8 = 8,
TP_DTMF_EVENT_DIGIT_9 = 9,
TP_DTMF_EVENT_ASTERISK = 10,
TP_DTMF_EVENT_HASH = 11,
TP_DTMF_EVENT_LETTER_A = 12,
TP_DTMF_EVENT_LETTER_B = 13,
TP_DTMF_EVENT_LETTER_C = 14,
TP_DTMF_EVENT_LETTER_D = 15,
} TpDTMFEvent;
Bitfield/set of flags generated from the Telepathy specification.
| 0 | |
| 1 | |
| 2 | |
| 3 | |
| 4 | |
| 5 | |
| 6 | |
| 7 | |
| 8 | |
| 9 | |
| * | |
| # | |
| A | |
| B | |
| C | |
| D |
#define TP_NUM_DTMF_EVENTS (15+1)
1 higher than the highest valid value of TpDTMFEvent.
#define NUM_TP_DTMF_EVENTS TP_NUM_DTMF_EVENTS
1 higher than the highest valid value of TpDTMFEvent. In new code, use TP_NUM_DTMF_EVENTS instead.
gchar tp_dtmf_event_to_char (TpDTMFEvent event);
Return a printable ASCII character representing event, or '?' if event
was not understood.
|
a TpDTMFEvent |
Returns : |
a printable ASCII character |
Since 0.13.3
typedef enum {
TP_MEDIA_STREAM_TYPE_AUDIO = 0,
TP_MEDIA_STREAM_TYPE_VIDEO = 1,
} TpMediaStreamType;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_MEDIA_STREAM_TYPES TP_NUM_MEDIA_STREAM_TYPES
1 higher than the highest valid value of TpMediaStreamType. In new code, use TP_NUM_MEDIA_STREAM_TYPES instead.
#define TP_NUM_MEDIA_STREAM_TYPES (1+1)
1 higher than the highest valid value of TpMediaStreamType.
typedef enum {
TP_MEDIA_STREAM_STATE_DISCONNECTED = 0,
TP_MEDIA_STREAM_STATE_CONNECTING = 1,
TP_MEDIA_STREAM_STATE_CONNECTED = 2,
} TpMediaStreamState;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_MEDIA_STREAM_STATES TP_NUM_MEDIA_STREAM_STATES
1 higher than the highest valid value of TpMediaStreamState. In new code, use TP_NUM_MEDIA_STREAM_STATES instead.
#define TP_NUM_MEDIA_STREAM_STATES (2+1)
1 higher than the highest valid value of TpMediaStreamState.
typedef enum {
TP_MEDIA_STREAM_DIRECTION_NONE = 0,
TP_MEDIA_STREAM_DIRECTION_SEND = 1,
TP_MEDIA_STREAM_DIRECTION_RECEIVE = 2,
TP_MEDIA_STREAM_DIRECTION_BIDIRECTIONAL = 3,
} TpMediaStreamDirection;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_MEDIA_STREAM_DIRECTIONS TP_NUM_MEDIA_STREAM_DIRECTIONS
1 higher than the highest valid value of TpMediaStreamDirection. In new code, use TP_NUM_MEDIA_STREAM_DIRECTIONS instead.
#define TP_NUM_MEDIA_STREAM_DIRECTIONS (3+1)
1 higher than the highest valid value of TpMediaStreamDirection.
typedef enum {
TP_MEDIA_STREAM_PENDING_LOCAL_SEND = 1,
TP_MEDIA_STREAM_PENDING_REMOTE_SEND = 2,
} TpMediaStreamPendingSend;
Bitfield/set of flags generated from the Telepathy specification.
| The local user has been asked to send media by the remote user. Call RequestStreamDirection to indicate whether or not this is acceptable. | |
| The remote user has been asked to send media by the local user. The StreamDirectionChanged signal will be emitted when the remote user accepts or rejects this change. |
typedef enum {
TP_CHANNEL_MEDIA_CAPABILITY_AUDIO = 1,
TP_CHANNEL_MEDIA_CAPABILITY_VIDEO = 2,
TP_CHANNEL_MEDIA_CAPABILITY_NAT_TRAVERSAL_STUN = 4,
TP_CHANNEL_MEDIA_CAPABILITY_NAT_TRAVERSAL_GTALK_P2P = 8,
TP_CHANNEL_MEDIA_CAPABILITY_NAT_TRAVERSAL_ICE_UDP = 16,
TP_CHANNEL_MEDIA_CAPABILITY_IMMUTABLE_STREAMS = 32,
} TpChannelMediaCapabilities;
The channel-type-specific capability flags used for Channel.Type.StreamedMedia in the Connection.Interface.Capabilities interface. See the InitialAudio property for details of the mechanisms that will replace this.
Bitfield/set of flags generated from the Telepathy specification.
| The handle is capable of using audio streams within a media channel. | |
| The handle is capable of using video streams within a media channel. | |
| The handle is capable of performing STUN to traverse NATs. | |
| The handle is capable of establishing Google Talk peer-to-peer connections (as implemented in libjingle 0.3) to traverse NATs. | |
| The handle is capable of establishing ICE UDP peer-to-peer connections (as defined by the IETF MMUSIC working group) to traverse NATs. | |
| Channels whose target handle is this contact will have ImmutableStreams = True. |
typedef enum {
TP_CHANNEL_TEXT_SEND_ERROR_UNKNOWN = 0,
TP_CHANNEL_TEXT_SEND_ERROR_OFFLINE = 1,
TP_CHANNEL_TEXT_SEND_ERROR_INVALID_CONTACT = 2,
TP_CHANNEL_TEXT_SEND_ERROR_PERMISSION_DENIED = 3,
TP_CHANNEL_TEXT_SEND_ERROR_TOO_LONG = 4,
TP_CHANNEL_TEXT_SEND_ERROR_NOT_IMPLEMENTED = 5,
} TpChannelTextSendError;
Bitfield/set of flags generated from the Telepathy specification.
| An unknown error occurred | |
| The requested contact was offline | |
| The requested contact is not valid | |
| The user does not have permission to speak on this channel | |
| The outgoing message was too long and was rejected by the server | |
| The channel doesn't support sending text messages to the requested contact |
#define TP_NUM_CHANNEL_TEXT_SEND_ERRORS (5+1)
1 higher than the highest valid value of TpChannelTextSendError.
#define NUM_TP_CHANNEL_TEXT_SEND_ERRORS TP_NUM_CHANNEL_TEXT_SEND_ERRORS
1 higher than the highest valid value of TpChannelTextSendError. In new code, use TP_NUM_CHANNEL_TEXT_SEND_ERRORS instead.
typedef enum {
TP_CHANNEL_TEXT_MESSAGE_TYPE_NORMAL = 0,
TP_CHANNEL_TEXT_MESSAGE_TYPE_ACTION = 1,
TP_CHANNEL_TEXT_MESSAGE_TYPE_NOTICE = 2,
TP_CHANNEL_TEXT_MESSAGE_TYPE_AUTO_REPLY = 3,
TP_CHANNEL_TEXT_MESSAGE_TYPE_DELIVERY_REPORT = 4,
} TpChannelTextMessageType;
The type of message.
Bitfield/set of flags generated from the Telepathy specification.
| An ordinary chat message. Unknown types SHOULD be treated like this. | |
| An action which might be presented to the user as "* <sender> <action>", such as an IRC CTCP ACTION (typically selected by the "/me" command). For example, the text of the message might be "drinks more coffee". | |
| A one-off or automated message not necessarily expecting a reply | |
| An automatically-generated reply message. | |
| A delivery report. This message type MUST NOT appear unless the channel supports the Messages interface; see Message_Part for the format that delivery reports must take. |
#define NUM_TP_CHANNEL_TEXT_MESSAGE_TYPES TP_NUM_CHANNEL_TEXT_MESSAGE_TYPES
1 higher than the highest valid value of TpChannelTextMessageType. In new code, use TP_NUM_CHANNEL_TEXT_MESSAGE_TYPES instead.
#define TP_NUM_CHANNEL_TEXT_MESSAGE_TYPES (4+1)
1 higher than the highest valid value of TpChannelTextMessageType.
typedef enum {
TP_CHANNEL_TEXT_MESSAGE_FLAG_TRUNCATED = 1,
TP_CHANNEL_TEXT_MESSAGE_FLAG_NON_TEXT_CONTENT = 2,
TP_CHANNEL_TEXT_MESSAGE_FLAG_SCROLLBACK = 4,
TP_CHANNEL_TEXT_MESSAGE_FLAG_RESCUED = 8,
} TpChannelTextMessageFlags;
Bitfield/set of flags generated from the Telepathy specification.
| The incoming message was truncated to a shorter length by the server or the connection manager. | |
| The incoming message contained non-text content which cannot be represented by this interface, but has been signalled in the Messages interface. Connection managers SHOULD only set this flag if the non-text content appears to be relatively significant (exactly how significant is up to the implementor). The intention is that if this flag is set, clients using this interface SHOULD inform the user that part of the message was not understood. | |
| The incoming message was part of a replay of message history. In XMPP multi-user chat, a few past messages are replayed when you join a chatroom. A sufficiently capable IRC connection manager could also set this flag on historical messages when connected to a proxy like bip or irssi-proxy. The existence of this flag allows loggers and UIs to use better heuristics when eliminating duplicates (a simple implementation made possible by this flag would be to avoid logging scrollback at all). | |
| The incoming message has been seen in a previous channel during the lifetime of the Connection, but had not been acknowledged when that channel closed, causing an identical channel (the channel in which the message now appears) to open. This means that a logger (which should already have seen the message in the previous channel) is able to recognise and ignore these replayed messages. |
typedef enum {
TP_CHANNEL_CHAT_STATE_GONE = 0,
TP_CHANNEL_CHAT_STATE_INACTIVE = 1,
TP_CHANNEL_CHAT_STATE_ACTIVE = 2,
TP_CHANNEL_CHAT_STATE_PAUSED = 3,
TP_CHANNEL_CHAT_STATE_COMPOSING = 4,
} TpChannelChatState;
Bitfield/set of flags generated from the Telepathy specification.
| The contact has effectively ceased participating in the chat. | |
| The contact has not been active for some time. | |
| The contact is actively participating in the chat. | |
| The contact has paused composing a message. | |
| The contact is composing a message to be sent to the chat. |
#define NUM_TP_CHANNEL_CHAT_STATES TP_NUM_CHANNEL_CHAT_STATES
1 higher than the highest valid value of TpChannelChatState. In new code, use TP_NUM_CHANNEL_CHAT_STATES instead.
#define TP_NUM_CHANNEL_CHAT_STATES (4+1)
1 higher than the highest valid value of TpChannelChatState.
typedef enum {
TP_CHANNEL_GROUP_FLAG_CAN_ADD = 1,
TP_CHANNEL_GROUP_FLAG_CAN_REMOVE = 2,
TP_CHANNEL_GROUP_FLAG_CAN_RESCIND = 4,
TP_CHANNEL_GROUP_FLAG_MESSAGE_ADD = 8,
TP_CHANNEL_GROUP_FLAG_MESSAGE_REMOVE = 16,
TP_CHANNEL_GROUP_FLAG_MESSAGE_ACCEPT = 32,
TP_CHANNEL_GROUP_FLAG_MESSAGE_REJECT = 64,
TP_CHANNEL_GROUP_FLAG_MESSAGE_RESCIND = 128,
TP_CHANNEL_GROUP_FLAG_CHANNEL_SPECIFIC_HANDLES = 256,
TP_CHANNEL_GROUP_FLAG_ONLY_ONE_GROUP = 512,
TP_CHANNEL_GROUP_FLAG_HANDLE_OWNERS_NOT_AVAILABLE = 1024,
TP_CHANNEL_GROUP_FLAG_PROPERTIES = 2048,
TP_CHANNEL_GROUP_FLAG_MEMBERS_CHANGED_DETAILED = 4096,
TP_CHANNEL_GROUP_FLAG_MESSAGE_DEPART = 8192,
} TpChannelGroupFlags;
Bitfield/set of flags generated from the Telepathy specification.
| The AddMembers method can be used to add or invite members who are not already in the local pending list (which is always valid). | |
| The RemoveMembers method can be used to remove channel members (removing those on the pending local list is always valid). | |
| The RemoveMembers method can be used on people on the remote pending list. | |
| A message may be sent to the server when calling AddMembers on contacts who are not currently pending members. | |
| A message may be sent to the server when calling RemoveMembers on contacts who are currently channel members. | |
| A message may be sent to the server when calling AddMembers on contacts who are locally pending. | |
| A message may be sent to the server when calling RemoveMembers on contacts who are locally pending. | |
| A message may be sent to the server when calling RemoveMembers on contacts who are remote pending. | |
| The 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 check the HandleOwners property or call GetHandleOwners to find the owners of these handles, which should be done if you wish to (e.g.) 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. | |
| Placing a contact in multiple groups of this type is not allowed and will raise NotAvailable (on services where contacts may only be in one user-defined group, user-defined groups will have this flag). | |
| In rooms with channel specific handles (ie Channel_Specific_Handles flag is set), this flag indicates that no handle owners are available, apart from the owner of the SelfHandle. This used to be an important optimization to avoid repeated GetHandleOwners calls, before we introduced the HandleOwners property and HandleOwnersChanged signal. | |
| This flag indicates that all the properties introduced in specification 0.17.6 are fully supported. | |
| Indicates that MembersChangedDetailed will be emitted for changes to this group's members in addition to MembersChanged. Clients can then connect to the former and ignore emission of the latter. This flag's state MUST NOT change over the lifetime of a channel. If it were allowed to change, client bindings would have to always connect to MembersChanged just in case the flag ever went away (and generally be unnecessarily complicated), which would mostly negate the point of having this flag in the first place. | |
| A message may be sent to the server when calling RemoveMembers on the SelfHandle. This would be set for XMPP Multi-User Chat or IRC channels, but not for a typical implementation of streamed media calls. |
typedef enum {
TP_CHANNEL_GROUP_CHANGE_REASON_NONE = 0,
TP_CHANNEL_GROUP_CHANGE_REASON_OFFLINE = 1,
TP_CHANNEL_GROUP_CHANGE_REASON_KICKED = 2,
TP_CHANNEL_GROUP_CHANGE_REASON_BUSY = 3,
TP_CHANNEL_GROUP_CHANGE_REASON_INVITED = 4,
TP_CHANNEL_GROUP_CHANGE_REASON_BANNED = 5,
TP_CHANNEL_GROUP_CHANGE_REASON_ERROR = 6,
TP_CHANNEL_GROUP_CHANGE_REASON_INVALID_CONTACT = 7,
TP_CHANNEL_GROUP_CHANGE_REASON_NO_ANSWER = 8,
TP_CHANNEL_GROUP_CHANGE_REASON_RENAMED = 9,
TP_CHANNEL_GROUP_CHANGE_REASON_PERMISSION_DENIED = 10,
TP_CHANNEL_GROUP_CHANGE_REASON_SEPARATED = 11,
} TpChannelGroupChangeReason;
The reason for a set of handles to move to one of Members, LocalPendingMembers or RemotePendingMembers, or to be removed from the group. A client may supply a reason when attempting to remove members from a group with RemoveMembersWithReason, and reasons are supplied by the CM when emitting MembersChanged and MembersChangedDetailed. Some reason codes have different meanings depending on the Actor in a MembersChanged signal.
Bitfield/set of flags generated from the Telepathy specification.
| No reason was provided for this change. In particular, this reason SHOULD be used when representing users joining a named chatroom in the usual way, users leaving a chatroom by their own request, and normal termination of a StreamedMedia call by the remote user. If the SelfHandle is removed from a group for this reason and the actor is not the SelfHandle, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Terminated. If the SelfHandle is removed from a group for this reason and the actor is also the SelfHandle, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Cancelled. | |
| The change is due to a user going offline. Also used when user is already offline, but this wasn't known previously. If a one-to-one StreamedMedia call fails because the contact being called is offline, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason Offline. For 1-1 calls, the call terminates as a result of removing the remote contact, so the SelfHandle should be removed at the same time as the remote contact and for the same reason. If a handle is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Offline. | |
| The change is due to a kick operation. If the SelfHandle is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Channel.Kicked. | |
| The change is due to a busy indication. If a one-to-one StreamedMedia call fails because the contact being called is busy, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason Busy. For 1-1 calls, the call terminates as a result of removing the remote contact, so the SelfHandle should be removed at the same time as the remote contact and for the same reason. If the SelfHandle is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Busy. | |
| The change is due to an invitation. This reason SHOULD only be used when contacts are added to the remote-pending set (to indicate that the contact has been invited) or to the members (to indicate that the contact has accepted the invitation). Otherwise, what would it mean? | |
| The change is due to a kick+ban operation. If the SelfHandle is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.Channel.Banned. | |
| The change is due to an error occurring. | |
| The change is because the requested contact does not exist. For instance, if the user invites a nonexistent contact to a chatroom or attempts to call a nonexistent contact, this could be indicated by the CM adding that contact's handle to remote-pending for reason None or Invited, then removing it for reason Invalid_Contact. In the case of a 1-1 StreamedMedia call, the CM SHOULD remove the self handle from the Group in the same signal. For 1-1 calls, the call terminates as a result of removing the remote contact, so the SelfHandle should be removed at the same time as the remote contact and for the same reason. If a contact is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.DoesNotExist. | |
| The change is because the requested contact did not respond. If a one-to-one StreamedMedia call fails because the contact being called did not respond, or the local user did not respond to an incoming call, the connection manager SHOULD indicate this by removing both the SelfHandle and the other contact's handle from the Group interface with reason No_Answer. Documenting existing practice. If a contact is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.NoAnswer. | |
| The change is because a contact's unique identifier changed. There must be exactly one handle in the removed set and exactly one handle in one of the added sets. The Renamed signal on the Renaming interface will have been emitted for the same handles, shortly before this MembersChanged signal is emitted. | |
| The change is because there was no permission to contact the requested handle. If a contact is removed from a group for this reason, the equivalent D-Bus error is org.freedesktop.Telepathy.Error.PermissionDenied. | |
| If 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. The SelfHandle SHOULD NOT be removed from channels with this reason. |
#define NUM_TP_CHANNEL_GROUP_CHANGE_REASONS TP_NUM_CHANNEL_GROUP_CHANGE_REASONS
1 higher than the highest valid value of TpChannelGroupChangeReason. In new code, use TP_NUM_CHANNEL_GROUP_CHANGE_REASONS instead.
#define TP_NUM_CHANNEL_GROUP_CHANGE_REASONS (11+1)
1 higher than the highest valid value of TpChannelGroupChangeReason.
typedef enum {
TP_CHANNEL_PASSWORD_FLAG_PROVIDE = 8,
TP_CHANNEL_PASSWORD_FLAG_HINT = 4,
} TpChannelPasswordFlags;
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_CONTACT_BLOCKING_CAPABILITY_CAN_REPORT_ABUSIVE = 1,
} TpContactBlockingCapabilities;
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_FAILURES = 1,
TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_SUCCESSES = 2,
TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_READ = 4,
TP_DELIVERY_REPORTING_SUPPORT_FLAG_RECEIVE_DELETED = 8,
} TpDeliveryReportingSupportFlags;
Flags indicating the level of support for delivery reporting on this channel, as found on the DeliveryReportingSupport property. Any future flags added to this set will conform to the convention that the presence of an extra flag implies that more operations will succeed. Note that CMs may always provide more reports than are requested in the Message_Sending_Flags passed to SendMessage. If senders want delivery reports, they should ask for them. If they don't want delivery reports, they can just ignore them, so there's no need to have capability discovery for what will happen if a delivery report isn't requested.
Bitfield/set of flags generated from the Telepathy specification.
| Clients MAY expect to receive negative delivery reports if Message_Sending_Flag_Report_Delivery is specified when sending. | |
| Clients MAY expect to receive positive delivery reports if Message_Sending_Flag_Report_Delivery is specified when sending. | |
| Clients MAY expect to receive Delivery_Status Read reports if Message_Sending_Flag_Report_Read is specified when sending. | |
| Clients MAY expect to receive Delivery_Status Deleted reports if Message_Sending_Flag_Report_Deleted is specified when sending. |
typedef enum {
TP_DELIVERY_STATUS_UNKNOWN = 0,
TP_DELIVERY_STATUS_DELIVERED = 1,
TP_DELIVERY_STATUS_TEMPORARILY_FAILED = 2,
TP_DELIVERY_STATUS_PERMANENTLY_FAILED = 3,
TP_DELIVERY_STATUS_ACCEPTED = 4,
TP_DELIVERY_STATUS_READ = 5,
TP_DELIVERY_STATUS_DELETED = 6,
} TpDeliveryStatus;
The status of a message as indicated by a delivery report. If this enum is extended in future specifications, this should only be to add new, non-overlapping conditions (i.e. all failures should still be signalled as either Temporarily_Failed or Permanently_Failed). If additional detail is required (e.g. distinguishing between the various types of permanent failure) this will be done using additional Delivery_Report_Header_Keys.
Bitfield/set of flags generated from the Telepathy specification.
| The message's disposition is unknown. Clients SHOULD consider all messages to have status Delivery_Status_Unknown unless otherwise specified; connection managers SHOULD NOT signal this delivery status explicitly. | |
| The message has been delivered to the intended recipient. | |
| Delivery of the message has failed. Clients SHOULD notify the user, but MAY automatically try sending another copy of the message. Similar to errors with type="wait" in XMPP; analogous to 4xx errors in SMTP. | |
| Delivery of the message has failed. Clients SHOULD NOT try again unless by specific user action. If the user does not modify the message or alter configuration before re-sending, this error is likely to happen again. Similar to errors with type="cancel", type="modify" or type="auth" in XMPP; analogous to 5xx errors in SMTP. | |
| An intermediate server has accepted the message but the message has not been yet delivered to the ultimate recipient. The connection manager might send a Failed report or Delivered report later. Similar to "202 Accepted" success code in SIP; analogous to 251 and 252 responses in SMTP. | |
| The message has been read by the intended recipient. | |
| The message has been deleted by the intended recipient. This MAY be signalled on its own if the message is deleted without being read, or after Read if the message was read before being deleted. |
#define NUM_TP_DELIVERY_STATUSES TP_NUM_DELIVERY_STATUSES
1 higher than the highest valid value of TpDeliveryStatus. In new code, use TP_NUM_DELIVERY_STATUSES instead.
#define TP_NUM_DELIVERY_STATUSES (6+1)
1 higher than the highest valid value of TpDeliveryStatus.
typedef enum {
TP_MEDIA_STREAM_ERROR_UNKNOWN = 0,
TP_MEDIA_STREAM_ERROR_EOS = 1,
TP_MEDIA_STREAM_ERROR_CODEC_NEGOTIATION_FAILED = 2,
TP_MEDIA_STREAM_ERROR_CONNECTION_FAILED = 3,
TP_MEDIA_STREAM_ERROR_NETWORK_ERROR = 4,
TP_MEDIA_STREAM_ERROR_NO_CODECS = 5,
TP_MEDIA_STREAM_ERROR_INVALID_CM_BEHAVIOR = 6,
TP_MEDIA_STREAM_ERROR_MEDIA_ERROR = 7,
} TpMediaStreamError;
Bitfield/set of flags generated from the Telepathy specification.
| An unknown error occured. | |
| The end of the stream was reached. | |
| There are no common codecs between the local side and the other particpants in the call. The possible codecs are not signalled here: the streaming implementation is assumed to report them in an implementation-dependent way, e.g. Farsight should use GstMissingElement. | |
| A network connection for the Media could not be established or was lost. | |
| There was an error in the networking stack (other than the connection failure). | |
| There are no installed codecs for this media type. | |
| The CM is doing something wrong. | |
| There was an error in the media processing stack. |
#define NUM_TP_MEDIA_STREAM_ERRORS TP_NUM_MEDIA_STREAM_ERRORS
1 higher than the highest valid value of TpMediaStreamError. In new code, use TP_NUM_MEDIA_STREAM_ERRORS instead.
#define TP_NUM_MEDIA_STREAM_ERRORS (7+1)
1 higher than the highest valid value of TpMediaStreamError.
typedef enum {
TP_MEDIA_STREAM_BASE_PROTO_UDP = 0,
TP_MEDIA_STREAM_BASE_PROTO_TCP = 1,
} TpMediaStreamBaseProto;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_MEDIA_STREAM_BASE_PROTOS TP_NUM_MEDIA_STREAM_BASE_PROTOS
1 higher than the highest valid value of TpMediaStreamBaseProto. In new code, use TP_NUM_MEDIA_STREAM_BASE_PROTOS instead.
#define TP_NUM_MEDIA_STREAM_BASE_PROTOS (1+1)
1 higher than the highest valid value of TpMediaStreamBaseProto.
typedef enum {
TP_MEDIA_STREAM_TRANSPORT_TYPE_LOCAL = 0,
TP_MEDIA_STREAM_TRANSPORT_TYPE_DERIVED = 1,
TP_MEDIA_STREAM_TRANSPORT_TYPE_RELAY = 2,
} TpMediaStreamTransportType;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_MEDIA_STREAM_TRANSPORT_TYPES TP_NUM_MEDIA_STREAM_TRANSPORT_TYPES
1 higher than the highest valid value of TpMediaStreamTransportType. In new code, use TP_NUM_MEDIA_STREAM_TRANSPORT_TYPES instead.
#define TP_NUM_MEDIA_STREAM_TRANSPORT_TYPES (2+1)
1 higher than the highest valid value of TpMediaStreamTransportType.
typedef enum {
TP_PROPERTY_FLAG_READ = 1,
TP_PROPERTY_FLAG_WRITE = 2,
} TpPropertyFlags;
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_MESSAGE_PART_SUPPORT_FLAG_ONE_ATTACHMENT = 1,
TP_MESSAGE_PART_SUPPORT_FLAG_MULTIPLE_ATTACHMENTS = 2,
} TpMessagePartSupportFlags;
Flags indicating the level of support for message parts on this channel. They are designed such that setting more flags always implies that the channel has more capabilities. If no flags are set, this indicates that messages may contain a single message part whose content-type is any of the types from SupportedContentTypes, possibly with some alternatives. There is no flag indicating support for alternatives. This is because the SendMessage implementation can always accept messages containing alternatives, even if the underlying protocol does not, by deleting all alternatives except the first (most preferred) that is supported. Each of the flags so far implies the previous flag, so we could have used a simple enumeration here; however, we've defined the message-part support indicator as a flag set for future expansion. See SupportedContentTypes for some examples.
Bitfield/set of flags generated from the Telepathy specification.
| SendMessage will accept messages containing a textual message body, plus a single attachment of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_Data_Only is not also set (because the connection manager can trivially provide an empty text part if necessary). | |
| SendMessage will accept messages containing a textual message body, plus an arbitrary number of attachments of any type listed in the SupportedContentTypes property. It does not make sense for this flag to be set if Message_Part_Support_Flag_One_Attachment is not also set. |
typedef enum {
TP_MESSAGE_SENDING_FLAG_REPORT_DELIVERY = 1,
TP_MESSAGE_SENDING_FLAG_REPORT_READ = 2,
TP_MESSAGE_SENDING_FLAG_REPORT_DELETED = 4,
} TpMessageSendingFlags;
Flags altering the way a message is sent. The "most usual" action should always be to have these flags unset. Some indication of which flags are supported is provided by the DeliveryReportingSupport property.
Bitfield/set of flags generated from the Telepathy specification.
| Provide a successful delivery report if possible, even if this is not the default for this protocol. Ignored if delivery reports are not possible on this protocol. In some protocols, like XMPP, it is not conventional to request or send positive delivery notifications. Delivery failure reports SHOULD always be sent, but if this flag is present, the connection manager MAY also try harder to obtain failed delivery reports or allow them to be matched to outgoing messages. | |
| Provide a delivery report when the message is read by the recipient, even if this is not the default for this protocol. Ignored if read reports are not possible on this protocol. | |
| Provide a delivery report when the message is deleted by the recipient, even if this is not the default for this protocol. Ignored if such reports are not possible on this protocol. |
#define NUM_TP_SOCKET_ACCESS_CONTROLS TP_NUM_SOCKET_ACCESS_CONTROLS
1 higher than the highest valid value of TpSocketAccessControl. In new code, use TP_NUM_SOCKET_ACCESS_CONTROLS instead.
#define TP_NUM_SOCKET_ACCESS_CONTROLS (3+1)
1 higher than the highest valid value of TpSocketAccessControl.
typedef enum {
TP_SOCKET_ACCESS_CONTROL_LOCALHOST = 0,
TP_SOCKET_ACCESS_CONTROL_PORT = 1,
TP_SOCKET_ACCESS_CONTROL_NETMASK = 2,
TP_SOCKET_ACCESS_CONTROL_CREDENTIALS = 3,
} TpSocketAccessControl;
Bitfield/set of flags generated from the Telepathy specification.
| The IP or Unix socket can be accessed by any local user (e.g. a Unix socket that accepts all local connections, or an IP socket listening on 127.0.0.1 (or ::1) or rejecting connections not from that address). The associated variant must be ignored. For a D-Bus tube, this means that the "same user" access control typically provided by default in D-Bus implementations SHOULD be disabled. If the socket is only available to local users (e.g. a Unix socket, an IPv4 socket bound to 127.0.0.1, or an IPv6 socket bound to ::1), the ANONYMOUS authentication mechanism MAY be enabled. | |
| May only be used on IP sockets, and only for Stream tubes. The associated variant must contain a struct Socket_Address_IPv4 (or Socket_Address_IPv6) containing the string form of an IP address of the appropriate version, and a port number. The socket can only be accessed if the connecting process has that address and port number; all other connections will be rejected. | |
| May only be used on IP sockets. The associated variant must contain a struct Socket_Netmask_IPv4 (or Socket_Netmask_IPv6) with signature (sy), containing the string form of an IP address of the appropriate version, and a prefix length "n". The socket can only be accessed if the first n bits of the connecting address match the first n bits of the given address. | |
| The high-level meaning of this access control type is that only the same user (e.g. same numeric Unix uid) is allowed to interact with the tube. Exactly how this is achieved varies by channel type. For StreamTube channels, this access control type may only be used on UNIX sockets. The connecting process must send a 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, without any attached credentials. (This mechanism is very similar to the first byte of a D-Bus connection, except that in D-Bus the byte is always zero, whereas in Tubes it can be nonzero.) For DBusTube channels, this access control type may be used on any type of socket, and there is no extra byte added by Telepathy at the beginning of the stream: all bytes in the stream are part of the D-Bus tube connection. The connecting process should prove its identity via any of the SASL authentication mechanisms usually used for D-Bus (in typical D-Bus implementations this involves either sending and receiving credentials as above, or demonstrating the ability to write to a file in the user's home directory). In either case, 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. In either tube type, the associated variant must be ignored. |
#define NUM_TP_SOCKET_ADDRESS_TYPES TP_NUM_SOCKET_ADDRESS_TYPES
1 higher than the highest valid value of TpSocketAddressType. In new code, use TP_NUM_SOCKET_ADDRESS_TYPES instead.
#define TP_NUM_SOCKET_ADDRESS_TYPES (3+1)
1 higher than the highest valid value of TpSocketAddressType.
typedef enum {
TP_SOCKET_ADDRESS_TYPE_UNIX = 0,
TP_SOCKET_ADDRESS_TYPE_ABSTRACT_UNIX = 1,
TP_SOCKET_ADDRESS_TYPE_IPV4 = 2,
TP_SOCKET_ADDRESS_TYPE_IPV6 = 3,
} TpSocketAddressType;
Bitfield/set of flags generated from the Telepathy specification.
| A Unix socket. The address variant contains a byte-array, signature 'ay', containing the path of the socket. | |
| An abstract Unix socket. The address variant contains a byte-array, signature 'ay', containing the path of the socket including the leading null byte. | |
| An IPv4 socket. The address variant contains a Socket_Address_IPv4, i.e. a structure with signature (sq) in which the string is an IPv4 dotted-quad address literal (and must not be a DNS name), while the 16-bit unsigned integer is the port number. | |
| An IPv6 socket. The address variant contains a Socket_Address_IPv6, i.e. a structure with signature (sq) in which the string is an IPv6 address literal as specified in RFC2373 (and must not be a DNS name), while the 16-bit unsigned integer is the port number. |
#define NUM_TP_TUBE_STATES TP_NUM_TUBE_STATES
1 higher than the highest valid value of TpTubeState. In new code, use TP_NUM_TUBE_STATES instead.
#define TP_NUM_TUBE_STATES (2+1)
1 higher than the highest valid value of TpTubeState.
typedef enum {
TP_TUBE_STATE_LOCAL_PENDING = 0,
TP_TUBE_STATE_REMOTE_PENDING = 1,
TP_TUBE_STATE_OPEN = 2,
} TpTubeState;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_TUBE_TYPES TP_NUM_TUBE_TYPES
1 higher than the highest valid value of TpTubeType. In new code, use TP_NUM_TUBE_TYPES instead.
#define TP_NUM_TUBE_TYPES (1+1)
1 higher than the highest valid value of TpTubeType.
typedef enum {
TP_TUBE_TYPE_DBUS = 0,
TP_TUBE_TYPE_STREAM = 1,
} TpTubeType;
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_CHANNEL_CALL_STATE_RINGING = 1,
TP_CHANNEL_CALL_STATE_QUEUED = 2,
TP_CHANNEL_CALL_STATE_HELD = 4,
TP_CHANNEL_CALL_STATE_FORWARDED = 8,
TP_CHANNEL_CALL_STATE_IN_PROGRESS = 16,
TP_CHANNEL_CALL_STATE_CONFERENCE_HOST = 32,
} TpChannelCallStateFlags;
A set of flags representing call states.
Bitfield/set of flags generated from the Telepathy specification.
| The contact has been alerted about the call but has not responded (e.g. 180 Ringing in SIP). | |
| The contact is temporarily unavailable, and the call has been placed in a queue (e.g. 182 Queued in SIP, or call-waiting in telephony). | |
| The contact has placed the call on hold, and will not receive media from the local user or any other participants until they unhold the call again. | |
| The initiator of the call originally called a contact other than the current recipient of the call, but the call was then forwarded or diverted. | |
| Progress has been made in placing the outgoing call, but the destination contact may not have been made aware of the call yet (so the Ringing state is not appropriate). This corresponds to SIP's status code 183 Session Progress, and could be used when the outgoing call has reached a gateway, for instance. | |
| This contact has merged this call into a conference. Note that GSM provides a notification when the remote party merges a call into a conference, but not when it is split out again; thus, this flag can only indicate that the call has been part of a conference at some point. If a GSM connection manager receives a notification that a call has been merged into a conference a second time, it SHOULD represent this by clearing and immediately re-setting this flag on the remote contact. |
#define NUM_TP_LOCAL_HOLD_STATES TP_NUM_LOCAL_HOLD_STATES
1 higher than the highest valid value of TpLocalHoldState. In new code, use TP_NUM_LOCAL_HOLD_STATES instead.
#define TP_NUM_LOCAL_HOLD_STATES (3+1)
1 higher than the highest valid value of TpLocalHoldState.
typedef enum {
TP_LOCAL_HOLD_STATE_UNHELD = 0,
TP_LOCAL_HOLD_STATE_HELD = 1,
TP_LOCAL_HOLD_STATE_PENDING_HOLD = 2,
TP_LOCAL_HOLD_STATE_PENDING_UNHOLD = 3,
} TpLocalHoldState;
The hold state of a channel.
Bitfield/set of flags generated from the Telepathy specification.
| All streams are unheld (the call is active). New channels SHOULD have this hold state. | |
| All streams are held (the call is on hold) | |
| The connection manager is attempting to move to state Held, but has not yet completed that operation. It is unspecified whether any, all or none of the streams making up the channel are on hold. Examining the Hold state of Call Contents (if applicable) may provide more useful information. | |
| The connection manager is attempting to move to state Unheld, but has not yet completed that operation. It is unspecified whether any, all or none of the streams making up the channel are on hold. Examining the Hold state of Call Contents (if applicable) may provide more useful information. |
#define NUM_TP_LOCAL_HOLD_STATE_REASONS TP_NUM_LOCAL_HOLD_STATE_REASONS
1 higher than the highest valid value of TpLocalHoldStateReason. In new code, use TP_NUM_LOCAL_HOLD_STATE_REASONS instead.
#define TP_NUM_LOCAL_HOLD_STATE_REASONS (2+1)
1 higher than the highest valid value of TpLocalHoldStateReason.
typedef enum {
TP_LOCAL_HOLD_STATE_REASON_NONE = 0,
TP_LOCAL_HOLD_STATE_REASON_REQUESTED = 1,
TP_LOCAL_HOLD_STATE_REASON_RESOURCE_NOT_AVAILABLE = 2,
} TpLocalHoldStateReason;
The reason for a change to the Local_Hold_State. Clients MUST treat unknown values as equivalent to Local_Hold_State_Reason_None.
Bitfield/set of flags generated from the Telepathy specification.
| The reason cannot be described by any of the predefined values (connection managers SHOULD avoid this reason, but clients MUST handle it gracefully) | |
| The change is in response to a user request | |
| The change is because some resource was not available |
typedef enum {
TP_ACCESS_CONTROL_TYPE_WHITELIST = 0,
TP_ACCESS_CONTROL_TYPE_PUBLISH_LIST = 1,
TP_ACCESS_CONTROL_TYPE_GROUP = 2,
TP_ACCESS_CONTROL_TYPE_OPEN = 3,
TP_ACCESS_CONTROL_TYPE_SUBSCRIBE_OR_PUBLISH_LIST = 4,
TP_ACCESS_CONTROL_TYPE_CLOSED = 5,
TP_ACCESS_CONTROL_TYPE_NOT_UNDERSTOOD = 6,
} TpAccessControlType;
A type for communication access control. These control policies are used in CommunicationPolicy.DRAFT as well as most rich presence interfaces. New interfaces should use this type, and NOT Rich_Presence_Access_Control_Type.
Bitfield/set of flags generated from the Telepathy specification.
| Only allow contacts that are in a certain whitelist. The associated variant in Access_Control is a list of Contact_Handle representing the whitelist, with signature au. | |
| Allow contacts in the user's 'publish' list. The associated variant in Access_Control is ignored. | |
| Only allow contacts that are in a certain group. The associated variant in Access_Control is a Group_Handle representing the permitted group. | |
| Allow all contacts. The associated variant in Access_Control is ignored. | |
| Allow all contacts in the user's 'subscribe' or 'publish' list. The associated variant in Access_Control is ignored. | |
| Forbid all contacts. The associated variant in Access_Control is ignored. | |
| The access control rule is too complex to be represented in the current Telepathy API. The associated variant is meaningless. Setting this mode is never valid; the connection manager MUST raise an error if this is attempted. XEP-0016 Privacy Lists can easily produce access control mechanisms that can't be expressed in a simpler API. We need to be able to at least indicate that fact. The associated variant in Access_Control is ignored. |
#define NUM_TP_ACCESS_CONTROL_TYPES TP_NUM_ACCESS_CONTROL_TYPES
1 higher than the highest valid value of TpAccessControlType. In new code, use TP_NUM_ACCESS_CONTROL_TYPES instead.
#define TP_NUM_ACCESS_CONTROL_TYPES (6+1)
1 higher than the highest valid value of TpAccessControlType.
typedef enum {
TP_RICH_PRESENCE_ACCESS_CONTROL_TYPE_WHITELIST = 0,
TP_RICH_PRESENCE_ACCESS_CONTROL_TYPE_PUBLISH_LIST = 1,
TP_RICH_PRESENCE_ACCESS_CONTROL_TYPE_GROUP = 2,
TP_RICH_PRESENCE_ACCESS_CONTROL_TYPE_OPEN = 3,
} TpRichPresenceAccessControlType;
A type of access control for Rich_Presence_Access_Control. For most types, the exact access control is given by an associated variant. These are the access control types from XMPP publish/subscribe (XEP-0060). Location uses this for historical reasons, new interfaces will use Access_Control_Type.
Bitfield/set of flags generated from the Telepathy specification.
| The associated variant is a list of contacts (signature 'au', Contact_Handle[]) who can see the extended presence information. | |
| All contacts in the user's 'publish' contact list can see the extended presence information. The associated variant is ignored. | |
| The associated variant is a handle of type Group (signature 'u', Group_Handle) representing a group of contacts who can see the extended presence information. | |
| Anyone with access to the service can see the extended presence information. |
#define NUM_TP_RICH_PRESENCE_ACCESS_CONTROL_TYPES TP_NUM_RICH_PRESENCE_ACCESS_CONTROL_TYPES
1 higher than the highest valid value of TpRichPresenceAccessControlType. In new code, use TP_NUM_RICH_PRESENCE_ACCESS_CONTROL_TYPES instead.
#define TP_NUM_RICH_PRESENCE_ACCESS_CONTROL_TYPES (3+1)
1 higher than the highest valid value of TpRichPresenceAccessControlType.
typedef enum {
TP_FILE_HASH_TYPE_NONE = 0,
TP_FILE_HASH_TYPE_MD5 = 1,
TP_FILE_HASH_TYPE_SHA1 = 2,
TP_FILE_HASH_TYPE_SHA256 = 3,
} TpFileHashType;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_FILE_HASH_TYPES TP_NUM_FILE_HASH_TYPES
1 higher than the highest valid value of TpFileHashType. In new code, use TP_NUM_FILE_HASH_TYPES instead.
#define TP_NUM_FILE_HASH_TYPES (3+1)
1 higher than the highest valid value of TpFileHashType.
typedef enum {
TP_FILE_TRANSFER_STATE_NONE = 0,
TP_FILE_TRANSFER_STATE_PENDING = 1,
TP_FILE_TRANSFER_STATE_ACCEPTED = 2,
TP_FILE_TRANSFER_STATE_OPEN = 3,
TP_FILE_TRANSFER_STATE_COMPLETED = 4,
TP_FILE_TRANSFER_STATE_CANCELLED = 5,
} TpFileTransferState;
Bitfield/set of flags generated from the Telepathy specification.
| An invalid state type used as a null value. This value MUST NOT appear in the State property. | |
| The file transfer is waiting to be accepted/closed by the receiver. The receiver has to call AcceptFile, then wait for the state to change to Open and check the offset value. | |
| The receiver has accepted the transfer. The sender now has to call ProvideFile to actually start the transfer. The receiver should now wait for the state to change to Open and check the offset value. | |
| The file transfer is open for traffic. | |
| The file transfer has been completed successfully. | |
| The file transfer has been cancelled. |
#define NUM_TP_FILE_TRANSFER_STATES TP_NUM_FILE_TRANSFER_STATES
1 higher than the highest valid value of TpFileTransferState. In new code, use TP_NUM_FILE_TRANSFER_STATES instead.
#define TP_NUM_FILE_TRANSFER_STATES (5+1)
1 higher than the highest valid value of TpFileTransferState.
typedef enum {
TP_FILE_TRANSFER_STATE_CHANGE_REASON_NONE = 0,
TP_FILE_TRANSFER_STATE_CHANGE_REASON_REQUESTED = 1,
TP_FILE_TRANSFER_STATE_CHANGE_REASON_LOCAL_STOPPED = 2,
TP_FILE_TRANSFER_STATE_CHANGE_REASON_REMOTE_STOPPED = 3,
TP_FILE_TRANSFER_STATE_CHANGE_REASON_LOCAL_ERROR = 4,
TP_FILE_TRANSFER_STATE_CHANGE_REASON_REMOTE_ERROR = 5,
} TpFileTransferStateChangeReason;
Bitfield/set of flags generated from the Telepathy specification.
| No reason was specified. | |
| The change in state was requested. | |
| The file transfer was cancelled by the local user. | |
| The file transfer was cancelled by the remote user. | |
| The file transfer was cancelled because of a local error. | |
| The file transfer was cancelled because of a remote error. |
#define NUM_TP_FILE_TRANSFER_STATE_CHANGE_REASONS TP_NUM_FILE_TRANSFER_STATE_CHANGE_REASONS
1 higher than the highest valid value of TpFileTransferStateChangeReason. In new code, use TP_NUM_FILE_TRANSFER_STATE_CHANGE_REASONS instead.
#define TP_NUM_FILE_TRANSFER_STATE_CHANGE_REASONS (5+1)
1 higher than the highest valid value of TpFileTransferStateChangeReason.
typedef enum {
TP_TUBE_CHANNEL_STATE_LOCAL_PENDING = 0,
TP_TUBE_CHANNEL_STATE_REMOTE_PENDING = 1,
TP_TUBE_CHANNEL_STATE_OPEN = 2,
TP_TUBE_CHANNEL_STATE_NOT_OFFERED = 3,
} TpTubeChannelState;
Bitfield/set of flags generated from the Telepathy specification.
| The initiator offered the tube. The tube is waiting to be accepted/closed locally. If the client accepts the tube, the tube's state will be Open. | |
| The tube is waiting to be accepted/closed remotely. If the recipient accepts the tube, the tube's state will be Open. | |
| The initiator offered the tube and the recipient accepted it. The tube is open for traffic. The tube's state stays in this state until it is closed. | |
| The tube channel has been requested but the tube is not yet offered. The client should offer the tube to the recipient and the tube's state will be Remote_Pending. The method used to offer the tube depends on the tube type. |
#define NUM_TP_TUBE_CHANNEL_STATES TP_NUM_TUBE_CHANNEL_STATES
1 higher than the highest valid value of TpTubeChannelState. In new code, use TP_NUM_TUBE_CHANNEL_STATES instead.
#define TP_NUM_TUBE_CHANNEL_STATES (3+1)
1 higher than the highest valid value of TpTubeChannelState.
typedef enum {
TP_DEBUG_LEVEL_ERROR = 0,
TP_DEBUG_LEVEL_CRITICAL = 1,
TP_DEBUG_LEVEL_WARNING = 2,
TP_DEBUG_LEVEL_MESSAGE = 3,
TP_DEBUG_LEVEL_INFO = 4,
TP_DEBUG_LEVEL_DEBUG = 5,
} TpDebugLevel;
Bitfield/set of flags generated from the Telepathy specification.
| Log level for errors. Error messages are always fatal, resulting in the service terminating after something completely unexpected occurred. | |
| Log level for critical messages. Critical messages are messages that the service might predict and it is up to the service itself to decide whether to terminate following a critical message. | |
| Log level for warnings. | |
| Log level for messages. | |
| Log level for information messages. | |
| Log level for debug messages. |
#define NUM_TP_DEBUG_LEVELS TP_NUM_DEBUG_LEVELS
1 higher than the highest valid value of TpDebugLevel. In new code, use TP_NUM_DEBUG_LEVELS instead.
#define TP_NUM_DEBUG_LEVELS (5+1)
1 higher than the highest valid value of TpDebugLevel.
typedef enum {
TP_CONTACT_INFO_FLAG_CAN_SET = 1,
TP_CONTACT_INFO_FLAG_PUSH = 2,
} TpContactInfoFlags;
Flags defining the behaviour of contact information on this protocol. Some protocols provide no information on contacts without an explicit request; others always push information to the connection manager as and when it changes.
Bitfield/set of flags generated from the Telepathy specification.
| Indicates that SetContactInfo is supported on this connection. | |
| Indicates that the protocol pushes all contacts' information to the connection manager without prompting. If set, ContactInfoChanged will be emitted whenever contacts' information changes. |
typedef enum {
TP_CONTACT_INFO_FIELD_FLAG_PARAMETERS_EXACT = 1,
TP_CONTACT_INFO_FIELD_FLAG_OVERWRITTEN_BY_NICKNAME = 2,
} TpContactInfoFieldFlags;
Flags describing the behaviour of a vCard field.
Bitfield/set of flags generated from the Telepathy specification.
| If present, exactly the parameters indicated must be set on this field; in the case of an empty list of parameters, this implies that parameters may not be used. If absent, and the list of allowed parameters is non-empty, any (possibly empty) subset of that list may be used. If absent, and the list of allowed parameters is empty, any parameters may be used. | |
| Indicates that this field will be overwritten when the user's alias is changed with SetAliases or when the Account's Nickname is updated. Clients that allow the editing of the Alias and the ContactInfo in the same location should hide fields with this flag. If a client allowed the user to edit both the nickname and the ContactInfo field at the same time, the user could set them to two different values even though they map to the same property. This would result in surprising behavior where the second value would win over the first. In addition to hiding this field when editing ContactInfo together with the user's nickname, it is recommended that clients call SetContactInfo before setting the user's nickname. This ensures that if the user changes the nickname, the correct value will get set even if the stale nickname is mistakenly sent along with SetContactInfo. If used, this flag typically appears on either the 'nickname' or 'fn' field. |
typedef enum {
TP_LOCATION_FEATURE_CAN_SET = 1,
} TpLocationFeatures;
Flags describing the Location features which may be supported on any given connection.
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_SERVICE_POINT_TYPE_NONE = 0,
TP_SERVICE_POINT_TYPE_EMERGENCY = 1,
TP_SERVICE_POINT_TYPE_COUNSELING = 2,
} TpServicePointType;
The various types of service points a channel might connect to.
Bitfield/set of flags generated from the Telepathy specification.
| The channel is not communicating with a service point, or it is not known whether it is communicating with a service point (e.g. an ordinary call). | |
| The service point is a generic emergency point. | |
| The service point is some kind of counseling service (ie, mental health or child-services counseling). |
#define NUM_TP_SERVICE_POINT_TYPES TP_NUM_SERVICE_POINT_TYPES
1 higher than the highest valid value of TpServicePointType. In new code, use TP_NUM_SERVICE_POINT_TYPES instead.
#define TP_NUM_SERVICE_POINT_TYPES (2+1)
1 higher than the highest valid value of TpServicePointType.
typedef enum {
TP_ANONYMITY_MODE_CLIENT_INFO = 1,
TP_ANONYMITY_MODE_SHOW_CLIENT_INFO = 2,
TP_ANONYMITY_MODE_NETWORK_INFO = 4,
} TpAnonymityModeFlags;
Flags for the various types of anonymity modes. These modes are solely to inform the CM of the desired anonymous settings. It is up to the CM to determine whether the anonymity modes should be handled within the CM itself, or whether the network that a CM might be talking to should be enforcing anonymity. CMs MAY support only a subset of these modes, and specific connections MAY support none at all.
Bitfield/set of flags generated from the Telepathy specification.
| Obscure any information that provides user identification, user-agent identification or personal details. Examples of this information might be GSM CallerID, SIP from address, various informational email headers, etc. The CM should scrub/replace any of this information before passing messages or data onto the network. Note that a CM which has the option of obscuring the information at the CM or privacy service level would choose both (anonymity services are opaque to clients of this interface). Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info. | |
| Explicitly request showing of client information. In connection context, this can be used to override service default. In channel context, this overrides connection anonymity modes. In GSM, it's possible to have CLIR enabled by default, and explicitly suppress CLIR for a single phone call. Clients SHOULD NOT set both Client_Info and Show_Client_Info modes. If they are set, the CM MUST respect Client_Info and ignore Show_Client_Info. The CM MAY set both Client_Info and Show_Client_Info in SupportedAnonymityModes to indicate its support for explicitly hiding and publicising client information. | |
| Obscure any originating IP address information, contact URIs, and anonymize all traffic involved with sending/receiving any media streams or call content. Examples of this include the "headers" portions of RFC 3323 as well as the History-Info (described in RFC 4244) for a SIP CM. This SHOULD have the effect of hiding address information from the remote contact (ie, the contact cannot know what IP address the session is originated from). Obviously the network still needs to be able to route information between contacts, so this provides no guarantees of what can be seen by intermediaries. |
typedef enum {
TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_PARAMETERS = 1,
TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_ENABLED = 2,
TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_PRESENCE = 4,
TP_STORAGE_RESTRICTION_FLAG_CANNOT_SET_SERVICE = 8,
} TpStorageRestrictionFlags;
Flags indicating restrictions imposed on an Account by its storage method.
Bitfield/set of flags generated from the Telepathy specification.
| The account's Parameters property can't be changed by calling UpdateParameters. | |
| The account can't be enabled/disabled by setting the Enabled property. | |
| The account's presence can't be changed by setting the RequestedPresence and AutomaticPresence properties. | |
| The account's Service property cannot be changed. |
typedef enum {
TP_TLS_CERTIFICATE_REJECT_REASON_UNKNOWN = 0,
TP_TLS_CERTIFICATE_REJECT_REASON_UNTRUSTED = 1,
TP_TLS_CERTIFICATE_REJECT_REASON_EXPIRED = 2,
TP_TLS_CERTIFICATE_REJECT_REASON_NOT_ACTIVATED = 3,
TP_TLS_CERTIFICATE_REJECT_REASON_FINGERPRINT_MISMATCH = 4,
TP_TLS_CERTIFICATE_REJECT_REASON_HOSTNAME_MISMATCH = 5,
TP_TLS_CERTIFICATE_REJECT_REASON_SELF_SIGNED = 6,
TP_TLS_CERTIFICATE_REJECT_REASON_REVOKED = 7,
TP_TLS_CERTIFICATE_REJECT_REASON_INSECURE = 8,
TP_TLS_CERTIFICATE_REJECT_REASON_LIMIT_EXCEEDED = 9,
} TpTLSCertificateRejectReason;
Possible reasons to reject a TLS certificate.
Bitfield/set of flags generated from the Telepathy specification.
| The certificate has been rejected for another reason not listed in this enumeration. | |
| The certificate is not trusted. | |
| The certificate is expired. | |
| The certificate is not active yet. | |
| The certificate provided does not have the expected fingerprint. | |
| The hostname certified does not match the provided one. | |
| The certificate is self-signed. | |
| The certificate has been revoked. | |
| The certificate uses an insecure cipher algorithm, or is cryptographically weak. | |
| The length in bytes of the certificate, or the depth of the certificate chain exceed the limits imposed by the crypto library. |
#define NUM_TP_TLS_CERTIFICATE_REJECT_REASONS TP_NUM_TLS_CERTIFICATE_REJECT_REASONS
1 higher than the highest valid value of TpTLSCertificateRejectReason. In new code, use TP_NUM_TLS_CERTIFICATE_REJECT_REASONS instead.
#define TP_NUM_TLS_CERTIFICATE_REJECT_REASONS (9+1)
1 higher than the highest valid value of TpTLSCertificateRejectReason.
typedef enum {
TP_TLS_CERTIFICATE_STATE_PENDING = 0,
TP_TLS_CERTIFICATE_STATE_ACCEPTED = 1,
TP_TLS_CERTIFICATE_STATE_REJECTED = 2,
} TpTLSCertificateState;
The possible states for a TLSCertificate object.
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_TLS_CERTIFICATE_STATES TP_NUM_TLS_CERTIFICATE_STATES
1 higher than the highest valid value of TpTLSCertificateState. In new code, use TP_NUM_TLS_CERTIFICATE_STATES instead.
#define TP_NUM_TLS_CERTIFICATE_STATES (2+1)
1 higher than the highest valid value of TpTLSCertificateState.
typedef enum {
TP_CONTACT_METADATA_STORAGE_TYPE_NONE = 0,
TP_CONTACT_METADATA_STORAGE_TYPE_SUBSCRIBED_OR_PENDING = 1,
TP_CONTACT_METADATA_STORAGE_TYPE_SUBSCRIBED = 2,
TP_CONTACT_METADATA_STORAGE_TYPE_ANYONE = 3,
} TpContactMetadataStorageType;
Values of this enumeration indicate the extent to which metadata such as aliases and group memberships can be stored for the contacts on a particular connection. On some protocols, certain metadata (for instance, contact aliases) can only be stored for contacts on the contact list, or contacts with a particular contact list state. To make it easier to deal with such protocols, if clients set metadata on a contact who is not in the required state, the Connection MUST cache the metadata for the duration of the session. If clients request the attributes of that contact after the appropriate "set" method has returned successfully, the Connection MUST return the new (cached) value. If the contact is later placed in the required state to store metadata (for instance, if subscription to the contact's presence is requested, on a protocol like MSN where the alias has storage type Subscribed_Or_Pending), the connection MUST store the cached metadata at that time. If the Connection didn't cache changes in this way, a client intending to change the alias on MSN would have to wait until the server acknowledged the subscription request; in the meantime, other clients would still display the old alias. The only exception to that general rule is that if the Connection cannot store particular metadata at all (i.e. the storage type is None), it MUST reject attempts to set it. If the implementation knows that metadata can't be stored at all, it's useful to report that, which can be done synchronously. In general, user interfaces should detect storage type None and not display editing controls at all.
Bitfield/set of flags generated from the Telepathy specification.
| This connection cannot store this type of metadata at all, and attempting to do so will fail with NotImplemented. Link-local XMPP can't store aliases or group memberships at all, and subscription and presence states are implicit (all contacts on the local network have subscribe = publish = Yes and no other contacts exist). As of April 2010, the XMPP server for Facebook Chat provides a read-only view of the user's Facebook contacts, so it could also usefully have this storage type. | |
| This type of metadata can only be stored permanently for contacts whose subscribe attribute is Ask or Yes. Contact aliases and groups on MSN have this behaviour. | |
| This type of metadata can only be stored permanently for contacts whose subscribe attribute is Yes. No service with this behaviour is currently known, but it's a stricter form of Subscribed_Or_Pending. | |
| The user can set this metadata for any valid contact identifier, whether or not they have any presence subscription relationship to it, and it will be stored on their contact list. Contact aliases and groups on XMPP have this behaviour; it is possible to put a contact in a group, or assign an alias to them, without requesting that presence be shared. |
#define NUM_TP_CONTACT_METADATA_STORAGE_TYPES TP_NUM_CONTACT_METADATA_STORAGE_TYPES
1 higher than the highest valid value of TpContactMetadataStorageType. In new code, use TP_NUM_CONTACT_METADATA_STORAGE_TYPES instead.
#define TP_NUM_CONTACT_METADATA_STORAGE_TYPES (3+1)
1 higher than the highest valid value of TpContactMetadataStorageType.
typedef enum {
TP_SUBSCRIPTION_STATE_UNKNOWN = 0,
TP_SUBSCRIPTION_STATE_NO = 1,
TP_SUBSCRIPTION_STATE_REMOVED_REMOTELY = 2,
TP_SUBSCRIPTION_STATE_ASK = 3,
TP_SUBSCRIPTION_STATE_YES = 4,
} TpSubscriptionState;
An enumeration indicating whether presence subscription is denied, denied but pending permission, or allowed. The exact semantics vary according to where this type is used: see the subscribe and publish contact attributes for details.
Bitfield/set of flags generated from the Telepathy specification.
| The presence subscription state is unknown. | |
| Presence information cannot be seen, and either the subscription state Removed_Remotely does not apply, or it is not known whether that state applies. | |
| Presence information cannot be seen because the remote contact took action: either the local user's request to see the remote contact's presence was denied, or the remote contact requested to see the local user's presence but then cancelled their request. | |
| Presence information cannot be seen. Permission to see presence information has been requested, and the request has not yet been declined or accepted. | |
| Presence information can be seen. |
#define NUM_TP_SUBSCRIPTION_STATES TP_NUM_SUBSCRIPTION_STATES
1 higher than the highest valid value of TpSubscriptionState. In new code, use TP_NUM_SUBSCRIPTION_STATES instead.
#define TP_NUM_SUBSCRIPTION_STATES (4+1)
1 higher than the highest valid value of TpSubscriptionState.
typedef enum {
TP_CONTACT_LIST_STATE_NONE = 0,
TP_CONTACT_LIST_STATE_WAITING = 1,
TP_CONTACT_LIST_STATE_FAILURE = 2,
TP_CONTACT_LIST_STATE_SUCCESS = 3,
} TpContactListState;
The progress made in retrieving the contact list.
Bitfield/set of flags generated from the Telepathy specification.
| The connection has not started to retrieve the contact list. If GetContactListAttributes is called in this state, it will raise NotYet. | |
| The connection has started to retrieve the contact list, but has not yet succeeded or failed. If GetContactListAttributes is called in this state, it will raise NotYet. | |
| The connection has tried and failed to retrieve the contact list. If GetContactListAttributes is called in this state, it will immediately raise an error indicating the reason for failure. The connection manager SHOULD try again to obtain the contact list, if appropriate for the protocol. If it succeeds later, the ContactListState MUST advance to Success. | |
| The connection has successfully retrieved the contact list. If GetContactListAttributes is called in this state, it will return successfully. |
#define NUM_TP_CONTACT_LIST_STATES TP_NUM_CONTACT_LIST_STATES
1 higher than the highest valid value of TpContactListState. In new code, use TP_NUM_CONTACT_LIST_STATES instead.
#define TP_NUM_CONTACT_LIST_STATES (3+1)
1 higher than the highest valid value of TpContactListState.
typedef enum {
TP_HTTP_METHOD_GET = 0,
TP_HTTP_METHOD_POST = 1,
} TpHTTPMethod;
The HTTP Method with which to request a URL.
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_HTTP_METHODS TP_NUM_HTTP_METHODS
1 higher than the highest valid value of TpHTTPMethod. In new code, use TP_NUM_HTTP_METHODS instead.
#define TP_NUM_HTTP_METHODS (1+1)
1 higher than the highest valid value of TpHTTPMethod.
typedef enum {
TP_MAIL_NOTIFICATION_FLAG_SUPPORTS_UNREAD_MAIL_COUNT = 1,
TP_MAIL_NOTIFICATION_FLAG_SUPPORTS_UNREAD_MAILS = 2,
TP_MAIL_NOTIFICATION_FLAG_EMITS_MAILS_RECEIVED = 4,
TP_MAIL_NOTIFICATION_FLAG_SUPPORTS_REQUEST_INBOX_URL = 8,
TP_MAIL_NOTIFICATION_FLAG_SUPPORTS_REQUEST_MAIL_URL = 16,
TP_MAIL_NOTIFICATION_FLAG_THREAD_BASED = 32,
} TpMailNotificationFlags;
Flags representing capabilities provided by a connection manager. Those values can be used as bitfield. Some flags depend on, or conflict with, each other. Connections SHOULD implement as many of these features as the underlying protocol allows, preferring to implement Supports_Unread_Mails instead of Emits_Mails_Received if both are possible.
Bitfield/set of flags generated from the Telepathy specification.
| This Connection provides the number of unread e-mails (or e-mail threads) in the main folder of your e-mail account, as the UnreadMailCount property. The connection manager will update this value by emitting the UnreadMailsChanged signal. | |
| This Connection provides a detailed list of unread e-mails, as the UnreadMails property. If this flag is set, Supports_Unread_Mail_Count MUST be set, and Emits_Mails_Received MUST NOT be set. The Connection will update the list by emitting the UnreadMailsChanged signals. | |
| This Connection emits the MailsReceived signal, which provides details about newly arrived e-mails but does not maintain their read/unread status afterwards. This flag MUST NOT be combined with Supports_Unread_Mails. | |
| This Connection can provide a URL (with optional POST data) to open the the inbox of the e-mail account in a web-based client, via the RequestInboxURL method. | |
| This Connection can provide a URL (with optional POST data) to open a specific mail in a web-based client, via the RequestMailURL method. This feature is not useful unless either Emits_Mails_Received or Supports_Unread_Mails is set. If this flag is not set, clients SHOULD fall back to using RequestInboxURL if available. | |
| Each Mail represents a thread of e-mails, which MAY have more than one sender. Google Talk notifies users about new mail in terms of unread threads, rather than unread e-mails. |
typedef enum {
TP_SASL_ABORT_REASON_INVALID_CHALLENGE = 0,
TP_SASL_ABORT_REASON_USER_ABORT = 1,
} TpSASLAbortReason;
A reason why SASL authentication was aborted by the client.
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_SASL_ABORT_REASONS TP_NUM_SASL_ABORT_REASONS
1 higher than the highest valid value of TpSASLAbortReason. In new code, use TP_NUM_SASL_ABORT_REASONS instead.
#define TP_NUM_SASL_ABORT_REASONS (1+1)
1 higher than the highest valid value of TpSASLAbortReason.
typedef enum {
TP_SASL_STATUS_NOT_STARTED = 0,
TP_SASL_STATUS_IN_PROGRESS = 1,
TP_SASL_STATUS_SERVER_SUCCEEDED = 2,
TP_SASL_STATUS_CLIENT_ACCEPTED = 3,
TP_SASL_STATUS_SUCCEEDED = 4,
TP_SASL_STATUS_SERVER_FAILED = 5,
TP_SASL_STATUS_CLIENT_FAILED = 6,
} TpSASLStatus;
Bitfield/set of flags generated from the Telepathy specification.
| The initial state. The Handler SHOULD either call AbortSASL, or connect to the NewChallenge signal then call StartMechanism or StartMechanismWithData. | |
| The challenge/response exchange is in progress. The Handler SHOULD call either Respond or AcceptSASL exactly once per emission of NewChallenge, or call AbortSASL at any time. | |
| The server has indicated successful authentication, and the connection manager is waiting for confirmation from the Handler. The Handler must call either AcceptSASL or AbortSASL to indicate whether it considers authentication to have been successful. | |
| The Handler has indicated successful authentication, and the connection manager is waiting for confirmation from the server. The state will progress to either Succeeded or Server_Failed when confirmation is received. | |
| Everyone is happy (the server sent success, and the client has called AcceptSASL). Connection to the server will proceed as soon as this state is reached. The Handler SHOULD call Close to close the channel. | |
| The server has indicated an authentication failure. If CanTryAgain is true, the client may try to authenticate again, by calling StartMechanism or StartMechanismWithData again. Otherwise, it should give up completely, by calling Close on the channel. | |
| The client has indicated an authentication failure. The possible actions are the same as for Server_Failed. |
#define NUM_TP_SASL_STATUSES TP_NUM_SASL_STATUSES
1 higher than the highest valid value of TpSASLStatus. In new code, use TP_NUM_SASL_STATUSES instead.
#define TP_NUM_SASL_STATUSES (6+1)
1 higher than the highest valid value of TpSASLStatus.
typedef enum {
TP_CAPTCHA_STATUS_LOCAL_PENDING = 0,
TP_CAPTCHA_STATUS_REMOTE_PENDING = 1,
TP_CAPTCHA_STATUS_SUCCEEDED = 2,
TP_CAPTCHA_STATUS_TRY_AGAIN = 3,
TP_CAPTCHA_STATUS_FAILED = 4,
} TpCaptchaStatus;
Bitfield/set of flags generated from the Telepathy specification.
| The challenge/response exchange is in progress and waiting for a local action. Call AnswerCaptchas to go to the Remote_Pending state, or call CancelCaptcha followed by Close to give up. | |
| The challenge/response exchange is in progress and waiting for a response from the server. Wait for a reply from the server, which will result in the Succeeded, Try_Again, or Failed state, or call CancelCaptcha followed by Close to give up. | |
| Everyone is happy. Connection to the server will proceed as soon as this state is reached. There is nothing useful to do in this state except to call Close to close the channel. | |
| The server has indicated an authentication failure. Call GetCaptchas again to get a new captcha, or CancelCaptcha followed by Close to give up. | |
| Authentication has failed in some way. There is nothing useful to do in this state except to close the channel with Close. |
#define NUM_TP_CAPTCHA_STATUSES TP_NUM_CAPTCHA_STATUSES
1 higher than the highest valid value of TpCaptchaStatus. In new code, use TP_NUM_CAPTCHA_STATUSES instead.
#define TP_NUM_CAPTCHA_STATUSES (4+1)
1 higher than the highest valid value of TpCaptchaStatus.
typedef enum {
TP_CAPTCHA_CANCEL_REASON_USER_CANCELLED = 0,
TP_CAPTCHA_CANCEL_REASON_NOT_SUPPORTED = 1,
TP_CAPTCHA_CANCEL_REASON_SERVICE_CONFUSED = 2,
} TpCaptchaCancelReason;
A reason why captcha authentication was aborted by the client.
Bitfield/set of flags generated from the Telepathy specification.
| The user aborted the authentication. If this is used, the CaptchaError SHOULD be set to Cancelled | |
| The Handler doesn't support the given/required captcha types. If this is used, the CaptchaError SHOULD be set to CaptchaNotSupported. This SHOULD also be used if Close is called before CancelCaptcha. If no Handler supports captcha channels, the ChannelDispatcher will just call Close, because it has no knowledge of specific channel types. | |
| The Handler doesn't understand the captcha data received. The challenger may be sending gibberish. If this is used, the CaptchaError SHOULD be set to ServiceConfused. |
#define NUM_TP_CAPTCHA_CANCEL_REASONS TP_NUM_CAPTCHA_CANCEL_REASONS
1 higher than the highest valid value of TpCaptchaCancelReason. In new code, use TP_NUM_CAPTCHA_CANCEL_REASONS instead.
#define TP_NUM_CAPTCHA_CANCEL_REASONS (2+1)
1 higher than the highest valid value of TpCaptchaCancelReason.
typedef enum {
TP_CAPTCHA_FLAGS_REQUIRED = 1,
} TpCaptchaFlags;
Extra flags to include with Captcha information
Bitfield/set of flags generated from the Telepathy specification.
typedef enum {
TP_CALL_CONTENT_DISPOSITION_NONE = 0,
TP_CALL_CONTENT_DISPOSITION_INITIAL = 1,
} TpCallContentDisposition;
The disposition of this content, which defines whether to automatically start sending data on the streams when Accept is called on the channel.
Bitfield/set of flags generated from the Telepathy specification.
| The content has no specific disposition. | |
| The content was initially part of the call. When Accept is called on the channel, all streams of this content with LocalSendingState set to Pending_Send will be moved to Sending as if SetSending (True) had been called. |
#define NUM_TP_CALL_CONTENT_DISPOSITIONS TP_NUM_CALL_CONTENT_DISPOSITIONS
1 higher than the highest valid value of TpCallContentDisposition. In new code, use TP_NUM_CALL_CONTENT_DISPOSITIONS instead.
#define TP_NUM_CALL_CONTENT_DISPOSITIONS (1+1)
1 higher than the highest valid value of TpCallContentDisposition.
typedef enum {
TP_CALL_CONTENT_PACKETIZATION_TYPE_RTP = 0,
TP_CALL_CONTENT_PACKETIZATION_TYPE_RAW = 1,
TP_CALL_CONTENT_PACKETIZATION_TYPE_MSN_WEBCAM = 2,
} TpCallContentPacketizationType;
A packetization method that can be used for a content.
Bitfield/set of flags generated from the Telepathy specification.
| Real-time Transport Protocol, as documented by RFC 3550. | |
| Raw media. | |
| MSN webcam. This is the video-only one-way type which was used in earlier versions of WLM. Although no longer used, modern WLM clients still support the MSN webcam protocol. |
#define NUM_TP_CALL_CONTENT_PACKETIZATION_TYPES TP_NUM_CALL_CONTENT_PACKETIZATION_TYPES
1 higher than the highest valid value of TpCallContentPacketizationType. In new code, use TP_NUM_CALL_CONTENT_PACKETIZATION_TYPES instead.
#define TP_NUM_CALL_CONTENT_PACKETIZATION_TYPES (2+1)
1 higher than the highest valid value of TpCallContentPacketizationType.
typedef enum {
TP_CALL_STATE_UNKNOWN = 0,
TP_CALL_STATE_PENDING_INITIATOR = 1,
TP_CALL_STATE_INITIALISING = 2,
TP_CALL_STATE_INITIALISED = 3,
TP_CALL_STATE_ACCEPTED = 4,
TP_CALL_STATE_ACTIVE = 5,
TP_CALL_STATE_ENDED = 6,
} TpCallState;
The state of a call, as a whole. The allowed transitions are: Pending_Initiator → Initialising (for outgoing calls, when Accept is called) Initialising → Initialised (for outgoing calls, when the remote client indicates that the user has been notified about the call. If the network is known not to provide feedback about whether the remote side is ringing, then the call should immediately be set to Initialised. Initialising → Initialised (for incoming calls, when e.g. the implementation has been initialised far enough that it is sensible to notify the user about the call (to reduce the probability that the user will pick up the call and have it immediately fail). The UI should then alert the user about the call, and call SetRinging) Initialised → Accepted (for outgoing calls to a contact, when the remote contact accepts the call; for incoming calls, when Accept is called.) Accepted → Active (when the local user successfully joins the call/conference, and media is known to be flowing successfully; also, when temporary connection problems are resolved (See below)). If the network is known not to provide feedback about when the call is properly connected, the call should immediately be set to Active. Active → Accepted (when there are temporary connection problems that the CM is aware of and able to recover from) any state → Ended (when the call is terminated normally, or when an error occurs that the CM is unable to recover from) Clients MAY consider unknown values from this enum to be an error - additional values will not be defined after the Call specification is declared to be stable.
Bitfield/set of flags generated from the Telepathy specification.
| The call state is not known. This call state MUST NOT appear as a value of the CallState property, but MAY be used by client code to represent calls whose state is as yet unknown. | |
| The initiator of the call hasn't accepted the call yet. This state only makes sense for outgoing calls, where it means that the local user has not yet sent any signalling messages to the remote user(s), and will not do so until Accept is called. | |
| Progress has been made in placing the call, but the contact has not been made aware of the call yet. This corresponds to SIP's status code 183 Session Progress, and should be used for the period where the CM is waiting for the streaming implementation to initialise (before sending the initial INVITE or equivalent) and when the outgoing call has reached a gateway or ICE negotiation is pending. UIs should not produce a dialtone or start ringing if the call is in this state. | |
| In the outgoing case: at least one called user has been alerted about the call (a SIP 180 (Ringing) packet or equivalent has been received) but none have answered, so the call cannot go to Accepted (use Ringing to determine which members have been informed and which haven't, if you care). UIs SHOULD produce a dialtone for outgoing calls in this state. In the incoming case, the local user should be informed of the call as soon as the call reaches this state (and SetRinging should be called to inform the CM that this has happened, so that it can relay this fact to the caller using a SIP 180 (Ringing) packet or equivalent). | |
| The contact being called has accepted the call, but the call is not in the Active state (The most common reason for this is that the streaming implementation hasn't connected yet). | |
| The contact being called has accepted the call, and discourse between at least two parties should now be possible. | |
| The call has ended, either via normal termination or an error. |
#define NUM_TP_CALL_STATES TP_NUM_CALL_STATES
1 higher than the highest valid value of TpCallState. In new code, use TP_NUM_CALL_STATES instead.
#define TP_NUM_CALL_STATES (6+1)
1 higher than the highest valid value of TpCallState.
typedef enum {
TP_CALL_STATE_CHANGE_REASON_UNKNOWN = 0,
TP_CALL_STATE_CHANGE_REASON_PROGRESS_MADE = 1,
TP_CALL_STATE_CHANGE_REASON_USER_REQUESTED = 2,
TP_CALL_STATE_CHANGE_REASON_FORWARDED = 3,
TP_CALL_STATE_CHANGE_REASON_REJECTED = 4,
TP_CALL_STATE_CHANGE_REASON_NO_ANSWER = 5,
TP_CALL_STATE_CHANGE_REASON_INVALID_CONTACT = 6,
TP_CALL_STATE_CHANGE_REASON_PERMISSION_DENIED = 7,
TP_CALL_STATE_CHANGE_REASON_BUSY = 8,
TP_CALL_STATE_CHANGE_REASON_INTERNAL_ERROR = 9,
TP_CALL_STATE_CHANGE_REASON_SERVICE_ERROR = 10,
TP_CALL_STATE_CHANGE_REASON_NETWORK_ERROR = 11,
TP_CALL_STATE_CHANGE_REASON_MEDIA_ERROR = 12,
TP_CALL_STATE_CHANGE_REASON_CONNECTIVITY_ERROR = 13,
} TpCallStateChangeReason;
A simple representation of the reason for a change in the call's state, which may be used by simple clients, or used as a fallback when the DBus_Reason member of a Call_State_Reason struct is not understood.
Bitfield/set of flags generated from the Telepathy specification.
| We just don't know. Unknown values of this enum SHOULD also be treated like this. | |
| Situation normal. Progress has been made in the setup/teardown of the call (and it didn't require any user interaction). | |
| The change was requested by the contact indicated by the Actor member of a Call_State_Reason struct. The DBus_Reason SHOULD be the empty string if the call was terminated normally, but MAY be a non-empty error name to indicate error-like call termination reasons (kicked from a conference by a moderator, etc.). | |
| The call was forwarded. If known, the handle of the contact the call was forwarded to will be indicated by the "forwarded-to" member of a CallStateDetails dictionnary in the CallStateChanged signal. | |
| The CallState changed from Initialised or Ended (or a content's direction changed) because it was rejected by the remote user. Corresponds to Rejected | |
| The CallState changed from Initialised or Ended because the initiator ended the call before the receiver accepted it. With an incoming call this state change reason signifies a missed call, or one that was picked up elsewhere before it was picked up here. Corresponds to NoAnswer or PickedUpElsewhere | |
| The CallState changed because one of the addresses does not exist on the network. Corresponds to DoesNotExist | |
| The CallState changed because the local user is not authorised. Corresponds to PermissionDenied or InsufficientBalance | |
| The CallState changed from Initialised Ended because the receiver is busy (e.g. is already engaged in another call, and has not placed the initiator in a call-waiting queue). Corresponds to Busy | |
| There has been an unexpected error in either the CM or some other local component. Corresponds to Confused or Media.StreamingError | |
| There has been an unexpected error in the server or some other remote component. Corresponds to ServiceConfused | |
| There has been a network error related to the CM or the signalling part of the call (compare and contrast: Streaming_Error). Corresponds to NetworkError | |
| Some aspect of the content is unsupported so has to be removed from the call. Corresponds to Media.UnsupportedType or Media.CodecsIncompatible | |
| It was not possible for the streaming implementation to connect to any of the users participating in this call or content. Corresponds to ConnectionFailed or ConnectionLost |
#define NUM_TP_CALL_STATE_CHANGE_REASONS TP_NUM_CALL_STATE_CHANGE_REASONS
1 higher than the highest valid value of TpCallStateChangeReason. In new code, use TP_NUM_CALL_STATE_CHANGE_REASONS instead.
#define TP_NUM_CALL_STATE_CHANGE_REASONS (13+1)
1 higher than the highest valid value of TpCallStateChangeReason.
typedef enum {
TP_CALL_STREAM_CANDIDATE_TYPE_NONE = 0,
TP_CALL_STREAM_CANDIDATE_TYPE_HOST = 1,
TP_CALL_STREAM_CANDIDATE_TYPE_SERVER_REFLEXIVE = 2,
TP_CALL_STREAM_CANDIDATE_TYPE_PEER_REFLEXIVE = 3,
TP_CALL_STREAM_CANDIDATE_TYPE_RELAY = 4,
TP_CALL_STREAM_CANDIDATE_TYPE_MULTICAST = 5,
} TpCallStreamCandidateType;
The network topology that an IP candidate represents. This can sometimes be used to infer what kind of performance characteristics (latency, bandwith, etc) can be expected of connections made to this candidate.
Bitfield/set of flags generated from the Telepathy specification.
| This is not an IP candidate. This is a reserved value, and should not be seen on the bus. | |
| This candidate represents a direct connection to the host, as its address is taken directly the host's IP stack. | |
| This candidate probably represents a connection to the host through a NAT device, as its address was discovered by sending a binding request to a STUN server or similar. | |
| This candidate probably represents a good route between the host and its peer, as its address was discovered by sending a STUN binding request to one of the candidates advertised by the peer. | |
| This candidate represents the address of a relay server (usually somewhere on the public internet). This candidate is the most likely to work, but all media will go via a relay server, so latency is likely to be higher than other types of candidate. | |
| This candidate represents a Multicast group. This value should only appear if the Stream's Transport is set to Multicast. |
#define NUM_TP_CALL_STREAM_CANDIDATE_TYPES TP_NUM_CALL_STREAM_CANDIDATE_TYPES
1 higher than the highest valid value of TpCallStreamCandidateType. In new code, use TP_NUM_CALL_STREAM_CANDIDATE_TYPES instead.
#define TP_NUM_CALL_STREAM_CANDIDATE_TYPES (5+1)
1 higher than the highest valid value of TpCallStreamCandidateType.
typedef enum {
TP_RCPT_XR_RTT_MODE_ALL = 0,
TP_RCPT_XR_RTT_MODE_SENDER = 1,
} TpRCPTXRRTTMode;
Bitfield/set of flags generated from the Telepathy specification.
#define NUM_TP_RCPT_XR_RTT_MODES TP_NUM_RCPT_XR_RTT_MODES
1 higher than the highest valid value of TpRCPTXRRTTMode. In new code, use TP_NUM_RCPT_XR_RTT_MODES instead.
#define TP_NUM_RCPT_XR_RTT_MODES (1+1)
1 higher than the highest valid value of TpRCPTXRRTTMode.
typedef enum {
TP_SENDING_STATE_NONE = 0,
TP_SENDING_STATE_PENDING_SEND = 1,
TP_SENDING_STATE_SENDING = 2,
TP_SENDING_STATE_PENDING_STOP_SENDING = 3,
} TpSendingState;
Enum indicating whether a contact is sending media.
Bitfield/set of flags generated from the Telepathy specification.
| The contact is not sending media and has not been asked to do so. | |
| The contact has been asked to start sending media. | |
| The contact is sending media. | |
| The contact has been asked to stop sending media. |
#define NUM_TP_SENDING_STATES TP_NUM_SENDING_STATES
1 higher than the highest valid value of TpSendingState. In new code, use TP_NUM_SENDING_STATES instead.
#define TP_NUM_SENDING_STATES (3+1)
1 higher than the highest valid value of TpSendingState.
typedef enum {
TP_STREAM_COMPONENT_UNKNOWN = 0,
TP_STREAM_COMPONENT_DATA = 1,
TP_STREAM_COMPONENT_CONTROL = 2,
} TpStreamComponent;
Media streams can use more than one UDP socket: one for RTP (data) and one for RTCP (control). Most of the time, they are adjacent to each other, but some protocols (xmpp) signal each port separately.
Bitfield/set of flags generated from the Telepathy specification.
| The stream transport type is unknown or not applicable (should not appear over dbus). | |
| This is the high-traffic data socket, containing the audio/video data for the stream. | |
| This is the low-traffic control socket, usually containing feedback about packet loss etc. |
#define NUM_TP_STREAM_COMPONENTS TP_NUM_STREAM_COMPONENTS
1 higher than the highest valid value of TpStreamComponent. In new code, use TP_NUM_STREAM_COMPONENTS instead.
#define TP_NUM_STREAM_COMPONENTS (2+1)
1 higher than the highest valid value of TpStreamComponent.
typedef enum {
TP_STREAM_ENDPOINT_STATE_CONNECTING = 0,
TP_STREAM_ENDPOINT_STATE_PROVISIONALLY_CONNECTED = 1,
TP_STREAM_ENDPOINT_STATE_FULLY_CONNECTED = 2,
TP_STREAM_ENDPOINT_STATE_EXHAUSTED_CANDIDATES = 3,
TP_STREAM_ENDPOINT_STATE_FAILED = 4,
} TpStreamEndpointState;
Represents the state of ICE negotiation for a single component of a stream to an endpoint.
Bitfield/set of flags generated from the Telepathy specification.
| Candidate gathering and connectivity checks are in progress. | |
| The streaming implementation has found at least one working candidate pair. It is possible to send media at this point, but the controlling side has yet to negotiate the final candidates for use in this call. | |
| This component of the stream is connected, and an updated offer has been sent and accepted (finalising the candidates to be used for the call). This should be set by the CM in response to AcceptSelectedCandidatePair. | |
| The streaming implementation has tried connecting to all of the available candidates and none of them have connected. This is distinct from Failed, because the CM might be able to provide more candidates later (more likely in XMPP than SIP). | |
| The CM and streaming implementation are in agreement that it is impossible to connect to this endpoint. This value should only be set by the CM. |
#define NUM_TP_STREAM_ENDPOINT_STATES TP_NUM_STREAM_ENDPOINT_STATES
1 higher than the highest valid value of TpStreamEndpointState. In new code, use TP_NUM_STREAM_ENDPOINT_STATES instead.
#define TP_NUM_STREAM_ENDPOINT_STATES (4+1)
1 higher than the highest valid value of TpStreamEndpointState.
typedef enum {
TP_STREAM_FLOW_STATE_STOPPED = 0,
TP_STREAM_FLOW_STATE_PENDING_START = 1,
TP_STREAM_FLOW_STATE_PENDING_STOP = 2,
TP_STREAM_FLOW_STATE_STARTED = 3,
} TpStreamFlowState;
The type of SendingState and ReceivingState.
Bitfield/set of flags generated from the Telepathy specification.
| No data is flowing (or expected to be flowing) at this time. | |
| The streaming implementation has been told to start or receiving, but has not yet indicated that it is doing so. | |
| The streaming implementation has been told to stop sending or receiving data, but it has not yet indicated that it has done so. | |
| The streaming implementation is successfully sending or receiving data, and everything is going swimmingly. |
#define NUM_TP_STREAM_FLOW_STATES TP_NUM_STREAM_FLOW_STATES
1 higher than the highest valid value of TpStreamFlowState. In new code, use TP_NUM_STREAM_FLOW_STATES instead.
#define TP_NUM_STREAM_FLOW_STATES (3+1)
1 higher than the highest valid value of TpStreamFlowState.
typedef enum {
TP_STREAM_TRANSPORT_TYPE_UNKNOWN = 0,
TP_STREAM_TRANSPORT_TYPE_RAW_UDP = 1,
TP_STREAM_TRANSPORT_TYPE_ICE = 2,
TP_STREAM_TRANSPORT_TYPE_GTALK_P2P = 3,
TP_STREAM_TRANSPORT_TYPE_WLM_2009 = 4,
TP_STREAM_TRANSPORT_TYPE_SHM = 5,
TP_STREAM_TRANSPORT_TYPE_MULTICAST = 6,
} TpStreamTransportType;
A transport that can be used for streaming.
Bitfield/set of flags generated from the Telepathy specification.
| The stream transport type is unknown or not applicable (for streams that do not have a configurable transport). | |
| Raw UDP, with or without STUN. All streaming clients are assumed to support this transport, so there is no handler capability token for it in the Call1 interface. [This corresponds to "none" or "stun" in the old Media.StreamHandler interface.] | |
| Interactive Connectivity Establishment, as defined by RFC 5245. Note that this value covers ICE-UDP only. [This corresponds to "ice-udp" in the old Media.StreamHandler interface.] | |
| Google Talk peer-to-peer connectivity establishment, as implemented by libjingle 0.3. [This corresponds to "gtalk-p2p" in the old Media.StreamHandler interface.] | |
| The transport used by Windows Live Messenger 2009 or later, which resembles ICE draft 19. [This corresponds to "wlm-2009" in the old Media.StreamHandler interface.] | |
| Shared memory transport, as implemented by the GStreamer shmsrc and shmsink plugins. | |
| Multicast transport. |
#define NUM_TP_STREAM_TRANSPORT_TYPES TP_NUM_STREAM_TRANSPORT_TYPES
1 higher than the highest valid value of TpStreamTransportType. In new code, use TP_NUM_STREAM_TRANSPORT_TYPES instead.
#define TP_NUM_STREAM_TRANSPORT_TYPES (6+1)
1 higher than the highest valid value of TpStreamTransportType.
typedef enum {
TP_CALL_FLAG_LOCALLY_HELD = 1,
TP_CALL_FLAG_LOCALLY_RINGING = 2,
TP_CALL_FLAG_LOCALLY_QUEUED = 4,
TP_CALL_FLAG_FORWARDED = 8,
TP_CALL_FLAG_CLEARING = 16,
} TpCallFlags;
A set of flags representing additional information than is available in CallState. Many of these flags only make sense in a particular (or may explain why a call is in a specific state).
Bitfield/set of flags generated from the Telepathy specification.
| The call has been put on hold by the local user, e.g. using the Hold interface. This flag SHOULD only be set if there is at least one Content, and all Contents are locally held. Otherwise, in transient situations where some but not all contents are on hold, UIs would falsely indicate that the call as a whole is on hold, which could lead to the user saying something they'll regret, while under the impression that the other contacts can't hear them! This flag exists as a simplified proxy for HoldStateChanged, to reduce the number of signals that need to be listened to by a simple UI. | |
| This flag exists for observability of the SetRinging method (e.g. so that loggers can tell whether the call got as far as alerting the user, or whether something went wrong before then). It should be set when the SetRinging is called, and unset when the call leaves Initialised. | |
| This flag exists for observability of the SetQueued method. It should be set when the SetQueued is called, and unset when the call leaves Initialising or Initialised. | |
| The initiator of the call originally called a contact other than the current recipient of the call, but the call was then forwarded or diverted. This flag only makes sense on outgoing calls. It SHOULD be set or unset according to informational messages from other contacts. | |
| This flag only occurs when the CallState is Ended. The call with this flag set has ended, but not all resources corresponding to the call have been freed yet. Depending on the protocol there might be some audible feedback while the clearing flag is set. In calls following the ITU-T Q.931 standard there is a period of time between the call ending and the underlying channel being completely free for re-use. |
typedef enum {
TP_CALL_MEMBER_FLAG_RINGING = 1,
TP_CALL_MEMBER_FLAG_HELD = 2,
TP_CALL_MEMBER_FLAG_CONFERENCE_HOST = 4,
} TpCallMemberFlags;
A set of flags representing the status of a remote contact in a call. It is protocol- and client-specific whether a particular contact will ever have a particular flag set on them, and Telepathy clients SHOULD NOT assume that a flag will ever be set. 180 Ringing in SIP, and its equivalent in XMPP, are optional informational messages, and implementations are not required to send them. The same applies to the messages used to indicate hold state.
Bitfield/set of flags generated from the Telepathy specification.
| The remote contact's client has told us that the contact has been alerted about the call but has not responded. This is a flag per member, not a flag for the call as a whole, because in Muji conference calls, you could invite someone and have their state be "ringing" for a while. | |
| The call member has put this call on hold. This is a flag per member, not a flag for the call as a whole, because in conference calls, any member could put the conference on hold. | |
| This contact has merged this call into a conference. Note that GSM provides a notification when the remote party merges a call into a conference, but not when it is split out again; thus, this flag can only indicate that the call has been part of a conference at some point. If a GSM connection manager receives a notification that a call has been merged into a conference a second time, it SHOULD represent this by clearing and immediately re-setting this flag on the remote contact. |
typedef enum {
TP_RTCP_XR_STATISTICS_FLAGS_LOSS = 1,
TP_RTCP_XR_STATISTICS_FLAGS_DUPLICATE = 2,
TP_RTCP_XR_STATISTICS_FLAGS_JITTER = 4,
TP_RTCP_XR_STATISTICS_FLAGS_TTL = 8,
TP_RTCP_XR_STATISTICS_FLAGS_HL = 16,
} TpRTCPXRStatisticsFlags;
Bitfield/set of flags generated from the Telepathy specification.
| Loss report flag, as defined in RFC3611 section 4.6. | |
| Duplicate report flag, as defined in RFC3611 section 4.6. | |
| Jitter flag, as defined in RFC3611 section 4.6. | |
| First bit of TTL or Hop Limit flag, as defined in RFC3611 section 4.6. | |
| Second bit of TTL or Hop Limit flag, as defined in RFC3611 section 4.6. |