You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Thomas O'Donnell <Th...@mdsglobal.com> on 2021/03/11 17:45:32 UTC
SMPP Splitting Policy (140+ octets)
Hi all,
I'm quite new to this so please bear with me. I've configured my SMPP component with the following properties.
bridgeErrorHandler: ERROR
dataCoding: 8
encoding: UTF-16
splittingPolicy: ACCEPT
However, when I send a message over 70 chars, the SMSC server requests it because the message is over 140 octets. My expectation is that, since splittingPolicy = ACCEPT, the SMPP server would split the original message into however many messages under 140 bytes are required so these could be accepted by the SMSC.
Am I missing something in the configuration or is my expectation incorrect?
Some other info:
- Messages under 70 chars are accepted.
- I can't find anything useful in the logs.
- I've tried setting splittingPolicy = REJECT but instead of stopping any messages over 140 octets, the message is still sent to, and rejected by, the SMSC.
- I haven't done much testing with other encodings combinations as some of the messages will contain Thai characters and this is the only encoding supported by the SMSC provider.
Thanks in advance,
Tommy O'Donnell
This email is intended for the person or company named and access by anyone else is unauthorised. If you are not the person or company named, please delete this email and notify the sender. The information in this email, including any attachments, may be confidential or legally privileged and its unauthorised disclosure, copying, distribution or use is prohibited and may be unlawful. This email has been sent from MDS Global Ltd, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training.
RE: SMPP Splitting Policy (140+ octets)
Posted by Thomas O'Donnell <Th...@mdsglobal.com>.
Hi Zheng,
Thank you for your help,
Regards,
Tommy
-----Original Message-----
From: Zheng Feng <zf...@redhat.com>
Sent: 17 March 2021 03:09
To: users@camel.apache.org
Subject: Re: SMPP Splitting Policy (140+ octets)
Hi Tommy,
I'm not sure if it is possible to default the set of SubmitMulti in the header. But I think this might depend on the SMGC(Short Message Gateway
Center) configuration.
On Wed, Mar 17, 2021 at 12:08 AM Thomas O'Donnell < Thomas.ODonnell@mdsglobal.com> wrote:
> Hi Zheng,
>
> Thank you, that worked. Do you always have to manually set the
> SmppCommandType in the header? I.e. Camel won't do it automatically
> based on message size?
>
> Is there any way to default to SubmitMulti for all requests?
>
> Regards,
>
> Tommy
>
> -----Original Message-----
> From: Zheng Feng <zf...@redhat.com>
> Sent: 12 March 2021 15:03
> To: users@camel.apache.org
> Subject: Re: SMPP Splitting Policy (140+ octets)
>
> Did you try to use 'SubmitMulti' ? just like
> exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti");
> Please refer to the test method sendSubmitMultiSM() in
> SmppComponentIntegrationTest.java
>
> On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell <
> Thomas.ODonnell@mdsglobal.com> wrote:
>
> > Hi all,
> >
> > I'm quite new to this so please bear with me. I've configured my
> > SMPP component with the following properties.
> >
> > bridgeErrorHandler: ERROR
> > dataCoding: 8
> > encoding: UTF-16
> > splittingPolicy: ACCEPT
> >
> > However, when I send a message over 70 chars, the SMSC server
> > requests it because the message is over 140 octets. My expectation
> > is that, since splittingPolicy = ACCEPT, the SMPP server would split
> > the original message into however many messages under 140 bytes are
> > required so these could be accepted by the SMSC.
> >
> > Am I missing something in the configuration or is my expectation
> incorrect?
> >
> > Some other info:
> > - Messages under 70 chars are accepted.
> > - I can't find anything useful in the logs.
> > - I've tried setting splittingPolicy = REJECT but instead of
> > stopping any messages over 140 octets, the message is still sent to,
> > and rejected by, the SMSC.
> > - I haven't done much testing with other encodings combinations as
> > some of the messages will contain Thai characters and this is the
> > only encoding supported by the SMSC provider.
> >
> > Thanks in advance,
> >
> > Tommy O'Donnell
> > This email is intended for the person or company named and access by
> > anyone else is unauthorised. If you are not the person or company
> > named, please delete this email and notify the sender. The
> > information in this email, including any attachments, may be
> > confidential or legally privileged and its unauthorised disclosure,
> > copying, distribution or use is prohibited and may be unlawful. This
> > email has been sent from MDS Global Ltd, a registered company
> > incorporated in England and Wales with registered number
> > 02263085 . The registered office is The Point, 410 Birchwood
> > Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> > email traffic data and also the content of email for the purposes of
> > security, ensure compliance with company policies and staff training.
> >
> >
> This email is intended for the person or company named and access by
> anyone else is unauthorised. If you are not the person or company
> named, please delete this email and notify the sender. The information
> in this email, including any attachments, may be confidential or
> legally privileged and its unauthorised disclosure, copying,
> distribution or use is prohibited and may be unlawful. This email has
> been sent from MDS Global Ltd, a registered company incorporated in
> England and Wales with registered number
> 02263085 . The registered office is The Point, 410 Birchwood
> Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> email traffic data and also the content of email for the purposes of
> security, ensure compliance with company policies and staff training.
>
This email is intended for the person or company named and access by anyone else is unauthorised. If you are not the person or company named, please delete this email and notify the sender. The information in this email, including any attachments, may be confidential or legally privileged and its unauthorised disclosure, copying, distribution or use is prohibited and may be unlawful. This email has been sent from MDS Global Ltd, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training.
RE: SMPP Splitting Policy (140+ octets)
Posted by Thomas O'Donnell <Th...@mdsglobal.com>.
Final update re. the below.
After some additional testing and diving into the code, I realised that messages were being split as per the SmppNLSTSplitter class (i.e. by 155 characters) even though the encoding = UTF-16. I set the language as UCS2 and now they are getting picked up by the SmppUcs2Splitter class and are split by 70 characters.
Regards,
Tommy
-----Original Message-----
From: Zheng Feng <zf...@redhat.com>
Sent: 17 March 2021 03:09
To: users@camel.apache.org
Subject: Re: SMPP Splitting Policy (140+ octets)
Hi Tommy,
I'm not sure if it is possible to default the set of SubmitMulti in the header. But I think this might depend on the SMGC(Short Message Gateway
Center) configuration.
On Wed, Mar 17, 2021 at 12:08 AM Thomas O'Donnell < Thomas.ODonnell@mdsglobal.com> wrote:
> Hi Zheng,
>
> Thank you, that worked. Do you always have to manually set the
> SmppCommandType in the header? I.e. Camel won't do it automatically
> based on message size?
>
> Is there any way to default to SubmitMulti for all requests?
>
> Regards,
>
> Tommy
>
> -----Original Message-----
> From: Zheng Feng <zf...@redhat.com>
> Sent: 12 March 2021 15:03
> To: users@camel.apache.org
> Subject: Re: SMPP Splitting Policy (140+ octets)
>
> Did you try to use 'SubmitMulti' ? just like
> exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti");
> Please refer to the test method sendSubmitMultiSM() in
> SmppComponentIntegrationTest.java
>
> On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell <
> Thomas.ODonnell@mdsglobal.com> wrote:
>
> > Hi all,
> >
> > I'm quite new to this so please bear with me. I've configured my
> > SMPP component with the following properties.
> >
> > bridgeErrorHandler: ERROR
> > dataCoding: 8
> > encoding: UTF-16
> > splittingPolicy: ACCEPT
> >
> > However, when I send a message over 70 chars, the SMSC server
> > requests it because the message is over 140 octets. My expectation
> > is that, since splittingPolicy = ACCEPT, the SMPP server would split
> > the original message into however many messages under 140 bytes are
> > required so these could be accepted by the SMSC.
> >
> > Am I missing something in the configuration or is my expectation
> incorrect?
> >
> > Some other info:
> > - Messages under 70 chars are accepted.
> > - I can't find anything useful in the logs.
> > - I've tried setting splittingPolicy = REJECT but instead of
> > stopping any messages over 140 octets, the message is still sent to,
> > and rejected by, the SMSC.
> > - I haven't done much testing with other encodings combinations as
> > some of the messages will contain Thai characters and this is the
> > only encoding supported by the SMSC provider.
> >
> > Thanks in advance,
> >
> > Tommy O'Donnell
> > This email is intended for the person or company named and access by
> > anyone else is unauthorised. If you are not the person or company
> > named, please delete this email and notify the sender. The
> > information in this email, including any attachments, may be
> > confidential or legally privileged and its unauthorised disclosure,
> > copying, distribution or use is prohibited and may be unlawful. This
> > email has been sent from MDS Global Ltd, a registered company
> > incorporated in England and Wales with registered number
> > 02263085 . The registered office is The Point, 410 Birchwood
> > Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> > email traffic data and also the content of email for the purposes of
> > security, ensure compliance with company policies and staff training.
> >
> >
> This email is intended for the person or company named and access by
> anyone else is unauthorised. If you are not the person or company
> named, please delete this email and notify the sender. The information
> in this email, including any attachments, may be confidential or
> legally privileged and its unauthorised disclosure, copying,
> distribution or use is prohibited and may be unlawful. This email has
> been sent from MDS Global Ltd, a registered company incorporated in
> England and Wales with registered number
> 02263085 . The registered office is The Point, 410 Birchwood
> Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> email traffic data and also the content of email for the purposes of
> security, ensure compliance with company policies and staff training.
>
This email is intended for the person or company named and access by anyone else is unauthorised. If you are not the person or company named, please delete this email and notify the sender. The information in this email, including any attachments, may be confidential or legally privileged and its unauthorised disclosure, copying, distribution or use is prohibited and may be unlawful. This email has been sent from MDS Global Ltd, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training.
Re: SMPP Splitting Policy (140+ octets)
Posted by Zheng Feng <zf...@redhat.com>.
Hi Tommy,
I'm not sure if it is possible to default the set of SubmitMulti in the
header. But I think this might depend on the SMGC(Short Message Gateway
Center) configuration.
On Wed, Mar 17, 2021 at 12:08 AM Thomas O'Donnell <
Thomas.ODonnell@mdsglobal.com> wrote:
> Hi Zheng,
>
> Thank you, that worked. Do you always have to manually set the
> SmppCommandType in the header? I.e. Camel won't do it automatically based
> on message size?
>
> Is there any way to default to SubmitMulti for all requests?
>
> Regards,
>
> Tommy
>
> -----Original Message-----
> From: Zheng Feng <zf...@redhat.com>
> Sent: 12 March 2021 15:03
> To: users@camel.apache.org
> Subject: Re: SMPP Splitting Policy (140+ octets)
>
> Did you try to use 'SubmitMulti' ? just like
> exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti"); Please
> refer to the test method sendSubmitMultiSM() in
> SmppComponentIntegrationTest.java
>
> On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell <
> Thomas.ODonnell@mdsglobal.com> wrote:
>
> > Hi all,
> >
> > I'm quite new to this so please bear with me. I've configured my SMPP
> > component with the following properties.
> >
> > bridgeErrorHandler: ERROR
> > dataCoding: 8
> > encoding: UTF-16
> > splittingPolicy: ACCEPT
> >
> > However, when I send a message over 70 chars, the SMSC server requests
> > it because the message is over 140 octets. My expectation is that,
> > since splittingPolicy = ACCEPT, the SMPP server would split the
> > original message into however many messages under 140 bytes are
> > required so these could be accepted by the SMSC.
> >
> > Am I missing something in the configuration or is my expectation
> incorrect?
> >
> > Some other info:
> > - Messages under 70 chars are accepted.
> > - I can't find anything useful in the logs.
> > - I've tried setting splittingPolicy = REJECT but instead of stopping
> > any messages over 140 octets, the message is still sent to, and
> > rejected by, the SMSC.
> > - I haven't done much testing with other encodings combinations as
> > some of the messages will contain Thai characters and this is the only
> > encoding supported by the SMSC provider.
> >
> > Thanks in advance,
> >
> > Tommy O'Donnell
> > This email is intended for the person or company named and access by
> > anyone else is unauthorised. If you are not the person or company
> > named, please delete this email and notify the sender. The information
> > in this email, including any attachments, may be confidential or
> > legally privileged and its unauthorised disclosure, copying,
> > distribution or use is prohibited and may be unlawful. This email has
> > been sent from MDS Global Ltd, a registered company incorporated in
> > England and Wales with registered number
> > 02263085 . The registered office is The Point, 410 Birchwood
> > Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> > email traffic data and also the content of email for the purposes of
> > security, ensure compliance with company policies and staff training.
> >
> >
> This email is intended for the person or company named and access by
> anyone else is unauthorised. If you are not the person or company named,
> please delete this email and notify the sender. The information in this
> email, including any attachments, may be confidential or legally privileged
> and its unauthorised disclosure, copying, distribution or use is prohibited
> and may be unlawful. This email has been sent from MDS Global Ltd, a
> registered company incorporated in England and Wales with registered number
> 02263085 . The registered office is The Point, 410 Birchwood Boulevard,
> Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data
> and also the content of email for the purposes of security, ensure
> compliance with company policies and staff training.
>
RE: SMPP Splitting Policy (140+ octets)
Posted by Thomas O'Donnell <Th...@mdsglobal.com>.
Hi Zheng,
Thank you, that worked. Do you always have to manually set the SmppCommandType in the header? I.e. Camel won't do it automatically based on message size?
Is there any way to default to SubmitMulti for all requests?
Regards,
Tommy
-----Original Message-----
From: Zheng Feng <zf...@redhat.com>
Sent: 12 March 2021 15:03
To: users@camel.apache.org
Subject: Re: SMPP Splitting Policy (140+ octets)
Did you try to use 'SubmitMulti' ? just like exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti"); Please refer to the test method sendSubmitMultiSM() in SmppComponentIntegrationTest.java
On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell < Thomas.ODonnell@mdsglobal.com> wrote:
> Hi all,
>
> I'm quite new to this so please bear with me. I've configured my SMPP
> component with the following properties.
>
> bridgeErrorHandler: ERROR
> dataCoding: 8
> encoding: UTF-16
> splittingPolicy: ACCEPT
>
> However, when I send a message over 70 chars, the SMSC server requests
> it because the message is over 140 octets. My expectation is that,
> since splittingPolicy = ACCEPT, the SMPP server would split the
> original message into however many messages under 140 bytes are
> required so these could be accepted by the SMSC.
>
> Am I missing something in the configuration or is my expectation incorrect?
>
> Some other info:
> - Messages under 70 chars are accepted.
> - I can't find anything useful in the logs.
> - I've tried setting splittingPolicy = REJECT but instead of stopping
> any messages over 140 octets, the message is still sent to, and
> rejected by, the SMSC.
> - I haven't done much testing with other encodings combinations as
> some of the messages will contain Thai characters and this is the only
> encoding supported by the SMSC provider.
>
> Thanks in advance,
>
> Tommy O'Donnell
> This email is intended for the person or company named and access by
> anyone else is unauthorised. If you are not the person or company
> named, please delete this email and notify the sender. The information
> in this email, including any attachments, may be confidential or
> legally privileged and its unauthorised disclosure, copying,
> distribution or use is prohibited and may be unlawful. This email has
> been sent from MDS Global Ltd, a registered company incorporated in
> England and Wales with registered number
> 02263085 . The registered office is The Point, 410 Birchwood
> Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor
> email traffic data and also the content of email for the purposes of
> security, ensure compliance with company policies and staff training.
>
>
This email is intended for the person or company named and access by anyone else is unauthorised. If you are not the person or company named, please delete this email and notify the sender. The information in this email, including any attachments, may be confidential or legally privileged and its unauthorised disclosure, copying, distribution or use is prohibited and may be unlawful. This email has been sent from MDS Global Ltd, a registered company incorporated in England and Wales with registered number 02263085 . The registered office is The Point, 410 Birchwood Boulevard, Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data and also the content of email for the purposes of security, ensure compliance with company policies and staff training.
Re: SMPP Splitting Policy (140+ octets)
Posted by Zheng Feng <zf...@redhat.com>.
Did you try to use 'SubmitMulti' ? just like
exchange.getIn().setHeader(SmppConstants.COMMAND, "SubmitMulti");
Please refer to the test method sendSubmitMultiSM() in
SmppComponentIntegrationTest.java
On Fri, Mar 12, 2021 at 1:56 AM Thomas O'Donnell <
Thomas.ODonnell@mdsglobal.com> wrote:
> Hi all,
>
> I'm quite new to this so please bear with me. I've configured my SMPP
> component with the following properties.
>
> bridgeErrorHandler: ERROR
> dataCoding: 8
> encoding: UTF-16
> splittingPolicy: ACCEPT
>
> However, when I send a message over 70 chars, the SMSC server requests it
> because the message is over 140 octets. My expectation is that, since
> splittingPolicy = ACCEPT, the SMPP server would split the original message
> into however many messages under 140 bytes are required so these could be
> accepted by the SMSC.
>
> Am I missing something in the configuration or is my expectation incorrect?
>
> Some other info:
> - Messages under 70 chars are accepted.
> - I can't find anything useful in the logs.
> - I've tried setting splittingPolicy = REJECT but instead of stopping any
> messages over 140 octets, the message is still sent to, and rejected by,
> the SMSC.
> - I haven't done much testing with other encodings combinations as some
> of the messages will contain Thai characters and this is the only encoding
> supported by the SMSC provider.
>
> Thanks in advance,
>
> Tommy O'Donnell
> This email is intended for the person or company named and access by
> anyone else is unauthorised. If you are not the person or company named,
> please delete this email and notify the sender. The information in this
> email, including any attachments, may be confidential or legally privileged
> and its unauthorised disclosure, copying, distribution or use is prohibited
> and may be unlawful. This email has been sent from MDS Global Ltd, a
> registered company incorporated in England and Wales with registered number
> 02263085 . The registered office is The Point, 410 Birchwood Boulevard,
> Warrington, Cheshire WA3 7WD. MDS Global Ltd may monitor email traffic data
> and also the content of email for the purposes of security, ensure
> compliance with company policies and staff training.
>
>