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

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