RE: SMPP DLR

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" <[email protected]>
To: "'Porter, Kelvin'" <[email protected]>
Cc: [email protected]
Subject: RE: SMPP DLR
Message-ID: <00e101cf297e$24e1ce30$6ea56a90$@[email protected]>
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:[email protected]]
Sent: donderdag 13 februari 2014 20:18
To: Rene Kluwen
Cc: [email protected]
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:[email protected]]
Sent: Thursday, February 13, 2014 12:51 PM
To: Porter, Kelvin
Cc: [email protected]
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:[email protected]]
Sent: donderdag 13 februari 2014 19:36
To: Rene Kluwen; [email protected]
Cc: [email protected]
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:[email protected]]
Sent: Thursday, February 13, 2014 5:12 AM
To: Porter, Kelvin; [email protected]
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:[email protected]] On Behalf Of Porter, Kelvin
Sent: woensdag 12 februari 2014 23:52
To: [email protected]
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" <[email protected]>
To: Rene Kluwen <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: RE: SMPP DLR
Message-ID:
	<73E6BC00A0E3DC4FB8B924269261D52D2E05FC9436@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:[email protected]]
Sent: Friday, February 14, 2014 6:13 AM
To: Porter, Kelvin
Cc: [email protected]
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:[email protected]]
Sent: donderdag 13 februari 2014 20:18
To: Rene Kluwen
Cc: [email protected]<mailto:[email protected]>
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:[email protected]]
Sent: Thursday, February 13, 2014 12:51 PM
To: Porter, Kelvin
Cc: [email protected]<mailto:[email protected]>
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:[email protected]]
Sent: donderdag 13 februari 2014 19:36
To: Rene Kluwen; [email protected]<mailto:[email protected]>
Cc: [email protected]<mailto:[email protected]>
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:[email protected]]
Sent: Thursday, February 13, 2014 5:12 AM
To: Porter, Kelvin; [email protected]<mailto:[email protected]>
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:[email protected]] On Behalf Of Porter, Kelvin
Sent: woensdag 12 februari 2014 23:52
To: [email protected]<mailto:[email protected]>
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