This 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 and receive generic binary object attachments, such as vCards. An application can:
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”,.
The send message operation 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 the SegmentsLimit specified in OAM. The default value is 1024.
The notification operation gives the application access to an array of SMPP UDHs, the SMPP DCS, the protocol identifier according to 3GPP 23.040 Version 6.5.0, and other data such as sender address, destination address and timestamp of the message.
Send receipts are returned to the application synchronously. Send receipts are acknowledgements that the network node has received the short message from the application by means of Oracle Communications Services Gatekeeper. Although a single short message may be sent to multiple destination addresses, normally only one send receipt is returned to the application by Oracle Communications Services Gatekeeper. The receipt is returned synchronously in the response message to the
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 in Parlay X 2.1 Short Messaging Communication Service for more information on receiving delivery receipts.
The Extended Web Services Binary SMS communication service supports the SMPP v3.4 network protocol. When using this protocol, Oracle Communications Services Gatekeeper connects to an SMSC using SMPP v3.4. Seein Concepts and Architectural Overview for the exact version of the standard Oracle Communications Services Gatekeeper supports. See Oracle Communications Services 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 sender name 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 inin 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 are two Binary SMS specific CDRs. They occur when the following criteria are met:
Table 8-1 lists EDR IDs created by the EWS Binary SMS/SMPP communication service. This list does not include EDRs created when exceptions are thrown. For more information, see Events, Alarms, and Charging..
Table 8-2 lists EDR IDs used by the EWS Binary SMS/SMPP communication service that are inherited from the Parlay X 2.1/SMPP communication service:
Table 8-3 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 Oracle Communications Services 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.