Re: [PATCH] fetch the message_id from submit_sm_resp

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]
>
>