Hi, I'm using Kannel for SMPP to SMSCs and I've found from the DELIVER_SM the extra optional parameters that are useful are: the user_message_reference,network_error_code and submit date and done date and the actual message_state. (These can be seen from the kannel access.log)
1)If you could set the user_message_reference via Kannel when you send the SMS, it's then carried through to the DELIVER_SM. 2)The network_error_code's are useful to indicate why the SMS was not delivered. 3)submit date and done date is useful. 4)message_state gives you 8 states as seen from table 5.2.28 from the SMPP v3.4 spec. Would it be possible to return these values back as well? Thanks -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Peter Beckman Sent: Wednesday, July 14, 2004 7:01 AM To: Stipe Tolj Cc: [EMAIL PROTECTED] Subject: 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/ ---------------------------------------------------------------------------
