Czy może ktoś zasugerować dostawcę usług wysyłania sms-ów? Nie myślę tu
o darmowych bramkach, ale o takim podmiocie, co zapewni jakieś api i
wsparcie.

--
Peter

do góry

Użytkownik "Peter" <p...@p...fm> napisał w wiadomości
news:h3ik1o$nku$1@node1.news.atman.pl...
> Czy może ktoś zasugerować dostawcę usług wysyłania sms-ów? Nie myślę tu
> o darmowych bramkach, ale o takim podmiocie, co zapewni jakieś api i
> wsparcie.

http://public.infobip.com/Products/SmsGateway.aspx

nie orientuję się jak teraz, ale w kwietniu orientacyjne ceny były następujące:
Era: 0,018 EUR
Play: 0,018 EUR
Orange: 0,025 EUR
Polkomtel: 0,025 EUR

czyli jakieś 7, 10 gr za sms

--
td
http://xmlguru.net

do góry

** Peter <p...@p...fm> wrote:

> Czy może ktoś zasugerować dostawcę usług wysyłania sms-ów? Nie myślę tu o
> darmowych bramkach, ale o takim podmiocie, co zapewni jakieś api i wsparcie.

Za mało danych podajesz. Bawię się w to mogę się podzielić wiedzą...

Ile tych SMSów chcesz wysyłać miesięcznie?

Jak rozumiem chcesz wysyłać do wszystkich sieci?

Jakie masz wymagania dotyczące dostępności usługi (SLA)?

Chcesz wysyłać po jednym SMSie czy bawić się w pakiety (coś w rodzaju sesja
N*pytanie-odpowiedź)?

SMS ma być wysyłany z numeru (nadawca np. 9123 - można oddzwonić/odpowiedzieć)
czy tekstowego identyfikatora (nadawca np. PeterCorp - nie można
oddzownić/odpowiedzieć)?

Interesuje Cię geolokalizacja skąd pochodził SMS?

Odnośnie API to czy zadowala Cię jedynie coś w rodzaju fire-and-forget (wyślij
i zapomnij) i potem miesięczne zestawienie czy chcesz też okresowo sprawdzać
status wiadomości (doręczona, niedoręczona)?

Odnośnie API to czy chcesz za pomocą niego jednocześnie kontrolować rozliczenie
usługi (np. autoryzować płatność za każdego SMS na podstawie przekazanego do
bramki tokenu, który pojawia się w zwrotnym zestawieniu)?

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** Peter <p...@p...fm> wrote:
>
>> Czy może ktoś zasugerować dostawcę usług wysyłania sms-ów? Nie myślę tu o
>> darmowych bramkach, ale o takim podmiocie, co zapewni jakieś api i wsparcie.
>
> Za mało danych podajesz. Bawię się w to mogę się podzielić wiedzą...

Za mało danych podaję, bo nie mam w tym doświadczenia. Dlatego chętnie
wysłucham kogoś, kto już przeszedł boje z tą usługą.

> Ile tych SMSów chcesz wysyłać miesięcznie?

Tego tak na prawdę nie wiadomo. Wiem jedno: nie będzie setek tysięcy.
Sądzę, że to będzie ilość na poziomie kilkuset. Może kilka tysięcy, choć
wątpię.

> Jak rozumiem chcesz wysyłać do wszystkich sieci?

Tak.

> Jakie masz wymagania dotyczące dostępności usługi (SLA)?

W ciągu 1-2h musi sms być wysłany.

> Chcesz wysyłać po jednym SMSie czy bawić się w pakiety (coś w rodzaju sesja
> N*pytanie-odpowiedź)?

Po jednym w zasadzie.

> SMS ma być wysyłany z numeru (nadawca np. 9123 - można oddzwonić/odpowiedzieć)
> czy tekstowego identyfikatora (nadawca np. PeterCorp - nie można
> oddzownić/odpowiedzieć)?

Tekstowego identyfikatora.

> Interesuje Cię geolokalizacja skąd pochodził SMS?

Nie.

> Odnośnie API to czy zadowala Cię jedynie coś w rodzaju fire-and-forget (wyślij
> i zapomnij) i potem miesięczne zestawienie czy chcesz też okresowo sprawdzać
> status wiadomości (doręczona, niedoręczona)?

Na razie "fire-and-forget".

> Odnośnie API to czy chcesz za pomocą niego jednocześnie kontrolować rozliczenie
> usługi (np. autoryzować płatność za każdego SMS na podstawie przekazanego do
> bramki tokenu, który pojawia się w zwrotnym zestawieniu)?

Nie. Przynajmniej w początkowej fazie działania usługi.

--
Peter

do góry

** Peter <p...@p...fm> wrote:

>> Ile tych SMSów chcesz wysyłać miesięcznie?

> Tego tak na prawdę nie wiadomo. Wiem jedno: nie będzie setek tysięcy. Sądzę,
> że to będzie ilość na poziomie kilkuset. Może kilka tysięcy, choć wątpię.

Ale bierzesz pod uwagę ew. rozwój itd.?

