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)); */
>