Oracle® Communications Services Gatekeeper Statement of Compliance Release 5.1 E37532-01 |
|
|
PDF · Mobi · ePub |
The following chapter describes the standard Oracle Communications Services Gatekeeper (Services Gatekeeper) Parlay X 2.1 Short Messaging communication services and how the interfaces and protocols comply to standards.
This section describes the standards compliance for the communication services for Parlay X 2.1:
The Parlay X 2.1 interface complies with ETSI ES 202 391-4 V1.2.1 (2006-12) Open Service Access (OSA); Parlay X Web Services; Part 4: Short Messaging (Parlay X 2).
See
ftp://ftp.3gpp.org/Specs/archive/29_series/29.199-04/29199-04-650.zip
for links to the specification.
Table 5-1 Statement of Compliance, Parlay X 2.1 Short Messaging
Method | Compliant(Yes | No) | Comment |
---|---|---|
Interface: SendSms |
||
sendSms |
Y |
|
sendSmsLogo |
Y |
Note: The image is not scaled. |
sendSmsRingtone |
Y |
Note: Ringtones must be in either SmartMessaging or EMS (iMelody) format |
getSmsDeliveryStatus |
Y |
|
Interface: SmsNotification |
||
notifySmsReception |
Y |
|
notifySmsDeliveryReceipt |
Y |
|
Interface: ReceiveSms |
||
getReceivedSms |
Y |
|
Interface: SmsNotificationManager |
||
startSmsNotification |
Y |
|
stopSmsNotification |
Y |
The SMPP v3.4 plug-in for Parlay X 2.1 Short Messaging and for the Extended Web Services (Binary SMS) acts as an External Short Message Entity (ESME) that connects to an SMSC over TCP/IP.
The plug-in instance binds itself to the SMSC either as ESME Transmitter and an ESME Receiver or as an ESME Transceiver.
The bindings occurs when the plug-in transitions from state inactive to active. It will not reach state active until it has bound. The plug-in unbinds itself prior to becoming inactive.
When an application sends an SMS with one recipient submit_sm PDU is used and when sending an SMS with 2 or more recipients submit_sm_multi is used.
Window size is configurable.
For application-initiated requests, the plug-in supports segmented SMSs using either 7-, 8-, or 16 bit data coding. The maximum length of an SMS segment is:
160 Characters for 7 bit data coding (SMSC default alphabet).
140 Characters for 8 bit data coding (ASCII).
70 Characters for 16bit coding (UCS2).
For network-triggered requests, the plug-in supports segmented SMSs in the same way as for application-initiated requests if the SMPP parameter short_message contains the user data. If short_message is empty the parameter message_payload, which can contain up to 64KB of data, is used.
For network-triggered requests, the SMS is propagated to the application via the Parlay X Short Messaging interface if the SMPP parameter data_coding equals 0x00, 0x01, 0x03, 0x05, 0x06, 0x07, 0x08, 0x0A, 0x0D, or 0x0E. In other cases, the SMS is forwarded to the application via the Binary SMS interface.
The plug-in complies to Short Message Peer to Peer, Protocol Specification v3.4, Document Version:- 12-Oct-1999 Issue 1.2.
Table 5-2 Statement of Compliance, SMPP v3.4 for Parlay X 2.1 Short Messaging
Protocol Data Units (PDUs) | Compliant(Yes | No) | Comment |
---|---|---|
Plug-in originated PDUs: |
||
bind_transmitter |
Y |
|
bind_receiver |
Y |
|
unbind |
Y |
|
submit_sm |
Y |
|
submit_multi |
Y |
|
deliver_sm_resp |
Y |
|
cancel_sm |
Y |
|
enquire_link |
Y |
|
enquire_link_resp |
Y |
|
generic_nack |
Y |
|
bind_transceiver |
Y |
|
data_sm |
N |
|
data_sm_resp |
N |
|
query_sm |
N |
|
replace_sm |
N |
|
SMSC originated PDUs: |
||
bind_transmitter_resp |
Y |
|
bind_receiver_resp |
Y |
|
unbind_resp |
Y |
|
submit_sm_resp |
Y |
esm_classes:
|
submit_multi_resp |
Y |
|
deliver_sm |
Y |
|
cancel_sm_resp |
Y |
|
enquire_link |
Y |
|
enquire_link_resp |
Y |
|
generic_nack |
Y |
|
bind_transceiver_resp |
Y |
|
outbind |
N |
|
data_sm |
N |
|
data_sm_resp |
N |
|
query_sm_resp |
N |
|
replace_sm_resp |
N |
|
alert_notification |
N |
The Parlay X 2.1 Short Messaging and EWS Binary SMS communication services support the following features, which are defined in the Short Message Peer-to-Peer Protocol Specification, Version 5.1. Services Gatekeeper supports these features as tunneled parameters.
Table 5-3 Statement of Compliance for Version 5.1 Features
Parameter | Section in Specification | Comments |
---|---|---|
billing_identification |
4.8.4.3 |
|
ussd_service_operation |
4.8.4.64 |
Version 5.1 added support to deliver_sm for bidrectional USSD. |
interface_version |
4.7.13 |
The Native SMPP Service accepts 5.1 as well as 3.4 as the interface version number. |