got DLR but could not find message or was not interested in it
Remember this one ? got DLR but could not find message or was not interested in it I'm getting this for messages received from CMDA handsets, regardless of DLR requested or not. The only diff in PDU from GSM based is the class is 2 instead of null. I've tried setting msg-id-type to 0,1,2 3 in various cvs versions ( latest being 3 weeks old ) No luck. Any ideas ? Regards Wayne Smithers 5th Finger Pty Ltd
Re: regarding SMPP - EMI/UCP mapping
SMPPBOX?? Is this a standard Kannel component? If not, where can we get that :-) TIA, JS - Original Message - From: Stipe Tolj [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Saturday, January 04, 2003 5:49 AM Subject: Re: regarding SMPP - EMI/UCP mapping S.Ramakrishnan wrote: Hi! Just wanted to know where we can get SMPP to EMI protocol Mapping.. Any RFC or Document on that? no, there is no RFC or document that would cover that. At least I don't know such thing. You may be able to use SMPP server side logic to fead an EMI client side again. Basically that is what we do with our smppbox, an SMPP v3.4 server based on Kannel. We feed the Kannel abstracted msg structure again to bearerbox and there you can have an UCP/EMI link to continue the delivery. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: got DLR but could not find message or was not interested in it
On Montag, Januar 6, 2003, at 12:11 Uhr, Wayne wrote: Remember this one ? got DLR but could not find message or was not interested in it I'm getting this for messages received from CMDA handsets, regardless of DLR requested or not. The only diff in PDU from GSM based is the class is 2 instead of null. I've tried setting msg-id-type to 0,1,2 3 in various cvs versions ( latest being 3 weeks old ) No luck. Any ideas ? Regards Wayne Smithers 5th Finger Pty Ltd can you provide a dump of the messages being sent and the answers received back? I presume the sent message and the received one are not looking the same to kannel either because of number type or message id. If you're using SMPP, there's some configuration variables to get around this problem. Andreas Fink Fink Consulting GmbH --- Tel: +41-61-332 Fax: +41-61-331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com ---
Performance...
I sent out 20 messages using the at2 smsc. From 3 of them, I never got a delivered-to-smsc ACK (and neither an NACK). From most of them but a few, I got the DLR status message back. I presume, they got lost whilst sending messages. Is this not a bad performance rate? Or do I see things wrong? -- Rene Kluwen Chimit Software
Re: regarding SMPP - EMI/UCP mapping
Jeetendra Singh wrote: SMPPBOX?? Is this a standard Kannel component? If not, where can we get that :-) the smppbox is a daemon (similiar as smsbox) that Wapme has developed as SMPP v3.4 server. It will be released as open source to the Kannel project in the near future. No, currently we can *not* provide anything for it. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: got DLR but could not find message or was not interested in it
Hi Wayne, As Andreas suggest check the pdu dumps - you might be receiving a deliver_sm esm_class of 0x01 which from SMPP specs is 'SMSC Delivery Receipt' which should be included (I have it in mine). Test with attached patch... cheers, Alan On Tue, 2003-01-07 at 00:11, Wayne wrote: Remember this one ? got DLR but could not find message or was not interested in it I'm getting this for messages received from CMDA handsets, regardless of DLR requested or not. The only diff in PDU from GSM based is the class is 2 instead of null. I've tried setting msg-id-type to 0,1,2 3 in various cvs versions ( latest being 3 weeks old ) No luck. Any ideas ? Regards Wayne Smithers 5th Finger Pty Ltd -- Alan McNatty [EMAIL PROTECTED] Index: gw/smsc/smsc_smpp.c === RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v retrieving revision 1.22 diff -r1.22 smsc_smpp.c 710c710,711 if ((pdu-u.deliver_sm.esm_class == 0x02 || --- if ((pdu-u.deliver_sm.esm_class == 0x01 || pdu-u.deliver_sm.esm_class == 0x02 ||
Re: 1 bug and some queries with SMPP driver
Queries: Should the SMPP driver treat message queue full errors in a similar manner to throttling errors as I think some SMSC operators request this behaviour. And it makes sense to retry a message that receives a message queue full error. A message queue full error is quite different from a throttling error - at least in my case. Throttling error is issued when I'm sending too much messages to the SMSC. The correct behaviour then is to slow down (I usually wait for a second per 8 fired messages). The queue full error is something completelly different (at least in my case). I get that one when the recepient can't receive any more SMS-s, and the SMSC has some SMS-s waiting in the queue. The queue in the SMSC is per subscriber and ussually holds 10 SMS's. This happens when the subscirber has turned off his phone or is otherwise unreachable, so the queue full error is not going to be resolved until the subscriber turns off his phone or the messages in the SMSC are expired. I think kannel's behaviour to these errors should be accordingly different. -- Damjan Georgievski
Solaris packaging
Hello all, The solaris directory in root cvs directory contains a pkginfo file but does not contain the template pkginfo.tmpl which is required by the mk-solaris-package.sh script. Hence the pkginfo file should be removed from cvs and the template added to get things working. Note: I've created the template by copying the pkginfo file and added the VERSION_NUMBER. cheers, Alan -- Alan McNatty [EMAIL PROTECTED] PKG=WAkannel-VERSION_NUMBER NAME=kannel ARCH=sparc VERSION=cvs CATEGORY=application VENDOR=Kannel project EMAIL=[EMAIL PROTECTED] PSTAMP=Andreas Fink BASEDIR=/usr/local CLASSES=none
Re: Solaris packaging
Alan McNatty wrote: Hello all, The solaris directory in root cvs directory contains a pkginfo file but does not contain the template pkginfo.tmpl which is required by the mk-solaris-package.sh script. Hence the pkginfo file should be removed from cvs and the template added to get things working. Note: I've created the template by copying the pkginfo file and added the VERSION_NUMBER. done and commited to cvs. Thanks Alan. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf Tel: +49-211-74845-0 Fax: +49-211-74845-299 E-Mail: [EMAIL PROTECTED] Internet: http://www.wapme-systems.de --- wapme.net - wherever you are
Re: got DLR but could not find message or was not interested in it
- Click - sorry Wayne, that won't be it if the dlr_find call is reporting it can't find it - ignore my last email. The other problem I had with one CDMA SMSC via SMPP was receiving the number as source not destination, ie ... see attached patch (which is not suggested to be committed to cvs, etc). Add some debugging to print out what you're adding and what you're looking for, etc... let me know how you get on. cheers, Alan On Tue, 2003-01-07 at 00:11, Wayne wrote: Remember this one ? got DLR but could not find message or was not interested in it I'm getting this for messages received from CMDA handsets, regardless of DLR requested or not. The only diff in PDU from GSM based is the class is 2 instead of null. I've tried setting msg-id-type to 0,1,2 3 in various cvs versions ( latest being 3 weeks old ) No luck. Any ideas ? Regards Wayne Smithers 5th Finger Pty Ltd -- Alan McNatty [EMAIL PROTECTED] Index: gw/smsc/smsc_smpp.c === RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v retrieving revision 1.22 diff -r1.22 smsc_smpp.c 784c785 octstr_get_cstr(pdu-u.deliver_sm.destination_addr), /* destination */ --- octstr_get_cstr(pdu-u.deliver_sm.source_addr), /* source */