(...)

>> Jakie masz wymagania dotyczące dostępności usługi (SLA)?

> W ciągu 1-2h musi sms być wysłany.

Takie SLA to będzie dodatkowe *kilka* tysięcy złotych miesięcznie - nie wiem
czy przy tej skali (kilkaset SMS miesięcznie) w ogóle Ci się to będzie
kalkulować bo wyjdzie jakieś 4 złote za SMS (tak z grubsza licząc 500 i 2000zł
za SLA).

Tzn. pytanie jest - co jeżeli SMS w ciągu 1-2h nie zostanie wysłany? Jedyna
sensowna konstrukcja to jest kara pieniężna dla dostawcy np. za każdego nie
wysłanego w terminie SMSa dostawca płaci 50zł.

Szczerze mówiąc Twoje wymaganie w tym zakresie jest stosunkowo wysokie -
porozmawiaj z beneficjentem/sponsorem tego systemu i wyjaśnij mu, że
zapewnienie dostępności na tym poziomie po prostu kosztuje - przecież dostawca
musi zapewnić sztab operatorów monitorujących 24/7/365, sztab administratorów,
którzy są w stanie reagować 24/7/365 oraz utrzymać nadmiarowość infrastruktury
(w zasadzie backupowe DC).

>> Chcesz wysyłać po jednym SMSie czy bawić się w pakiety (coś w rodzaju sesja
>> N*pytanie-odpowiedź)?

> Po jednym w zasadzie.

Czyli tylko wysyłać - bez interakcji i odbierania?

>> SMS ma być wysyłany z numeru (nadawca np. 9123 - można
>> oddzwonić/odpowiedzieć) czy tekstowego identyfikatora (nadawca np. PeterCorp
>> - nie można oddzownić/odpowiedzieć)?

> Tekstowego identyfikatora.

Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca musi
przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować taki
identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
identyfikatorem tekstowym ale stwarzało to podatność dla systemów np. tokenów
przy płatnościach itd.

(...)

>> Odnośnie API to czy zadowala Cię jedynie coś w rodzaju fire-and-forget
>> (wyślij i zapomnij) i potem miesięczne zestawienie czy chcesz też okresowo
>> sprawdzać status wiadomości (doręczona, niedoręczona)?

> Na razie "fire-and-forget".

To jak chcesz weryfikować czy dostawca nie wystawia Ci złej faktury? Nie chodzi
mi implikowanie złej woli w przypadku takich pierdalamentów w rodzaju różnicy
kilku złotych tylko o to, że jak to się mówi kontrola najwyższą formą zaufania.
:)

Poza tym to też zależy od tego dla jakiej organizacji/instytucji implementowany
jest ten system. Np. u mnie jakby jakaś kontrola wewnętrzna (a mogę liczyć, że
będzie ich przynajmniej dwie prędzej czy później) wykryłaby, że jakiś tam SMS
nie został wysłany, został zafakturowany, a umowa przewiduje karę umowną to by
mnie ścigali, że działam na szkodę... :)

>> Odnośnie API to czy chcesz za pomocą niego jednocześnie kontrolować
>> rozliczenie usługi (np. autoryzować płatność za każdego SMS na podstawie
>> przekazanego do bramki tokenu, który pojawia się w zwrotnym zestawieniu)?

> Nie. Przynajmniej w początkowej fazie działania usługi.

Moim zdaniem jednak warto coś takiego mieć (chociażby dla kontroli działania) -
jeżeli API to udostępnia i nie trzeba za to dopłacać to warto.

Tzn. chodzi mi o coś takiego, że wywołując wysłanie SMS np. za pomocą
pseudokodu:

sendSMS(rcpt,body,id)

W parametrze id przekazujesz jakiś identyfikator i potem w miesięcznym raporcie
z rozliczeniem masz listę wszystkich SMS w formie tabeli:

data,status,rcpt,body,id

I możesz sobie skorelować to co wysyłasz od siebie z tym co jest billingowane u
operatora - przecież bez tego nie jesteś w stanie weryfikować czy wspomniane
1-2h jest realizowane prawda?

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

** Konrad Kosmowski <k...@k...net> wrote:

Jeszcze uzupełnię...

>>> SMS ma być wysyłany z numeru (nadawca np. 9123 - można
>>> oddzwonić/odpowiedzieć) czy tekstowego identyfikatora (nadawca np.
>>> PeterCorp - nie można oddzownić/odpowiedzieć)?

>> Tekstowego identyfikatora.

> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca musi
> przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować taki
> identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np. tokenów
> przy płatnościach itd.

Identyfikator tekstowy może mieć do 11 znaków oraz raczej bez umowy (dosyć
skomplikowanej) z brokerem (dostawcą) się nie obędzie ponieważ oznacza to, że
broker rejestruje identyfikator w Twoim imieniu i przyjmuje wobec operatora
zobowiązania. Czyli tutaj musi być jakaś forma umowy - przy zwykłym numerze
pewnie dałoby się po prostu jakoś online płacić za usługę akceptując regulamin
i to by wystarczyło.

