Alex,
Agreed, I'll post the patch when it's ready (probably tonight/tomorrow).
Regards,
--
Alejandro Guerrieri
[EMAIL PROTECTED]
El 27/11/2008, a las 07:50 a.m., Alexander Malysh escribió:
Hi Alex,
patch look good and if no objections from others I will commit it to
meta-data branch.
As for the message_id. It would be great to have it in meta-data but
if I think a bit more about it, it will become very messy.
How about defining new field in Msg struct (what you did already)
and name it like foreign_id. This field will be logged to access log
and can take message id from any SMSC module?
Thanks,
Alex
Alejandro Guerrieri schrieb:
Alex,
Done. Please check the attached patch.
There's still the issue regarding the "message_id" param on
submit_sm_resp / data_sm_resp.
The new match by tag method voids the option of using the same
filtering mechanism mentioned on my previous, mail since it would
require a match by name (or inventing a tag
address for message_id, which is not an option IMHO).
Since it's not a TLV, does it make sense to add it to meta-data, or
maybe exploring other ways to be able to retrieve it? Maybe a
special % param or a conf directive like "smsc-message-id-into-meta-
data" on the smpp group. Do you have any other ideas about how to
achieve this?
Regards,
--
Alejandro Guerrieri
[EMAIL PROTECTED]
El 26/11/2008, a las 06:43 a.m., Alexander Malysh escribió:
Hi Alex,
great!!! :)
Could you please change this patch to use dictionary tlv_by_tag
because the name of configured TLV may be different of the one in
SMPP spec. but the tag will be equal. I think it's up to user
which name configured TLV should use.
And minor issue: please always make patches from gateway root
directory with cvs diff -Nau.
Thanks,
Alex
Alejandro Guerrieri schrieb:
Hi,
This patch allows meta-data to carry all available TLV's not only
the User-Defined.
All TLV's defined on smpp_pdu.def were "hijacked" by the main pdu
structure, so they never reached the tlv dictionary. What this
patch does is to check for defined TLV's on the smpp-tlv group
and copy them to the tlv dictionary. Those TLV's are then
available on the meta-data parameter.
It only copies the TLV's explicitly defined, otherwise the meta-
data parameter would be unnecessary cluttered with all available
TLV's.
This solves the "receipted_message_id" issue with deliver_sm (to
name one), but does _not_ solve the "message_id" param on submit/
deliver/data_sm_response, since message_id is not a TLV.
For that parameter I could add a call for meta_data_set_value to
inject it into the meta data (already tried and works), but then
it would be always available.
To avoid this, I could use the same filtering mechanism as with
the TLV's, but that would mean defining a dummy tag address,
since this is not a TLV so it doesn't have a documented address.
I could filter using tag_by_name, so the address wouldn't matter
anyways, but it's somewhat ugly imho.
Ideas? Opinions?
Regards,
--
Alejandro Guerrieri
[EMAIL PROTECTED]
