camel-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From build...@apache.org
Subject svn commit: r929879 - in /websites/production/camel/content: book-component-appendix.html book-in-one-page.html cache/main.pageCache smpp.html
Date Thu, 20 Nov 2014 17:19:36 GMT
Author: buildbot
Date: Thu Nov 20 17:19:36 2014
New Revision: 929879

Log:
Production update by buildbot for camel

Modified:
    websites/production/camel/content/book-component-appendix.html
    websites/production/camel/content/book-in-one-page.html
    websites/production/camel/content/cache/main.pageCache
    websites/production/camel/content/smpp.html

Modified: websites/production/camel/content/book-component-appendix.html
==============================================================================
--- websites/production/camel/content/book-component-appendix.html (original)
+++ websites/production/camel/content/book-component-appendix.html Thu Nov 20 17:19:36 2014
@@ -1529,11 +1529,11 @@ template.send("direct:alias-verify&
                     </div>
     </div>
 <p>The <strong>cxf:</strong> component provides integration with <a
shape="rect" href="http://cxf.apache.org">Apache CXF</a> for connecting to JAX-WS
services hosted in CXF.</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1416500271918 {padding: 0px;}
-div.rbtoc1416500271918 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1416500271918 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1416503840638 {padding: 0px;}
+div.rbtoc1416503840638 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1416503840638 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1416500271918">
+/*]]>*/</style></p><div class="toc-macro rbtoc1416503840638">
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-CXFComponent">CXF
Component</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-URIformat">URI
format</a></li><li><a shape="rect" href="#CXF-Options">Options</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-Thedescriptionsofthedataformats">The
descriptions of the dataformats</a>
@@ -11545,7 +11545,7 @@ protected RouteBuilder createRouteBuilde
     &lt;!-- use the same version as your Camel core version --&gt;
 &lt;/dependency&gt;
 ]]></script>
-</div></div><h3 id="BookComponentAppendix-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipi
 ent handset.&#160; SMS messages are not encrypted or authenticated in any other part
of the network.&#160; Some operators allow staff in retail outlets or call centres to
browse through the SMS message histories of their customers.&#160; Message sender identity
can be easily forged.&#160; Regulators and even the mobile telephone industry itself has
cautioned against the use of SMS in two-factor authentication schemes and other purposes where
security is important.</li></ul><p>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.</p><h2 id="BookComponentAppendix-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component act
 s when more than one value is set.</p><p>Data coding is an 8 bit field in the
SMPP wire format.</p><p>Alphabet corresponds to bits 0-3 of the data coding field.&#160;
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.</p><p>Furthermore, 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.&#160; This is why the Alphabet class in JSMPP doesn't support the value 3 (binary
0011) which indicates ISO-8859-1.</p><p>Although JSMPP provides a representation
of the message class parameter, the Camel component doesn't currently provide a way to set
it other than manually setting the corresponding bits in the data coding field.</p><p>When
setting the data coding field in the outgoing message, the Camel component considers the following
values and uses th
 e first one it can find:</p><ul><li>the data coding specified in a header</li><li>the
alphabet specified in a header</li><li>the data coding specified in the endpoint
configuration (URI parameter)</li></ul><p>Older versions of Camel had bugs
in support for international character sets.&#160; This feature only worked when a single
encoding was used for all messages and was troublesome when users wanted to change it on a
per-message basis.&#160; Users who require this to work should ensure their version of
Camel includes the fix for&#160;</p><div class="error">Error rendering macro
'jira' : com.atlassian.confluence.macro.MacroExecutionException: java.lang.RuntimeException:
Not Found</div>.<p>In addition to trying to send the data coding value to the
SMSC, the Camel component also tries to analyze the message body, convert it to a Java String
(Unicode) and convert that to a byte array in the corresponding alphabet&#160; When deciding
which alphabet to use in the byte array, the Camel S
 MPP component does not consider the data coding value (header or configuration), it only
