Hi Alan,
Just to clarify on what Alex says. Some other modes that the SMSc may
support in default mode, are:
Datagram: UDP based, immediate best effort high throughput transmition with
no retried, validity period or storage. Similar to UDP.
Forward: Single transaction based, for real-time applications, i.e. parking
tickets, without storage, where result is returned in response.
Kannel doesn't support those, only reliable store and forward. Therefore the
default mode wouldn't be appropriate.
Configuration would be fine for those buggy SMScs, that do store and
forward, but do not accept it as an option.
BR,
Nikos
----- Original Message -----
From: "Alexander Malysh" <amal...@kannel.org>
To: "Alan McNatty" <a...@catalyst.net.nz>
Cc: "Nikos Balkanas" <nbalka...@gmail.com>; <de...@vm1.kannel.org>
Sent: Tuesday, August 02, 2011 12:29 PM
Subject: Re: Making SMPP esm_class configurable?
Hi,
please don't change default because we want that SMSC _store_ and _forward_
our message that
is what we also tell SMSC. This works in 99% cases but sometimes buggy SMSCs
don't accept this
and rejects messages.
Please keep default as is and make config option for buggy SMSCs.
Thanks,
Alex
Am 02.08.2011 um 06:11 schrieb Alan McNatty:
Sorry that should be ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE.
Index: gw/smsc/smsc_smpp.c
===================================================================
--- gw/smsc/smsc_smpp.c (revision 4913)
+++ gw/smsc/smsc_smpp.c (working copy)
@@ -876,7 +876,7 @@
* set the esm_class field
* default is store and forward, plus udh and rpi if requested
*/
- pdu->u.submit_sm.esm_class =
ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE;
+ pdu->u.submit_sm.esm_class = ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE;
if (octstr_len(msg->sms.udhdata))
pdu->u.submit_sm.esm_class = pdu->u.submit_sm.esm_class |
ESM_CLASS_SUBMIT_UDH_INDICATOR;
On Tue, 2011-08-02 at 15:59 +1200, Alan McNatty wrote:
Hi Nikos,
You mean simply change the default:
Index: gw/smsc/smsc_smpp.c
===================================================================
--- gw/smsc/smsc_smpp.c (revision 4913)
+++ gw/smsc/smsc_smpp.c (working copy)
@@ -876,7 +876,7 @@
* set the esm_class field
* default is store and forward, plus udh and rpi if requested
*/
- pdu->u.submit_sm.esm_class =
ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE;
+ pdu->u.submit_sm.esm_class = ESM_CLASS_DEFAULT_SMSC_MODE;
if (octstr_len(msg->sms.udhdata))
pdu->u.submit_sm.esm_class = pdu->u.submit_sm.esm_class |
ESM_CLASS_SUBMIT_UDH_INDICATOR;
Anyone think we should have a config option? Or just happy to run with
he above. I need to test myself but is this likely to be a compatibility
breaker for anyone?
Cheers,
Alan
On Mon, 2011-08-01 at 07:13 +0300, Nikos Balkanas wrote:
Hi Alan,
According to the spec SMPP 5.0, p 125,
ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE is
the default esm class. That part should be patched in. As far as making
it
configurable, I have no objections to it. A few people over the years
have
had to manually patch it in.
BR,
Nikos
----- Original Message -----
From: "Alan McNatty" <a...@catalyst.net.nz>
To: <devel@kannel.org>
Sent: Monday, August 01, 2011 6:21 AM
Subject: Making SMPP esm_class configurable?
Hi All,
I found a thread on this from back in Feb 2005 (having received a query
from provided now myself) .. last word by Alejandro and a lukewarm
(+0 -
+1) comment from Stipe about committing if patch provided. I would
provide a config patch if anyone would vote in it's favour?
Consider:
gw/smsc/smsc_smpp.c
875 /*
876 * set the esm_class field
877 * default is store and forward, plus udh and rpi if requested
878 */
879 pdu->u.submit_sm.esm_class =
ESM_CLASS_SUBMIT_STORE_AND_FORWARD_MODE;
But the 'default' is surely ESM_CLASS_SUBMIT_DEFAULT_SMSC_MODE, no?
Cheers,
Alan
