The absence of a entity, Contact, Room, etc. For instance, ContactSearch1, RoomList1, ServerAuthentication1 and ServerTLSConnection1 channels do not communicate with a specific entity, so they have this channel type. This entity type is also used for chatrooms that cannot be addressed by name (so users cannot join by typing a name or number, only by being invited), such as multi-user "switchboards" in MSNP. Where this appears alongside a Handle and/or Identifier, the handle MUST be 0 and the identifier MUST be the empty string.

A contact, i.e. a person or automated system. The corresponding identifier is a normalized form of the contact's unique machine-readable identifier in this particular protocol (such as an XMPP JID, SIP URI, AIM screen-name, ICQ number or IRC nickname). For instance, any parts of the identifier that are defined to be case-insensitive by the protocol SHOULD be normalized to lower-case. In protocols where conferencing systems cannot reliably be distinguished from individuals, conferencing systems MAY also appear with Contact. For instance, calls to/from SIP teleconferencing "rooms" typically appear as a simple SIP URI

A chatroom or teleconferencing system that can be addressed by name. The corresponding identifier is a normalized form of the room's unique machine-readable identifier in this particular protocol, such as the JID "jdev@conference.jabber.org" on XMPP, or the channel name "#telepathy" on IRC.

Not used within Telepathy itself, but reserved for use by telepathy-logger. telepathy-logger uses this type to represents the owner of the account whose channel has been logged to. We don't need this concept in Telepathy itself but it's convenient to use the same enum across the whole API.

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; 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 Cellular1 preferences.

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 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.

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 im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.Error.NetworkError, im.telepathy.v1.Error.ConnectionRefused, im.telepathy.v1.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 im.telepathy.v1.Error.NetworkError, im.telepathy.v1.Error.ConnectionLost or some more specific error.

The username or password was invalid. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.Error.EncryptionNotAvailable if encryption was not available at all, or im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.Error.Cert.Untrusted.

The server's SSL certificate has expired. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.Error.Cert.Expired.

The server's SSL certificate is not yet valid. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.Error.Cert.NotActivated.

The server's SSL certificate did not match its hostname. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.Error.Cert.FingerprintMismatch.

The server's SSL certificate is self-signed. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.Error.Cert.Invalid.

The server's SSL certificate has been revoked. When disconnected for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.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 im.telepathy.v1.Error.Cert.LimitExceeded

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.

An invalid presence type used as a null value. This value MUST NOT appear in the Statuses property.

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.

0

1

2

3

4

5

6

7

8

9

*

#

A

B

C

D

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

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. See Message_Part for the format that delivery reports must take.

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.

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 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 (i.e. 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 calls to the now-removed GetHandleOwners method, before we introduced the HandleOwners property and HandleOwnersChanged signal.

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.

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 and users leaving a chatroom by their own request. If the SelfHandle is removed from a group for this reason and the actor is not the SelfHandle, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.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 handle is removed from a group for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.Error.Channel.Kicked.

The change is due to a busy indication. If the SelfHandle is removed from a group for this reason, the equivalent D-Bus error is im.telepathy.v1.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 im.telepathy.v1.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, 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. If a contact is removed from a group for this reason, the equivalent D-Bus error is im.telepathy.v1.Error.DoesNotExist.

The change is because the requested contact did not respond. If a contact is removed from a group for this reason, the equivalent D-Bus error is im.telepathy.v1.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 Renaming1 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 im.telepathy.v1.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 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.

The ProvidePassword method must be called now for the user to join the channel

The RoomConfig1.PasswordHint contains a hint for the password.

When calling BlockContacts, the contacts may be reporting as abusive to the server administrators by setting Report_Abusive to True.

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.

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.

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.

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.

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.

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 StreamTube1 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 <link linkend="sendmsg"><function>sendmsg()</function></link> 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 DBusTube1 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.

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.

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.

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

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 whose publish state is Yes, i.e. those who can normally see the local user's presence. The associated variant in Access_Control is ignored.

Only allow contacts that are in a certain user-defined group, as configured by the ContactGroups1 interface. The associated variant in Access_Control is a string (D-Bus type 's'), the name of a contact group.

Allow all contacts. The associated variant in Access_Control is ignored.

Allow contacts whose subscribe and/or publish state is Yes, i.e. those whose presence can normally be seen by the local user, and those who can normally see the local user's presence. 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.

No hash.

MD5 digest as a string of 32 ASCII hex digits.

SHA1 digest as a string of ASCII hex digits.

SHA256 digest as a string of ASCII hex digits.

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.

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.

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.

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.

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.

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.

Indicates that setting your own location with SetLocation is supported on this connection.

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).

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.

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.

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.

The certificate is currently waiting to be accepted or rejected.

The certificate has been verified.

The certificate has been rejected.

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.

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.

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.

Use the GET method when opening the URL.

Use the POST method when opening the URL. Refer to HTTP_Post_Data for more details.

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.

The server sent an invalid challenge or data.

The user aborted the authentication.

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.

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.

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.

This captcha mechanism is required to be successfully answered in order to pass this captcha challenge.

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.

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.

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.

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

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.

Both RTP data senders and data receivers MAY send DLRR blocks.

Only active RTP senders MAY send DLRR blocks, i.e., non RTP senders SHALL NOT send DLRR blocks.

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.

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.

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.

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.

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.

The call has been put on hold by the local user, e.g. using the Hold1 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.

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.

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.

UDP (User Datagram Protocol)

TCP (Transmission Control Protocol)

Media are not being sent or received

Media are being sent, but not received

Media are being received, but not sent

Media are being sent and received

An audio stream

A video stream