Konstantin,
That's fine with me. This is beyond DLR matching. What kannel does with this
hash is not this patch's business.
BR,
Nikos
----- Original Message -----
From: Konstantin Vayner
To: Nikos Balkanas
Cc: Alejandro Guerrieri ; [email protected]
Sent: Wednesday, July 21, 2010 6:11 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Nikos,
You can send to the same hash number that you got from the operator for a
certain period of time from his last MO
after that he is no longer accessible for you until he sends a new MO - and
then a new (other) hash is generated
hashes are per-broker as far as i know, too...
so you cant reuse this hash from other broker account
2010/7/21 Nikos Balkanas <[email protected]>
Thanks for clarification. Help me clarify one more thing.
This is for MO traffic (no DLRs). I know about MO response (the sms-service
result), but what is MT response to an MO?
BR,
Nikos
----- Original Message ----- From: "Alejandro Guerrieri"
<[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: <[email protected]>; "Alexander Malysh" <[email protected]>;
<[email protected]>
Sent: Wednesday, July 21, 2010 4:31 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Some operators don't send the phone number in plain text. Instead, they send
some sort of hashed string.
To send an MT in response to an MO, you send it with the destination set as
that hashed string instead of a phone number. The operator matches the hash
on their side and deliver to the real number.
This is to avoid ESME's from collecting phone numbers and use them for spam
or resell it.
Regards,
Alex
--
Alejandro Guerrieri
[email protected]
On 21/07/2010, at 15:02, Nikos Balkanas wrote:
Interesting, PDU level spam? Why then do they bother encrypting it? They
could just leave it blank or fill in some garbadge.
Could you provide me a detailed log excerpt of such a submission and DLR
with encryption?
The limitation that you refer to, is only valid for EMI/CIMD2. SMPP faces no
such issue. Should have been mentioned though, but now it is too late, I am
designing a patch for it.
@Alex: What do you think? It seems I need to make that parameter
configurable. I will have to resubmit. Please do not commit yet.
BR,
Nikos
----- Original Message ----- From: "Vincent CHAVANIS"
<[email protected]>
To: "Nikos Balkanas" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, July 21, 2010 3:12 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi,
we cannot predict the alias from the MSISDN
this was designed for ;)
Also, This should IMO be mentionned into the source
of the driver, that we cannot send 2mt within the same sec
for the same dest/alias because, this is an known
limitation of the protocol.
Vincent.
Le 21/07/2010 13:52, Nikos Balkanas a ��©crit :
Hi Vincent,
In this version, this patch will not affect other than EMI and CIMD2 DLRs.
SMPP for example doesn't match against destination. However, EMI and CIMD2
do. Not
to worry, though. Such a condition was anticipated. Mechanism was
implemented to quickly switch from driver-specific to smsc configuration
specific. Therefore
with a minor change destination matching could be disabled for those smscs
that use such encryption.
However, that would mean that patch wouldn't apply for these cases, ie, DLRs
received at the same time. A better way would be to calculate the encryption
and
implement it when used. Is there a way to predict it? How can I get more
info about it?
BR,
Nikos
----- Original Message ----- From: "Vincent CHAVANIS"
<[email protected]>
To: <[email protected]>
Sent: Wednesday, July 21, 2010 1:45 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hi nikos,
'alias' is an "crypted" MSISDN done by the operator-side
to protect the customer (avoid spamming, and any abuses)
This actually exists here in fr but i assume,
this also exists on other countries
I just want to be sure this will not
break any existing installations.
Vincent.
Le 21/07/2010 12:16, Nikos Balkanas a � β€ �’Β©crit :
@Vincent: With respect to destination alias, what do you mean? Looking for
alias in gwlib/cfg.def I cannot find anything relevant.
