Re: Patch: EMI UUCP DLR

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