considers the specified alphabet (from either the header or endpoint parameter).</p><p>If
some characters in the String can't be represented in the chosen alphabet, they may be replaced
by the question mark ( ? ) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are
specified in the SMPP specification v3.4, section 5.2.19.&#160; 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.&#160; Choosing the value 0 for the alphabet selects
the SMSC <e
 m>default</em> alphabet, this usually means GSM 3.38 but it is not guaranteed.&#160;
The SMPP gateway Nexmo <a shape="rect" class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="BookComponentAppendix-URIformat.62">URI
format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><h3 id="BookComponentAppendix-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipi
 ent handset.&#160; SMS messages are not encrypted or authenticated in any other part
of the network.&#160; Some operators allow staff in retail outlets or call centres to
browse through the SMS message histories of their customers.&#160; Message sender identity
can be easily forged.&#160; Regulators and even the mobile telephone industry itself has
cautioned against the use of SMS in two-factor authentication schemes and other purposes where
security is important.</li></ul><p>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.</p><h2 id="BookComponentAppendix-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component act
 s when more than one value is set.</p><p>Data coding is an 8 bit field in the
SMPP wire format.</p><p>Alphabet corresponds to bits 0-3 of the data coding field.&#160;
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.</p><p>Furthermore, 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.&#160; This is why the Alphabet class in JSMPP doesn't support the value 3 (binary
0011) which indicates ISO-8859-1.</p><p>Although JSMPP provides a representation
of the message class parameter, the Camel component doesn't currently provide a way to set
it other than manually setting the corresponding bits in the data coding field.</p><p>When
setting the data coding field in the outgoing message, the Camel component considers the following
values and uses th
 e first one it can find:</p><ul><li>the data coding specified in a header</li><li>the
alphabet specified in a header</li><li>the data coding specified in the endpoint
configuration (URI parameter)</li></ul><p>Older versions of Camel had bugs
in support for international character sets.&#160; This feature only worked when a single
encoding was used for all messages and was troublesome when users wanted to change it on a
per-message basis.&#160; Users who require this to work should ensure their version of
Camel includes the fix for&#160;</p><div class="error">Error rendering macro
'jira' : com.atlassian.confluence.macro.MacroExecutionException: java.lang.RuntimeException:
Not Found</div>.<p>In addition to trying to send the data coding value to the
SMSC, the Camel component also tries to analyze the message body, convert it to a Java String
(Unicode) and convert that to a byte array in the corresponding alphabet&#160; When deciding
which alphabet to use in the byte array, the Camel S
 MPP component does not consider the data coding value (header or configuration), it only
considers the specified alphabet (from either the header or endpoint parameter).</p><p>If
some characters in the String can't be represented in the chosen alphabet, they may be replaced
by the question mark ( ? ) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are
specified in the SMPP specification v3.4, section 5.2.19.&#160; 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.&#160; Choosing the value 0 for the alphabet selects
the SMSC <e
 m>default</em> alphabet, this usually means GSM 3.38 but it is not guaranteed.&#160;
The SMPP gateway Nexmo <a shape="rect" class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="BookComponentAppendix-Messagesplittingandthrottling">Message
splitting and throttling</h3><p>After transforming a message body from a String
to a byte array, the Camel component is also responsible for splitting the message into parts
(within the 140 byte SMS size limit) before passing it to JSMPP.&#160; This is completed
automatically.</p><p>If the GSM 3.38 alphabet is used, the component will pack
up to 160 characters into the 140 byte message body.&#160; If an 8 bit character set is
us
 ed (e.g. ISO-8859-1 for western Europe) then 140 characters will be allowed within the 140
