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