Interface Channel.Interface.SMS

Interface Index (Compact) | Summary | Description | Signals | Properties

Signals

SMSChannelChanged (b: SMSChannel)

Properties

Flash b Read only Immutable
SMSChannel b Read only Sometimes immutable, Requestable
Added in 0.19.12. Imported from rtcom-telepathy-glib, with the unused properties removed and the documentation tidied up.
Objects implementing this interface must also implement:

Description

This interface contains SMS-specific properties for text channels.

The presence of this interface on a channel does not imply that messages will be delivered via SMS.

This interface MAY appear in the Interfaces property of channels where SMSChannel would be immutable and false. It SHOULD appear on channels where SMSChannel is immutable and true, and also on channels where SMSChannel is mutable (i.e. channels that might fall back to sending SMS at any time, such as on MSN).

Handler filters

A handler for class 0 SMSes should advertise the following filter:

{ ...ChannelType: ...Text,
  ...TargetHandleType: Handle_Type_Contact,
  ...SMS.Flash: True,
}

It should also set its BypassApproval property to True, so that it is invoked immediately for new channels.

Signals

(Permalink)

SMSChannelChanged (b: SMSChannel)

Added in UNRELEASED.

Parameters

This signal indicates a change in the SMSChannel property.

Properties

Accessed using the org.freedesktop.DBus.Properties interface.
(Permalink)

Flash — b

Read only
This property is immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals.

If True, then this channel is exclusively for receiving class 0 SMSes (and no SMSes can be sent using SendMessage on this channel). If False, no incoming class 0 SMSes will appear on this channel.

This property is immutable (cannot change), and therefore SHOULD appear wherever immutable properties are reported, e.g. NewChannels signals.

Rationale:

Class 0 SMSes should be displayed immediately to the user, and need not be saved to the device memory unless the user explicitly chooses to do so. This is unlike “normal”, class 1 SMSes, which must be stored, but need not be shown immediately in their entirity to the user.

Separating class 0 SMSes into their own channel with this immutable property allows them to be dispatched to a different Handler—which would include this property in its HandlerChannelFilter—avoiding the normal Text channel handler having to decide for each message whether it should be displayed to the user immediately or handled normally.

Currently, no mechanism is defined for sending class 0 SMSes. It seems reasonable to support specifying the class of an outgoing SMS in its header Message_Part, rather than requiring the UI to request a special channel for such SMSes; hence, we define here that channels with Flash set to True are read-only.

(Permalink)

SMSChannel — b

Read only
Depending on the protocol, this property may be immutable which means that it can never change once the channel has been created. Immutable properties SHOULD appear in the channel detail list of NewChannels signals.
This property is requestable, which means that it is allowed in the properties hash of a channel request such as in the CreateChannel and EnsureChannel methods on Requests and ChannelDispatcher. The property should also appear in either the Fixed_Properties or Allowed_Properties of a RequestableChannelClass advertised by the CM.
Added in UNRELEASED.

If TRUE, messages sent and received on this channel are transmitted via SMS.

If this property is included in the channel request, the Connection Manager MUST return an appropriate channel (i.e. if TRUE the channel must be for SMSes, if FALSE it must not), or else fail to provide the requested channel with the NotCapable error.

For example, to explicitly request an SMS channel to a contact. You might construct a channel request like:

{
  Channel.Type: Channel.Type.Text,
  Channel.TargetHandleType: Handle_Type_Contact,
  Channel.TargetID: escher.cat,
  Channel.Interface.SMS.SMSChannel: True,
}
Rationale:
Some protocols allow us to send SMSes to a remote contact, without knowing the phone number to which those SMSes will be sent. This provides a mechanism to request such channels.

If this property is not included in the channel request, the Connection Manager MAY return an SMS channel if that is the most appropriate medium (i.e. if the channel target is a phone number).

Rationale:
To some types of identifiers (i.e. phone numbers) it only makes sense to return an SMS channel, this is what happens currently with telepathy-ring. We don't want to break this behaviour when we are not explicit about the type of channel we want. Alternatively, for protocols where there is an SMS fallback for IM messages, it's possible that we don't care what sort of channel we get, and simply want notification of the transport.

Some protocols have a fallback to deliver IM messages via SMS. On these protocols, the Connection Manager SHOULD set the property value as appropriate, and notify its change with SMSChannelChanged.

Rationale:
Protocols such as MSN can fall back to delivering IM messages via SMS. Where possible we want clients to be able to inform the user that their messages are going to be redirected to the remote contact's phone.