Nine functions of brew SDK: telecommunications services

Direct delivery of telecommunications services is a major feature of brew technology. The telecom services supported by brew mainly refer to the speech service, the short message function, the Bluetooth communication function, and the multicast communication function of the residential area. Before brew3.x, both the voice and text message functions can be provided through the itapi. This method is also limited in brew 3.x and later versions.

Itapi is a simple device call layer interface. It provides the following services: get the call status, arrange voice calls, extract SMS text from the SMS message, get the incoming or calling caller number, and register the SMS message, send SMS messages. Itapi allows applications to register the following notifications: nmask_tapi_status, nmask_tapi_sms_text, and nmask_tapi_sms_ts.

Applications can receive SMS messages through the itapi:

1. The target is the targeted SMS message of the BREW application, which is sent in the form of // brew: <classid >:< message>. When the classid of the target application is specified, itapi_sendsms () formats the message internally.

2. All text messages

3. All messages with specific telecom service IDS

4. All text messages with a specific prefix

Among them, you do not need to register the SMS to receive the SMS pointing to the application and receive it as the evt_app_message event. dwparam contains the pointer to the SMS payload, which can be used as char * pszmsgtxt = (char *) dwparam.

For access to receive arbitrary text messages, the application must use the nmask_tapi_sms_text mask to register the TAPI class for receiving the evt_policy event. dwparam contains a pointer to aeenotify. The message can be used as aeenotecx * pnotify = (aeenotecx *) dwparam; aeesmstextmsg * ptextmsg = (aeesmstextmsg *) pnotify-> pdata;

If the application receives a specific telecom service message, it must use the following mask uint32 mask = (nmask_tapi_sms_ts | (sms_teleservice_id <16) for registration and receive it as an evt_notify event, dwparam contains a pointer to aeenoworkflow. It can be used as aeenoworkflow * py y = (aeenoworkflow *) dwparam; aeesmsmsg * PMSG = (aeesmsmsg *) pnotify-> pdata;

If you access and receive text messages with a specific Prefix: the message format is // <sms_prefix >:< message_text>, the application must register as a <sms_prefix> handler and receive the messages as evt_app_browse_url. Dwparam contains a pointer to // <sms_prefix >:< message_text>.

You can use the itapi in brew to know the change of the device status. With the nmask_tapi_status mask, applications can use the TAPI class to receive notifications as long as the call status of the device changes. As long as the status changes, the application will receive the evt_policy event. The dwparam of this event is of the aeenoworkflow type. The pdata Member in this aeenoworkflow structure belongs to the tapistatus type and contains details about the current call status of the device.

Brew 3.x provides a new interface ismsmsg, isms, ismsnotifier, and the new interface ismsstorage fully implements the SMS protocol TIA-EIA-637-A, while the old interface only partially implements this protocol. For text message sending, the new interface mainly supports the following three encoding formats:

L ascii-unit: byte; maximum length: 160

L uncode-unit: double byte, maximum length: 70

L Binary-unit: byte, maximum length: 140

The original interface only supports one encoding format, which is specified by aee_deviceitem_tapi_sms_encoding. For SMS receiving, the new interface can get more information: the text message content/encoding format, the sender's number, and the time when the SMS center receives the text message. The old interface can only get the text message content. Ismsstorage & ismsstorage2 is used to store, read, delete, and update text messages. The Storage types include the Ruim card and the mobile phone itself.

Brew 3.x and later versions also provide complete support for General voice payment, Bluetooth, and WiFi, so that applications can gain a wider range of communication capabilities.

 

This article from the csdn blog, reproduced please indicate the source: http://blog.csdn.net/wireless_com/archive/2010/04/07/5456725.aspx