Re: Making SMPP esm_class configurable?

Unless someone can verify that nothing else other than esm_class changes
(i.e. payload) between datagram and store and forward mode, then values
should be exclusively 0 or 3. Kannel doesn't support any other modes.

BR,
Nikos

On Fri, Sep 9, 2011 at 12:28 PM, Alejandro Guerrieri
<[email protected]>wrote:

> 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.
> >
>
>
>