byte message body.&#160; If 16 bit UCS-2 encoding is used then just 70 characters fit
into each 140 byte message.</p><p>Some SMSC providers implement throttling rules.&#160;
Each part of a message that has been split may be counted separately by the provider's throttling
mechanism.&#160; The Camel Throttler component can be useful for throttling messages in
the SMPP route before handing them to the SMSC.</p><h3 id="BookComponentAppendix-URIformat.62">URI
format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
 <script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[smpp://[username@]hostname[:port][?options]
 smpps://[username@]hostname[:port][?options]
 ]]></script>

Modified: websites/production/camel/content/book-in-one-page.html
==============================================================================
--- websites/production/camel/content/book-in-one-page.html (original)
+++ websites/production/camel/content/book-in-one-page.html Thu Nov 20 17:19:36 2014
@@ -4120,11 +4120,11 @@ While not actual tutorials you might fin
                     </div>
     </div>
 <h2 id="BookInOnePage-Preface">Preface</h2><p>This tutorial aims to guide
the reader through the stages of creating a project which uses Camel to facilitate the routing
of messages from a JMS queue to a <a shape="rect" class="external-link" href="http://www.springramework.org"
rel="nofollow">Spring</a> service. The route works in a synchronous fashion returning
a response to the client.</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1416500332180 {padding: 0px;}
-div.rbtoc1416500332180 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1416500332180 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1416503871086 {padding: 0px;}
+div.rbtoc1416503871086 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1416503871086 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1416500332180">
+/*]]>*/</style></p><div class="toc-macro rbtoc1416503871086">
 <ul class="toc-indentation"><li><a shape="rect" href="#Tutorial-JmsRemoting-TutorialonSpringRemotingwithJMS">Tutorial
on Spring Remoting with JMS</a></li><li><a shape="rect" href="#Tutorial-JmsRemoting-Preface">Preface</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-Prerequisites">Prerequisites</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-Distribution">Distribution</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-About">About</a></li><li><a
shape="rect" href="#Tutorial-JmsRemoting-CreatetheCamelProject">Create the Camel Project</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#Tutorial-JmsRemoting-UpdatethePOMwithDependencies">Update
the POM with Dependencies</a></li></ul>
 </li><li><a shape="rect" href="#Tutorial-JmsRemoting-WritingtheServer">Writing
the Server</a>
@@ -6310,11 +6310,11 @@ So we completed the last piece in the pi
 
 
 <style type="text/css">/*<![CDATA[*/
-div.rbtoc1416500336351 {padding: 0px;}
-div.rbtoc1416500336351 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1416500336351 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1416503874013 {padding: 0px;}
+div.rbtoc1416503874013 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1416503874013 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style><div class="toc-macro rbtoc1416500336351">
+/*]]>*/</style><div class="toc-macro rbtoc1416503874013">
 <ul class="toc-indentation"><li><a shape="rect" href="#Tutorial-AXIS-Camel-TutorialusingAxis1.4withApacheCamel">Tutorial
using Axis 1.4 with Apache Camel</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#Tutorial-AXIS-Camel-Prerequisites">Prerequisites</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-Distribution">Distribution</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-Introduction">Introduction</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-SettinguptheprojecttorunAxis">Setting up the project
to run Axis</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#Tutorial-AXIS-Camel-Maven2">Maven
2</a></li><li><a shape="rect" href="#Tutorial-AXIS-Camel-wsdl">wsdl</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-ConfiguringAxis">Configuring Axis</a></li><li><a
shape="rect" href="#Tutorial-AXIS-Camel-RunningtheExample">Running the Example</a></li></ul>
@@ -19686,11 +19686,11 @@ template.send(&quot;direct:alias-verify&
                     </div>
     </div>
 <p>The <strong>cxf:</strong> component provides integration with <a
shape="rect" href="http://cxf.apache.org">Apache CXF</a> for connecting to JAX-WS
services hosted in CXF.</p><p><style type="text/css">/*<![CDATA[*/
-div.rbtoc1416500373236 {padding: 0px;}
-div.rbtoc1416500373236 ul {list-style: disc;margin-left: 0px;}
-div.rbtoc1416500373236 li {margin-left: 0px;padding-left: 0px;}
+div.rbtoc1416503893416 {padding: 0px;}
+div.rbtoc1416503893416 ul {list-style: disc;margin-left: 0px;}
+div.rbtoc1416503893416 li {margin-left: 0px;padding-left: 0px;}
 
-/*]]>*/</style></p><div class="toc-macro rbtoc1416500373236">
+/*]]>*/</style></p><div class="toc-macro rbtoc1416503893416">
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-CXFComponent">CXF
Component</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-URIformat">URI
format</a></li><li><a shape="rect" href="#CXF-Options">Options</a>
 <ul class="toc-indentation"><li><a shape="rect" href="#CXF-Thedescriptionsofthedataformats">The
descriptions of the dataformats</a>
@@ -29702,7 +29702,7 @@ protected RouteBuilder createRouteBuilde
     &lt;!-- use the same version as your Camel core version --&gt;
 &lt;/dependency&gt;
 ]]></script>
