|
|
The following chapter describes the Extended Web Services Binary SMS Communication Service in detail.
The Extended Web Services Binary SMS communication service allows applications to use Short Messaging to send generic binary object attachments, such as vCards. The only operation it supports is sendBinarySms. Messages can be sent to one or more destination addresses.
The actual message element is made up of an array of UDH and message parts, encoded in Base64. See 3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS); (Release 6) 3GPP 23.040 Version 6.5.0, http://www.3gpp.org/ftp/Specs/html-info/23040.htm.
This interface gives an application the flexibility to manipulate the SMPP UDH and message data. Both the UDH and message data elements are optional, but the overall element, binaryMessage, is required. The contents of the UDH and the message can be of any binary data, although any byte array should be less than 140 bytes due to SMPP limitations, and the number of BinaryMessage arrays should be less than SegmentsLimit specified in OAM. The default value is 1024.
Send Receipts are returned to the application synchronously. Send Receipts are merely acknowledgements that the network node has received the Short Message from the application by means of Network Gatekeeper. Although a single Short Message may be sent to multiple destination addresses, normally only one Send Receipt is returned to the application by Network Gatekeeper. The receipt is returned synchronously in the response message to the sendBinarySms operation.
Delivery receipt notifications can be set up using this operation, but the actual asynchronous delivery of receipts is accomplished using the Parlay X 2.1 Short Messaging interface. See Delivery Receipts for more information on receiving Delivery Receipts.
| Note: | The EWS Binary SMS communication service does not support receiving mobile originated messages. |
The Extended Web Services Binary SMS communication service supports the SMPP v3.4 network protocol. When using this protocol, Network Gatekeeper connects to an SMSC using SMPP v3.4. See “Appendix A: Standards and Specifications” in the Architectural Overview for the exact version of the standard Network Gatekeeper supports. See the WebLogic Network Gatekeeper System Administrator’s Guide for a description of how the plug-in connects to an SMPP v.3.4 compliant SMSC.
| Note: | SMPP expects the sendName value to be in ASCII characters. The use of non-ASCII characters may cause the request to become garbled or even be removed at the SMSC. |
Communication services share many common features, covered in the “Introducing Communication Services” chapter of Concepts and Architectural Overview, but each one has a few characteristics that are specific only to that service. This section describes those specific features for the Extended Web Service Binary SMS communication service, including:
There is one Binary SMS specific CDR. It occurs when the following criterion is met:
The following is the sole EdrId created by the EWS Binary SMS/SMPP communication service. This list does not include EDRs created when exceptions are thrown. For more information, seeEvents, Alarms, and Charging..
The following is a list of EdrIds used by the EWS Binary SMS/SMPP communication service that are inherited from the Parlay X 2.1/SMPP communication service:
The table below outlines the correlation between the methods being invoked from either the application (in application-initiated requests) or the telecom network (in network-initiated requests) and the transaction type collected by the statistics counters in Network Gatekeeper for the EWS Binary SMS communication service:
| Note: | Method names for network-initiated requests are specified by the internal Gatekeeper name, which is not necessarily the same as the message from the network. |
The EWS Binary SMS communication service supports the tel: address scheme.
|