Re: Patch: EMI UUCP DLRs (final)

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