Re: Fw: Patch: EMI UUCP DLRs (final)

Hi nikos,

I never mention this was an issue, i just want to inform you
some points that are not documented on the EMI 4.6 Specs.
We have here a limitation due to the protocol. I'm fine with it.

Vincent.


Le 21/07/2010 16:48, Nikos Balkanas a écrit :
> Hi Vincent,
>
> If that is the case, this is a non-issue, and we can go ahead. Is that what you were referring, to?
>
> BR,
> Nikos
> ----- Original Message ----- From: "Nikos Balkanas" <[email protected]>
> To: "Thomas Gottgens" <[email protected]>
> Cc: <[email protected]>
> Sent: Wednesday, July 21, 2010 5:22 PM
> Subject: 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]
>>
>
>
>

-- 
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[email protected]
Tel : +33 4 92 90 99 84 (fax 9142)