komunikacja komórka<->serwer przy użyciu GPRS

[johnyjj2]

Witam!

Rzecz jest w tym, że chciałbym aby:
1. użytkownik uruchamiał na telefonie komórkowym (max 700 zł) aplikację w Javie,
2. przy pomocy tej aplikacji użytkownik wprowadzałby pewne dane głosowe,
3. dane te komórka wysyłałaby na serwer (stąd też pomyślałem o GPRS-ie; drugą opcją, wydaje mi się, że gorszą, byłby VoIP SIP),
4. serwer w pewien sposób analizowałby te dane (odebrane np. jako plik dźwiękowy - jaki format? wave, rm? - o długości np. 2sek, 5s, 20s),
5. serwer odpowiadałby wiadomością tekstową na komórkę,
6. aplikacja w Javie na komórce analizowałaby tą informację tekstową,
7. i tak dalej :-)
Czy możecie mi zasugerować jakieś technologie, protokoły, tutoriale?

Z góry dzięki za pomoc :-)
Pozdrawiam,
Rafał

[Wawelski]

AD.3 - a ten VoIP to nie po GPRS?

Chodzi Ci o program typu MusicID którym nagrywasz kawałek utworu i dostajesz info o wykonawcy i tytule?
Chyba odsyłanie powinno być tak samo, przez net, jak wysyłanie.

[johnyjj2]

Dzięki za odpowiedź :-).

Jest różnica między VoIP-em, a GPRS-em.

VoIP, czyli Voice over Internet Protocol wykorzystuje internet do przesyłu informacji. Czyli w mojej sytuacji raczej odpada, bo jest ta odległość, dajmy na to, 2 km pomiędzy telefonem i serwerem. Dałoby się to rozwiązać przy pomocy anteny kierunkowej oraz telefonu voip (są też bramki voip), ale to zwiększa koszty eksploatacji oraz podatność na zakłócenia.

GPRS to technologia w sieciach GSM do pakietowego przesyłania danych - umożliwia korzystanie z internetu albo transmisji strumieniowej audio/wideo (źródło: Wikipedia). Wykorzystuje sieci GSM, a nie internet. Sieci GSM są raczej mniej podatne na zakłócenia, za to koszty eksploatacji mogłyby być trochę większe. Mimo to skłaniałbym się ku GPRS.

I nie chodzi mi o MusicID, ale o wykorzystanie programu do rozpoznawania mowy na serwerze.

Pozdrawiam!

[andy]

XMPP (rozszerzenie Jingle) - protokół do przesyłu dźwięku/video.

Na serwerze zainstalowane np. eJabberd2 z którym łączy się telefon i przesyła dźwięk do usługi która odpowiednio analizuje i odsyła wiadomość. Problem w tym, że nie mam pojęcia czy istnieje darmowa implementacja czegoś takiego.


Tak w ogóle to do czego Ci to potrzebne?

[Wawelski]

Napisany przez johnyjj2

Dzięki za odpowiedź :-).

Jest różnica między VoIP-em, a GPRS-em.

To ja wiem, że jest różnica. Tylko jak na telefonie będziesz miało VoIP jak nie przez GPRS (czy raczej już HSDPA częściej)? Więc tak czy inaczej będzie szło przez GPRS.

Jak głos, to ma sens "zwykłe" połączenie GSM. Ale to raczej kwestia obadania ofert, co wyjdzie lepiej cenowo i prościej technicznie w implementacji. Przy zwykłym połączeniu nie potrzebujesz nic na telefonie i każdy aparat to obsłuży. Jak odesłanie SMSem - to też każdy.
Można też jakiś format dźwiękowy i MMS albo mail, albo cokolwiek. VoIP IMO ma najmniejszy sens - bo komplikacja, a jak rozmowy nie międzynarodowe, to cenowo też żadna rewelacja.

[sobrus]

Z punktu widzenia programu będzie całkowicie obojętne czy to GPRS czy HSDPA (tak jak mp programista Firefoxa nie zajmuje się modemami ADSL).
Java operuje na poziomie protokołu TCP/IP, kwestię realizacji połączenia zostawmy systemowi operacyjnemu telefonu.

Bedzie to wygladac następująco
- aplikacja nagywa dzwiek i ma go gdzieś w pamieci
- tworzy połączenie z serwerem na porcie na którym on nasłuchuje (pewnie pare linijek kodu nie licząc obsługi błędów, adres serwera zawsze taki sam)
- zapisuje dane binarnie do strumienia (nie programuje w Javie to nie wiem dokładnie jak to tam wyglada, ale bedzie to pewnie jedna instrukcja, ew w pętli)
- zamyka połączenie i zaczyna nasłuch na dane zwrotne (czeka).
itd...