-</div></div><h3 id="BookInOnePage-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipient hand
 set.&#160; SMS messages are not encrypted or authenticated in any other part of the network.&#160;
Some operators allow staff in retail outlets or call centres to browse through the SMS message
histories of their customers.&#160; Message sender identity can be easily forged.&#160;
Regulators and even the mobile telephone industry itself has cautioned against the use of
SMS in two-factor authentication schemes and other purposes where security is important.</li></ul><p>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.</p><h2 id="BookInOnePage-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component acts when more than
  one value is set.</p><p>Data coding is an 8 bit field in the SMPP wire format.</p><p>Alphabet
corresponds to bits 0-3 of the data coding field.&#160; 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.</p><p>Furthermore,
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.&#160; This is why the Alphabet class in JSMPP doesn't
support the value 3 (binary 0011) which indicates ISO-8859-1.</p><p>Although JSMPP
provides a representation of the message class parameter, the Camel component doesn't currently
provide a way to set it other than manually setting the corresponding bits in the data coding
field.</p><p>When setting the data coding field in the outgoing message, the Camel
component considers the following values and uses the first one it c
 an find:</p><ul><li>the data coding specified in a header</li><li>the
alphabet specified in a header</li><li>the data coding specified in the endpoint
configuration (URI parameter)</li></ul><p>Older versions of Camel had bugs
in support for international character sets.&#160; This feature only worked when a single
encoding was used for all messages and was troublesome when users wanted to change it on a
per-message basis.&#160; Users who require this to work should ensure their version of
Camel includes the fix for&#160;</p><div class="error">Error rendering macro
'jira' : com.atlassian.confluence.macro.MacroExecutionException: java.lang.RuntimeException:
Not Found</div>.<p>In addition to trying to send the data coding value to the
SMSC, the Camel component also tries to analyze the message body, convert it to a Java String
(Unicode) and convert that to a byte array in the corresponding alphabet&#160; When deciding
which alphabet to use in the byte array, the Camel SMPP component do
 es not consider the data coding value (header or configuration), it only considers the specified
alphabet (from either the header or endpoint parameter).</p><p>If some characters
in the String can't be represented in the chosen alphabet, they may be replaced by the question
mark ( ? ) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are specified in the
SMPP specification v3.4, section 5.2.19.&#160; 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.&#160; Choosing the value 0 for the alphabet selects the SMSC <em>default</em>
a
 lphabet, this usually means GSM 3.38 but it is not guaranteed.&#160; The SMPP gateway
Nexmo <a shape="rect" class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="BookInOnePage-URIformat.63">URI
format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><h3 id="BookInOnePage-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipient hand
 set.&#160; SMS messages are not encrypted or authenticated in any other part of the network.&#160;