W ogóle umowa z brokerem to jest ciężki kawałek prawniczego bełkotu gdyż między
innymi ma zabezpieczać przed spamem i podobnymi działaniami co jest dosyć
trudne do zdefiniowania.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** Peter <p...@p...fm> wrote:
>
>>> Ile tych SMSów chcesz wysyłać miesięcznie?
>
>> Tego tak na prawdę nie wiadomo. Wiem jedno: nie będzie setek tysięcy. Sądzę,
>> że to będzie ilość na poziomie kilkuset. Może kilka tysięcy, choć wątpię.
>
> Ale bierzesz pod uwagę ew. rozwój itd.?

Zależy, jak zdefiniujemy ten "rozwój". Raczej nie przewiduję, aby był
bardzo progresywny. Cała rzecz w tym, że usługa ta jest potrzebna do
powiadamiania o nowym zdarzeniu w określonym programie. Natomiast ilość
tych zdarzeń nie rośnie w tempie "kwadratowym".

> (...)
>
>>> Jakie masz wymagania dotyczące dostępności usługi (SLA)?
>
>> W ciągu 1-2h musi sms być wysłany.
>
> Takie SLA to będzie dodatkowe *kilka* tysięcy złotych miesięcznie - nie wiem
> czy przy tej skali (kilkaset SMS miesięcznie) w ogóle Ci się to będzie
> kalkulować bo wyjdzie jakieś 4 złote za SMS (tak z grubsza licząc 500 i 2000zł
> za SLA).
>
> Tzn. pytanie jest - co jeżeli SMS w ciągu 1-2h nie zostanie wysłany? Jedyna
> sensowna konstrukcja to jest kara pieniężna dla dostawcy np. za każdego nie
> wysłanego w terminie SMSa dostawca płaci 50zł.
>
> Szczerze mówiąc Twoje wymaganie w tym zakresie jest stosunkowo wysokie -
> porozmawiaj z beneficjentem/sponsorem tego systemu i wyjaśnij mu, że
> zapewnienie dostępności na tym poziomie po prostu kosztuje - przecież dostawca
> musi zapewnić sztab operatorów monitorujących 24/7/365, sztab administratorów,
> którzy są w stanie reagować 24/7/365 oraz utrzymać nadmiarowość infrastruktury
> (w zasadzie backupowe DC).

To wiele wyjaśnia. Gdyby jednak przyjąć, że ten sms może być wysłany,
ale niekoniecznie z takim czasem, jak 1-2h, tylko po prostu wysłany, to
mamy dwie sytuacje:

* sms dojdzie, kiedy będzie mógł; to oznacza, że może dojść nawet w
ciągu kilku godzin (nie wiem czy też nawet nie w ciągu 24h, choć to
chyba skrajność)
* beneficjent takiej usługi nie musi ponosić kosztów z tytułu utrzymania
wysokich warunków SLA

Wynika z tego, iż muszę ustalić, czy wiadomość wysłana sms-em jest
priorytetowa. W tym sensie, czy jej dostarczenie jest bezwzględnie
wymagane w ciągu określonego czasu, czy też nie jest. Jeśli założę (na
ten moment), że dostarczenie sms-a nie jest istotne w sensie 1-2h, no to
przynajmniej jedną sprawę będę miał jasną. A z drugiej strony czy
wysłany sms po n godzinach będzie nadal miał sens? Chodzi o to, że
podaną wiadomość odczytam dawno w programie, po czym po paru godzinach
dostanę wiadomość dokładnie taką samą, ale sms-em.

W takim przypadku kompromisem byłoby móc anulować wysłanie sms-a, zanim
się go otrzyma. Np. kiedy wiadomość odczytam już w programie, to sms już
nie jest mi potrzebny. A zatem mógłbym dokonać anulowanie wysyłki sms-a.
Pytanie tylko czy to możliwe?

>>> Chcesz wysyłać po jednym SMSie czy bawić się w pakiety (coś w rodzaju sesja
>>> N*pytanie-odpowiedź)?
>
>> Po jednym w zasadzie.
>
> Czyli tylko wysyłać - bez interakcji i odbierania?

Tak, ponieważ ten sms zawierać ma informację "tylko do odczytu".

>>> SMS ma być wysyłany z numeru (nadawca np. 9123 - można
>>> oddzwonić/odpowiedzieć) czy tekstowego identyfikatora (nadawca np. PeterCorp
>>> - nie można oddzownić/odpowiedzieć)?
>
>> Tekstowego identyfikatora.
>
> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca musi
> przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować taki
> identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np. tokenów
> przy płatnościach itd.
>
> (...)

W takim razie mogę śmiało uznać, że wystarczy, jeśli to będzie z numeru.
Jakiegokolwiek. To w zupełności wystarczy. Ten sms nie ma jakiejś
krytycznej wartości, a ma być jedynie nośnikiem informacji, gdyby nie
było się w tym momencie przy komputerze.

