You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@camel.apache.org by "Jonas Bengtsson (Created) (JIRA)" <ji...@apache.org> on 2011/09/27 10:16:13 UTC
[jira] [Created] (CAMEL-4491) dataCoding not working properly in
camel-smpp
dataCoding not working properly in camel-smpp
---------------------------------------------
Key: CAMEL-4491
URL: https://issues.apache.org/jira/browse/CAMEL-4491
Project: Camel
Issue Type: Bug
Components: camel-smpp
Affects Versions: 2.8.0, 2.7.0, 2.9.0
Reporter: Jonas Bengtsson
Attachments: patch.txt
This is related to CAMEL-3093.
The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
{code}
new GeneralDataCoding(
false,
true,
MessageClass.CLASS1,
Alphabet.valueOf(submitSm.getDataCoding()))
{code}
It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
{code}
new GeneralDataCoding(submitSm.getDataCoding())
{code}
This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Jonas Bengtsson (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13134852#comment-13134852 ]
Jonas Bengtsson commented on CAMEL-4491:
----------------------------------------
I have now done some testing with the SNAPSHOT-version and so far it works great. With the new version, the only thing I have to do is to pass it strings. Even with the default values I don't have to do any extra work myself.
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Updated JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Müller updated CAMEL-4491:
------------------------------------
Fix Version/s: 2.9.0
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Fix For: 2.9.0
>
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13133081#comment-13133081 ]
Christian Müller commented on CAMEL-4491:
-----------------------------------------
Hello Jonas!
A few days ago I committed a patch to this component to allow sending multilingual and multipart messages: [CAMEL-4086|https://issues.apache.org/jira/browse/CAMEL-4086]
It would be great if you could test whether this fix also your issue. You can find our latest SNAPSHOTS [here|https://repository.apache.org/content/repositories/snapshots/]. I still have to update the WIKI pages which should be done after the weekend.
Best,
Christian
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Jonas Bengtsson (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonas Bengtsson updated CAMEL-4491:
-----------------------------------
Attachment: patch.txt
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13135014#comment-13135014 ]
Christian Müller commented on CAMEL-4491:
-----------------------------------------
Jonas, thank you very much. I really appreciate it.
I will close this issue, because it looks like it's solved with CAMEL-4086. Feel free to reopen this issue or open a new one if you have problems again.
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Fix For: 2.9.0
>
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Closed JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Müller closed CAMEL-4491.
-----------------------------------
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Fix For: 2.9.0
>
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Resolved JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Müller resolved CAMEL-4491.
-------------------------------------
Resolution: Fixed
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Fix For: 2.9.0
>
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (CAMEL-4491) dataCoding not working properly in
camel-smpp
Posted by "Christian Müller (Assigned JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CAMEL-4491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Christian Müller reassigned CAMEL-4491:
---------------------------------------
Assignee: Christian Müller
> dataCoding not working properly in camel-smpp
> ---------------------------------------------
>
> Key: CAMEL-4491
> URL: https://issues.apache.org/jira/browse/CAMEL-4491
> Project: Camel
> Issue Type: Bug
> Components: camel-smpp
> Affects Versions: 2.7.0, 2.8.0, 2.9.0
> Reporter: Jonas Bengtsson
> Assignee: Christian Müller
> Attachments: patch.txt
>
>
> This is related to CAMEL-3093.
> The way the dataCoding option works is incorrect (or at least very confusing). After reading the documentation I was under the impression that the given value would be used in the data_coding-part of the submit_sm PDU-packets, but this is not the case. When 0 is given as dataCoding 0x11 (hexadecimal) is sent in the PDU-packets. If 4 is specified 0x15 is sent, and if 8 is specified then 0x19 is sent. This is caused in SmppProducer by the use of the constructor with several parameters:
> {code}
> new GeneralDataCoding(
> false,
> true,
> MessageClass.CLASS1,
> Alphabet.valueOf(submitSm.getDataCoding()))
> {code}
> It constructs a DCS-value as defined in the GSM 03.38 specification, not as specified in the SMPP specification. 0x11 is for example a valid DCS-value in GSM 03.38, but is reserved in SMPP. I think that it would be better and more logical if the constructor with one parameter was used instead:
> {code}
> new GeneralDataCoding(submitSm.getDataCoding())
> {code}
> This is more flexibal (DCS-values can still be created manually) and is a better default value (0 instead of 0x11). With my SMS-center (this probably varies between centers though) a data_coding of 0x11 forces me to do the 7-bit GSM decoding myself. When 0 is specified (or 3) all I have to do is to pass it ISO-8859-1 encoded bytes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira