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]
