Hi, Firstly thanks for all the feedback and suggested methods to handle it, I will review and see what makes the most sense for me to use. In the meantime, if they reply to my request for change on this I will let you all know.
I will post the changes I end up doing to the code as a diff to the user list, in case someone else finds it useful for their setup, although of course it will be 100% unsuitable for ever being merged to the main code base. If anyone wishes to know the operator I can disclose it off list. Thanks, Kyriacos On 18/02/2011 13:51, Nikos Balkanas wrote: >> There's no reference to unique id's and it says "The format for this >> Delivery Receipt message is SMSC vendor specific". > > Nope, you are wrong. Please read the spec again. This is what it says > Ch 2.11 p 34: > > The following fields are relevant in the deliver_sm and data_sm > operations when used for transmitting delivery receipts. > • source address (i.e. source_addr_ton, source_addr_npi, source_addr) > The source address will be taken from the destination address of the > original short message which generated the delivery receipt. > • destination address (i.e. dest_addr_ton, dest_addr_npi, > destination_addr) > The destination address will be taken from the source address of the > original short message which generated the delivery receipt. > • esm_class > • message_state > • network_error_code > • receipted_message_id > > Also in p 67 Ch 4.4.2: Submit_sm_resp: > Body: message_id : > This field contains the SMSc message ID of the submitted message. It > may be used at a later stage to query the status of a message, cancel > or replace the message. > > p. 128 Ch 4.2.23: Mandatory SMPP parameters -> message-id: > The unique message identifier reference assigned by the SMSC to each > submitted short message... > > Lastly, and most importantly, p. 139 Ch 5.3.2.12: SMPP Optional > Parameter tag definitions->receipted_message_id: > The receipted_message_id parameter indicates the ID of the message > being receipted in an SMSC Delivery Receipt. This is the opaque SMSC > message identifier that was returned in the message_id parameter of > the SMPP response PDU that acknowledged the submission of the original > message. > > As you can see, in the main body of the spec there is no ambiguity of > what the receipted message-id is. In the appendix, the format only is > ambiguous, the substance, as indicated in the body, is not. > > BR, > Nikos > ----- Original Message ----- From: Alejandro Guerrieri > To: Nikos Balkanas > Cc: Kyriacos Sakkas ; Alan McNatty ; users > Sent: Friday, February 18, 2011 1:05 PM > Subject: Re: Odd DLR msg ID from operator > > > This is what the spec says (Appendix B): > > > SMPP provides for return of an SMSC delivery receipt via the > deliver_sm or data_sm PDU, which indicates the delivery status of the > message. > The informational content of an SMSC Delivery Receipt may be inserted > into the short_message parameter of the deliver_sm operation. The > format for this Delivery Receipt message is SMSC vendor specific but > following is a typical example of Delivery Receipt report. > “id:IIIIIIIIII sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done > date:YYMMDDhhmm stat:DDDDDDD err:E Text: . . . . . . . . .” > The fields of the above delivery receipt example are explained in the > following table: > > > [table explaining the parameters from the example] > > > > There's no reference to unique id's and it says "The format for this > Delivery Receipt message is SMSC vendor specific". > > > In other words, the SMSC vendor could use whatever they fit convenient > and it wouldn't be breaking the spec at all. > > > Nonsense, I know, sadly the SMSC Developers Forum was disbanded in > 2007 so there's nowhere to go and propose a spec review,I guess. > > > Regards, > > > Alex > > > > > > > > > 2011/2/18 Nikos Balkanas <[email protected]> > > Yes, I've seen this kind of mess many times before... and shockingly > it's not contrary to the spec. > > > > But it is contrary to the spec. Although DLR format may be "blurry", a > unique ID is required and it should be the same in submit_sm_resp and > deliver_sm (hex conversion notwithstanding). > > BR, > Nikos > ----- Original Message ----- From: Alejandro Guerrieri > To: Kyriacos Sakkas > Cc: Nikos Balkanas ; Alan McNatty ; users > Sent: Friday, February 18, 2011 12:47 PM > > Subject: Re: Odd DLR msg ID from operator > > > Yes, I've seen this kind of mess many times before... and shockingly > it's not contrary to the spec. > > > The spec is really blurry on DLR's, it only provides an "example" of > what a DLR would look like, but it doesn't enforce any particular format. > > > Kannel only accept a couple of the more popular formats, but > definitely needs help dealing with non-standard formats, specially > when the id's doesn't even match. > > > Perhaps a simpler approach would have been to regex-match for > "^\d{2}\/" and remove it if present? > > > Regards, > > > Alex > > > 2011/2/18 Kyriacos Sakkas <[email protected]> > > Hi All, > > This is definitely an SMPP connection, whether it actually it is SMPP, > thats a different story :). > > I have already asked the relevant (big name) operator whether this is > something they can change. To give you the full story we have multiple > binds with this operator, each bind used to bill (MT billing) a > different amount. Now the first issue I noticed is that no matter what > bind you sent from, the DLR comes from the 0 rated bind. After asking > them about this they replied that yes that's just how it is, so I edited > the source files and chhanged the mysql dlr functions to handle this, > while not breaking any other connections I have - I made the smsc field > length=12 (any longer smsc-id names get truncated to 12 chars on insert) > , put smsc=LEFT(?,12) in the queries to match the longer smsc-id s I use > for this operator (which have to be unique in order for me to be able to > specify which one the message goes out from). > > So that was fixed.. after fixing that I noticed that DLRs were not > matching again, and spotted that they are changing the ID string along > the way. > > So I can solve this by doing something similar to the above, chopping > the first 2 chars in the mysql queries, but this one will not be easy to > do and retain compatibility with the rest of the normally behaving binds > to other operator that I have. Running a dedicated server for this guys > is an option, I would just rather not if I can. I guess I could set a > conf parameter that passes a flag to the dlr functions that tels them to > change queries (like how MSISDNs are added to queries for EMI/UCP & > SMPP) but that would just seriously brake my upstream compatibility, > plus my programing skill are probably not up to it. > > So yep if someone things that this can be done with pure MYSQL triggers > or something like that, which does not need heavy kannel changes, please > let me know. > > Thanks, > Kyriacos Sakkas > > > On 18/02/2011 07:50, Nikos Balkanas wrote: > > Hi, > > I was asking for the raw logs, to verify that is indeed SMPP traffic, > as stated from the PDU names. If it is, then it seems contrary to the > spec. He could try talking to his SMSc about it. > > BR, > Nikos > ----- Original Message ----- From: "Alan McNatty" <[email protected]> > To: "Alejandro Guerrieri" <[email protected]> > Cc: "users" <[email protected]> > Sent: Thursday, February 17, 2011 11:36 PM > Subject: Re: Odd DLR msg ID from operator > > > > Hi Alex, > > I wonder (just off the top of my head) .. if using DB DLR with stored > procedure / trigger could work by stripping the prefix on insert? > > Just a random idea that could be worth looking into - possible/obvious > performance implication. > > Cheers, > Alan > > > On 18/02/11 10:26, Alejandro Guerrieri wrote: > > Looks like the SMSC is doing fancy stuff with their DLR's. > > If that's the case, there's no easy fix, it's either asking your SMSC > to change it (probably unlikely) or tweaking the code to ignore those > two digits before the first "/". > > Regards, > > Alex > > On Thu, Feb 17, 2011 at 10:30 AM, Kyriacos Sakkas > <[email protected] <mailto:[email protected]>> wrote: > > Hi, > > Wondering if anyone can help with this. > When I submit an sms I get the following ID in the submit_sm_resp: > *01*//415ce0ae676d19fc000000000000000000000000/1231615516543 > > When the message is delivered I get the following id in the > deliver_sm: > *04*/415ce0ae676d19fc000000000000000000000000/1231615516543 > > As you can see those two numbers are not the same, leading to the > query not matching. > > Any help will be greatly appreciated, I can provide further info > if needed. > > Regards, > Kyriacos Sakkas > > -- Kyriacos Sakkas > Development Team > Netsmart > Tel: + 357 22 452565 > Fax: + 357 22 452566 > Email: [email protected] <mailto:[email protected]> > http://www.netsmart.com.cy > > Taking Business to a New Level! > > ** Confidentiality Notice: The information contained in this email > message may be privileged, confidential and protected from > disclosure. > If you are not the intended recipient, any dissemination, > distribution, > or copying of this email message is strictly prohibited. > If you think that you have received this email message in error, > please > email the sender at [email protected] > <mailto:[email protected]> ** > > > > > > > > -- > Kyriacos Sakkas > Development Team > Netsmart > Tel: + 357 22 452565 > Fax: + 357 22 452566 > Email: [email protected] > http://www.netsmart.com.cy > > Taking Business to a New Level! > > ** Confidentiality Notice: The information contained in this email > message may be privileged, confidential and protected from disclosure. > If you are not the intended recipient, any dissemination, distribution, > or copying of this email message is strictly prohibited. > If you think that you have received this email message in error, please > > email the sender at [email protected] ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: [email protected] http://www.netsmart.com.cy Taking Business to a New Level! ** Confidentiality Notice: The information contained in this email message may be privileged, confidential and protected from disclosure. If you are not the intended recipient, any dissemination, distribution, or copying of this email message is strictly prohibited. If you think that you have received this email message in error, please email the sender at [email protected] **