>>> Odnośnie API to czy zadowala Cię jedynie coś w rodzaju fire-and-forget
>>> (wyślij i zapomnij) i potem miesięczne zestawienie czy chcesz też okresowo
>>> sprawdzać status wiadomości (doręczona, niedoręczona)?
>
>> Na razie "fire-and-forget".
>
> To jak chcesz weryfikować czy dostawca nie wystawia Ci złej faktury? Nie chodzi
> mi implikowanie złej woli w przypadku takich pierdalamentów w rodzaju różnicy
> kilku złotych tylko o to, że jak to się mówi kontrola najwyższą formą zaufania.
> :)

No ba! "Zaufanie to piękna rzecz, ale kontrola jeszcze lepsza" - to
prawda. Praktycznie powinno dać się zweryfikować to, bo przecież za
pomocą jakiegoś API wysyłam sms-a i mogę zliczać liczbę wysyłek. Pytanie
czy takie coś wystarczy? A co z tymi sms-ami, które anulowałem? (o ile
da się)

> Poza tym to też zależy od tego dla jakiej organizacji/instytucji implementowany
> jest ten system. Np. u mnie jakby jakaś kontrola wewnętrzna (a mogę liczyć, że
> będzie ich przynajmniej dwie prędzej czy później) wykryłaby, że jakiś tam SMS
> nie został wysłany, został zafakturowany, a umowa przewiduje karę umowną to by
> mnie ścigali, że działam na szkodę... :)

No właśnie. Dlatego, jak podałem wyżej, można by zliczać po swojej
stronie ilość wysłanych sms-ów i porównywać to z danymi od operatora.
Pytanie tylko na ile operator w ogóle weźmie pod uwagę ilość podaną
przez beneficjenta w przypadku reklamacji? Musiałby istnieć jakiś system
weryfikacji danych.

>>> Odnośnie API to czy chcesz za pomocą niego jednocześnie kontrolować
>>> rozliczenie usługi (np. autoryzować płatność za każdego SMS na podstawie
>>> przekazanego do bramki tokenu, który pojawia się w zwrotnym zestawieniu)?
>
>> Nie. Przynajmniej w początkowej fazie działania usługi.
>
> Moim zdaniem jednak warto coś takiego mieć (chociażby dla kontroli działania) -
> jeżeli API to udostępnia i nie trzeba za to dopłacać to warto.
>
> Tzn. chodzi mi o coś takiego, że wywołując wysłanie SMS np. za pomocą
> pseudokodu:
>
> sendSMS(rcpt,body,id)
>
> W parametrze id przekazujesz jakiś identyfikator i potem w miesięcznym raporcie
> z rozliczeniem masz listę wszystkich SMS w formie tabeli:
>
> data,status,rcpt,body,id
>
> I możesz sobie skorelować to co wysyłasz od siebie z tym co jest billingowane u
> operatora - przecież bez tego nie jesteś w stanie weryfikować czy wspomniane
> 1-2h jest realizowane prawda?

O proszę. A parę linii wyżej właśnie o to się martwiłem, po czym widzę,
że jednak jest możliwa weryfikacja kontroli działania usługi. Pozostaje
mi tylko pytanie czy można anulować wysyłkę sms-a, jeśli jeszcze go nie
otrzymałem, a wiem np., że już go nie potrzebuję.

--
Peter

do góry

Konrad Kosmowski pisze:
> ** Konrad Kosmowski <k...@k...net> wrote:
>
> Jeszcze uzupełnię...
>
>>>> SMS ma być wysyłany z numeru (nadawca np. 9123 - można
>>>> oddzwonić/odpowiedzieć) czy tekstowego identyfikatora (nadawca np.
>>>> PeterCorp - nie można oddzownić/odpowiedzieć)?
>
>>> Tekstowego identyfikatora.
>
>> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca musi
>> przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować taki
>> identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
>> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np. tokenów
>> przy płatnościach itd.
>
> Identyfikator tekstowy może mieć do 11 znaków oraz raczej bez umowy (dosyć
> skomplikowanej) z brokerem (dostawcą) się nie obędzie ponieważ oznacza to, że
> broker rejestruje identyfikator w Twoim imieniu i przyjmuje wobec operatora
> zobowiązania. Czyli tutaj musi być jakaś forma umowy - przy zwykłym numerze
> pewnie dałoby się po prostu jakoś online płacić za usługę akceptując regulamin
> i to by wystarczyło.

Muszę to sprawdzić, ale wydaje mi się, że w tym przypadku identyfikator
tekstowy nie będzie konieczny.

> W ogóle umowa z brokerem to jest ciężki kawałek prawniczego bełkotu gdyż między
> innymi ma zabezpieczać przed spamem i podobnymi działaniami co jest dosyć
> trudne do zdefiniowania.

A to już inna sprawa. Czasem nawet "2 słowa" potrafią diametralnie
zmienić sens umowy.

--
Peter

do góry

** Peter <p...@p...fm> wrote:

(Ciach SLA)

> To wiele wyjaśnia. Gdyby jednak przyjąć, że ten sms może być wysłany, ale
> niekoniecznie z takim czasem, jak 1-2h, tylko po prostu wysłany, to mamy dwie
> sytuacje:

Nie. Ale to nie rozumiemy się. W *normalnej* sytuacji SMS jest wysyłany od
Ciebie do bramki z prędkością jakieś 50 szt. na sekundę. Dalej bramka brokera
rozsyła do danych SMSC ale generalnie trwa to momentalnie (o ile odbiorca ma
włączony telefon, nie występuje np. świąteczne przeciążenie sieci GSM itd.).

O czym ja mówię to sytuacja, w której brokerowi pada datacenter i wyniku tego
Ty nie możesz nic wysłać przez jakiś czas.

> * sms dojdzie, kiedy będzie mógł; to oznacza, że może dojść nawet w ciągu
> kilku godzin (nie wiem czy też nawet nie w ciągu 24h, choć to chyba
> skrajność)

Ale to nie o to mi chodziło (chociaż de facto chodzi o fakt dojścia SMS) -
chodzi mi o to, że bramka dostawcy padła i jej nie ma.

> * beneficjent takiej usługi nie musi ponosić kosztów z tytułu utrzymania
> wysokich warunków SLA

No to nie ma uzasadnienia dla płacenia za SLA. Nie napisałeś nic o tym jaka to
usługa dlatego zwracam na to uwagę.

Np. są usługi w których Ty klientowi gwarantujesz, że co by się nie stało to
dostanie SMS w ciągu N jednostek czasu, a jak nie dostanie to Ty wypłacasz
odszkodowanie. Jeżeli klient sobie tego życzy to odpowiednio zapłaci. W takiej
sytuacji Ty z kolei wymagasz od brokera zbliżonych parametrów, aby było tak, że
jak Ty się nie wywiążesz z usługi to płacisz klientowi odszkodowanie z tego co
Ci broker wypłacił. :) Mniej więcej po to jest SLA.

(...)

> A z drugiej strony czy wysłany sms po n godzinach będzie nadal miał sens?
> Chodzi o to, że podaną wiadomość odczytam dawno w programie, po czym po paru
> godzinach dostanę wiadomość dokładnie taką samą, ale sms-em.

Od tego to jest ważność wiadomości SMS, którą respektuje SMSC operatora
komórkowego - i to jest kolejny (o ile Ci to potrzebny) parametr, który
chciałbyś przekazywać do brokera wywołując API.

> W takim przypadku kompromisem byłoby móc anulować wysłanie sms-a, zanim się
> go otrzyma. Np. kiedy wiadomość odczytam już w programie, to sms już nie jest
> mi potrzebny. A zatem mógłbym dokonać anulowanie wysyłki sms-a. Pytanie
> tylko czy to możliwe?

Ja się pogubiłem w tym co napisałeś. Generalnie przez brokera w prosty sposób
to się odbywa tak:

1. Wysyłasz przez API wywołanie wysłania SMS do brokera.
2. Broker przetwarza wywołanie i przesyła do właściwego SMSC (wcześniej jeszcze
odpytuje SMSC o przynależność numeru bo obecnie prefiks nie definiuje z jakiej
sieci jest numer).
3. SMSC odbiera wiadomość SMS, kolejkuje i dostarcza (bądź nie - abonent
niedostępny) wiadomość.

W między czasie broker może odpytywać SMSC operatora o status wiadomości
(odebrana, oczekuje, zły numer itd.), a Ty możesz odpytywać o to brokera.
Działanie asynchroniczne.

Co może pójść nie tak?
1. Połączenie do brokera nie jest dostępne - padła sieć.
2. Połączenie do brokera jest ale wysypał im się serwer/usługa i nie odpowiada.
3. Połączenie do brokera i usługi jest, ale oprogramowanie brokera zwariowało i
faktycznie nic nie wysyła.

I to samo powyższe na styku broker/operator. Do tego dodaj jeszcze odpytywanie
o status itd. :)

(...)

>> Czyli tylko wysyłać - bez interakcji i odbierania?

> Tak, ponieważ ten sms zawierać ma informację "tylko do odczytu".

Ale jedną wiadomość w ciągu N czasu czy może to będzie tak, że w ciągu
przewidywalnego czasu do odbiorcy wyślesz kilka wiadomości? Jeżeli tak to
pogadaj z brokerem o pakietach - duzi operatorzy już je obsługują. Chodzi mi o
to, że jeżeli wyjdzie Ci, że przy jednej "transakcji" w systemie statystycznie
wychodzi 2,3 wysłanych wiadomości SMS w ciągu np. doby to warto pomyśleć o
pakietach (to jest po prostu forma rozliczenia).

(...)

>> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca
>> musi przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować
>> taki identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
>> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np.
>> tokenów przy płatnościach itd.

>> (...)

> W takim razie mogę śmiało uznać, że wystarczy, jeśli to będzie z numeru.
> Jakiegokolwiek. To w zupełności wystarczy. Ten sms nie ma jakiejś krytycznej
> wartości, a ma być jedynie nośnikiem informacji, gdyby nie było się w tym
> momencie przy komputerze.