Java to język wysokiego poziomu. Operacje na TCP/IP są tam z tego co pamietam prawie tak łatwe jak operacje na zwykłych plikach, a o dostęp do internetu zatroszczy sie VM oraz system operacyjny (przy próbie otworzenia połączenia telefon zapyta się czy umożliwić aplikacji dostęp do internetu).

Dlatego zastanawianie sie nad protokołem jest bez sensu, bo i tak będzie to TCP/IP Przy czym oczywiście pakietów nikt ręcznie nie rzeźbi bo zrobi to Java.
Trzeba sie zastanowić nad formatem przesyłu danych (najłatwiej pewnie ADPCM) a VoIP zostawić w spokoju.

[johnyjj2]

Dzięki wielkie za Wasze odpowiedzi, są one dla mnie niezmiernie przydatne :-)

Wprowadziłem pewne nieznaczne zmiany w pomyśle i teraz wyglądało by to tak:
1. użytkownik uruchamia MIDlet (na komórce z Symbianem bądź bez)
2. MIDlet łączy się przy pomocy GSM/GPRS/EDGE/UMTS z serwerem (jak rozumiem wybór pomiędzy GSM/GPRS/EDGE/UMTS nie jest ode mnie zależny)
3. następuje zwykła rozmowa telefoniczna, z tą różnicą, że drugim rozmówcą nie jest człowiek, tylko komputer :-P
4. użytkownik kończy połączenie
5. użytkownik wyłącza MIDlet

Zaś na serwerze punkt (3) wyglądał by tak:
Serwer w czasie rzeczywistym odbiera rozmowę od użytkownika komórki. Przesłana mowa jest w czasie rzeczywistym wysyłana do ciągłego rozpoznawania mowy w programie Sphinx4 na serwerze. Po uzyskaniu odpowiednich informacji od użytkownika drogą głosową, zamiany ich na plik tekstowy i przeanalizownia tego pliku tekstowego, serwer przesyła swoją "mowę" do komórki (czyli albo syntezator mowy albo kilka gotowych, standardowych plików mp3 do wysłania).

Właściwie to zamierzam zacząć od czegoś trochę innego. Niemniej cena telefonu nie może przekroczyć siedmiu stów, więc nie wiem, czy sprzęt za taką cenę będzie wystarczająco dobry do stworzenia tego mojego pomysłu, stąd też braki sprzętowe w razie czego "obszedł bym" właśnie przy pomocy komunikacji GPRS z serwerem.

Zaś ten trochę inny pomysł jest taki, że to komórka rozpoznaje mowę i odpowiada przy pomocy tych paru mp3 (lub ew. tekstowo na wyświetlaczu) użytkownikowi. Wtedy, wydaje mi się, że telefon musiał by mieć system operacyjny Symbian (na którym MIDlety też można odpalać). No a do rozpoznawania mowy bezpośrednio na komórce zastosował bym mający mniejsze wymagania sprzętowe (-> http://cmusphinx.sourceforge.net/sph...-faq.html#j2me) PocketSphinx (napisany w C++) zamiast Sphinx4 (napisany w Javie).

Na dzień dzisiejszy zrobiłem coś jeszcze prostszego :-D:
1. Użytkownik uruchamia MIDlet na komórce bez Symbiana.
2. Wpisuje odpowiednie dane, korzystając z klawiszy na telefonie. Zaimplementowany algorytm komunikuje się tekstowo z użytkownikiem.
3. Na podstawie danych stworzony jest plik tekstowy.
4. Plik ten zostaje wysłany jako zmienna string przy pomocy httpconnection metody POST. (Wcześniej próbowałem Wireless Messaging API do wysłania danych jako SMS, ale coś przykładowa aplikacja nie działała, więc dałem sobie spokój).
5. Dane zostają odebrane przez Servlet na serwerze z TomCat.

Pozdrawiam :-)!

[Szczota]

Generalnie Twoj pomysl ma jedna ogromna wade... przesyl danych o GPRS - tutaj zapomnij bo nie da sie tego zrealizowac. Jest to technicznie wrecz niemozliwe. EDGE, dalej za wolne ale do 2min powinno wszystko sie przetransferowac w dwie strony. Jedyna realna transmisja to UMTS/HSPA.

Kolejna sprawa to koszty wykorzystywania danych... bez pakietu na internet moze byc kiepsko.

Jesli nie masz zasiegu conajmniej EDGE to nawet nie mysl o tym.

[Wawelski]

Dalej nie rozumiem.
Po co MIDlet - co on ma robić, skoro chodzi o nagranie, jak na zwykłej automatycznej sekretarce?

[johnyjj2]

Dzięki za odpowiedzi :-)

