Hello,

I have been working through the smpp dlr reports process and had to make
a few changes to get it working with my local smsc. I have outlined the
changes I had to make and attached a patch for details (not intended to
be committed). I would appreciate any and all comments. 

1) submit_sm gave message id in decimal (same as deliver_sm). So needed
to change the base 16 conversion to base 10 in submit_sm_resp
handle_pdu. Would appreciate any thoughts on this - I'm not sure how
you'd be able to tell if the deliver_sm was base 10 or 16?

2) The esm_class was comming through as 0x01 (SM contains SMSC Delivery
Report) in deliver_sm hadle_dpu. Sounds right to me. 0x01 and 0x02 is
all we need - is anyone getting a 0x04 - this is reservered in specs?

3) I needed to use the source_addr rather than destination_addr in
dlr_find in deliver_sm handle_pdu. My copy of the 3.4 specs suggest the
source address of a deliver_sm should be unknown. I will pass this
finding on but would anyone mind if I coded up a suitable work around
(ie: if destination_addr is null the check if there's a non-null
source_addr or sim.).

Cheers,
Alan

(Note: patch also contains earlier deferred/validity timing stuff.)
Index: gw/smsc_smpp.c
===================================================================
RCS file: /home/cvs/gateway/gw/smsc_smpp.c,v
retrieving revision 1.71
diff -r1.71 smsc_smpp.c
332c332,333
<         if (gwqdiff >= 0)
---
> 
>         if (gwqdiff >= 0) {
334c335
<         else
---
> 	} else {
335a337,338
> 	    gwqdiff *= -1;         // Make absolute 
> 	}
339c342
<             buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%01d%02d%1s",
---
>             buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%02d%1s",
342c345,346
<                     0, gwqdiff, octstr_get_cstr(relation_UTC_time));
---
>                     gwqdiff, octstr_get_cstr(relation_UTC_time));
> 
349c353
<             buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%01d%02d%1s",
---
>             buffer = octstr_format("%02d%02d%02d%02d%02d%02d0%02d%1s",
352c356
<                     0, gwqdiff, octstr_get_cstr(relation_UTC_time));
---
>                     gwqdiff, octstr_get_cstr(relation_UTC_time));
557,558c561,575
<             /* got a deliver ack? */ 
<             if ((pdu->u.deliver_sm.esm_class == 0x02 || 
---
> 
> 	    /* Based on SMPP spec esm_class for deliver_sm is defined as ...
> 	     *
> 	     *   Message Type (bits (5-2)
> 	     *
> 	     *   xx0000xx (0x00) - Default Message Type
> 	     *   xx0001xx (0x01) - SM contains SMSC Delivery Receipt
> 	     *   xx0010xx (0x02) - SM contains SME Delivery Ack
> 	     *   xx0011xx (0x04) - reserverd
> 	     *
> 	     *   As a result I don't know why we need 0x4 - anyone?
> 	     */
> 
>             if ((pdu->u.deliver_sm.esm_class == 0x01 ||
>                  pdu->u.deliver_sm.esm_class == 0x02 || 
602a620,625
> 
> 		    /* XXX - Unsure why there is a difference between source and destination in 
> 		     *       deliver_sm. Maybe we need some extra logic here to choose the one
> 		     *       that is non-null?
> 		     */
> 		    
605c628,629
<                                       octstr_get_cstr(pdu->u.deliver_sm.destination_addr), /* destination */ 
---
>                                       octstr_get_cstr(pdu->u.deliver_sm.source_addr),      /* source ??   */ 
>                                   /*  octstr_get_cstr(pdu->u.deliver_sm.destination_addr),  * destination */ 
708a733
> 
710c735,737
<                         octstr_get_cstr(pdu->u.submit_sm_resp.message_id), NULL, 16)); 
---
>                         octstr_get_cstr(pdu->u.submit_sm_resp.message_id), NULL, 10)); 
>                      /* octstr_get_cstr(pdu->u.submit_sm_resp.message_id), NULL, 16)); */
> 

Reply via email to