No ale to powinieneś napisać od razu. :)

(...)

>> Poza tym to też zależy od tego dla jakiej organizacji/instytucji
>> implementowany jest ten system. Np. u mnie jakby jakaś kontrola wewnętrzna
>> (a mogę liczyć, że będzie ich przynajmniej dwie prędzej czy później)
>> wykryłaby, że jakiś tam SMS nie został wysłany, został zafakturowany, a
>> umowa przewiduje karę umowną to by mnie ścigali, że działam na szkodę... :)

> No właśnie. Dlatego, jak podałem wyżej, można by zliczać po swojej stronie
> ilość wysłanych sms-ów i porównywać to z danymi od operatora. Pytanie tylko
> na ile operator w ogóle weźmie pod uwagę ilość podaną przez beneficjenta w
> przypadku reklamacji? Musiałby istnieć jakiś system weryfikacji danych.

Musisz po swojej stronie zapisywać wszystko co wysyłasz (log po prostu data, nr
odbiorcy, treść, identyfikator transakcji itd.), od dostawcy wymagaj, aby taki
sam log (tylko od swojej strony) przekazywał Ci w raporcie billingowym do
faktury. A potem przy rozliczeniu weryfikuj. Dodanie przekazywania unikatowego
(ten definiujesz Ty) identyfikatora aby się pojawiał w raporcie zwrotnym
ułatwia przetwarzanie takich danych no bo wiąże to co jest u Ciebie, z tym co
Ci liczy dostawca.

Przy czym kontrola jest dlatego, że każdy może się pomylić. Nie sądzę aby na
sensownych warunkach umowy dostawca miał motyw do tego aby robić drobne
przekręty w ten sposób. Po prostu chodzi o wykrywanie pomyłek, a dalsze
postępowanie to przecież zależy od zaufania i woli współpracy - najczęściej jak
dostawca się pomyli i stwierdzi to u siebie na podstawie Twojego raportu to do
jakiegoś kompromisu dojdziecie np. policzy Ci mniej za następny miesiąc.

(...)

>> I możesz sobie skorelować to co wysyłasz od siebie z tym co jest
>> billingowane u operatora - przecież bez tego nie jesteś w stanie weryfikować
>> czy wspomniane 1-2h jest realizowane prawda?

> O proszę. A parę linii wyżej właśnie o to się martwiłem, po czym widzę, że
> jednak jest możliwa weryfikacja kontroli działania usługi.

No tak. Tylko, że ja zupełnie nie mam doświadczenia z takimi masowymi bramkami.
To co my mamy to API było tworzone pod nasze wymagania i tam to precyzowaliśmy,
nie wiem jak jest u masowych (ale to logiczne jest aby była taka funkcjonalność
- zwróć na to uwagę).

> Pozostaje mi tylko pytanie czy można anulować wysyłkę sms-a, jeśli jeszcze go
> nie otrzymałem, a wiem np., że już go nie potrzebuję.

Szczerze mówiąc nie wiem. Anulować możesz tylko wiadomości oczekujące na
doręczenie. A wydaje mi się, że zaksięgują Ci płatność za wysyłkę bez względu
na to czy odbiorca miał włączony czy wyłączony telefon.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** Peter <p...@p...fm> wrote:
>
> (Ciach SLA)
>
>> To wiele wyjaśnia. Gdyby jednak przyjąć, że ten sms może być wysłany, ale
>> niekoniecznie z takim czasem, jak 1-2h, tylko po prostu wysłany, to mamy dwie
>> sytuacje:
>
> Nie. Ale to nie rozumiemy się. W *normalnej* sytuacji SMS jest wysyłany od
> Ciebie do bramki z prędkością jakieś 50 szt. na sekundę. Dalej bramka brokera
> rozsyła do danych SMSC ale generalnie trwa to momentalnie (o ile odbiorca ma
> włączony telefon, nie występuje np. świąteczne przeciążenie sieci GSM itd.).
>
> O czym ja mówię to sytuacja, w której brokerowi pada datacenter i wyniku tego
> Ty nie możesz nic wysłać przez jakiś czas.

W porządku. Powyższe jednak nie stanowi problemu, ponieważ wiadomość
wysłana sms-em nie jest krytyczna, tzn. nie musi być dostarczona w
określonym przedziale czasowym. Nie jestem pewien, czy dobrze się
rozumiemy, ale może trzeba więcej informacji.

>> * sms dojdzie, kiedy będzie mógł; to oznacza, że może dojść nawet w ciągu
>> kilku godzin (nie wiem czy też nawet nie w ciągu 24h, choć to chyba
>> skrajność)
>
> Ale to nie o to mi chodziło (chociaż de facto chodzi o fakt dojścia SMS) -
> chodzi mi o to, że bramka dostawcy padła i jej nie ma.

Wtedy powinienem mieć przynajmniej jakiś komunikat zwrotny. O ile jest
taka możliwość. Padnięcie usługi nie oznacza od razu brak kontaktu z
serwerem brokera. Chociaż nie mogę tego wykluczyć.

