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