Re: mBlox SMPP optional parameters
Alexander Malysh wrote: Hi Ian, please no vendor specific things in kannel (vote -0 ;))... Understood. But perhaps if someone could think of a way for users to submit any optional parameter in the range 0x1400 to 0x3fff without the tag being named specifically mBlox? (See SMPP v3.4 section 5.3.1) p.s. you should post your changes and they should be of interest for other users... and may be will be commited to cvs or at least part of those... I've got a few people testing it a bit more first. -- Ian Cass Thanks in advance! Ian Cass wrote: Hi guys, I spent a few hours at the end of last week making Kannel work with our SMPP vendor specific optional parameters that we (mBlox) have implemented for our PSMS solution. Should I submit the patch or would you rather not have vendor specific stuff in the Kannel? -- Ian Cass (mBlox)
Re: mBlox SMPP optional parameters
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, nisan - At 11:30 AM 2004/07/14, you wrote: Alexander Malysh wrote: Hi Ian, please no vendor specific things in kannel (vote -0 ;))... Understood. But perhaps if someone could think of a way for users to submit any optional parameter in the range 0x1400 to 0x3fff without the tag being named specifically mBlox? (See SMPP v3.4 section 5.3.1) p.s. you should post your changes and they should be of interest for other users... and may be will be commited to cvs or at least part of those... I've got a few people testing it a bit more first. -- Ian Cass Thanks in advance! Ian Cass wrote: Hi guys, I spent a few hours at the end of last week making Kannel work with our SMPP vendor specific optional parameters that we (mBlox) have implemented for our PSMS solution. Should I submit the patch or would you rather not have vendor specific stuff in the Kannel? -- Ian Cass (mBlox) www.clickatell.com Any message, anywhere Phone: +27 21 9487150
Re: mBlox SMPP optional parameters
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. Yep, that all makes complete sense. Abstraction is great provided you can find a way to make it work with everything. Perhaps Kannel needs some way that you can define optional input fields for the front end then a way to map them in the configuration file on to specific protocol output fields on the back end. That way you would have more flexibity to tune each particular deliverer without introducing vendor specific exceptions. I'll wander through the code see if I can do anything to demonstrate what I mean. -- Ian Cass so -1 for this going to CVS, nisan - At 11:30 AM 2004/07/14, you wrote: Alexander Malysh wrote: Hi Ian, please no vendor specific things in kannel (vote -0 ;))... Understood. But perhaps if someone could think of a way for users to submit any optional parameter in the range 0x1400 to 0x3fff without the tag being named specifically mBlox? (See SMPP v3.4 section 5.3.1) p.s. you should post your changes and they should be of interest for other users... and may be will be commited to cvs or at least part of those... I've got a few people testing it a bit more first. -- Ian Cass Thanks in advance! Ian Cass wrote: Hi guys, I spent a few hours at the end of last week making Kannel work with our SMPP vendor specific optional parameters that we (mBlox) have implemented for our PSMS solution. Should I submit the patch or would you rather not have vendor specific stuff in the Kannel? -- Ian Cass (mBlox) www.clickatell.com Any message, anywhere Phone: +27 21 9487150
Re: Fw: WapPush delivery problem
Yury Mikhienko wrote: I tried to use the Openwave Wap Push library for push SI over kannel PPG. Push message was accepted by kannel PPG and sent (and delevered) to a mobile phone (NOKIA 7650) successfully, but I did not get a SI on the phone incoming messages . May be the mobile does not understand it, but if I try to push default kannel test WapPush - it works just fine with me. Can anyone help me to solve this problem? kannel logs: -- FOR OPENWAVE WapPush - 2004-07-07 09:43:28 [392] [6] DEBUG: esm_class: 67 = 0x0043 2004-07-07 09:43:28 [392] [6] DEBUG: protocol_id: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: priority_flag: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: schedule_delivery_time: NULL 2004-07-07 09:43:28 [392] [6] DEBUG: validity_period: 040708094328016+ 2004-07-07 09:43:28 [392] [6] DEBUG: registered_delivery: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: replace_if_present_flag: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: data_coding: 4 = 0x0004 2004-07-07 09:43:28 [392] [6] DEBUG: sm_default_msg_id: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: sm_length: 122 = 0x007a 2004-07-07 09:43:28 [392] [6] DEBUG: short_message: 2004-07-07 09:43:28 [392] [6] DEBUG:Octet string at 0x8195698: 2004-07-07 09:43:28 [392] [6] DEBUG: len: 122 2004-07-07 09:43:28 [392] [6] DEBUG: size: 1024 2004-07-07 09:43:28 [392] [6] DEBUG: immutable: 0 2004-07-07 09:43:28 [392] [6] DEBUG: data: 06 05 04 0b 84 23 f0 00 06 32 ae a9 4f 70 65 6e .#...2..Open 2004-07-07 09:43:28 [392] [6] DEBUG: data: 77 61 76 65 20 57 41 50 20 50 75 73 68 20 4c 69 wave WAP Push Li 2004-07-07 09:43:28 [392] [6] DEBUG: data: 62 72 61 72 79 2c 20 4a 61 76 61 20 45 64 69 74 brary, Java Edit 2004-07-07 09:43:28 [392] [6] DEBUG: data: 69 6f 6e 20 31 2e 35 00 8d be c3 93 02 05 6a 00 ion 1.5...j. 2004-07-07 09:43:28 [392] [6] DEBUG: data: 45 c6 0c 03 77 61 70 2e 6d 6f 62 69 63 6f 6d 6b E...wap.mobicomk 2004-07-07 09:43:28 [392] [6] DEBUG: data: 2e 72 75 00 0a c3 07 20 04 06 07 09 42 36 10 c3 .ru B6.. 2004-07-07 09:43:28 [392] [6] DEBUG: data: 07 20 04 06 08 09 42 36 01 03 64 6f 77 6e 6c 6f . B6..downlo 2004-07-07 09:43:28 [392] [6] DEBUG: data: 61 64 20 6c 69 6e 6b 00 01 01 ad link... 2004-07-07 09:43:28 [392] [6] DEBUG:Octet string dump ends. 2004-07-07 09:43:28 [392] [6] DEBUG: SMPP PDU dump ends. 2004-07-07 09:43:28 [392] [6] DEBUG: SMPP[SMPP_TR]: Got PDU: 2004-07-07 09:43:28 [392] [6] DEBUG: SMPP PDU 0x8195590 dump: 2004-07-07 09:43:28 [392] [6] DEBUG: type_name: submit_sm_resp 2004-07-07 09:43:28 [392] [6] DEBUG: command_id: 2147483652 = 0x8004 2004-07-07 09:43:28 [392] [6] DEBUG: command_status: 0 = 0x 2004-07-07 09:43:28 [392] [6] DEBUG: sequence_number: 36 = 0x0024 2004-07-07 09:43:28 [392] [6] DEBUG: message_id: 225AAF4D 2004-07-07 09:43:28 [392] [6] DEBUG: SMPP PDU dump ends. ... - FOR KANNEL TEST_PPG WapPush -- 2004-07-07 10:40:25 [392] [6] DEBUG: esm_class: 67 = 0x0043 2004-07-07 10:40:25 [392] [6] DEBUG: protocol_id: 0 = 0x 2004-07-07 10:40:25 [392] [6] DEBUG: priority_flag: 0 = 0x 2004-07-07 10:40:25 [392] [6] DEBUG: schedule_delivery_time: NULL 2004-07-07 10:40:25 [392] [6] DEBUG: validity_period: 040708104025016+ 2004-07-07 10:40:25 [392] [6] DEBUG: registered_delivery: 0 = 0x 2004-07-07 10:40:25 [392] [6] DEBUG: replace_if_present_flag: 0 = 0x 2004-07-07 10:40:25 [392] [6] DEBUG: data_coding: 4 = 0x0004 2004-07-07 10:40:25 [392] [6] DEBUG: sm_default_msg_id: 0 = 0x 2004-07-07 10:40:25 [392] [6] DEBUG: sm_length: 78 = 0x004e 2004-07-07 10:40:25 [392] [6] DEBUG: short_message: 2004-07-07 10:40:25 [392] [6] DEBUG:Octet string at 0x81956e0: 2004-07-07 10:40:25 [392] [6] DEBUG: len: 78 2004-07-07 10:40:25 [392] [6] DEBUG: size: 1024 2004-07-07 10:40:25 [392] [6] DEBUG: immutable: 0 2004-07-07 10:40:25 [392] [6] DEBUG: data: 06 05 04 0b 84 23 f0 01 06 05 ae 8d bf c3 93 02 .#.. 2004-07-07 10:40:25 [392] [6] DEBUG: data: 05 6a 00 45 c6 0c 03 77 61 70 2e 69 6f 62 6f 78 .j.E...wap.iobox 2004-07-07 10:40:25 [392] [6] DEBUG: data: 2e 63 6f 6d 00 0a c3 05 20 03 05 07 14 10 c3 04 .com ... 2004-07-07 10:40:25 [392] [6] DEBUG: data: 20 04 09 08 01 03 57 61 6e 74 20 74 6f 20 74 65.Want to te 2004-07-07 10:40:25 [392] [6] DEBUG: data: 73 74 20 61 20 66 65 74 63 68 3f 00 01 01 st a fetch?... 2004-07-07 10:40:25 [392] [6] DEBUG:Octet string dump ends. 2004-07-07 10:40:25 [392] [6] DEBUG: SMPP PDU dump ends. 2004-07-07 10:40:25 [392] [6] DEBUG: SMPP[SMPP_TR]: Got PDU: 2004-07-07
mmsbox
I'm considering writing an mmsbox(*), but until I go ahead and code it, I need to get a few things straight about the architecture of Kannel, and how an mmsbox would fit into it. Here' what I'm thinking about doing: Mobile phone submits MMS mmsbox listening for HTTP requests receives MMS from phone mmsbox decodes the MMS to an RFC-822-format mail. mmsbox relays decoded MMS to an SMTP server. The SMTP server either stores or relays the mail. If it's a local user, the SMTP server somehow relays the mail back to the mmsbox. mmsbox sends notification to recipient with the appropriate message ID. Phone receives notification. Phone makes request to URL from notification. Kannel receives request for URL. Message ID from URL is used to look up mail from IMAP storage Fetched mail from storage is reconverted to binary MMS format. Encoded MMS is sent in response to phone. Does this look right? From what I can tell about Kannel, it currently communicates heavily between the bearerbox and the smsboxes and wapboxes.. I suppose that the received MMS COULD be sent to the bearerbox, sent either back to the same mmsbox or another mmsbox, and from there relayed to the SMTP server. Likewise, when a client tries to fetch a message, the request COULD be received by mmsbox, sent on to bearerbox which asks either the same mmsbox or another one to fetch the mail from storage and send it back to bearerbox, which in turn sends it back to the mmsbox that got the request and sends the response to the client. This setup is MUCH more complex, adds a lot of internal network traffic, BUT gives a lot of control back to the bearerbox, where I believe it belongs, right? *: I'm very keen on doing this, but as I work as a programmer for at company that develops and hosts mobile solutions, I should ask my boss for permission to develop this mmsbox for Kannel. He's however on holiday, so right now I'm just spending my time thinking about how I should design this.. BTW, how do you people convince your managers to allow you to release this stuff under BSD license? My best arguments right now are the fact that a bunch of VERY knowledgeable people will review every little bit of design and code, and will probably be helpful in perfecting the software at no cost to the company. What else can I throw at them? -- Søren Hansen [EMAIL PROTECTED]
Re: [FYI] cvs currently throws: internal error
James just fixed the corrupted file in cvs root. Applause to James please! ;) 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
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: SMPP Server
Alexei Pashkovsky wrote: I've modified the smsc_smpp module to behave as smpp server. Modifications were done on CVS dated about 2 weeks ago. At the moment it seems to work smooth, but probably more features should be added, also I believe there're memory leaks. Authentication done using mysql database. At the moment it simply allows users to connect with SMPP gateway and send messages thru, after receiving the message from smpp, it matches user/pass from DB and resends the sms with Kannel HTTP query to the gateway. Middle layer can serve as billing system as well. To simplify the whole thing, the smsbox is not being used. The original Kannel functionality is kept, while the smsc driver is called smpp2, and can be activated from config file if needed. Is there any interest on adding this to Kannel CVS ? definetly! +1 is reviewing this. Please send the patch in 'diff -u' format to the list or directly. Stipe P.S. at the moment we supply this solution to some of our customers, but I'm willing to share the source so someone can help me in bugtracing :) BTW, our smppbox is currently also to be most likely to enter the Kannel CVS as seperate module. 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
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-
msg_id in SMPP
Tolj, The type of msg_id in submit_sm_resp is C-Octet_String. What kind of number can be fill in msg_id field? hexadecimal or decimal? Best Regards, Guanghua Hou UTStarCom BJRD 010-85205651
RE: SMPP Server
Hi, I'm working in the concept for a smppbox for Kannel. I think we can share information, and help. Thanks === Ing. Csar Garca email: [EMAIL PROTECTED] CEOS Integradores de Sistemas, C.A. Barcelona, Edo. Anzoategui Telf. / Fax : +58-281-2749969
[no subject]
I not found the smsc_smpp2 in the CVS, you can send me the modification. Thanks === Ing. Csar Garca email: [EMAIL PROTECTED] CEOS Integradores de Sistemas, C.A. Barcelona, Edo. Anzoategui Telf. / Fax : +58-281-2749969
