Hi Alex,
would you please test attached patch?
On Friday 16 January 2004 15:20, Alex Kinch wrote:
> Resending as my mail's been playing up :-)
>
> ----- Original Message -----
> From: Alex Kinch
> To: [EMAIL PROTECTED]
> Sent: Friday, January 09, 2004 10:14 PM
> Subject: Re: DLR sql select problem with message id containing space
>
>
> Happy New Year to all :-)
>
> Don't suppose the problem with spaces in message id's and DLR's got fixed
> in CVS?
>
> Alex
> ----- Original Message -----
> From: Alex Kinch
> To: Rene Kluwen ; [EMAIL PROTECTED]
> Sent: Wednesday, December 24, 2003 12:59 AM
> Subject: Re: DLR sql select problem with message id containing space
>
>
> Hi Rene
>
> In the SMPP v3.4 issue 1.2 (12th October 1999) docs that I have, it's
> been up'd from 9 to 33, and then to 65 octets. I guess this is to
> accomodate for the increasing use of GUID-style message ids?
>
> It seems that Kannel handles the SUBMIT_SM_RESP ok with these long ids,
> but doesn't do it in the DELIVER_SM for the DLR.
>
> Alex
> ----- Original Message -----
> From: Rene Kluwen
> To: Alex Kinch ; [EMAIL PROTECTED]
> Sent: Tuesday, December 23, 2003 9:24 PM
> Subject: RE: DLR sql select problem with message id containing space
>
>
> Fix would be not too hard to implement... BUT...
> In the SMPP specs that I have (note: I am talking about v3.3) it says:
> Message ID, var max. 9. So taking off the terminating NUL this means that
> message ids can be 8 characters at most. I noticed this 'quirk' (message
> ids of more than 8 chars) also with a certain upstream provider that I
> have.
>
> Question: Has this changed in successive SMPP versions? Or is it just
> plainly against specifications?
>
> Regards,
>
> Rene Kluwen
> Chimit
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf
> Of Alex Kinch Sent: dinsdag 23 december 2003 18:47
> To: [EMAIL PROTECTED]
> Subject: DLR sql select problem with message id containing space
>
>
> Hi,
>
> Just hooked up another SMPP connection, and they use rather large
> message ids. For example:
>
> 00047274 20031223170148.364
>
> Kannel is inserting this whole value (including characters after the
> space) into the ts field on the dlr table. However, when it comes to
> receiving the delivery report, it's truncating the message id after the
> first space, so it does:
>
> DLR[mysql]: Looking for DLR smsc=XXXX, ts=00047274,
> dst=44xxxxxxxxxx, type=1
>
> Which of course it won't find, as it's lost the rest of the message
> id.
>
> My C coding skills aren't up to much, but I would imagine it requires
> something that tests the first character after the space to see if it's
> numeric.
>
> Alex
--
Best regards / Mit besten Gr��en aus D�sseldorf
Dipl.-Ing.
Alexander Malysh
___________________________________________
Centrium GmbH
Vogelsanger Weg 80
40470 D�sseldorf
Fon: +49 (0211) 74 84 51 80
Fax: +49 (0211) 277 49 109
email: [EMAIL PROTECTED]
web: www.centrium.de
msn: [EMAIL PROTECTED]
icq: 98063111
___________________________________________
Please avoid sending me Word, Excel or PowerPoint attachments.
See http://www.fsf.org/philosophy/no-word-attachments.html
Index: gw/smsc/smsc_smpp.c
===================================================================
RCS file: /home/cvs/gateway/gw/smsc/smsc_smpp.c,v
retrieving revision 1.59
diff -a -u -r1.59 smsc_smpp.c
--- gw/smsc/smsc_smpp.c 4 Dec 2003 16:51:05 -0000 1.59
+++ gw/smsc/smsc_smpp.c 16 Jan 2004 15:23:28 -0000
@@ -966,33 +966,26 @@
*/
if ((pdu->u.deliver_sm.esm_class & ~0xC3) == 0x04) {
Octstr *respstr;
- Octstr *msgid = NULL;
- Octstr *stat = NULL;
+ Octstr *msgid = NULL, *stat = NULL;
int dlrstat;
- long curr = 0, vpos = 0;
+ char id_cstr[65], stat_cstr[11], sub_d_cstr[11], done_d_cstr[11];
+ int sub, dlrvrd, ret;
debug("bb.sms.smpp",0,"SMPP[%s] handle_pdu, got DLR",
octstr_get_cstr(smpp->conn->id));
respstr = pdu->u.deliver_sm.short_message;
- /* get server message id */
- if ((curr = octstr_search(respstr, octstr_imm("id:"), 0)) != -1) {
- vpos = octstr_search_char(respstr, ' ', curr);
- if ((vpos-curr >0) && (vpos != -1))
- msgid = octstr_copy(respstr, curr+3, vpos-curr-3);
- } else {
- msgid = NULL;
- }
-
- /* get err & status code */
- if ((curr = octstr_search(respstr, octstr_imm("stat:"), 0)) != -1) {
- vpos = octstr_search_char(respstr, ' ', curr);
- if ((vpos-curr >0) && (vpos != -1))
- stat = octstr_copy(respstr, curr+5, vpos-curr-5);
- } else {
- stat = NULL;
+ ret = sscanf(octstr_get_cstr(respstr), "id:%64[^sub:] sub:%d dlvrd:%d submit date:%10s done date:%10s stat:%10[^err:]",
+ id_cstr, &sub, &dlrvrd, sub_d_cstr, done_d_cstr, stat_cstr);
+ if (ret == 6) {
+ msgid = octstr_create(id_cstr);
+ octstr_strip_blanks(msgid);
+ stat = octstr_create(stat_cstr);
+ octstr_strip_blanks(stat);
}
+ else
+ warning(0, "SMPP[%s]: Couldnot parse DLR string.", octstr_get_cstr(smpp->conn->id));
/*
* we get the following status:
@@ -1055,7 +1048,6 @@
* The DLR trigger URL is indicated by msg->sms.dlr_url.
*/
dlrmsg->sms.msgdata = octstr_duplicate(respstr);
- dlrmsg->sms.sms_type = report;
reason = bb_smscconn_receive(smpp->conn, dlrmsg);
} else {