Jeśli chodzi o przesył to oczywiście nie muszę wykorzystać tylko GSM/GPRS/EDGE/UMTS/HSDPA (czy, jak się okazuje, tylko tych dwóch ostatnich). Zastanawiałem się nad innymi rozwiążaniami przesyłu danych, tj. antena kierunkowa typu Yagi + lokalna sieć WiFi (odległość to max kilka kilometrów, bardzo możliwe, że mniej). Niemniej w wypadku WiFi boję się, że koszty wdrożenia byłyby zbyt duże (nawet jeśli koszty eksploatacji mniejsze) + przede wszystkim zbyt duże zakłócenia.

Co do zasięgu co najmniej EDGE - jak to sprawdzić, czy mam?

No a MIDlet to po prostu aplikacja w Javie na komórkę. No i nie do końca to jest zwykłe nagranie (nagranie, czyli coś jednostronnego, ja mówię, serwer słucha), ale raczej rozmowa (ja mówię i serwer odpowiada, czyli komunikacja dwustronna).
Do tego jeszcze wchodzi w grę przeczytanie pliku konfiguracyjnego zapisanego na komórce, co wpływało by na pewne zmiany w algorytmie, wedle którego serwer rozmawia z użytkownikiem.
Jak byś to inaczej sugerował rozwiązać, jak nie przy pomocy MIDletu (czyli po prostu aplikacja na komórkę)? Niby może być taka opcja, że po prostu użytkownik dzwoniłby na specjalny numer, który byłby powiązany z serwerem, ale nie bardzo wiem, jak coś takiego zaimplementować.

Pozdrawiam :-)!

[Wawelski]

Napisany przez johnyjj2

No a MIDlet to po prostu aplikacja w Javie na komórkę. No i nie do końca to jest zwykłe nagranie (nagranie, czyli coś jednostronnego, ja mówię, serwer słucha), ale raczej rozmowa (ja mówię i serwer odpowiada, czyli komunikacja dwustronna).

Czyli dokładnie to, co ma Orange na poczcie głosowej? Identyfikacja po numerze telefonu, a potem:
- aby skasować, powiedz kasuj
- kasuj
- czy potwierdzasz skasowanie? Powiedz tak
- tak

Czyli zwykłe połączenie głosowe i wszystko po stronie serwera IMO byłoby najłatwiejszym i tanim rozwiązaniem. Nie ma problemu z aplikacjami (wiele nawet drogich komórek nie ma javy, dla przykładu żaden Windows Mobile nie ma w standardzie, a znam sporo osób co z emulatorem sobie słabo radzą).

[johnyjj2]

Dzięki wielkie za odpowiedź :-)!

Wynikałoby, że znów, po długim czasie poszukwiań, powinienem całkowicie zmienić podejście i stworzyć ten projekt w sposób inny :-).

Dokładnie, to co Orange ma na poczcie głosowej, co mają banki na infoliniach nie wymagających człowieka po stronie banku itd. Niemniej, czy mógłbyś mi, proszę, podać link do jakiegoś tutoriala jak coś takiego stworzyć :-)? No i tu jest trochę więcej rozpoznawania, bo chciałbym, żeby rozpoznawać cyfry, zamiast kazać użytkownikowi je wcisnąć na komórce.

Co do Windows Mobile to nie bardzo się orientuję w Microsoftowych technolgiach, bo z zasady (może niesłusznej) staram się omijać wszystko, co sygnuje sobą Microsoft. Co do tego, że wiele drogich komórek nie ma Javy to mnie zdziwiłeś. To czego w takim razie takie używają takie komórki zamiast Javy? Co do zaś obsługi emulatorów to niestety jestem taką osobą, która słabo sobie z tym radzi. Możesz podać linki do tutoriali :-)? Jedyne, czego używałem to emulator w Wireless Toolkit 2.5.2.

Miałem też wcześniej dziwny problem z odpaleniem Wireless Messaging API na komórce. Był przykład takiego MIDletu wykorzystującego WMA. Zapisałem go (albo był już nawet domyślnym przykładem, instalowanym razem z WT252) przy pomocy Wireless Toolkit, a potem nagrałem na prawdziwy telefon. W kodzie, przed kompilacją do .jar (wraz z .jad) zmian chyba żadnych nie wprowadzałem. Uruchamiałem program, podawałem numer (była nawet możliwość wyboru ze swojej listy z numerami telefonów, więc komunikacja z softem komórki była zaimplementowana ). Dawałem dalej, pisałem treść wiadomości, następnie "wyślij" i lipa. Włączały się wibracje na komórce, chyba też jakiś dźwięk, pisał, że wysyła i lipa... niczego nie wysłał na drugą komórkę. Zresztą, później stwierdziłem, że jednak lepiej to wysłać jako POST przez httpconnection w MIDlecie, a nie przez SMS-a. Niemniej jednak jestem ciekaw, dlaczego ten domyślny przykład Wireless Messaging API nie zadziałał mi :-).

Pozdrawiam i dzięki :-)!