Some operators allow staff in retail outlets or call centres to browse through the SMS message
histories of their customers.&#160; Message sender identity can be easily forged.&#160;
Regulators and even the mobile telephone industry itself has cautioned against the use of
SMS in two-factor authentication schemes and other purposes where security is important.</li></ul><p>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.</p><h2 id="BookInOnePage-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component acts when more than
  one value is set.</p><p>Data coding is an 8 bit field in the SMPP wire format.</p><p>Alphabet
corresponds to bits 0-3 of the data coding field.&#160; 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.</p><p>Furthermore,
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.&#160; This is why the Alphabet class in JSMPP doesn't
support the value 3 (binary 0011) which indicates ISO-8859-1.</p><p>Although JSMPP
provides a representation of the message class parameter, the Camel component doesn't currently
provide a way to set it other than manually setting the corresponding bits in the data coding
field.</p><p>When setting the data coding field in the outgoing message, the Camel
component considers the following values and uses the first one it c
 an find:</p><ul><li>the data coding specified in a header</li><li>the
alphabet specified in a header</li><li>the data coding specified in the endpoint
configuration (URI parameter)</li></ul><p>Older versions of Camel had bugs
in support for international character sets.&#160; This feature only worked when a single
encoding was used for all messages and was troublesome when users wanted to change it on a
per-message basis.&#160; Users who require this to work should ensure their version of
Camel includes the fix for&#160;</p><div class="error">Error rendering macro
'jira' : com.atlassian.confluence.macro.MacroExecutionException: java.lang.RuntimeException:
Not Found</div>.<p>In addition to trying to send the data coding value to the
SMSC, the Camel component also tries to analyze the message body, convert it to a Java String
(Unicode) and convert that to a byte array in the corresponding alphabet&#160; When deciding
which alphabet to use in the byte array, the Camel SMPP component do
 es not consider the data coding value (header or configuration), it only considers the specified
alphabet (from either the header or endpoint parameter).</p><p>If some characters
in the String can't be represented in the chosen alphabet, they may be replaced by the question
mark ( ? ) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are specified in the
SMPP specification v3.4, section 5.2.19.&#160; 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.&#160; Choosing the value 0 for the alphabet selects the SMSC <em>default</em>
a
 lphabet, this usually means GSM 3.38 but it is not guaranteed.&#160; The SMPP gateway
Nexmo <a shape="rect" class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="BookInOnePage-Messagesplittingandthrottling">Message
splitting and throttling</h3><p>After transforming a message body from a String
to a byte array, the Camel component is also responsible for splitting the message into parts
(within the 140 byte SMS size limit) before passing it to JSMPP.&#160; This is completed
automatically.</p><p>If the GSM 3.38 alphabet is used, the component will pack
up to 160 characters into the 140 byte message body.&#160; 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.&#160;
If 16 bit UCS-2 encoding is used then just 70 characters fit into each 140 byte message.</p><p>Some
SMSC providers implement throttling rules.&#160; Each part of a message that has been
split may be counted separately by the provider's throttling mechanism.&#160; The Camel
Throttler component can be useful for throttling messages in the SMPP route before handing
them to the SMSC.</p><h3 id="BookInOnePage-URIformat.63">URI format</h3><div
class="code panel pdl" style="border-width: 1px;"><div class="codeContent panelContent
pdl">
 <script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[smpp://[username@]hostname[:port][?options]
 smpps://[username@]hostname[:port][?options]
 ]]></script>

Modified: websites/production/camel/content/cache/main.pageCache
==============================================================================
Binary files - no diff available.

Modified: websites/production/camel/content/smpp.html
==============================================================================
--- websites/production/camel/content/smpp.html (original)
+++ websites/production/camel/content/smpp.html Thu Nov 20 17:19:36 2014
@@ -93,7 +93,7 @@
     &lt;!-- use the same version as your Camel core version --&gt;
 &lt;/dependency&gt;
 ]]></script>
