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] **
>
