1) Not everyone needs a DLR for every SMS sent. 2) This solutions would force the SMS Msg struct passed back and forth between the bearerbox and the smsbox to increase in size with data that might not be relevant. 3) This solution cannot be abstracted and used for all SMSC interfaces (unless all you want is the 'ts' field reported for every SMSC). 4) Kannel is not ONLY an HTTP<->SMPP gateway...It is also HTTP<->CIMD, HTTP<->EMI/UCP, HTTP<->SEMA, SMPP<->CIMD, SMPP<->EMI/UCP, SMPP<->SEMA, CIMD<->EMI/UCP, CIMD<->SEMA. Therefore, adding SMSC protcol specific things to the smsbox can hinder compatibility.
Yes, it's easy to make a quick hack to add the message-id to the SMS Msg struct for people ONLY connected via SMPP. But, what about the others? Would it not be a better idea to implement some mapping system between the UUID and the DLR's? After all, you get the UUID upon submission of the SMS via the sendsms function. I was planning on implementing this but it appears Alex trumped me on it and is trying to move his implementation from his private source tree to Kannel. Matthew (and others)...it's great to extend Kannel to fit your's (and possibly other's) needs. But, don't think that extension with limited scope MUST be added into Kannel. Instead, try to abstract your solution to the point where it can be implemented in a generic way that can benefit all users of Kannel (not just the SMPP group). I have many private hacks to Kannel that work only for certain situations (GSM modem hacks that requeue based on signal quality, hacked-SMPP TLA parsing, optimization for ARM7 processors, ROM-based bearerbox, etc). None of them are generic enough that I can submit it for review and voting. Instead, I keep my eyes glued to the mailing lists to see if anyone else might benefit from my hacks and I mail them privately. When I can make my hacks generic enough, I will try and submit them for a vote. If no one excepts it, then fine. But, I know that if my hacks are not general enough then they will be rejected. See ya... d.c. **>In-Reply-To: <[EMAIL PROTECTED]> **>From: Matthew Hixson <[EMAIL PROTECTED]> **>Subject: Re: messageid DLR parameter **>Date: Tue, 8 Feb 2005 14:25:59 -0800 **>To: devel <[email protected]> **> **>Is there a good reason for not adding this functionality? Sounds like **>a lot of us could make use of this. **> -M@ **> **>On Feb 8, 2005, at 1:09 PM, fred wrote: **> **>> **>> **>> **>>>you will probably have to do a hack yourself, for some reason these **>>>guys **>>>have resisted doing this for **>>>ages...us in our real world need to match up dlr receipts, in the **>>>first **>>case **>>>we use a transactionid along with the sendsms, **>>>but sometimes that doesn't work when you have multiple smpp **>>>connections to **>>>the same telco, and for some reason **>>>they send a dlr sometimes on a different connection from where it was **>>sent! **>>>So then the messageid comes useful. **>>> **>>>places to change.. **>>>urltrans.c **>>>add another case, eg **>>> case 'Z': /* message id */ **>>> if (octstr_len(request->sms.messageid)) { **>>> enc = octstr_duplicate(request->sms.messageid); **>>> octstr_url_encode(enc); **>>> octstr_append(result, enc); **>>> octstr_destroy(enc); **>>> } **>>> **>>> **>>>msg-decl.h **>>> OCTSTR(messageid); **>>> **>>>and of course you need to fill in messageid at the appropriate places **>>>in **>>>smsc_smpp etc... **>>> **>>>then you'll be able to add %Z in your dlr-url config **>>> **>>>cheers **>>> **>>> **>>>----- Original Message ----- **>>>From: "Hillel Bilman" <[EMAIL PROTECTED]> **>>>To: <[EMAIL PROTECTED]> **>>>Cc: "Kannel Devel" <[email protected]> **>>>Sent: Tuesday, February 08, 2005 8:33 PM **>>>Subject: messageid DLR parameter -#- MailID:PAAA **>>> **>>> **>>>>Dear Alex, **>>>> **>>>>Have you had a chance to add your code for receiving the messageid, **>>>received **>>>>back via the SubmitSMSResponse, via a DLR parameter to the CVS **>>repository? **>>>>This would be great if you have such code and you are prepared to **>>>>submit **>>>it. **>>>> **>>>>Thanks **>>>> **>>>> **>>>> **>>> **>> **>> **> **>
