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. 0x0400 Message Billed (OK) 0x04A0 Message Unbillable 0x04A1 MSISDN Blacklisted 0x04A2 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/ ---
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. 0x0400 Message Billed (OK) 0x04A0 Message Unbillable 0x04A1 MSISDN Blacklisted 0x04A2 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/ ---
Re: [Kannel-Users] Re: mBlox SMPP optional parameters
Nisan Bloch wrote: > 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 But look at how ambiguous SMPP is! You can hardly blame them. Besides, if everyone did everything standard, companies like us wouldn't exist. -- Ian Cass
RE: [Kannel-Users] Re: mBlox SMPP optional parameters
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. 0x0400 Message Billed (OK) 0x04A0 Message Unbillable 0x04A1 MSISDN Blacklisted 0x04A2 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/ ---
Re: [Kannel-Users] Re: mBlox SMPP optional parameters
Ian Cass wrote: > > Nisan Bloch wrote: > > > 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 > > But look at how ambiguous SMPP is! You can hardly blame them. Besides, if > everyone did everything standard, companies like us wouldn't exist. That's true in some sense. But we (as enforcement of open software) should propagate standards, and SMPP should be obeyed as one. (my 2ct) 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-
Re: [Kannel-Users] Re: mBlox SMPP optional parameters
So interestingly this raises some very real issues for companies such as us in the market place who connect to the MBlox gateway as one of our aggregator partners and keep getting complained at that our installations of Kannel _don't_ support the extended parameters that Ian and the team have added. In meetings I do stress that Kannel supports the standard specs of SMPP 3.4 and therefore we shouldn't need to support the extended parameters that the MBlox gateway has been the argument back has always been that SMPP 3.4 specification _does_ allow extended parameters to be added. Therefore we have the issue here of either rebuilding Kannel against CVS every few months and adding in the MBlox changes or branching our own version and maintaining that. Obviously neither are ideal as with the first we don't get the bug fixes and updates from the group, but obviously with the second we're not diffing and patching files all the time. So.. what about the ability to have vendor specific #defines in the build? If you look at the SOAP code (which Nisan I think you wrote some of, and Mobileway wrote some of) there are two vendor specific formats in there for European carriers to support their own formats of XML. I agree they shouldn't be there as standard, but this could be a way of extending the SMPP support to proprietary formats. Stipe - any thoughts your side on how we could extract vendor specific code, but maybe still have it as a build option? Regards Alex Skywire/Enpocket
