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
A handler for class 0 SMSes should advertise the following filter:
{ ...ChannelType :
...Text ,
...TargetHandleType :
Contact ,
...SMS1.Flash :
True,
}It should also set its True, so that it is invoked immediately for new
channels.
Contacts to whom SMSes can be sent SHOULD indicate this via a
requestable channel class with
For instance, a contact that can accept both text and SMS channels:
[
({ ...ChannelType :
...Text ,
...TargetHandleType :
Contact ,
},
[ ...TargetHandle ,
...TargetID ]),
({ ...ChannelType :
...Text ,
...TargetHandleType :
Contact ,
...SMSChannel : True,
},
[ ...TargetHandle ,
...TargetID ]),
]
If True, then this channel is exclusively for
receiving class 0 SMSes (and no SMSes can be sent using 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.
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
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 True are read-only.
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
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,
}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).
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
Returns the number of 140 octet chunks required to send a message via SMS, as well as the number of remaining characters available in the final chunk and, if possible, an estimate of the cost.
There are a number of different SMS encoding mechanisms, and the client doesn't know which mechanisms an individual CM might support. This method allows the client, without any knowledge of the encoding mechanism, to provide length details to the user.
Clients SHOULD limit the frequency with which this method is called and SHOULD NOT call it for every keystroke. Clients MAY estimate the remaining size between single keystrokes.
The number of 140 octet chunks required to send this message.
For example, in the GSM standard 7-bit encoding, a 162 character message would require 2 chunks.
The number of further characters that can be fit in the final
chunk. A negative value indicates that the message will be
truncated by abs(Remaining_Characters). The value
MIN_INT32 (-231)
indicates the message will be truncated by an unknown amount.
For example, in the GSM standard 7-bit encoding, a 162 character message would return 144 remaining characters (because of the space required for the multipart SMS header).
The estimated cost of sending this message. The currency and
scale of this value are the same as the
A value of -1 indicates the cost could not be
estimated.