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