Re: [PATCH] fetch the message_id from submit_sm_resp

something like this:

diff --git a/gw/dlr.c b/gw/dlr.c
index a0045b9..44b0d8f 100644
--- a/gw/dlr.c
+++ b/gw/dlr.c
@@ -315,6 +315,10 @@ void dlr_add(const Octstr *smsc, const Octstr *ts, 
const Msg *msg)
  {
      struct dlr_entry *dlr = NULL;

+    if (msg->sms.foreign_id != NULL)
+        octstr_destroy(msg->sms.foreign_id);
+    msg->sms.foreign_id = octstr_duplicate(ts);
+
      if(octstr_len(smsc) == 0) {
         warning(0, "DLR[%s]: Can't add a dlr without smsc-id", dlr_type());
          return;

Then any SMSC module that supports DLR will have foreign_key 
automagically set and you don't need to implement it in each SMSC module.

Thanks,
Alex

Alejandro Guerrieri schrieb:
> Sorry I don't follow, could you please clarify further?
> 
> Regards,
> -- 
> Alejandro Guerrieri
> [email protected]
> 
> 
> 
> El 28/11/2008, a las 08:39 a.m., Alexander Malysh escribió:
> 
>> hmm, I see you use dlr.c to provide foreign_id in dlrs. Then why don't 
>> you use dlr_add to provide foreign_id for the MT message? Then it will 
>> work for all protos where DLR supported auto magically :)
>>
>> Thanks,
>> Alex
>>
>> Alejandro Guerrieri schrieb:
>>> Hi,
>>> As discussed before, this patch adds the %w parameter to the dlr-url 
>>> and also to the access-log-format configuration parameter. A new 
>>> "foreign_id" member is added to the msg structure.
>>> To clarify further:
>>> When sending MT, you can now pass the parameter "%w" to the dlr-url, 
>>> and it will be filled with the "message_id" that comes on the 
>>> submit_sm_resp PDU.
>>> You can also add the %w to your "access-log-format" and the 
>>> message_id will be written on your access log as well.
>>> I've used %w, maybe %f (as in "foreign") is more appropriate?
>>> This only works with SMPP so far. I don't have any experience nor 
>>> availability to connect to other SMSC types (I don't even know if 
>>> there's a field similar to SMPP's "message_id" I can hook to). If 
>>> anybody knows anything about other SMSC's and can give me some hints, 
>>> I can try adding support for it as well.
>>> NOTE: The %w parameter will only be available on the _first_ dlr hit. 
>>> If you configure "real" SMSC DLR's, further notifications will be 
>>> carried from the SMSC on deliver_sm PDU's (according to SMPP 3.4 rev 
>>> 1.2, section 2.10.1) thus the message_id won't be available. That PDU 
>>> have the receipted_message_id field, which is a TLV and should now be 
>>> available as meta-data.
>>> This shouldn't be a problem anyway, since this value _should_ be the 
>>> same as the first one, and then a match over the %d parameter could 
>>> be made. The application could also parse the meta-data, of course.
>>> Regards,
>>> -- 
>>> Alejandro Guerrieri
>>> [email protected]
>>
>>
> 
> 
>