-</div></div><h3 id="SMPP-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipient handset.&#160
 ; SMS messages are not encrypted or authenticated in any other part of the network.&#160;
Some operators allow staff in retail outlets or call centres to browse through the SMS message
histories of their customers.&#160; Message sender identity can be easily forged.&#160;
Regulators and even the mobile telephone industry itself has cautioned against the use of
SMS in two-factor authentication schemes and other purposes where security is important.</li></ul><p>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.</p><h2 id="SMPP-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component acts when more than one value is set.
 </p><p>Data coding is an 8 bit field in the SMPP wire format.</p><p>Alphabet
corresponds to bits 0-3 of the data coding field.&#160; 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.</p><p>Furthermore,
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.&#160; This is why the Alphabet class in JSMPP doesn't
support the value 3 (binary 0011) which indicates ISO-8859-1.</p><p>Although JSMPP
provides a representation of the message class parameter, the Camel component doesn't currently
provide a way to set it other than manually setting the corresponding bits in the data coding
field.</p><p>When setting the data coding field in the outgoing message, the Camel
component considers the following values and uses the first one it can find:</p><ul><l
 i>the data coding specified in a header</li><li>the alphabet specified in
a header</li><li>the data coding specified in the endpoint configuration (URI
parameter)</li></ul><p>Older versions of Camel had bugs in support for international
character sets.&#160; This feature only worked when a single encoding was used for all
messages and was troublesome when users wanted to change it on a per-message basis.&#160;
Users who require this to work should ensure their version of Camel includes the fix for&#160;</p><div
class="error">Error rendering macro 'jira' : com.atlassian.confluence.macro.MacroExecutionException:
java.lang.RuntimeException: Not Found</div>.<p>In addition to trying to send the
data coding value to the SMSC, the Camel component also tries to analyze the message body,
convert it to a Java String (Unicode) and convert that to a byte array in the corresponding
alphabet&#160; When deciding which alphabet to use in the byte array, the Camel SMPP component
does not consider th
 e data coding value (header or configuration), it only considers the specified alphabet (from
either the header or endpoint parameter).</p><p>If some characters in the String
can't be represented in the chosen alphabet, they may be replaced by the question mark ( ?
) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are specified in the SMPP specification
v3.4, section 5.2.19.&#160; 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.&#160;
Choosing the value 0 for the alphabet selects the SMSC <em>default</em> alphabet,
this usua
 lly means GSM 3.38 but it is not guaranteed.&#160; The SMPP gateway Nexmo <a shape="rect"
class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="SMPP-URIformat">URI
format</h3><div class="code panel pdl" style="border-width: 1px;"><div class="codeContent
panelContent pdl">
+</div></div><h3 id="SMPP-SMSlimitations">SMS limitations</h3><p>SMS
is neither reliable or secure.&#160; 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.</p><ul><li>Reliability: although the SMPP
standard offers a range of feedback mechanisms to indicate errors, non-delivery and confirmation
of delivery it is not uncommon for mobile networks to hide or simulate these responses.&#160;
For example, some networks automatically send a delivery confirmation for every message even
if the destination number is invalid or not switched on.&#160; Some networks silently
drop messages if they think they are spam.&#160; Spam detection rules in the network may
be very crude, sometimes more than 100 messages per day from a single sender may be considered
spam.</li><li>Security: there is basic encryption for the last hop from the radio
tower down to the recipient handset.&#160
 ; SMS messages are not encrypted or authenticated in any other part of the network.&#160;
Some operators allow staff in retail outlets or call centres to browse through the SMS message
histories of their customers.&#160; Message sender identity can be easily forged.&#160;
Regulators and even the mobile telephone industry itself has cautioned against the use of
SMS in two-factor authentication schemes and other purposes where security is important.</li></ul><p>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.</p><h2 id="SMPP-Datacoding,alphabetandinternationalcharactersets">Data
coding, alphabet and international character sets</h2><p>Data coding and alphabet
can be specified on a per-message basis.&#160; Default values can be specified for the
endpoint.&#160; It is important to understand the relationship between these options and
the way the component acts when more than one value is set.
 </p><p>Data coding is an 8 bit field in the SMPP wire format.</p><p>Alphabet
