Re: [Kannel-Users] Re: mBlox SMPP optional parameters

Hi

yes, it would be useful to get more info back - I have some recent patches 
(last few weeks) that deal with some of these. These are still under 
testing on our side. I will release as soon as possible.

As for publishing with SMPP.org and hoping that the aggregators and 
operators will fall in line - mm I doubt it :-) - look at the variation in 
deliver_sm dlr text formats, look at the various non standard uses of smpp 
params....

nisan

At 04:01 PM 2004/07/14, Peter Beckman wrote:

>What I'd love to see is this.  From Table 5-7 in the Kannel 1.3.1
>documentation, add these fields:
>
>     %m  message_id returned by remote SMSC
>     %o  command_id returned by SMSC
>     %O  command_status returned by SMSC
>
>This way, anyone can write a handler using the DLR reporting, and we can
>all make it specific to what we need.  No sense in changing kannel for
>vendor-specifics.
>
>The problem is that if the command_status is anything other than 0x0,
>kannel believes correctly that there was some sort of error.  I haven't
>looked at v4 or v5, but there needs to be a way to communicate information
>back from the SMSC other than what would be considered an "error" in the
>command_status.  We don't want to foul-up command_id.
>
>So lets write one that we can all use.
>
>0x00000400  Message Billed (OK)
>0x000004A0  Message Unbillable
>0x000004A1  MSISDN Blacklisted
>0x000004A2  Carrier Invalid (Number Portability)
>
>I'm not thinking clearly, but its a start.  I'll look at the patch and see
>what responses people want.
>
>I think we should write and publish a spec, give it to the SMPP org even,
>for this sort of thing.  If we can get SMPP to publish it, the carriers and
>aggregators should fall in line.  Hopefully.
>
>Beckman
>
>On Wed, 14 Jul 2004, Stipe Tolj wrote:
>
> > Nisan Bloch - Clickatell wrote:
> > >
> > > Hi Ian
> > >
> > > part of the problem here is that  each vendor will then have their own
> > > proprietary settings,
> > > now most of us who use kannel for high volume messaging and have many 
> links
> > > running and external applications that handle the routing - this 
> would then
> > > mean that the routing apps would need to have specific knowledge of the
> > > optional/proprietary settings for each gateway. Part of the idea of 
> Kannel
> > > is to abstract the links so external apps do not need to know anything
> > > about the various protocols and connections.  Then the next issue is 
> how to
> > > pass these through from smsbox.
> > >
> > > so -1 for this going to CVS,
> >
> > I couldn't have frazed it clearer ;). Thanks Nisan.
> >
> > Same for me: -1 in adding spefiic vendor things to SMPP.
> >
> > Ian: you can think of how we could leaverage the SMPP module to
> > "handle" vendor specific things. Like a dependency SMPP client
> > implementation modole. But this is way out of scope currently for the
> > group I guess.
> >
> > Stipe
> >
> > mailto:[email protected]
> > -------------------------------------------------------------------
> > Wapme Systems AG
> >
> > Vogelsanger Weg 80
> > 40470 Düsseldorf, NRW, Germany
> >
> > phone: +49.211.74845.0
> > fax: +49.211.74845.299
> >
> > mailto:[email protected]
> > http://www.wapme-systems.de/
> > -------------------------------------------------------------------
> >
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: GnuPG v1.2.2 (Cygwin)
> >
> > mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS
> > OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2
> > nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT
> > dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv
> > bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID
> > AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl
> > OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ
> > K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H
> > g2HyLAEKQIp30Q==
> > =aYCI
> > -----END PGP PUBLIC KEY BLOCK-----
> >
>
>---------------------------------------------------------------------------
>Peter Beckman                                                  Internet Guy
>[email protected]                             http://www.purplecow.com/
>---------------------------------------------------------------------------