Hi,
You may right, but you are speaking about internal sms key, whitch is not used
when you have a mysql dlr database and incoming dlr must be paired with one
inside the database!
The original code only deals with smsc and ts which makes database
inconsistent!!!
static struct dlr_entry* dlr_mysql_get(const Octstr *smsc, const Octstr *ts,
const Octstr *dst)
{
struct dlr_entry *res = NULL;
Octstr *sql;
MYSQL_RES *result;
MYSQL_ROW row;
sql = octstr_format("SELECT %s, %s, %s, %s, %s, %s FROM %s WHERE %s='%s'
AND %s='%s';",
octstr_get_cstr(fields->field_mask),
octstr_get_cstr(fields->field_serv),
octstr_get_cstr(fields->field_url),
octstr_get_cstr(fields->field_src),
octstr_get_cstr(fields->field_dst),
octstr_get_cstr(fields->field_boxc),
octstr_get_cstr(fields->table),
octstr_get_cstr(fields->field_smsc),
octstr_get_cstr(smsc),
octstr_get_cstr(fields->field_ts), octstr_get_cstr(ts));
static void dlr_mysql_remove(const Octstr *smsc, const Octstr *ts, const Octstr
*dst)
{
Octstr *sql;
debug("dlr.mysql", 0, "removing DLR from database");
sql = octstr_format("DELETE FROM %s WHERE %s='%s' AND %s='%s' LIMIT 1;",
octstr_get_cstr(fields->table),
octstr_get_cstr(fields->field_smsc),
octstr_get_cstr(smsc),
octstr_get_cstr(fields->field_ts), octstr_get_cstr(ts));
static void dlr_mysql_update(const Octstr *smsc, const Octstr *ts, const Octstr
*dst, int status)
{
Octstr *sql;
debug("dlr.mysql", 0, "updating DLR status in database");
sql = octstr_format("UPDATE %s SET %s=%d WHERE %s='%s' AND %s='%s' LIMIT
1;",
octstr_get_cstr(fields->table),
octstr_get_cstr(fields->field_status), status,
octstr_get_cstr(fields->field_smsc),
octstr_get_cstr(smsc),
octstr_get_cstr(fields->field_ts), octstr_get_cstr(ts));
Bye,
Gabor
-----Original Message-----
From: Nikos Balkanas [mailto:[email protected]]
Sent: Friday, March 12, 2010 4:22 PM
To: Maros Gabor EB_HU; [email protected]
Subject: Re: Duplicated FID (foreign_id)
Hi,
The internal kannel key is:
smsc, FID, destination.
So you don't need any patch, it works fine the way it is.
BR,
Nikos
----- Original Message -----
From: "Gabor Maros" <[email protected]>
To: <[email protected]>
Sent: Friday, March 12, 2010 4:46 PM
Subject: Re: Duplicated FID (foreign_id)
>
> Hi,
>
> I just want to write down our solution:
> I sent the question about the problem to our sms provider, which told me
> that if i want to pair the sent sm with delivery report than the key is
> not
> just the FID (which is just a timestamp), but the FID+destination.
> So we had to change the code of kannel. We using mysql dlr database, so we
> just changed gw/dlr_mysql.c at 3 places (it can be seen in the enclosed
> file
> http://old.nabble.com/file/p27875373/dlr_mysql.c dlr_mysql.c )
>
>
>
> If we send more SMs to one destination in one sec, than the provider
> shifts
> FID (timestamp at theire side), so even this case the FID+destination will
> be unique.
>
> Bye!
>
>
>
> Gabor Maros wrote:
>>
>> Hi,
>>
>> can anybody tell me how is FID generated or on which side.
>> I ask it because I have a problem: in access.log there are different
>> messages that have the same PIDs, and I need to know where I should
>> search
>> the problem (on kannel side, or on my sms provider's side).
>>
>> Thanks!
>>
>
> --
> View this message in context:
> http://old.nabble.com/Duplicated-FID-%28foreign_id%29-tp27853586p27875373.html
> Sent from the Kannel - User mailing list archive at Nabble.com.
>
>
____________________________________________________________________________________________________
Ez az e-mail és az összes hozzá tartozó csatolt melléklet titkos és/vagy
jogilag, szakmailag vagy más módon védett információt tartalmazhat. Amennyiben
nem Ön a levél címzettje akkor a levél tartalmának közlése, reprodukálása,
másolása, vagy egyéb más úton történő terjesztése, felhasználása szigorúan
tilos. Amennyiben tévedésből kapta meg ezt az üzenetet kérjük azonnal értesítse
az üzenet küldőjét. Az Erste Bank Hungary Nyrt. (EBH) nem vállal felelősséget
az információ teljes és pontos - címzett(ek)hez történő - eljuttatásáért,
valamint semmilyen késésért, kapcsolat megszakadásból eredő hibáért, vagy az
információ felhasználásából vagy annak megbízhatatlanságából eredő kárért.
Az üzenetek EBH-n kívüli küldője vagy címzettje tudomásul veszi és hozzájárul,
hogy az üzenetekhez más banki alkalmazott is hozzáférhet az EBH folytonos
munkamenetének biztosítása érdekében.
This e-mail and any attached files are confidential and/or covered by legal,
professional or other privilege. If you are not the addressee, any disclosure,
reproduction, copying, distribution, or other dissemination or use of this
communication is strictly prohibited. If you have received this transmission in
error please notify Erste Bank Hungary Nyrt. (EBH) immediately. EBH does not
accept liability for the correct and complete transmission of the information,
nor for any delay or interruption of the transmission, nor for damages arising
from the use of or reliance on the information.
The sender or recipient of these messages agrees that they may be read by other
EBH employees than the official recipient or sender in order to ensure the
continuity of work-related activities and allow supervision thereof.
____________________________________________________________________________________________________
