This is an automated email from the ASF dual-hosted git repository.
orpiske pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
commit 2de023fd8fac7c588595282c6b86255a9717d47d
Author: Otavio Rodolfo Piske <angusyo...@gmail.com>
AuthorDate: Wed Feb 21 18:04:50 2024 +0100
CAMEL-20410: documentation fixes for camel-smpp
- Fixed samples
- Fixed grammar and typos
- Fixed punctuation
- Added and/or fixed links
- Converted to use tabs
---
.../camel-smpp/src/main/docs/smpp-component.adoc | 54 ++++++++++++----------
1 file changed, 29 insertions(+), 25 deletions(-)
diff --git a/components/camel-smpp/src/main/docs/smpp-component.adoc
b/components/camel-smpp/src/main/docs/smpp-component.adoc
index a1e6748b640..5e71a77e616 100644
--- a/components/camel-smpp/src/main/docs/smpp-component.adoc
+++ b/components/camel-smpp/src/main/docs/smpp-component.adoc
@@ -25,8 +25,8 @@ The Camel component currently operates as an
http://en.wikipedia.org/wiki/ESME[ESME] (External Short Messaging
Entity) and not as an SMSC itself.
-You are also able to execute ReplaceSm,
-QuerySm, SubmitMulti, CancelSm and DataSm.
+You are also able to execute `ReplaceSm`,
+`QuerySm`, `SubmitMulti`, `CancelSm`, and `DataSm`.
Maven users will need to add the following dependency to their `pom.xml`
for this component:
@@ -43,12 +43,12 @@ for this component:
== SMS limitations
-SMS is neither reliable or secure. Users who require reliable and
+SMS is neither reliable nor secure. Users who require reliable and
secure delivery may want to consider using the XMPP or SIP components
instead, combined with a smartphone app supporting the chosen protocol.
* Reliability: although the SMPP standard offers a range of feedback
-mechanisms to indicate errors, non-delivery and confirmation of delivery
+mechanisms to indicate errors, non-delivery and confirmation of delivery,
it is not uncommon for mobile networks to hide or simulate these
responses. For example, some networks automatically send a delivery
confirmation for every message even if the destination number is invalid
@@ -62,11 +62,11 @@ authenticated in any other part of the network. Some
operators allow
staff in retail outlets or call centres to browse through the SMS
message histories of their customers. Message sender identity can be
easily forged. Regulators and even the mobile telephone industry itself
-has cautioned against the use of SMS in two-factor authentication
+ have cautioned against the use of SMS in two-factor authentication
schemes and other purposes where security is important.
While the Camel component makes it as easy as possible to send messages
-to the SMS network, it can not offer an easy solution to these problems.
+to the SMS network, it cannot offer an easy solution to these problems.
== Data coding, alphabet and international character sets
@@ -77,12 +77,13 @@ component acts when more than one value is set.
Data coding is an 8 bit field in the SMPP wire format.
-Alphabet corresponds to bits 0-3 of the data coding field. For some
-types of message, where a message class is used (by setting bit 5 of the
+The alphabet corresponds to bits 0–3 of the data coding field.
+For some types of message, where a message class is used (by setting bit 5 of
the
data coding field), the lower two bits of the data coding field are not
-interpreted as alphabet and only bits 2 and 3 impact the alphabet.
+interpreted as alphabet.
+Only bits 2 and 3 impact the alphabet.
-Furthermore, current version of the JSMPP library only seems to support
+Furthermore, the current version of the JSMPP library only seems to support
bits 2 and 3, assuming that bits 0 and 1 are used for message class.
This is why the Alphabet class in JSMPP doesn't support the value 3
(binary 0011) which indicates ISO-8859-1.
@@ -108,19 +109,20 @@ array, the Camel SMPP component does not consider the
data coding value
(header or configuration), it only considers the specified alphabet
(from either the header or endpoint parameter).
-If some characters in the String can not be represented in the chosen
-alphabet, they may be replaced by the question mark ( ? ) symbol. Users
-of the API may want to consider checking if their message body can be
+If some characters in the String cannot be represented in the chosen
+alphabet, they may be replaced by the question mark (`?`) symbol.
+Users of the API may want to consider checking if their message body can be
converted to ISO-8859-1 before passing it to the component and if not,
-setting the alphabet header to request UCS-2 encoding. If the alphabet
-and data coding options are not specified at all then the component may
+setting the alphabet header to request UCS-2 encoding.
+If the alphabet
+and data coding options are not specified at all, then the component may
try to detect the required encoding and set the data coding for you.
-The list of alphabet codes are specified in the SMPP specification v3.4,
+The list of alphabet codes is specified in the SMPP specification v3.4,
section 5.2.19. One notable limitation of the SMPP specification is
that there is no alphabet code for explicitly requesting use of the GSM
-3.38 (7 bit) character set. Choosing the value 0 for the alphabet
-selects the SMSC _default_ alphabet, this usually means GSM 3.38 but it
+3.38 (7-bit) character set. Choosing `0` for the alphabet
+selects the SMSC _default_ alphabet, this usually means GSM 3.38, but it
is not guaranteed. The SMPP gateway Nexmo
https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-[actually
allows the default to be mapped to any other character set with a
@@ -136,10 +138,11 @@ Camel component is also responsible for splitting the
message into parts
is completed automatically.
If the GSM 3.38 alphabet is used, the component will pack up to 160
-characters into the 140 byte message body. If an 8 bit character set is
-used (e.g. ISO-8859-1 for western Europe) then 140 characters will be
-allowed within the 140 byte message body. If 16 bit UCS-2 encoding is
-used then just 70 characters fit into each 140 byte message.
+characters into the 140-byte message body.
+If an 8-bit character set is used (e.g., ISO-8859-1 for Western Europe), then
140 characters will be
+allowed within the 140-byte message body.
+If 16 bit UCS-2 encoding is
+ used, then just 70 characters fit into each 140-byte message.
Some SMSC providers implement throttling rules. Each part of a message
that has been split may be counted separately by the provider's
@@ -201,7 +204,7 @@ When the SMPP consumer receives a `DeliverSm` or
can also throw a `ProcessRequestException` instead of handle the
failure. In this case, this exception is forwarded to the underlying
http://jsmpp.org[JSMPP library] which will return the included error
-code to the SMSC. This feature is useful to e.g. instruct the SMSC to
+code to the SMSC. This feature is useful to e.g., instruct the SMSC to
resend the short message at a later time. This could be done with the
following lines of code:
@@ -272,10 +275,11 @@
from("direct:messageReceiver").id("sampleMessageReceiverRouteId")
--------------------------------------------------------------------------------------------------------------------------
Please note that with TRX binding type, you wouldn't define a corresponding
redundant SMPP consumer. Camel will use the
-specified route by `messageReceiverRouteId` as the corresponding consumer.
Internally it uses one and same SmppSession
+specified route by `messageReceiverRouteId` as the corresponding consumer.
Internally, it uses one and same SmppSession
as producer for the provided consumer.
-When the SMPP Server doesn't support TRX then you have to define separate
producer (TX by default) and consumer (RX by default).
+When the SMPP Server doesn't support TRX,
+then you have to define separate producer (TX by default) and consumer (RX by
default).
[TIP]
====