corresponds to bits 0-3 of the data coding field.&#160; 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.</p><p>Furthermore,
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.&#160; This is why the Alphabet class in JSMPP doesn't
support the value 3 (binary 0011) which indicates ISO-8859-1.</p><p>Although JSMPP
provides a representation of the message class parameter, the Camel component doesn't currently
provide a way to set it other than manually setting the corresponding bits in the data coding
field.</p><p>When setting the data coding field in the outgoing message, the Camel
component considers the following values and uses the first one it can find:</p><ul><l
 i>the data coding specified in a header</li><li>the alphabet specified in
a header</li><li>the data coding specified in the endpoint configuration (URI
parameter)</li></ul><p>Older versions of Camel had bugs in support for international
character sets.&#160; This feature only worked when a single encoding was used for all
messages and was troublesome when users wanted to change it on a per-message basis.&#160;
Users who require this to work should ensure their version of Camel includes the fix for&#160;</p><div
class="error">Error rendering macro 'jira' : com.atlassian.confluence.macro.MacroExecutionException:
java.lang.RuntimeException: Not Found</div>.<p>In addition to trying to send the
data coding value to the SMSC, the Camel component also tries to analyze the message body,
convert it to a Java String (Unicode) and convert that to a byte array in the corresponding
alphabet&#160; When deciding which alphabet to use in the byte array, the Camel SMPP component
does not consider th
 e data coding value (header or configuration), it only considers the specified alphabet (from
either the header or endpoint parameter).</p><p>If some characters in the String
can't be represented in the chosen alphabet, they may be replaced by the question mark ( ?
) symbol.&#160; 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.&#160; 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.</p><p>The list of alphabet codes are specified in the SMPP specification
v3.4, section 5.2.19.&#160; 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.&#160;
Choosing the value 0 for the alphabet selects the SMSC <em>default</em> alphabet,
this usua
 lly means GSM 3.38 but it is not guaranteed.&#160; The SMPP gateway Nexmo <a shape="rect"
class="external-link" href="https://help.nexmo.com/hc/en-us/articles/204015813-How-to-change-the-character-encoding-in-SMPP-"
rel="nofollow">actually allows the default to be mapped to any other character set with
a control panel option</a>. It is suggested that users check with their SMSC operator
to confirm exactly which character set is being used as the default.</p><h3 id="SMPP-Messagesplittingandthrottling">Message
splitting and throttling</h3><p>After transforming a message body from a String
to a byte array, the Camel component is also responsible for splitting the message into parts
(within the 140 byte SMS size limit) before passing it to JSMPP.&#160; This is completed
automatically.</p><p>If the GSM 3.38 alphabet is used, the component will pack
up to 160 characters into the 140 byte message body.&#160; If an 8 bit character set is
used (e.g. ISO-8859-1 for western Europe) then 140 ch
 aracters will be allowed within the 140 byte message body.&#160; If 16 bit UCS-2 encoding
is used then just 70 characters fit into each 140 byte message.</p><p>Some SMSC
providers implement throttling rules.&#160; Each part of a message that has been split
may be counted separately by the provider's throttling mechanism.&#160; The Camel Throttler
component can be useful for throttling messages in the SMPP route before handing them to the
SMSC.</p><h3 id="SMPP-URIformat">URI format</h3><div class="code panel
pdl" style="border-width: 1px;"><div class="codeContent panelContent pdl">
 <script class="theme: Default; brush: java; gutter: false" type="syntaxhighlighter"><![CDATA[smpp://[username@]hostname[:port][?options]
 smpps://[username@]hostname[:port][?options]
 ]]></script>



Mime
View raw message