Hi Kelvin, >From your email it appears this bug does not appear if your client binds as a transceiver, is this correct?
Rgds Date: Fri, 14 Feb 2014 13:13:17 +0100 From: "Rene Kluwen" <rene.klu...@chimit.nl> To: "'Porter, Kelvin'" <kelvin.por...@h3net.com> Cc: devel@kannel.org Subject: RE: SMPP DLR Message-ID: <00e101cf297e$24e1ce30$6ea56a90$@klu...@chimit.nl> Content-Type: text/plain; charset="iso-8859-1" Your implementation is not correct. Also the original value of 0x1f for registered_delivery is invalid. Setting both the 2 last significant bits is a reserved value and hence not supported. If you follow the smpp specifications, you will get proper results. == Rene From: Porter, Kelvin [mailto:kelvin.por...@h3net.com] Sent: donderdag 13 februari 2014 20:18 To: Rene Kluwen Cc: devel@kannel.org Subject: RE: SMPP DLR Hi, Here is a proposal for a simple-minded patch? [root@sms1 /usr/ports/www/kannel/work/gateway-1.5.0/addons/opensmppbox]# svn diff Index: gw/opensmppbox.c =================================================================== --- gw/opensmppbox.c (revision 77) +++ gw/opensmppbox.c (working copy) @@ -1245,17 +1245,8 @@ msg->sms.priority = pdu->u.submit_sm.priority_flag; /* ask for the delivery reports if needed */ - switch (pdu->u.submit_sm.registered_delivery & 0x03) { - case 1: - msg->sms.dlr_mask = (DLR_SUCCESS | DLR_FAIL | DLR_SMSC_FAIL); - break; - case 2: - msg->sms.dlr_mask = (DLR_FAIL | DLR_SMSC_FAIL); - break; - default: - msg->sms.dlr_mask = 0; - break; - } + msg->sms.dlr_mask = pdu->u.submit_sm.registered_delivery; + if (pdu->u.submit_sm.esm_class & (0x04|0x08)) { msg->sms.sms_type = report_mo; } However, I do not understand all nuances of the kannel design. How should the code know the source version of the protocol from the ESME (e.g., v3.3 or 3.4 or 5.0) and what version of the protocol to send to the SCMS (i.e., emit v3.4)? As a programmer, I would tend to have a normalized PDU version for exchange between the (opensmpp|sms)box and the bearerbox, but that may not be the way it is intended to work. Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, February 13, 2014 12:51 PM To: Porter, Kelvin Cc: devel@kannel.org Subject: RE: SMPP DLR Around line 1248 in gw/opensmppbox.c It?s taking the SMPP v3.3 case only, and even that with a slight modification. == Rene From: Porter, Kelvin [mailto:kelvin.por...@h3net.com] Sent: donderdag 13 februari 2014 19:36 To: Rene Kluwen; us...@kannel.org Cc: devel@kannel.org Subject: RE: SMPP DLR Hi Renee, Thank you for your response. I will try it with the registered_delivery set to 1. Can you please give a hint as to where you think that the bug might reside in opensmppbox? I can take a look at the source and see if anything sticks out? Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, February 13, 2014 5:12 AM To: Porter, Kelvin; us...@kannel.org Subject: RE: SMPP DLR I see that?s a bug in opensmppbox. Try to set registered_delivery to 1 instead, meanwhile I come up with a fix. == Rene From: users [mailto:users-boun...@kannel.org] On Behalf Of Porter, Kelvin Sent: woensdag 12 februari 2014 23:52 To: us...@kannel.org Subject: SMPP DLR Hi, I have a simple problem. I have the following set up: Client ?[SMPP]? opensmppbox ? sqlbox ? bearerbox ?[SMPP]? SMSC My clients sends a submit_sm request into the opensmppbox, I can see that the submit_sm message is marked requested_delivery: 31 = 0x0000001f in the logs; however, when I see the corresponding submit_sm sent to the SMSC, I see that requested_delivery is set to 0, in the logs for the SMSC connection. The only impediment that I can think of is that my client(s) bind as transmitter and receiver separately and not as a transceiver. I can send and receive messages with no problem. What do I need to do to insure that the requested_delivery flag is correctly relayed to the SMSC? Thank you. Regards, Kelvin R. Porter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://www.kannel.org/pipermail/devel/attachments/20140214/95175318/attachm ent-0001.html> ------------------------------ Message: 2 Date: Fri, 14 Feb 2014 15:45:21 -0600 From: "Porter, Kelvin" <kelvin.por...@h3net.com> To: Rene Kluwen <rene.klu...@chimit.nl> Cc: "devel@kannel.org" <devel@kannel.org> Subject: RE: SMPP DLR Message-ID: <73e6bc00a0e3dc4fb8b924269261d52d2e05fc9...@mail1.hypercube-llc.com> Content-Type: text/plain; charset="iso-8859-1" Hi, Thank you for the corrections. I will investigate further. Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Friday, February 14, 2014 6:13 AM To: Porter, Kelvin Cc: devel@kannel.org Subject: RE: SMPP DLR Your implementation is not correct. Also the original value of 0x1f for registered_delivery is invalid. Setting both the 2 last significant bits is a reserved value and hence not supported. If you follow the smpp specifications, you will get proper results. == Rene From: Porter, Kelvin [mailto:kelvin.por...@h3net.com] Sent: donderdag 13 februari 2014 20:18 To: Rene Kluwen Cc: devel@kannel.org<mailto:devel@kannel.org> Subject: RE: SMPP DLR Hi, Here is a proposal for a simple-minded patch... [root@sms1 /usr/ports/www/kannel/work/gateway-1.5.0/addons/opensmppbox]# svn diff Index: gw/opensmppbox.c =================================================================== --- gw/opensmppbox.c (revision 77) +++ gw/opensmppbox.c (working copy) @@ -1245,17 +1245,8 @@ msg->sms.priority = pdu->u.submit_sm.priority_flag; /* ask for the delivery reports if needed */ - switch (pdu->u.submit_sm.registered_delivery & 0x03) { - case 1: - msg->sms.dlr_mask = (DLR_SUCCESS | DLR_FAIL | DLR_SMSC_FAIL); - break; - case 2: - msg->sms.dlr_mask = (DLR_FAIL | DLR_SMSC_FAIL); - break; - default: - msg->sms.dlr_mask = 0; - break; - } + msg->sms.dlr_mask = pdu->u.submit_sm.registered_delivery; + if (pdu->u.submit_sm.esm_class & (0x04|0x08)) { msg->sms.sms_type = report_mo; } However, I do not understand all nuances of the kannel design. How should the code know the source version of the protocol from the ESME (e.g., v3.3 or 3.4 or 5.0) and what version of the protocol to send to the SCMS (i.e., emit v3.4)? As a programmer, I would tend to have a normalized PDU version for exchange between the (opensmpp|sms)box and the bearerbox, but that may not be the way it is intended to work. Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, February 13, 2014 12:51 PM To: Porter, Kelvin Cc: devel@kannel.org<mailto:devel@kannel.org> Subject: RE: SMPP DLR Around line 1248 in gw/opensmppbox.c It's taking the SMPP v3.3 case only, and even that with a slight modification. == Rene From: Porter, Kelvin [mailto:kelvin.por...@h3net.com] Sent: donderdag 13 februari 2014 19:36 To: Rene Kluwen; us...@kannel.org<mailto:us...@kannel.org> Cc: devel@kannel.org<mailto:devel@kannel.org> Subject: RE: SMPP DLR Hi Renee, Thank you for your response. I will try it with the registered_delivery set to 1. Can you please give a hint as to where you think that the bug might reside in opensmppbox? I can take a look at the source and see if anything sticks out? Regards, Kelvin R. Porter From: Rene Kluwen [mailto:rene.klu...@chimit.nl] Sent: Thursday, February 13, 2014 5:12 AM To: Porter, Kelvin; us...@kannel.org<mailto:us...@kannel.org> Subject: RE: SMPP DLR I see that's a bug in opensmppbox. Try to set registered_delivery to 1 instead, meanwhile I come up with a fix. == Rene From: users [mailto:users-boun...@kannel.org] On Behalf Of Porter, Kelvin Sent: woensdag 12 februari 2014 23:52 To: us...@kannel.org<mailto:us...@kannel.org> Subject: SMPP DLR Hi, I have a simple problem. I have the following set up: Client -[SMPP]--> opensmppbox --> sqlbox --> bearerbox -[SMPP]--> SMSC My clients sends a submit_sm request into the opensmppbox, I can see that the submit_sm message is marked requested_delivery: 31 = 0x0000001f in the logs; however, when I see the corresponding submit_sm sent to the SMSC, I see that requested_delivery is set to 0, in the logs for the SMSC connection. The only impediment that I can think of is that my client(s) bind as transmitter and receiver separately and not as a transceiver. I can send and receive messages with no problem. What do I need to do to insure that the requested_delivery flag is correctly relayed to the SMSC? Thank you. Regards, Kelvin R. Porter
