Re: UCP 52 behaviour
As I said it, some operators does not allow notifications. That means that if you try to ask a DLR, your are notified of failure everytime, and you can't send... Maybe it's not the normal way of running an SMSC, but the what I'm sure of is that I can't be notified using the standard DLR mechanism... Mat. Andreas Fink wrote: On Dienstag, August 19, 2003, at 05:01 Uhr, Mat wrote: Hi list, I was wondering why kannel does not have a callback mechanism so that when an MT fails and an NACK is returned after the UCP 52, we can directly update our DB. As some operators does not allow notifications (UCP 53), we have to grep/perl/sed our logfiles, which can be heavy and intrinsecly inconsitent. The current DLR mechanism does that very well, so I'm pretty sure the current code base allow to add this easily. We would just have to provide an "mtID" during the call to /cgi-bin/sendsms , which would be reforwarded to an url defined in the config file, or given as an urlencoded parameter to sendsms. Did I miss something? Are there any people who implemented such feature? Does that feature interrest someone ? If we provide a patch, will it be integrated ? I dont know what your problem is... if the message is NACK'ed at submission, you get SMSC delivery failed report... Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] --
UCP 52 behaviour
Hi list, I was wondering why kannel does not have a callback mechanism so that when an MT fails and an NACK is returned after the UCP 52, we can directly update our DB. As some operators does not allow notifications (UCP 53), we have to grep/perl/sed our logfiles, which can be heavy and intrinsecly inconsitent. The current DLR mechanism does that very well, so I'm pretty sure the current code base allow to add this easily. We would just have to provide an "mtID" during the call to /cgi-bin/sendsms , which would be reforwarded to an url defined in the config file, or given as an urlencoded parameter to sendsms. Did I miss something? Are there any people who implemented such feature? Does that feature interrest someone ? If we provide a patch, will it be integrated ? Thank you in advance! Mat.
Re: at2 DLR weirdness
Answers follows... Oded Arbel wrote: On Sunday 20 July 2003 18:47, Mat wrote: We are connected directly to an operator which is using an SMSC running under OpenVMS. What protocol do you use to connect EMI4.0 Apparently, the information of what they are running is a bit secret, which is not very surprising. It is to me. After discussing with them, it appears they effectivly use a CMG solution. Is it possible to fingerprint an SMSC ? There are some unique "bugs" and features that can be detected on some SMSCs of some providers. I don't think a comprehensive list has ever been set up. I also think that the Kannel project is in a unique situation that allows us to do just that.. Great! Maybe the bug tracking system that kannel use could have other branch with all SMSC implemations that we encountered. That could also help to have a map with all compatibility issues reported in... Mat.
Re: at2 DLR weirdness
We are connected directly to an operator which is using an SMSC running under OpenVMS. I know that Compaq is providing LogicaCMG SMSC solutions, it may be that... Apparently, the information of what they are running is a bit secret, which is not very surprising. Is it possible to fingerprint an SMSC ? But what is really strange to me is most of time it works fine, and only a few messages are affected. How do you think I should investigate ? Many thanks! Oded Arbel wrote: On Sunday 20 July 2003 16:12, Mat wrote: Ok! So if I understand well, I've to spank my operator because he has a broken SMSC ? Are you using your provider SMSC directly or through some abstraction layer ? if its the former, then I'd wager we need to probe the issue deeper on Kannel's side : I learned not to mistrust the major SMSC providers (except comverse ;-) - its more likely to be our fault. if its the later, then you most definetly need to spank your operator - I learned that most operator's internal software departments suck. Do you think I can discuss with them if I provide them network message IDs of lost messages ? Is it easy to make these IDs appear in the kannel logfiles ? They appear on the AT2 log after CMGS response.
Re: at2 DLR weirdness
Oded Arbel wrote: Mat wrote: The goal is to monitor the SMSC connection with the GSM modem. For this, I send a specific keyword with the modem, and I wait for the answer. In order to make the tests more reliable, I use a dlrmask=31 when I send the MO, so our monitoring don't shout for a stupid network problem. This part works almost fine, but the success isn't as accurate: Sometimes when I send an SMS with the modem, I got a DLR call with a value of 1 which should mean that the MO has been delivered. Before the dlrvalue=1, I can have a DLR call with dlrvalue=8 or dlrvalue=4. 8 (SMSC_SUCCESS) means that the modem successfuly sent the message to the network and received the network's message ID for that SM. 4 (BUFFERED) means that the message was stored on the network (modem's SMSC peer) but was not forwarded to the recipient yet. this message will only be received if the network was unable to deliver the SM imidietly. The fact is that these messages never came to my servers, and I have incomming traffic. dlrvalue = 1 (DELIVERED) means that the destination acknowledged the reception of the message and the modem's peer SMSC has forwarded that acknowledgment to the modem. when that DLR is sent out by kannel, you should have already received the MO on your server, if not - check your SMSC connection - apparently, your SMSC acknowledges SM reception for you but does not forward you the message. At m-Wise we implement similar functionality, and noticed that at times we lose messages on the network even though a DELIVERED dlr has been received. this is usually due to some SMSC abstraction (we usually do not conenct directly to the network SMSCs, but to a network operator's abstraction layer) that drops messages on the floor at convinient times. -- Oded Arbel Ok! So if I understand well, I've to spank my operator because he has a broken SMSC ? Do you think I can discuss with them if I provide them network message IDs of lost messages ? Is it easy to make these IDs appear in the kannel logfiles ? Thank you!
at2 DLR weirdness
Hi list, I have the following setup: -A Wavecom GSM modem connected to a linux box, running kannel 1.2.1 (stable) compiled by hand -An EMI SMSC connection The goal is to monitor the SMSC connection with the GSM modem. For this, I send a specific keyword with the modem, and I wait for the answer. In order to make the tests more reliable, I use a dlrmask=31 when I send the MO, so our monitoring don't shout for a stupid network problem. This part works almost fine, but the success isn't as accurate: Sometimes when I send an SMS with the modem, I got a DLR call with a value of 1 which should mean that the MO has been delivered. Before the dlrvalue=1, I can have a DLR call with dlrvalue=8 or dlrvalue=4. The fact is that these messages never came to my servers, and I have incomming traffic. What do you gentlemen think it can be? There are so many point of failures that I can't figure it out... For me the bug can come from : - Kannel at2 driver / dlr handling - The GSM modem - The operator SMSC Thank for your precious time and knowledge... Mat.
