Re: Making SMPP esm_class configurable?

Yes, 0, 1, 2 and 3 inclusive.

Regards,
--
Alejandro Guerrieri
[email protected]



On Sep 9, 2011, at 10:38 AM, Milan P. Stanic wrote:

> On Fri, 2011-09-09 at 08:40, Alan McNatty wrote:
>> Thanks Alejandro,
>> 
>> OK can we please hear from anyone who would be unhappy if the patch was
>> restricted to values 0 _to_ 3? This sounds good to me.
> 
> "0 _to_ 3" means 0, 1, 2 and 3 as possible values. Right?
> 
>> If no takers (I'll give it a week or so) I will keep integer but put
>> back some constraints (and adjust the documentation) and re-submit.
>> Appreciate everyone's patience it's good to get this flexible enough to
>> work for everyone whilst still including some sensible limits. 
>> 
>> Cheers,
>> Alan
>> 
>> On Thu, 2011-09-08 at 14:26 +0200, Alejandro Guerrieri wrote:
>>> Ops, missed the point, sorry.
>>> 
>>> IMHO restricted to 0 and 3 should cover most cases. You could take it further and allowing 0 _to_ 3 to make it slightly more flexible as well.
>>> 
>>> Default should be 3 to keep it backwards-compatible.
>>> 
>>> Regards,
>>> --
>>> Alejandro Guerrieri
>>> [email protected]
>>> 
>>> 
>>> 
>>> On Sep 8, 2011, at 2:17 PM, Alexander Malysh wrote:
>>> 
>>>> Hi Alex,
>>>> 
>>>> this is not the question whether commit or not. The question is, how patch should looks like?
>>>> a) commit as boolean
>>>> b) commit as integer with restrictions -> need recompile when not supported values (0 or 3) should be used
>>>> c) commit as integer without restrictions
>>>> 
>>>> Thanks,
>>>> Alexander Malysh
>>>> 
>>>> Am 08.09.2011 um 13:37 schrieb Alejandro Guerrieri:
>>>> 
>>>>> Having to patch and recompile Kannel a few times in the past to change that parameters to make it work in South America, I can only say +1 to it :)
>>>>> 
>>>>> Regards,
>>>>> --
>>>>> Alejandro Guerrieri
>>>>> [email protected]
>>>>> 
>>>>> 
>>>>> 
>>>>> On Sep 8, 2011, at 12:29 PM, Alexander Malysh wrote:
>>>>> 
>>>>>> Hi Alan,
>>>>>> 
>>>>>> thanks for the patch but I'm waiting for more comments in this topic.
>>>>>> If no comments coming, I will commit your patch next week.
>>>>>> 
>>>>>> Thanks,
>>>>>> Alexander Malysh
>>>>>> 
>>>>>> Am 07.09.2011 um 02:14 schrieb Alan McNatty:
>>>>>> 
>>>>>>> Hi Alex,
>>>>>>> 
>>>>>>> Based on option a) please find the attached patch. I understand reasons
>>>>>>> for locking it down but it is clear to me that users want more control
>>>>>>> over this setting (beyond what we may think is sensible). Userguide
>>>>>>> patch hopefully spells out a sufficient warning.
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Alan
>>>>>>> 
>>>>>>> On Thu, 2011-08-18 at 18:57 +0200, Alexander Malysh wrote:
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> 
>>>>>>>> I don't see this as issue. The user ether let it default or try to
>>>>>>>> change in agreement with SMSC operator. If user will try some random
>>>>>>>> values
>>>>>>>> then operator will just shutdown his account. If you ask me, I don't
>>>>>>>> see any need to allow changing default esm-class. But if we see buggy
>>>>>>>> SMSCs
>>>>>>>> that don't accept STORE & FORWARD mode then I don't know what to
>>>>>>>> expect here. Maybe some drunk developer implement SMS as datagram
>>>>>>>> mode,
>>>>>>>> who knows :-)
>>>>>>>> 
>>>>>>>> 
>>>>>>>> We have 2 options:
>>>>>>>> a) allow user to set any values and write in the docs that this may be
>>>>>>>> dangerous
>>>>>>>> b) we restrict user to only have two options 0 (default mode) and 3
>>>>>>>> (store & forward), then boolean value should be enough
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Alex
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Am 18.08.2011 um 12:33 schrieb Nikos Balkanas:
>>>>>>>> 
>>>>>>>>> Hi Alex,
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> I don't agree that this should be left open to the user. A few may
>>>>>>>>> know what to do with the spec. However, a lot will play around with
>>>>>>>>> the values until they get them working. Consider that a user sets
>>>>>>>>> this to DATAGRAM, and kannel generates a store and forward pdu with
>>>>>>>>> DATAGRAM esm_class. It doesn't hurt kannel, but what about the SMSc
>>>>>>>>> that receives it? It could possibly generate a core dump if the
>>>>>>>>> implementation is widely different, resulting in loss of service. Do
>>>>>>>>> you really want to leave that open?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> BR,
>>>>>>>>> Nikos
>>>>>>>>> 
>>>>>>>>> On Thu, Aug 18, 2011 at 11:31 AM, Alexander Malysh
>>>>>>>>> <[email protected]> wrote:
>>>>>>>>> Hi Alan,
>>>>>>>>> 
>>>>>>>>> sorry to write my response late (I was on vacation), but I
>>>>>>>>> don't think we need some restriction on configured
>>>>>>>>> esm-class.
>>>>>>>>> If we allow to change esm-class in the config, IMHO there is
>>>>>>>>> no need to restrict it's value, because
>>>>>>>>> the user know what he does.
>>>>>>>>> 
>>>>>>>>> For cannel it's equal, which value to set as esm-class
>>>>>>>>> because kannel doesn't interpreting it.
>>>>>>>>> 
>>>>>>>>> Thanks,
>>>>>>>>> Alex
>>>>>>>>> 
>>>>>>>>> Am 15.08.2011 um 09:35 schrieb Alan McNatty:
>>>>>>>>> 
>>>>>>>>>> Thanks Nikos,
>>>>>>>>>> 
>>>>>>>>>> That's good news since, thanks to Edgard for pointing out,
>>>>>>>>> I forgot to
>>>>>>>>>> include gwlib/cfg.def in the patch. Updated patch
>>>>>>>>> attached.
>>>>>>>>>> 
>>>>>>>>>> Cheers,
>>>>>>>>>> Alan
>>>>>>>>>> 
>>>>>>>>>> On Mon, 2011-08-15 at 04:29 +0300, Nikos Balkanas wrote:
>>>>>>>>>>> I guess Alex M is busy. There are a few patches prior to
>>>>>>>>> yours that
>>>>>>>>>>> wait for commission. Don't worry, he never misses a
>>>>>>>>> patch. He is the
>>>>>>>>>>> gateway maintainer.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> BR,
>>>>>>>>>>> Nikos
>>>>>>>>>>> 
>>>>>>>>>>> On Mon, Aug 15, 2011 at 3:22 AM, Alan McNatty
>>>>>>>>> <[email protected]>
>>>>>>>>>>> wrote:
>>>>>>>>>>> Thanks Rene,
>>>>>>>>>>> 
>>>>>>>>>>> Can anyone with commit access give a final nod of
>>>>>>>>> acceptance?
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, 2011-08-09 at 21:08 +0200, Rene Kluwen
>>>>>>>>> wrote:
>>>>>>>>>>>> +1 for me as well.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> From: [email protected]
>>>>>>>>>>> [mailto:[email protected]] On
>>>>>>>>>>>> Behalf Of Nikos Balkanas
>>>>>>>>>>>> Sent: Tuesday, 09 August, 2011 02:11
>>>>>>>>>>>> To: Alan McNatty
>>>>>>>>>>>> Cc: [email protected]
>>>>>>>>>>>> Subject: Re: Making SMPP esm_class configurable?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Looks great! +1.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Nikos
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, Aug 9, 2011 at 2:59 AM, Alan McNatty
>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks again Nikos,
>>>>>>>>>>>> 
>>>>>>>>>>>> Yeah 0 and 3 are all I'm interested in - wasn't sure if
>>>>>>>>>>> others wanted
>>>>>>>>>>>> support for non-compliant things.
>>>>>>>>>>>> 
>>>>>>>>>>>> Made changes as you suggested - please check out the
>>>>>>>>>>> attached patch.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Alan
>>>>>>>>>>>> 
>>>>>>>>>>>> On Mon, 2011-08-08 at 05:39 +0300, Nikos Balkanas wrote:
>>>>>>>>>>>>> Hi Alan,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Currently kannel doesn't support more modes. Therefore
>>>>>>>>>>> test should
>>>>>>>>>>>>> more specific:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> else if (esm_class != SMPP_STORE... && esm_class !=
>>>>>>>>>>> DEFAULT...))  //
>>>>>>>>>>>>> use constants
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Also I see no need for panicking over a single smsc:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> error(0, "SMPP: Invalid esm_class mode \"5\" in
>>>>>>>>>>> configuration.
>>>>>>>>>>>>> Switching to \"Store and Forward\");
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> There are still many hexadecimal references to the
>>>>>>>>>>> userguide, and it
>>>>>>>>>>>>> doesn't restrict choices. Therefore, I suggest the
>>>>>>>>>>> following text:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Value for esm_class according to the SMPP spec.
>>>>>>>>> Accepted
>>>>>>>>>>> values are
>>>>>>>>>>>> 0
>>>>>>>>>>>>> (Default smsc mode) and 3 (Store and Forward). Defaults
>>>>>>>>> to
>>>>>>>>>>> 3.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> HTH,
>>>>>>>>>>>>> Nikos
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Aug 8, 2011 at 5:01 AM, Alan McNatty
>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> Thanks Nikos,
>>>>>>>>>>>>> 
>>>>>>>>>>>>> See attached.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Also just wanted to check thoughts the range
>>>>>>>>> check
>>>>>>>>>>> (possibly
>>>>>>>>>>>>> remove and
>>>>>>>>>>>>> leave it open?).
>>>>>>>>>>>>> 
>>>>>>>>>>>>> i.e.
>>>>>>>>>>>>> +    else if (esm_class > 0x03 || esm_class < 0)
>>>>>>>>>>>>> +        panic(0, "SMPP: Invalid esm_class
>>>>>>>>>>> directive in
>>>>>>>>>>>>> configuration.");
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, 2011-08-08 at 04:44 +0300, Nikos
>>>>>>>>> Balkanas
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> Hi Alan,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Patch looks good. userguide needs some changes:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 1) Capitalize after periods (For example, For
>>>>>>>>>>> default
>>>>>>>>>>>> mode)
>>>>>>>>>>>>>> 2) In configuration the value should be integer,
>>>>>>>>>>> not hex
>>>>>>>>>>>> (3
>>>>>>>>>>>>> not 03).
>>>>>>>>>>>>>> cfg_get_integer doesn't understand hex (0xA5).
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Nikos
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Mon, Aug 8, 2011 at 4:02 AM, Alan McNatty
>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> patch attached.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Votes / comments, etc?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, 2011-08-03 at 09:39 +1200, Alan
>>>>>>>>>>> McNatty
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> Thanks Nikos/Alex for the feedback - I
>>>>>>>>>>> will work
>>>>>>>>>>>>> on config
>>>>>>>>>>>>>> patch.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, 2011-08-02 at 23:10 +0300,
>>>>>>>>>>> Nikos
>>>>>>>>>>>> Balkanas
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 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"
>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>> To: "Alan McNatty"
>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>> Cc: "Nikos Balkanas"
>>>>>>>>>>> <[email protected]>;
>>>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>> 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"
>>>>>>>>>>>> <[email protected]>
>>>>>>>>>>>>>>>>>>> To: <[email protected]>
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> <esm_class.patch>
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> <esm_class.patch2>
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
>> 
>> 
> 
> -- 
> Kind regards,  Milan
> --------------------------------------------------
> Arvanta, IT Security        http://www.arvanta.net
> Please do not send me e-mail containing HTML code.
>