>> * beneficjent takiej usługi nie musi ponosić kosztów z tytułu utrzymania
>> wysokich warunków SLA
>
> No to nie ma uzasadnienia dla płacenia za SLA. Nie napisałeś nic o tym jaka to
> usługa dlatego zwracam na to uwagę.

Jest program, w którym użytkownicy wpisują swoje zdarzenia. Każde nowe
zdarzenie musi generować sms-a na konkretny numer telefonu. Sms ów nie
jest informacją krytyczną, a jedynie treścią tzw. "do wiadomości". Nie
jest wymagane jej dostarczenie natychmiast, ale tak, jak jest to w
rzeczywistości - wysyłam i... czekam, aż dojdzie. Przy czym sądzę, że
kilka godzin oczekiwania zupełnie jest do przyjęcia, ale już kilkanaście
powoduje to, że treść tego sms-a staje się bezwartościowa, bo dana osoba
mogła już w programie dawno odczytać wiadomość.

A zatem musiałby istnieć jakiś mechanizm dzięki któremu będzie można
anulować dostarczenie sms-a. O ile takowy istnieje.

> Np. są usługi w których Ty klientowi gwarantujesz, że co by się nie stało to
> dostanie SMS w ciągu N jednostek czasu, a jak nie dostanie to Ty wypłacasz
> odszkodowanie. Jeżeli klient sobie tego życzy to odpowiednio zapłaci. W takiej
> sytuacji Ty z kolei wymagasz od brokera zbliżonych parametrów, aby było tak, że
> jak Ty się nie wywiążesz z usługi to płacisz klientowi odszkodowanie z tego co
> Ci broker wypłacił. :) Mniej więcej po to jest SLA.

To trochę ryzykowne, bo wpakowuję się w przepychanki prawne w razie
draki. W zasadzie nie chciałbym być "pomiędzy" i wolałbym, aby klient
miał z brokerem bezpośredni kontakt. Ja wolałbym tylko stworzyć
odpowiednie narzędzie do kontaktu pomiędzy klientem a brokerem.

> (...)
>
>> A z drugiej strony czy wysłany sms po n godzinach będzie nadal miał sens?
>> Chodzi o to, że podaną wiadomość odczytam dawno w programie, po czym po paru
>> godzinach dostanę wiadomość dokładnie taką samą, ale sms-em.
>
> Od tego to jest ważność wiadomości SMS, którą respektuje SMSC operatora
> komórkowego - i to jest kolejny (o ile Ci to potrzebny) parametr, który
> chciałbyś przekazywać do brokera wywołując API.

A zatem mogę ustawić ważność czasu wiadomości, ale anulować jej wysłania
nie mogę. Tak?

>> W takim przypadku kompromisem byłoby móc anulować wysłanie sms-a, zanim się
>> go otrzyma. Np. kiedy wiadomość odczytam już w programie, to sms już nie jest
>> mi potrzebny. A zatem mógłbym dokonać anulowanie wysyłki sms-a. Pytanie
>> tylko czy to możliwe?
>
> Ja się pogubiłem w tym co napisałeś. Generalnie przez brokera w prosty sposób
> to się odbywa tak:
>
> 1. Wysyłasz przez API wywołanie wysłania SMS do brokera.
> 2. Broker przetwarza wywołanie i przesyła do właściwego SMSC (wcześniej jeszcze
> odpytuje SMSC o przynależność numeru bo obecnie prefiks nie definiuje z jakiej
> sieci jest numer).
> 3. SMSC odbiera wiadomość SMS, kolejkuje i dostarcza (bądź nie - abonent
> niedostępny) wiadomość.

Ok, mechanizm jest zrozumiały.

> W między czasie broker może odpytywać SMSC operatora o status wiadomości
> (odebrana, oczekuje, zły numer itd.), a Ty możesz odpytywać o to brokera.
> Działanie asynchroniczne.

To ważne, aby mieć stały kontakt z brokerem.

> Co może pójść nie tak?
> 1. Połączenie do brokera nie jest dostępne - padła sieć.
> 2. Połączenie do brokera jest ale wysypał im się serwer/usługa i nie odpowiada.
> 3. Połączenie do brokera i usługi jest, ale oprogramowanie brokera zwariowało i
> faktycznie nic nie wysyła.
>
> I to samo powyższe na styku broker/operator. Do tego dodaj jeszcze odpytywanie
> o status itd. :)
>
> (...)

Wygląda na to, że jest trochę z tymi sms-ami problemów, ale da się je
rozwiązać. Zapewne zależy wiele od jakości brokera i operatora.

>>> Czyli tylko wysyłać - bez interakcji i odbierania?
>
>> Tak, ponieważ ten sms zawierać ma informację "tylko do odczytu".
>
> Ale jedną wiadomość w ciągu N czasu czy może to będzie tak, że w ciągu
> przewidywalnego czasu do odbiorcy wyślesz kilka wiadomości? Jeżeli tak to
> pogadaj z brokerem o pakietach - duzi operatorzy już je obsługują. Chodzi mi o
> to, że jeżeli wyjdzie Ci, że przy jednej "transakcji" w systemie statystycznie
> wychodzi 2,3 wysłanych wiadomości SMS w ciągu np. doby to warto pomyśleć o
> pakietach (to jest po prostu forma rozliczenia).
>
> (...)

