Re: Odd DLR msg ID from operator
That is currently my plan. Waiting for a response from them hopefully today. I would be very surprised if it was only me that complained about this. Kyriacos On 21/02/2011 09:10, Nikos Balkanas wrote: I still think that your best bet would be to contact your provider. I have no experience dealing with them, but it seems to me that if he is a big SMPP one, then all of his clients will have the same problem. That means if the ticket is still active, the more reason for him to change. If not, he might know what his other clients have done about it. BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: Kyriacos Sakkas kyria...@netsmart.com.cy Cc: users us...@vm1.kannel.org Sent: Monday, February 21, 2011 1:16 AM Subject: Re: Odd DLR msg ID from operator Hi Kyriacos, Taking this a step further as I was wondering if this was actually possible. Caveat: I'm thinking out loud in pgsql (more user than admin/guru) and not mysql .. An insert/update/delete trigger to strip out the prefix (eg 01//) wouldn't be a problem assuming you could identify the smsc id, etc (so can avoid impacting those that are behaving). The issue as I see is with the select when you finally get your DLR .. If the 04/ was consistent you would just add it as part of the insert trigger which would work fine. But I'm guessing the '04/' is just an example and is varying so you need would need a view (pref materialized) do strip it out so your select matches. But .. you can't insert / update, etc on a view (in postgres .. as far as I know) so as it stands with the existing kannel config I can't see a way of doing this if this is what you are seeing. However, it might be do-able with a combination of views, triggers, schemas (so you can have a table and a view of the same name but in different schema) and/or different read/write user (associated with different schema). But some code change to support schemas / users would be required in kannel. You would need to check out what mysql can do here .. might not be impossible .. for example, from what I can see online (no personal experience) Oracle seems to support an Instead Of trigger so you could use / handle inserts/etc on a view. Maybe someone with a bit more experience with DB wrangling might be able to help you further with mysql. As Alex notes I suspect a simpler solution might be to support a regexp on DLR details in kannel ;) Cheers, Alan On 18/02/11 22:35, Kyriacos Sakkas wrote: 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. -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy **
Re: Odd DLR msg ID from operator
Hi Kyriacos, Taking this a step further as I was wondering if this was actually possible. Caveat: I'm thinking out loud in pgsql (more user than admin/guru) and not mysql .. An insert/update/delete trigger to strip out the prefix (eg 01//) wouldn't be a problem assuming you could identify the smsc id, etc (so can avoid impacting those that are behaving). The issue as I see is with the select when you finally get your DLR .. If the 04/ was consistent you would just add it as part of the insert trigger which would work fine. But I'm guessing the '04/' is just an example and is varying so you need would need a view (pref materialized) do strip it out so your select matches. But .. you can't insert / update, etc on a view (in postgres .. as far as I know) so as it stands with the existing kannel config I can't see a way of doing this if this is what you are seeing. However, it might be do-able with a combination of views, triggers, schemas (so you can have a table and a view of the same name but in different schema) and/or different read/write user (associated with different schema). But some code change to support schemas / users would be required in kannel. You would need to check out what mysql can do here .. might not be impossible .. for example, from what I can see online (no personal experience) Oracle seems to support an Instead Of trigger so you could use / handle inserts/etc on a view. Maybe someone with a bit more experience with DB wrangling might be able to help you further with mysql. As Alex notes I suspect a simpler solution might be to support a regexp on DLR details in kannel ;) Cheers, Alan On 18/02/11 22:35, Kyriacos Sakkas wrote: 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.
Re: Odd DLR msg ID from operator
I still think that your best bet would be to contact your provider. I have no experience dealing with them, but it seems to me that if he is a big SMPP one, then all of his clients will have the same problem. That means if the ticket is still active, the more reason for him to change. If not, he might know what his other clients have done about it. BR, Nikos - Original Message - From: Alan McNatty a...@catalyst.net.nz To: Kyriacos Sakkas kyria...@netsmart.com.cy Cc: users us...@vm1.kannel.org Sent: Monday, February 21, 2011 1:16 AM Subject: Re: Odd DLR msg ID from operator Hi Kyriacos, Taking this a step further as I was wondering if this was actually possible. Caveat: I'm thinking out loud in pgsql (more user than admin/guru) and not mysql .. An insert/update/delete trigger to strip out the prefix (eg 01//) wouldn't be a problem assuming you could identify the smsc id, etc (so can avoid impacting those that are behaving). The issue as I see is with the select when you finally get your DLR .. If the 04/ was consistent you would just add it as part of the insert trigger which would work fine. But I'm guessing the '04/' is just an example and is varying so you need would need a view (pref materialized) do strip it out so your select matches. But .. you can't insert / update, etc on a view (in postgres .. as far as I know) so as it stands with the existing kannel config I can't see a way of doing this if this is what you are seeing. However, it might be do-able with a combination of views, triggers, schemas (so you can have a table and a view of the same name but in different schema) and/or different read/write user (associated with different schema). But some code change to support schemas / users would be required in kannel. You would need to check out what mysql can do here .. might not be impossible .. for example, from what I can see online (no personal experience) Oracle seems to support an Instead Of trigger so you could use / handle inserts/etc on a view. Maybe someone with a bit more experience with DB wrangling might be able to help you further with mysql. As Alex notes I suspect a simpler solution might be to support a regexp on DLR details in kannel ;) Cheers, Alan On 18/02/11 22:35, Kyriacos Sakkas wrote: 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.
Re: Odd DLR msg ID from operator
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 a...@catalyst.net.nz To: Alejandro Guerrieri alejandro.guerri...@gmail.com Cc: users users@kannel.org 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy ** -- Kyriacos Sakkas Development Team Netsmart Tel: + 357 22 452565 Fax: + 357 22 452566 Email: kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy **
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 kyria...@netsmart.com.cy
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 a...@catalyst.net.nz
To: Alejandro Guerrieri alejandro.guerri...@gmail.com
Cc: users users@kannel.org
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
kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543
When the message is delivered I get the following id in the
deliver_sm:
*04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy
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 kyria...@netsmart.com.cy
Re: Odd DLR msg ID from operator
Hi, 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. It is a very light kannel change in gw/dlr_mysql.c, since you know the smsc-id, but even at that you branch off and in the future you will have to merge in any dlr_mysql.c changes. Why don't they change it? How can they be a big name operator and screw up DLRs for all their clients? BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Nikos Balkanas nbalka...@gmail.com Cc: Alan McNatty a...@catalyst.net.nz; Alejandro Guerrieri alejandro.guerri...@gmail.com; users us...@vm1.kannel.org; Kyriacos Sakkas kyria...@netsmart.com.cy Sent: Friday, February 18, 2011 11:35 AM Subject: Re: Odd DLR msg ID from operator 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 a...@catalyst.net.nz To: Alejandro Guerrieri alejandro.guerri...@gmail.com Cc: users users@kannel.org 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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
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.
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 kyria...@netsmart.com.cy
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 a...@catalyst.net.nz
To: Alejandro Guerrieri alejandro.guerri...@gmail.com
Cc: users users@kannel.org
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
kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543
When the message is delivered I get the following id in the
deliver_sm:
*04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy
http://www.netsmart.com.cy
Taking Business to a New Level!
** Confidentiality Notice: The information contained
Re: Odd DLR msg ID from operator
There might be a reason (or not) for them to do that kind of stuff, but I've learned that your chances of getting them to change it are quite slim. Even if they're willing to do it, rolling out that kind of infrastructure change on a carrier-grade network would mean months of testing and coordination. I've tried, it's a waste of time ;) Regards, Alex 2011/2/18 Nikos Balkanas nbalka...@gmail.com Hi, 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. It is a very light kannel change in gw/dlr_mysql.c, since you know the smsc-id, but even at that you branch off and in the future you will have to merge in any dlr_mysql.c changes. Why don't they change it? How can they be a big name operator and screw up DLRs for all their clients? BR, Nikos - Original Message - From: Kyriacos Sakkas kyria...@netsmart.com.cy To: Nikos Balkanas nbalka...@gmail.com Cc: Alan McNatty a...@catalyst.net.nz; Alejandro Guerrieri alejandro.guerri...@gmail.com; users us...@vm1.kannel.org; Kyriacos Sakkas kyria...@netsmart.com.cy Sent: Friday, February 18, 2011 11:35 AM Subject: Re: Odd DLR msg ID from operator 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 a...@catalyst.net.nz To: Alejandro Guerrieri alejandro.guerri...@gmail.com Cc: users users@kannel.org 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done
date:YYMMDDhhmm stat:DDD 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 nbalka...@gmail.com
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 kyria...@netsmart.com.cy
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 a...@catalyst.net.nz
To: Alejandro Guerrieri alejandro.guerri...@gmail.com
Cc: users users@kannel.org
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
Re: Odd DLR msg ID from operator
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done date:YYMMDDhhmm
stat:DDD 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 nbalka...@gmail.com
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 kyria...@netsmart.com.cy
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
Re: Odd DLR msg ID from operator
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:II sub:SSS dlvrd:DDD submit date:YYMMDDhhmm done
date:YYMMDDhhmm stat:DDD 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 nbalka...@gmail.com
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 kyria...@netsmart.com.cy
Hi All,
This is definitely an SMPP connection, whether it actually it is SMPP,
thats a different
Odd DLR msg ID from operator
Hi, Wondering if anyone can help with this. When I submit an sms I get the following ID in the submit_sm_resp: *01*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy **
Re: Odd DLR msg ID from operator
Hi, Please post detailed bb log entries from the incident, from the original logs. BR, Nikos - Original Message - From: Kyriacos Sakkas To: users Sent: Thursday, February 17, 2011 11:30 AM Subject: Odd DLR msg ID from operator Hi, Wondering if anyone can help with this. When I submit an sms I get the following ID in the submit_sm_resp: 01//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: 04/415ce0ae676d19fc/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: kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy **
Re: Odd DLR msg ID from operator
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 kyria...@netsmart.com.cywrote: Hi, Wondering if anyone can help with this. When I submit an sms I get the following ID in the submit_sm_resp: *01*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cyhttp://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 kyria...@netsmart.com.cy **
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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy **
Re: Odd DLR msg ID from operator
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 a...@catalyst.net.nz To: Alejandro Guerrieri alejandro.guerri...@gmail.com Cc: users users@kannel.org 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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*//415ce0ae676d19fc/1231615516543 When the message is delivered I get the following id in the deliver_sm: *04*/415ce0ae676d19fc/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: kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy 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 kyria...@netsmart.com.cy mailto:kyria...@netsmart.com.cy **
