Re: smppbox code questions

As anticipated this is wrong and can be confusing to users.

BR,
Nikos
----- Original Message ----- 
From: "Rene Kluwen" <[email protected]>
To: "'Rene Kluwen'" <[email protected]>; "'Nikos Balkanas'" 
<[email protected]>; "'Victor Luchitz'" <[email protected]>; 
<[email protected]>
Sent: Monday, July 12, 2010 6:48 PM
Subject: RE: smppbox code questions


>I added the file VERSION.
> Also I changed the gw/smppbox.c and I think I have a workaround.
>
> Now report_versions() says:
>
> 2010-07-12 17:47:35 [25289] [0] INFO: Debug_lvl = -1, log_file = <none>,
> log_lvl = 0
> 2010-07-12 17:47:35 [25289] [0] DEBUG: Kannel smppbox version svn-r20:21M
> version `svn-r4833'.
>
> It is not ideal. But it works. Maybe I should send a patch for gwlib.
>
> Alex: Let me know if I should do the same for sqlbox.
>
> == Rene
>
>
> Index: gw/smppbox.c
> ===================================================================
> --- gw/smppbox.c        (revision 21)
> +++ gw/smppbox.c        (working copy)
> @@ -79,6 +79,10 @@
> #include "gw/heartbeat.h"
> #include "gw/meta_data.h"
>
> +#undef GW_NAME
> +#undef GW_VERSION
> +#include "../sb-config.h"
> +
> /* our config */
> static Cfg *cfg;
> /* have we received restart cmd from bearerbox? */
> @@ -1943,6 +1947,10 @@
>     return 0;
> }
>
> +#undef OCTSTR
> +#undef SINGLE_GROUP
> +#undef MULTI_GROUP
> +
> static int smppbox_is_single_group(Octstr *query)
> {
>     #define OCTSTR(name)
> @@ -1959,7 +1967,7 @@
> int main(int argc, char **argv)
> {
>        int cf_index;
> -       Octstr *filename;
> +       Octstr *filename, *version;
>
>        gwlib_init();
>        all_boxes = gwlist_create();
> @@ -1984,7 +1992,9 @@
>
>        octstr_destroy(filename);
>
> -       report_versions("smppbox");
> +       version = octstr_format("smppbox version %s", GW_VERSION);
> +       report_versions(octstr_get_cstr(version));
> +       octstr_destroy(version);
>
>        init_smppbox(cfg);
>
>
>
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf
> Of Rene Kluwen
> Sent: maandag 12 juli 2010 17:27
> To: 'Nikos Balkanas'; 'Victor Luchitz'; [email protected]
> Subject: RE: smppbox code questions
>
> To be honest: I didn't try it.
> But report_versions() is a gwlib library functions and outputs the values
> that it was compiled with.
>
> == Rene
>
> -----Original Message-----
> From: Nikos Balkanas [mailto:[email protected]]
> Sent: maandag 12 juli 2010 11:45
> To: Rene Kluwen; 'Victor Luchitz'; [email protected]
> Subject: Re: smppbox code questions
>
> Hey, I didn't say it would work, just asked if you had tried it. You can't
> expect me to remember by heart where each #define is set. Unfortunately it
> needs patching.
>
> BR,
> Nikos
>
> ----- Original Message ----- 
> From: "Rene Kluwen" <[email protected]>
> To: "'Nikos Balkanas'" <[email protected]>; "'Victor Luchitz'"
> <[email protected]>; <[email protected]>
> Sent: Monday, July 12, 2010 1:30 AM
> Subject: RE: smppbox code questions
>
>
>> Nikos, you disappoint me.
>>
>> report_versions() is linked in from the gwlib libraries with the values
>> that
>> it was compiled with. Try it, and you will see.
>>
>> == Rene
>>
>> -----Original Message-----
>> From: Nikos Balkanas [mailto:[email protected]]
>> Sent: zondag 11 juli 2010 17:33
>> To: Rene Kluwen; 'Victor Luchitz'; [email protected]
>> Subject: Re: smppbox code questions
>>
>> Nope, that would defeat the whole puprose. Add it to your code, just
>> before
>> calling report_versions()
>>
>> BR,
>> Nikos
>> ----- Original Message ----- 
>> From: "Rene Kluwen" <[email protected]>
>> To: "'Nikos Balkanas'" <[email protected]>; "'Victor Luchitz'"
>> <[email protected]>; <[email protected]>
>> Sent: Sunday, July 11, 2010 4:50 PM
>> Subject: RE: smppbox code questions
>>
>>
>>>I haven't tried.
>>> But it will only work if I recompile gwlib after the new #define's.
>>>
>>> == Rene
>>>
>>> -----Original Message-----
>>> From: Nikos Balkanas [mailto:[email protected]]
>>> Sent: zondag 11 juli 2010 9:46
>>> To: Rene Kluwen; 'Victor Luchitz'; [email protected]
>>> Subject: Re: smppbox code questions
>>>
>>> Hi,
>>>
>>> Have you tried:
>>>
>>> #undef GW_NAME
>>> #undef GW_VERSION
>>>
>>> #define GW_VERSION ...
>>> #define GW_NAME ...
>>>
>>> and then call report_versions?
>>>
>>> BR,
>>> Nikos
>>> ----- Original Message ----- 
>>> From: "Rene Kluwen" <[email protected]>
>>> To: "'Victor Luchitz'" <[email protected]>; <[email protected]>
>>> Sent: Saturday, July 10, 2010 11:48 PM
>>> Subject: RE: smppbox code questions
>>>
>>>
>>> That is a gwlib quirk. The function report_versions() has the Kannel
>>> version
>>>
>>> hard coded in it.
>>> Sqlbox has the same problem.
>>>
>>> Maybe we need to send in a patch for gwlib/utils.c.
>>>
>>> == Rene
>>>
>>> -----Original Message-----
>>> From: Victor Luchitz [mailto:[email protected]]
>>> Sent: zaterdag 10 juli 2010 22:17
>>> To: [email protected]; Rene Kluwen
>>> Subject: Re: smppbox code questions
>>>
>>> Yeah, I made similar changes locally with the same result: at startup,
>>> smppbox prints the following message:
>>> [91108] [0] DEBUG: Kannel smppbox version `svn-r4833M'.
>>> which is kannel's svn revision number, not that of smppbox.
>>>
>>> 2010/7/10 Rene Kluwen <[email protected]>:
>>>> I did an attempt to include the svn version numbers.
>>>> But so far no luck. I did check things in, in case you want to have a
>>>> look
>>>
>>>> at it.
>>>>
>>>> -----Original Message-----
>>>> From: Victor Luchitz [mailto:[email protected]]
>>>> Sent: zaterdag 10 juli 2010 18:27
>>>> To: Rene Kluwen
>>>> Subject: Re: smppbox code questions
>>>>
>>>> Ok, then. On a side note, the configure.in file needs to be updated to
>>>> reflect the cvs -> svn change, currently the configure script still
>>>> tries to fetch the version number from CVS/Entries file and fails at
>>>> doing so. I am by no means an M4/autotools expert, guess some
>>>> copy&paste job could be done using the main kannel configure.in..
>>>>
>>>> 2010/7/10 Rene Kluwen <[email protected]>:
>>>>> I decided to change the sources with longer variables, so things are
>>>>> consistent with smsbox.
>>>>> cfg.diff has also been committed.
>>>>>
>>>>> == Rene
>>>>>
>>>>> -----Original Message-----
>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>> Sent: zaterdag 10 juli 2010 15:53
>>>>> To: [email protected]; Rene Kluwen
>>>>> Subject: Re: smppbox code questions
>>>>>
>>>>> Oh, my original patch was missing the smppbox-cfg.def part (in
>>>>> attachment) so currently you can't specify any of the new vars,
>>>>> otherwise
>>>
>>>>> smppbox doesn't start.
>>>>> One thing I noticed is that you committed my patch with vars using
>>>>> shorter names: src-addr-npi, etc, while the svn doc uses longer names
>>>>> for
>>>
>>>>> them: source-addr-npi, dest-addr-npi and so on. Either the source code
>>>>> needs correction to match the documentation or later is messed up
>>>>> :)
>>>>>
>>>>> 2010/7/10 Rene Kluwen <[email protected]>:
>>>>>> Right away I also checked in your ton/npi patch.
>>>>>>
>>>>>> == Rene
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>> Sent: vrijdag 9 juli 2010 23:19
>>>>>> To: Rene Kluwen
>>>>>> Subject: Re: smppbox code questions
>>>>>>
>>>>>> Yeah, I was thinking about this "hack" as well, but it's going to
>>>>>> create more problems than it solves. Btw, why does smppbox use
>>>>>> system-type as boxc_id instead of ESME's login name? That forces
>>>>>> EMSE's to have distinct system-type values, while almost all SMSC'es
>>>>>> I've seen so far allow connections with empty system-type string, for
>>>>>> example.
>>>>>>
>>>>>> 2010/7/10 Rene Kluwen <[email protected]>:
>>>>>>> Heh... I think the way it works now is best for the average user.
>>>>>>> But I am sure you are competent enough to change it to your own
>>>>>>> needs.
>>>>>>> One "hack" that you can make is make the system-type of the client
>>>>>>> the
>>>>>>> same as your smsc-id in your kannel.conf.
>>>>>>> This is of course not recommended for most persons, but it might 
>>>>>>> work
>>>>>>> for you.
>>>>>>>
>>>>>>> == Rene
>>>>>>>
>>>>>>>
>>>>>>> -----Original Message-----
>>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>>> Sent: vrijdag 9 juli 2010 22:39
>>>>>>> To: Rene Kluwen
>>>>>>> Subject: Re: smppbox code questions
>>>>>>>
>>>>>>> I have a pretty good idea how it works, it's just that the way it
>>>>>>> works doesn't suit my needs ;)
>>>>>>>
>>>>>>> 2010/7/9 Rene Kluwen <[email protected]>:
>>>>>>>> Surely this is relevant.
>>>>>>>>
>>>>>>>> Smppbox is not interested in bearerbox generated dlr's. It just
>>>>>>>> needs
>>>>>>>> to "dlr_find" the dlr's that it added itself via dlr_add.
>>>>>>>> Bearerbox takes care of its own dlr's. Smppbox also takes care of
>>>>>>>> its
>>>>>>>> own dlr's.
>>>>>>>>
>>>>>>>> I think you should re-read the code again to see how it works.
>>>>>>>>
>>>>>>>> == Rene
>>>>>>>>
>>>>>>>> -----Original Message-----
>>>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>>>> Sent: vrijdag 9 juli 2010 15:35
>>>>>>>> To: [email protected]; Rene Kluwen
>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>
>>>>>>>> Yes, but how is this relevant? I mean, there are two possibilities
>>>>>>>> to make smppbox be aware of bearerbox-generated DLRs:
>>>>>>>>
>>>>>>>> 1) use boxc_id as smsc-id in dlr_add in bearerbox and then pass the
>>>>>>>> report_mo message to smppbox without issuing dlr_find in bearerbox
>>>>>>>> 2) use "proper"/parent smsc-id in smppbox
>>>>>>>>
>>>>>>>> The whole issue arises from the need to pass SMSC-related DLR's to
>>>>>>>> smppbox without the later issuing any DLR's itself. For example, a
>>>>>>>> MT message may fail to be delivered due to insufficient funds on
>>>>>>>> user's account.
>>>>>>>>
>>>>>>>> 2010/7/9 Rene Kluwen <[email protected]>:
>>>>>>>>> If bearerbox sends a report_mo, then it should include a status
>>>>>>>>> (dlr
>>>>>>>>> type) as well.
>>>>>>>>> Or am I wrong?
>>>>>>>>>
>>>>>>>>> == Rene
>>>>>>>>>
>>>>>>>>> -----Original Message-----
>>>>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>>>>> Sent: vrijdag 9 juli 2010 14:24
>>>>>>>>> To: [email protected]; Rene Kluwen
>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>
>>>>>>>>> Unfortunately there's currently no way to add a SMSC_SUCCESS or
>>>>>>>>> SMSC_FAIL DLR in smppbox so I have/need to do that in bearerbox.
>>>>>>>>> But oh, well, I'll just go with boxc_id as smsc-id and live with
>>>>>>>>> this fact.
>>>>>>>>>
>>>>>>>>> 2010/7/9 Rene Kluwen <[email protected]>:
>>>>>>>>>> But bearerbox inserts it's own dlr's. As does smppbox.
>>>>>>>>>> So bearerbox will find their dlr's. And smppbox will do also.
>>>>>>>>>>
>>>>>>>>>> == Rene
>>>>>>>>>>
>>>>>>>>>> -----Original Message-----
>>>>>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>>>>>> Sent: vrijdag 9 juli 2010 13:55
>>>>>>>>>> To: Rene Kluwen
>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>
>>>>>>>>>> Well, this is going against the logic in bearerbox. For example,
>>>>>>>>>> if you pass a DLR via standard Kannel HTTP protocol, bearerbox
>>>>>>>>>> will try to find a matching DLR using its own smsc-id, upon
>>>>>>>>>> failing to do, it won't pass the DLR to smppbox either.
>>>>>>>>>>
>>>>>>>>>> 2010/7/9 Rene Kluwen <[email protected]>:
>>>>>>>>>>> The first parameter (smsc_id) is to determine "who's" dlr it is
>>>>>>>>>>> to
>>>>>>>>>>> begin with. So in short: To which smsc it belongs.
>>>>>>>>>>> Because smppbox does things the other way around, it passes the
>>>>>>>>>>> boxc_id variable. So if two boxes happen to have the same "ts"
>>>>>>>>>>> (which can in theory happen) the value is used to distinguish to
>>>>>>>>>>> which box_id it belongs.
>>>>>>>>>>>
>>>>>>>>>>> == Rene
>>>>>>>>>>>
>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>> From: Victor Luchitz [mailto:[email protected]]
>>>>>>>>>>> Sent: vrijdag 9 juli 2010 11:12
>>>>>>>>>>> To: [email protected]; Rene Kluwen
>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>
>>>>>>>>>>> On a side note, why does smppbox use boxc_id as the first
>>>>>>>>>>> parameter passed to dlr_add and dlr_find? Both functions take
>>>>>>>>>>> smsc_id as the first argument and boxc_id value is obtained from
>>>>>>>>>>> the sms struct.
>>>>>>>>>>>
>>>>>>>>>>> 2010/7/8 Rene Kluwen <[email protected]>:
>>>>>>>>>>>> Done.
>>>>>>>>>>>> Current revision is 17.
>>>>>>>>>>>>
>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>> From: [email protected] 
>>>>>>>>>>>> [mailto:[email protected]]
>>>>>>>>>>>> On Behalf Of Victor Luchitz
>>>>>>>>>>>> Sent: donderdag 8 juli 2010 15:06
>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>
>>>>>>>>>>>> Yeah, you committed the proposed change to boxc->boxc_id in
>>>>>>>>>>>> revision 15. What I'm asking about is the suggestion and patch 
>>>>>>>>>>>> I
>>>>>>>>>>>> posted here:
>>>>>>>>>>>> http://www.kannel.org/pipermail/devel/2010-July/003653.html
>>>>>>>>>>>>
>>>>>>>>>>>> 2010/7/8 Rene Kluwen <[email protected]>:
>>>>>>>>>>>>> It's already in the code.
>>>>>>>>>>>>> Current revision is 16.
>>>>>>>>>>>>>
>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>
>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>> From: [email protected]
>>>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor Luchitz
>>>>>>>>>>>>> Sent: donderdag 8 juli 2010 7:52
>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>>
>>>>>>>>>>>>> Any hope this will be reviewed and committed?
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm also working on a patch that adds TLV support to smppbox
>>>>>>>>>>>>> but I'd like to get this one included first.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 2010/7/6 Victor Luchitz <[email protected]>:
>>>>>>>>>>>>>> Yup, it's working fine now. Noticed there's another memleak
>>>>>>>>>>>>>> though:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> another octstr_destroy(msgid); call is needed right after 
>>>>>>>>>>>>>> the:
>>>>>>>>>>>>>> /* we could not find a corresponding dlr; nothing to send */
>>>>>>>>>>>>>> line.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm also attaching another patch which allows transmission of
>>>>>>>>>>>>>> custom error codes in DLR's in the same manner as the message
>>>>>>>>>>>>>> text bit.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 2010/7/6 Rene Kluwen <[email protected]>:
>>>>>>>>>>>>>>> I have no way of testing this here. But since either way
>>>>>>>>>>>>>>> cannot
>>>
>>>>>>>>>>>>>>> harm I changed it.
>>>>>>>>>>>>>>> Current smppbox revision is now 15.
>>>>>>>>>>>>>>> Could you please check out and see if this fixes your
>>>>>>>>>>>>>>> problem?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>> From: [email protected]
>>>>>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor 
>>>>>>>>>>>>>>> Luchitz
>>>>>>>>>>>>>>> Sent: dinsdag 6 juli 2010 14:53
>>>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>>>> Subject: Re: smppbox code questions
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 1) I think this assumption is incorrect. I have the routing
>>>>>>>>>>>>>>> set up this way in bearerbox:
>>>>>>>>>>>>>>> group = smsbox-route
>>>>>>>>>>>>>>> smsbox-id = vma
>>>>>>>>>>>>>>> smsc-id = HTTP
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So all messages on the 'HTTP' smsc get routed to smppbox.
>>>>>>>>>>>>>>> However, the custom HTTP protocol in the above layer does 
>>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>> use dlr_find to route messages to a specific box for two
>>>>>>>>>>>>>>> reasons:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> a) wrong smsc-id is used in the query (bearerbox doesn't 
>>>>>>>>>>>>>>> know
>>>>>>>>>>>>>>> that smppbox overrides the smsc id with system-type) so
>>>>>>>>>>>>>>> dlr_find always fails
>>>>>>>>>>>>>>> b) dlr_find removes DLR from the table and then subsequently
>>>>>>>>>>>>>>> readds it, which is rather stressful on the DB for no sane
>>>>>>>>>>>>>>> reason
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What it does instead is simply setting the sms_type to
>>>>>>>>>>>>>>> report_mo, leaving box_id empty as in regular MO messages.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> 2010/7/6 Rene Kluwen <[email protected]>:
>>>>>>>>>>>>>>>> To start with the last thing:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) You are right. It should use the msgid's in the dlr_url
>>>>>>>>>>>>>>>> from the dlr instance. I changed it.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> About 1): We assume msg->boxc_id and box->boxc_id are the
>>>>>>>>>>>>>>>> same
>>>
>>>>>>>>>>>>>>>> in this case. Otherwise the message wouldn't have ended up
>>>>>>>>>>>>>>>> there.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> == Rene
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>> From: [email protected]
>>>>>>>>>>>>>>>> [mailto:[email protected]] On Behalf Of Victor
>>>>>>>>>>>>>>>> Luchitz
>>>>>>>>>>>>>>>> Sent: maandag 5 juli 2010 20:36
>>>>>>>>>>>>>>>> To: [email protected]
>>>>>>>>>>>>>>>> Subject: smppbox code questions
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have a few questions for you regarding the handling of
>>>>>>>>>>>>>>>> DLR's by smppbox, which might also turn out to be bugs.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 1)
>>>>>>>>>>>>>>>> In msg_to_pdu function there's a line which reads:
>>>>>>>>>>>>>>>> dlr = dlr_find(msg->sms.boxc_id, msgid, msg->sms.receiver,
>>>>>>>>>>>>>>>> dlrtype);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I think it's incorrect because when a DLR is stored by
>>>>>>>>>>>>>>>> smppbox in handle_pdu, the boxc_id it uses is that from
>>>>>>>>>>>>>>>> smpp_logins file (system_type). That in turn may cause
>>>>>>>>>>>>>>>> dlr_find to always fail. So in my opinion the correct
>>>>>>>>>>>>>>>> dlr_find
>>>
>>>>>>>>>>>>>>>> call is this:
>>>>>>>>>>>>>>>> dlr = dlr_find(box->boxc_id, msgid, msg->sms.receiver,
>>>>>>>>>>>>>>>> dlrtype);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> 2) another thing I find not quite correct is the way 
>>>>>>>>>>>>>>>> smppbox
>>>>>>>>>>>>>>>> splits message ids for concatenated DLR's. Basically, what
>>>>>>>>>>>>>>>> smppbox does is
>>>>>>>>>>>>>>>> this:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> parts = octstr_split(msg->sms.dlr_url, octstr_imm(";"));
>>>>>>>>>>>>>>>> msgid = gwlist_extract_first(parts); ...
>>>>>>>>>>>>>>>> Then it loops through all elements of the 'parts' list and
>>>>>>>>>>>>>>>> here is where the potential problem lies. smppbox assumes
>>>>>>>>>>>>>>>> that msgid for the concatenated DLR is always equal to
>>>>>>>>>>>>>>>> dlr_url
>>>
>>>>>>>>>>>>>>>> which is not always true.
>>>>>>>>>>>>>>>> In fact, I think it's never true for concatenated DLR's
>>>>>>>>>>>>>>>> stored by the dlr_add call in handle_pdu. Also, for 
>>>>>>>>>>>>>>>> example,
>>>>>>>>>>>>>>>> the 'msgid' and 'dlrurls' columns in the storage table can
>>>>>>>>>>>>>>>> have different maxiumum lengths, allowing truncation of the
>>>>>>>>>>>>>>>> msgid. Here's my proposed fix - add the following bit of
>>>>>>>>>>>>>>>> code
>>>>>>>>>>>>>>>> to msg_to_pdu:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> gwlist_destroy(parts, octstr_destroy_item); parts =
>>>>>>>>>>>>>>>> octstr_split(dlr->sms.dlr_url, octstr_imm(";"));
>>>>>>>>>>>>>>>> gwlist_extract_first(parts);
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> right above the following bit:
>>>>>>>>>>>>>>>> if (gwlist_len(parts) > 0) {
>>>>>>>>>>>>>>>>    while ((msgid2 = gwlist_extract_first(parts)) != NULL) {
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> --
>>>>>>>>>>>> Best regards,
>>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Best regards,
>>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>>  Victor Luchitz
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Best regards,
>>>>>>>>>  Victor Luchitz
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Best regards,
>>>>>>>>  Victor Luchitz
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>>  Victor Luchitz
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>>  Victor Luchitz
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Best regards,
>>>>>  Victor Luchitz
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>  Victor Luchitz
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>> -- 
>>> Best regards,
>>> Victor Luchitz
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
>
>
>
>