Dziękuję. Zwrócę uwagę na pakiety. W sumie rzeczywiście może się okazać,
że jeśli średnia ilość na miesiąc wychodzi n, to może warto będzie
negocjować pakiety.

>>> Rejestracja identyfikatora to jednorazowa opłata rzędu 1000zł - dostawca
>>> musi przejść procedury w centrach SMSC każdej z sieci (!) aby zarejestrować
>>> taki identyfikator. Kiedyś mając dostęp do SMSC dało się słać z dowolnym
>>> identyfikatorem tekstowym ale stwarzało to podatność dla systemów np.
>>> tokenów przy płatnościach itd.
>
>>> (...)
>
>> W takim razie mogę śmiało uznać, że wystarczy, jeśli to będzie z numeru.
>> Jakiegokolwiek. To w zupełności wystarczy. Ten sms nie ma jakiejś krytycznej
>> wartości, a ma być jedynie nośnikiem informacji, gdyby nie było się w tym
>> momencie przy komputerze.
>
> No ale to powinieneś napisać od razu. :)
>
> (...)

No cóż. Pierwszy raz badam ten temat, a zatem mogę błądzić ;-)

>>> Poza tym to też zależy od tego dla jakiej organizacji/instytucji
>>> implementowany jest ten system. Np. u mnie jakby jakaś kontrola wewnętrzna
>>> (a mogę liczyć, że będzie ich przynajmniej dwie prędzej czy później)
>>> wykryłaby, że jakiś tam SMS nie został wysłany, został zafakturowany, a
>>> umowa przewiduje karę umowną to by mnie ścigali, że działam na szkodę... :)
>
>> No właśnie. Dlatego, jak podałem wyżej, można by zliczać po swojej stronie
>> ilość wysłanych sms-ów i porównywać to z danymi od operatora. Pytanie tylko
>> na ile operator w ogóle weźmie pod uwagę ilość podaną przez beneficjenta w
>> przypadku reklamacji? Musiałby istnieć jakiś system weryfikacji danych.
>
> Musisz po swojej stronie zapisywać wszystko co wysyłasz (log po prostu data, nr
> odbiorcy, treść, identyfikator transakcji itd.), od dostawcy wymagaj, aby taki
> sam log (tylko od swojej strony) przekazywał Ci w raporcie billingowym do
> faktury. A potem przy rozliczeniu weryfikuj. Dodanie przekazywania unikatowego
> (ten definiujesz Ty) identyfikatora aby się pojawiał w raporcie zwrotnym
> ułatwia przetwarzanie takich danych no bo wiąże to co jest u Ciebie, z tym co
> Ci liczy dostawca.
>
> Przy czym kontrola jest dlatego, że każdy może się pomylić. Nie sądzę aby na
> sensownych warunkach umowy dostawca miał motyw do tego aby robić drobne
> przekręty w ten sposób. Po prostu chodzi o wykrywanie pomyłek, a dalsze
> postępowanie to przecież zależy od zaufania i woli współpracy - najczęściej jak
> dostawca się pomyli i stwierdzi to u siebie na podstawie Twojego raportu to do
> jakiegoś kompromisu dojdziecie np. policzy Ci mniej za następny miesiąc.
>
> (...)

To takie działanie prewencyjne, ale potrzebne.

>>> I możesz sobie skorelować to co wysyłasz od siebie z tym co jest
>>> billingowane u operatora - przecież bez tego nie jesteś w stanie weryfikować
>>> czy wspomniane 1-2h jest realizowane prawda?
>
>> O proszę. A parę linii wyżej właśnie o to się martwiłem, po czym widzę, że
>> jednak jest możliwa weryfikacja kontroli działania usługi.
>
> No tak. Tylko, że ja zupełnie nie mam doświadczenia z takimi masowymi bramkami.
> To co my mamy to API było tworzone pod nasze wymagania i tam to precyzowaliśmy,
> nie wiem jak jest u masowych (ale to logiczne jest aby była taka funkcjonalność
> - zwróć na to uwagę).

Być może będzie możliwość "doszlifowania" API.

>> Pozostaje mi tylko pytanie czy można anulować wysyłkę sms-a, jeśli jeszcze go
>> nie otrzymałem, a wiem np., że już go nie potrzebuję.
>
> Szczerze mówiąc nie wiem. Anulować możesz tylko wiadomości oczekujące na
> doręczenie. A wydaje mi się, że zaksięgują Ci płatność za wysyłkę bez względu
> na to czy odbiorca miał włączony czy wyłączony telefon.

A to trochę nie do końca sprawiedliwe, bo w końcu anulowałem usługę i
nie powinna być ona wykonana. Myślę, że to mogą precyzować warunki
umowy, z którym trzeba się dokładnie zapoznać.

--
Peter

do góry