# Communication Service Reference

# Extended Web Services Binary SMS Communication Service

This chapter describes the Extended Web Services Binary SMS Communication Service in detail.

- An Overview of the EWS Binary SMS Communication Service

- Supported Network Protocols

- Configuration Specifics for the EWS Binary SMS Communication Service

- Charging Data Records
- Event Data
- Statistics
- Supported Address Schemes

## An Overview of the EWS Binary SMS Communication Service

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:

- Send short messages with binary attachments to one or more destination addresses
- Subscribe and unsubscribe for network-triggered binary short messages with binary attachments
- Receive network-triggered short messages with binary attachments

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.

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

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 `sendBinarySms` operation.

#### Delivery Receipts

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.

### Supported Network Protocols

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. See “Appendix A: Standards and Specifications” in 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.

## Configuration Specifics for the EWS Binary SMS Communication Service

Communication services share many common features, covered in “Introducing Communication Services” in 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:

- Charging Data Records
- Event Data
- Statistics
- Supported Address Schemes

### Charging Data Records

There are two Binary SMS specific CDRs. They occur when the following criteria are met:

- After a `sendBinarySms` is sent from Oracle Communications Services Gatekeeper to the network
- When a network-triggered message has been successfully delivered to the application.

### Event Data

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-1 Event types emitted in the Binary SMS /SMPP communication service
EdrId | Method Called
--- | ---
7101 | sendBinarySms
7201 | startBinarySmsNotification
7202 | stopBinarySmsNotification
7203 | receivedMobileOriginatedBinarySMS
7205 | notifyBinarySmsReception

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-2 Inherited event types emitted in the Binary SMSBinary SMS /SMPP communication service
EdrId | Method Called
--- | ---
7005 | sendSubmit
7009 | sendSubmitMulti
7010 | sendCancel

### Statistics

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.

Table 8-3 Transaction types for EWS Binary SMS communication service
Method | Transaction type
--- | ---
sendBinarySMS | TRANSACTION_TYPE_MESSAGING_SEND
receivedMobileOriginatedBinarySMS | TRANSACTION_TYPE_MESSAGING_RECEIVE

### Supported Address Schemes

The EWS Binary SMS communication service supports the`tel:` address scheme.