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