Hi,
This patch will be rejected as we need a global resolution
of the problem. I've already posted this patch a couple of years ago.
(http://www.mail-archive.com/[email protected]/msg05349.html)
I didn't know about your patch, I joined kannel a bit after, I think :-)
My patch is different and more global. It handles cases when no dst is known
and when it is known. It also patches all dbs supported by kannel. However,
I was not aware that dst could come in with less digits than sent, so I will
have to address this. Thanks for pointing this out. Instead of using the
whole dst for the query, I could just use the last 5 digits and like.
However, that would mean extra processing in the case where dst is known
(like...) therefore I would like a solid confirmation that indeed source can
be different in the DLR than destination in the MT sent.
Also your patch does not fully-fixes this issue.
If 2 MT are sended on the same second.
Which DLR will you get ? (probably the first one inserted on your db)
Nope. That was what this patch was created for. If dst is known, then dst
(along with ts and smsc-id) are used for the query. Therefore it will
discriminate between 2 MTs at the same time from their destination. It is
assumed, that if you don't use unique ts (ie timestamp) you will at least
include a dst.
BR,
Nikos
----- Original Message -----
From: "Vincent CHAVANIS" <[email protected]>
To: <[email protected]>
Sent: Thursday, June 24, 2010 5:27 PM
Subject: Re: Patch: EMI UUCP DLR
Hi Nikos,
This patch will be rejected as we need a global resolution
of the problem. I've already posted this patch a couple of years ago.
(http://www.mail-archive.com/[email protected]/msg05349.html)
Also your patch does not fully-fixes this issue.
If 2 MT are sended on the same second.
Which DLR will you get ? (probably the first one inserted on your db)
Vincent.
--
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[email protected]
Le 24/06/2010 12:14, Nikos Balkanas a Γ©crit :
Hi,
This patch to dlr_mysql, dlr_pgsql, dlr_oracle, dlr_mssql, dlr_mem &
dlr_sdb adds support for destination number on dlr_get, dlr_remove &
dlr_update. This is to fix a long known issue with EMI DLRs, where they
use non-unique ts (timestamp) and kannel mismatches DLRs. It compiles
clean, but I cannot test it.
Notes:
1) It needs dst NULL if it doesn't exist (some SMScs don't include it in
DLRs). Going through the code this is valid for smpp & EMI.
2) dlr_oracle.c already had implemented dst in querries. How come it
didn't conflict with said SMScs? Aligned it with rest.
3) There is no dlr_mem_update. Shouldn't there be?
@Luis: Could you please test it?
BR,
Nikos
----- Original Message ----- From: Luis Tiago Rico
To: [email protected]
Sent: Monday, June 14, 2010 12:28 PM
Subject: RE: DLR matches wrong message
This is a known problem to Kannel.
Kannel, using EMI connection, cannot guarantee DLR matching of messages
sent at the same timestamp.
Why?
Because it does not compare the MSISDN! It only queries DLR
�database’, with the timestamp (even that is not in
milliseconds)
and SMSC.
I think there is a patch for this problem (don’t know where). Or if
you manage, you can change the Kannel source code, and add the MSISDN to
the database query…. Some of these days I will have to do it for
myself.
And why this haven’t been included in the last release?
Because this does not work for all SMSC. Not all of them send back the
MSISDN…
Hope my explanation was correct!
Best Regards,
Tiago Rico
From: [email protected] [mailto:[email protected]] On
Behalf Of Konstantin Vayner
Sent: segunda-feira, 14 de Junho de 2010 09:04
To: Kannel Users
Subject: DLR matches wrong message
Hi everyone,
I'm using emi/ucp smsc under kannel 1.4.3. Here's smsc group
configuration (sensitive information masked):
group = smsc
smsc = emi
smsc-id = ucp_smsc
log-file = "/var/log/kannel/ucp_smsc.log"
log-level = 0
host = 1.2.3.4
port = 1234
smsc-username = "678"
smsc-password = XYZPWZYX
keepalive = 50
idle-timeout = 60
source-addr-autodetect = yes
allowed-smsc-id = ucp_smsc
flow-control = 1
throughput = 8
The problem is: messages sent on same timestamp mix up in DLRs even
though they are sent to different destinations. E.g. sending to X and Y
at the same time makes kannel send both DLRs to a dlr-url supplied for X.
Here's the log:
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 parsing
packet: < 04/00043/R/51/A//0541234567:130610111626/43 >
2010-06-13 11:15:33 [8444] [16] DEBUG: DLR[internal]: Adding DLR
smsc=ucp_smsc, ts=130610111626, src=031111111, dst=0541234567, mask=31,
boxc=
2010-06-13 11:15:33 [8444] [16] DEBUG: SMSC[ucp_smsc]: creating DLR
message
2010-06-13 11:15:33 [8444] [16] DEBUG: SMSC[ucp_smsc]: DLR =
http://127.0.0.1/imsc/interfaces/kannel_http/dlr.php?msg_id=32490951&dlr=%d&reason=%A
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: Got packet from
the main socket
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 parsing
packet: <
73/00239/O/53/678/0541234567/////////////130610111626/1/107/130610111626/3//4D65737361676520666F7220303534343937363830352C2077697468206964656E74696669636174696F6E2031303036313331313136323620686173206265656E206275666665726564/////////////F4
>
2010-06-13 11:15:33 [8444] [16] DEBUG: DLR[internal]: Looking for DLR
smsc=ucp_smsc, ts=130610111626, dst=0541234567, type=4
2010-06-13 11:15:33 [8444] [16] DEBUG: DLR[internal]: created DLR
message for URL
<http://127.0.0.1/imsc/interfaces/kannel_http/dlr.php?msg_id=32490951&dlr=%d&reason=%A>
2010-06-13 11:15:33 [8444] [16] DEBUG: DLR[internal]: DLR not destroyed,
still waiting for other delivery report
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 sending
packet: < 73/00020/R/53/A///A0 >
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 sending
packet: <
05/00376/O/51/0549988770/036532407//1//7///////1306102100//////4/1072/005400530054002D0042005A003A000A05D905EA05E805EA002005E405D905E705D305D505E005D505EA000A05D105E105DA000A0032002C003400330036002C003000350036002E00320032002005E905D7000A00310033002F00300036002000310031003A00310033002000680074007400700073003A002F002F007700770077002E0070////1//////0106050003030201020108///3F
>
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: Got packet from
the main socket
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 parsing
packet: < 05/00043/R/51/A//0549988770:130610111626/46 >
2010-06-13 11:15:33 [8444] [16] DEBUG: DLR[internal]: Adding DLR
smsc=ucp_smsc, ts=130610111626, src=032222222, dst=0549988770, mask=31,
boxc=
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 sending
packet: <
06/00182/O/51/0549988770/036532407///////////1306102100//////4/0304/006100790070006F0061006C0069006D002E0063006F002E0069006C002F00620061006E006B////1//////0106050003030202020108///B4
>
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: Got packet from
the main socket
2010-06-13 11:15:33 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 parsing
packet: < 06/00043/R/51/A//0549988770:130610111627/48 >
2010-06-13 11:15:33 [8444] [16] DEBUG: SMSC[ucp_smsc]: creating DLR
message
2010-06-13 11:15:33 [8444] [16] DEBUG: SMSC[ucp_smsc]: DLR =
http://127.0.0.1/imsc/interfaces/kannel_http/dlr.php?msg_id=32490499&dlr=%d&reason=%A
**this one is still correct**
... and then, a few seconds later ...
2010-06-13 11:15:46 [8444] [16] DEBUG: EMI2[ucp_smsc]: emi2 parsing
packet: <
89/00295/O/53/678/0549988770/////////////130610111626/0/000/130610111638/3//4D65737361676520666F7220303534343937333538352C2077697468206964656E74696669636174696F6E2031303036313331313136323620686173206265656E2064656C697665726564206F6E20323031302D30362D31332061742031313A31363A33382E/////////////A0
>
2010-06-13 11:15:46 [8444] [16] DEBUG: DLR[internal]: Looking for DLR
smsc=ucp_smsc, ts=130610111626, dst=0549988770, type=1
2010-06-13 11:15:46 [8444] [16] DEBUG: DLR[internal]: created DLR
message for URL
<http://127.0.0.1/imsc/interfaces/kannel_http/dlr.php?msg_id=32490951&dlr=%d&reason=%A>
**this one went out to a dlr-url of wrong message**
