----- Original Message ----- From: "Davy Chan" <[EMAIL PROTECTED]> To: "Matthew Hixson" <[EMAIL PROTECTED]> Cc: "devel" <[email protected]> Sent: Wednesday, February 09, 2005 7:04 PM Subject: Re: messageid DLR parameter -#- MailID:PAAA
> > 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. well there is already dlr_url, which if you use for each message can add quite a lot to the mesg size, so complaining about adding more for this is invalid i think > 3) This solution cannot be abstracted and used for all SMSC interfaces > (unless all you want is the 'ts' field reported for every SMSC). we are talking about abstraction are we not ? so if an interface does not inherently support a messageid, or some means of referencing a mesg from the SMSC point of view, then then its valid to be a void action if the interface doesn't support it actually it might help if we list which ones DO NOT have a message id like thing in the interface ? i just looked at SMASI for example, the Sequence, MsgReference, its kind of the same thing, however instead of being given the message ref by the other side (SMSC) the i/f tells the SMSC what the ref is. I still see it as the same concept? no ? yes ? we also have a HTTP interface - not using kannel tho - to a telco, it also has a messageid thing - basically the transaction no of the http get process.....so there... > 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 > **>>>> > **>>>> > **>>>> > **>>> > **>> > **>> > **> > **> >
