Thanks, Thomas.
Absolutely, yes. If the MT is pushed to a hashed string, that string is used
as destination by bb and entered in the dlr_entry on suybmit_sm_resp (SMPP).
Since the same hash is used by the SMSc in DLR (deliver_sm), it will succeed
no matter what.
If that is what is at stake, patch won't be affected by this.
BR,
Nikos
----- Original Message -----
From: "Thomas Gottgens" <[email protected]>
To: "Nikos Balkanas" <[email protected]>
Sent: Wednesday, July 21, 2010 5:14 PM
Subject: Re: Patch: EMI UUCP DLRs (final)
Hello Nikos,
this becomes relevant if you not use the sms-service
result as an answer but generate the answer from a script and submit a
new MT-SMS via the cgi or other means.
Having said that, if i need to send to the hash instead of the MSISDN,
would the incoming
DLR's for that new SMS not contain the same hash, hence the match
succeeds?
Wednesday, July 21, 2010, 4:03:16 PM, you wrote:
NB> Thanks for clarification. Help me clarify one more thing.
NB> This is for MO traffic (no DLRs). I know about MO response (the
sms-service
NB> result), but what is MT response to an MO?
NB> BR,
NB> Nikos
NB> ----- Original Message -----
NB> From: "Alejandro Guerrieri" <[email protected]>
NB> To: "Nikos Balkanas" <[email protected]>
NB> Cc: <[email protected]>; "Alexander Malysh"
<[email protected]>;
NB> <[email protected]>
NB> Sent: Wednesday, July 21, 2010 4:31 PM
NB> Subject: Re: Patch: EMI UUCP DLRs (final)
NB> Some operators don't send the phone number in plain text. Instead,
they send
NB> some sort of hashed string.
NB> To send an MT in response to an MO, you send it with the destination
set as
NB> that hashed string instead of a phone number. The operator matches the
hash
NB> on their side and deliver to the real number.
NB> This is to avoid ESME's from collecting phone numbers and use them for
spam
NB> or resell it.
NB> Regards,
NB> Alex
NB> --
NB> Alejandro Guerrieri
NB> [email protected]
NB> 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.
--
Best regards,
Thomas mailto:[email protected]
