Hi James (and list),
Thanks for your comment
.
I realize that, and I tried the same with the 'generic' system-type,
as I wrote last time - I moved on to the 'kannel' system-type based on
one of the developers' reply to an earlier, similar question (I've
also quoted its subject line). I also saw a full opensmppbox config
attached to another post to this list where this option was used
inside a http smsc with system-type set to 'kannel'. Since I wrote my
last message to this list I realized that the DLRs he was referring to
work only in the opposite direction (an external application sending
messages through kannel to an SMSC and expecting delivery reports from
kannel).
In my case, a message arrives on an SMPP channel to opensmppbox ->
bearerbox -> http smsc -> my script that actually sends the message
using an appliance, then status updates (accepted/rejected) should
propagate back to opensmppbox and finally, to the client.
In the meantime, I temporarily resolved this issue by adding an
strpos() check where the evaluation of DLR messages happens in
gw/opensmppbox.c for the string (queued/noqueue) that comes back from
my script in the HTTP response. I'm pretty sure you don't wanna know
the details of how I handled this and I surely wanna forget it soon,
but was also very tired and I needed a quick fix, too, so I didn't
have much of a choice. If you actually do care, here's what I did and
I don't even know how many ways I've broken opensmppbox by doing so:
dlvrd = octstr_imm("000");
switch (dlrtype) {
case DLR_UNDEFINED:
case DLR_NOTHING:
dlr_state = 8;
dlr_status = octstr_imm("REJECTD");
break;
case DLR_SUCCESS:
dlr_state = 2;
dlr_status = octstr_imm("DELIVRD");
dlvrd = octstr_imm("001");
break;
case DLR_BUFFERED:
dlr_state = 6;
dlr_status = octstr_imm("ACCEPTD");
break;
case DLR_SMSC_SUCCESS:
/* please note that this state does not quite conform
to the SMMP v3.4 spec */
dlr_state = 0;
dlr_status = octstr_imm("BUFFRED");
break;
case DLR_FAIL:
case DLR_SMSC_FAIL:
dlr_state = 5;
dlr_status = octstr_imm("UNDELIV");
break;
}
text = octstr_get_cstr(msg->sms.msgdata);
// here's what I added in a hurry
if (strstr(text, "NACK/queued")) {
dlr_state = 6;
dlr_status = octstr_imm("ACCEPTD");
} else {
dlr_state = 8;
dlr_status = octstr_imm("REJECTD");
}
The point is that the backend allows for these two status updates
only; these are the only responses I can get from the gateway that
sends the messages, there's no DELIVRD or UNDELIV status or anything I
could map these to. I should handle temporary or permanent failures of
the environment later when I figure out how to do so.
Thanks again,
Gabor
On Wed, May 11, 2011 at 11:56 AM, James Caradoc-Davies (Strike Media)
<[email protected]> wrote:
> Hi Gabor,
>
> If you examine smsc_http.c you will see that status-success-regex is used
> only by 'system-type = generic', not by 'kannel'.
>
> Regards,
>
> James
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Gabor Szucs
> Sent: 10 May 2011 13:52
> To: [email protected]
> Subject: DLRs and the http smsc
>
> Dear Nikos, Rene, Alexander and everyone else,
>
> I'm sorry to bother this list and particularly the maintainers with this
> question, but I'm puzzled about kannel's behavior (or my
> ignorance) regarding DLRs and the http smsc.
>
> I'm trying to set up kannel with opensmppbox to route messages coming from
> opensmppbox to an external script. I've accomplished this task and I also
> moved on to DLRs.
> Believe me I've RTFM and I've seen the list archives, e.g. the "esme and
> http smsc delivery report" and "generic http smsc statuses"
> threads.
> However, I've noticed that due to my lack of experience I cannot set up the
> http smsc with neither (generic or kannel) system-type to generate simple
> [accept|reject] DLRs based on the text returned by my script.
>
> DLRs for _rejected_ messages get through nicely (awesome job with Kannel
> BTW), but those that actually match the 'status-success-regex'
> are also marked as UNDELIV
>
> the relevant section of my kannel.conf:
>
> smsc = http
> smsc-id = BBBB
> system-type = kannel
> # or generic
> smsc-username = whatever
> smsc-password = ditto
> # or without these
> port = nnnnn
> send-url =
> "http://host.name.tld/receive_sms_from_kannel.scr?from=%P&to=%p&text=%b&dlr-
> url=%R"
> # or without the query part
> log-level = 0
> reroute-dlr = true
> generic-param-dlr-mask = 24
> # 28? 63?
> status-success-regex = "queued"
>
>
> the bearerbox output of a successfully queued (accepted) session:
>
> 2011-05-10 11:29:44 [23906] [13] DEBUG: data: 2e 34 2e 32 38 0d 0a
> 0d 0a 71 75 65 75 65 64 .4.28....queued
> 2011-05-10 11:29:44 [23906] [13] DEBUG: Octet string dump ends.
> # end of HTTP transcript
> 2011-05-10 11:29:44 [23906] [8] DEBUG: SMSC[AAAA]: creating DLR message
> 2011-05-10 11:29:44 [23906] [8] DEBUG: SMSC[AAAA]: DLR = 578769f2
> 2011-05-10 11:29:44 [23906] [32] DEBUG: send_msg: sending msg to boxc:
> <BBBB>
> 2011-05-10 11:29:44 [23906] [32] DEBUG: boxc_sender: sent message to
> <188.65.177.89>
> 2011-05-10 11:29:45 [23906] [31] DEBUG: boxc_receiver: got ack
>
> the relevant output from opensmppbox:
>
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 69 64 3a 35 37 38
> 37 36 39 66 32 20 73 75 62 3a id:578769f2 sub:
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 30 30 31 20 64 6c
> 76 72 64 3a 30 30 30 20 73 75 001 dlvrd:000 su
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 62 6d 69 74 20 64
> 61 74 65 3a 31 31 30 35 31 30 bmit date:110510
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 31 31 32 39 20 64
> 6f 6e 65 20 64 61 74 65 3a 31 1129 done date:1
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 31 30 35 31 30 31
> 31 32 39 20 73 74 61 74 3a 55 105101129 stat:U
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 4e 44 45 4c 49 56
> 20 65 72 72 3a 30 30 30 20 74 NDELIV err:000 t
> 2011-05-10 11:29:44 [11423] [15] DEBUG: data: 65 78 74 3a 20 4e
> 41 43 4b 2f 71 75 65 75 65 64 ext: NACK/queued
>
> I realize that I myself might have induced this behavior by not setting a
> proper dlr-mask override somewhere, or it could be just normal, but it looks
> quite similar to the negative reply (which has the same UNDELIV status), the
> only difference being the appended 'queued' or 'noqueue' reply from my
> application. Also it would by nicer to get a REJECTD status for these, too,
> but I have no idea how to configure Kannel to achieve this result.
> I expected a status update with the status set to 'ACCEPTD' - am I wrong? Or
> - in other words - ho can I get Kannel to transmit a deliver_sm PDU with an
> ACCEPTD status? I might have to brush up my skills in ANSI C. :)
>
> Thanks in advance,
> Gabor
>
>
