Vissza a 90-es, vagy küldjön egy üzenetet, hogy a pager keresztül java
Annak ellenére, hogy a látszólagos döntések átláthatósága és másodlagos én tapasztalatom szerint, úgy döntött, hogy részletesen írja le tetteikért, mert az információ az interneten a témában bemutatott nem annyira: a fórumokon, hogy válaszoljon a kérdésekre, és ritkán nemetko. Bizonyos, ez a szöveg nagyban időt takaríthat meg.
1. lépés - INVITE
Az első szakasz - tárcsázza a lapozás állomás - valósult keresztül SIP protokollt és a megfelelő jain szívható Java-könyvtár. A legjobb leírása a protokoll elvek találtam ügyéről kiadványaiban „Interaction SIP kliensek. 1. rész „és” Interaction SIP kliensek. 2. rész " és a leginkább emészthető bemutató Jane - itt (de csak egy gyűjtemény a példák itt adta jobb).
Ahogy predpogotovki Csináltam egy osztály:
c a szükséges mezőket, amelyek először is meg kell inicializálni leírtak a bemutató:
A második esetben, meg kell adnia a fogadó ahonnan küldi az üzenetet, hogy kezdeményezi:
Egy másik érdekes elem, sőt, a test SDP-üzenetek, amelyeket a leírás, hogy mi szükséges a sikeres kommunikáció. A mi esetünkben ez így néz ki:
2. lépés - Hitelesítés
Ha tudtuk, hogy küldjön ki a megfelelő meghívjuk, a legjobb, a cél szerver küld nekünk az OK áhított állapot üzenet 200, és a legrosszabb esetben - meg fogja oldani egy kis gyötrelem azonosítása. A második esetben a válasz állapota 401 vagy 407. Itt a kód, amellyel a választ nem küldenek. Támogatására szükség lesz egy újabb verziója jain szívható (pl 1.2.228). Meg kell helyezni processResponse () metódus érvként ResponseEvent responseEvt.
Megjegyzés: a négy érv handleChallenge (), anélkül, hogy az üzenet formátumát változások nem lesz megfelelő, és a hitelesítés sikertelen.
Osztályok AccountManagerImpl és neohodimo UserCredentialsImpl kell csatolni az Ön által írtam őket a modell azon, hogy az itt bemutatott.
Miután elküldte a regisztrációs adatokat, nyugodtan számíthat a szükséges 200 OK, amelyet nem szabad elfelejteni, hogy küldjön egy ACK. Ez a fajta üzenet nagyon egyszerűen:
3. lépés - SIP INFO
Ezután jön az izgalmas rész - DTMF-jelek (e megnyomásával nyomógombos üzemmód). Globálisan meg lehet csinálni két különböző protokollok: a SIP és RTP. Persze, először úgy döntöttek, hogy a legkisebb ellenállás útját. Minden karakter volt, itt alakult ki egy ilyen kérés, amely aztán el kellett küldeni a szerverre:
Az eljárás maga küld egy kicsit furcsán néz (azt hiszem, épül a modell a „révén Zhmerinka in Paris”), de egyébként semmi működött. Általában könyvtár tűnt nekem egy kicsit bugos: nagyon gyakran különféle oldatok úgy nézett ki, nagyrészt azonos, nem működött.
Mit is mondhatnék? Végrehajtása után ezt a lépést, kiderült, hogy nem minden a VoIP-szerver egyaránt barátságos: bizonyos volt elég a továbbított jeleket a SIP, ahogy valaki azok nem elég, mert nem ad ki hangot, és ezért nem veszik észre. Természetesen a törvény szerint az aljasság volt a célom, a második típusú szerver. Ezért ...
4. lépés: A formáció a RTP-csomag
Általában, amikor rájöttem, hogy a problémát nem lehet megoldani egy SIP-edik, reméltem, hogy legalább tudom használni egy másik könyvtárat is nenapryazhno DTMF-jeleket. De ott volt. Általában, ha azt mondjuk, «RTP keresztül Dzhavu”, azt jelenti, JMF. De először is, ez már egy régi, és nem igazán támogatja. Másodszor, ez több alkalmas az átviteli bonyolultabb média. Harmadszor, az útmutatók, hogy én találtam nem voltak nagyon értelmes. Íme egy példa a dokumentációban, a melynek közepén emelkedik egy bizonyos rtpSession nyomait, amely az első bizonyos számú percig keres találom minden sikerült.
Egy másik lehetőség az volt libjitsi könyvtárban. ami egész készüléket. Tőle személyes kölcsön is sikerült, bár van egy szép módszer sendDTMF, vagy valami ilyesmi. kód struktúrája olyan, hogy nem születik vagy egészben, vagy bármilyen módon. Ezt végül úgy döntött, a normális emberi egy csomagot, és küldje át az UDP-sokket.
Tehát itt van egy jelentős fragment RtpPacket osztály: a főbb területeket és a kivitelező a megfelelő értékeket a DTMF átvitel. Mit jelentenek ezek a dolgok vannak írva sok helyen, így nem fogom megismételni. Megjegyzem, hogy az csak a paraméter értéke SSRC elvileg nem fontos, de mindannyian küldött egy csomagot ülésén meg kell egyeznie. hasznosadatformátum számot a DTMF-csomag (payload típus) - 101 (már regisztrált, amikor a SIP által kezdeményezett kommunikáció).
A legfontosabb lépés létre egy csomagot -, hogy kitöltse a byte tömb adatok. Abban DTMF természetesen a méret: az első byte - ez valójában átvitt jel értéke (0-16), az első felében a második byte - különböző áruházak (jellemzően 0), a második felében a második bayta- mennyiség (normál érték - 10), a másik két - ez az időtartam (alapértelmezett - 160).
Minden egyes létrehozott jelet körülbelül 10 csomagok (a szám változhat):
- egy első, kezdeti, van marker = 1, a maradék - 0;
- az utolsó három - trailing, marker = 0, de az első bit a második bájt adatblokk = 1 a nem végleges adatblokk csomagot egy jel adására 1 lenne:
És a végén, mint ez:
Időpecsét összes DTMF-tartozó csomagok ugyanazt a jelet maradhat ugyanaz (mondjuk, T). De a következő csomagot kell:
5. lépéssel RTP-csatornás
Aztán, ahogy én naivan azt hittem csak én ponadelat bájt DatagramPacket'ov, lök őket a foglalatba, és arról, hogy eltűnik a szerverre. De ott volt. Válaszul a szerver továbbra is letörnek kommunikáció a mondat közepén, mintha soha nem kapott. A Wireshark elvileg nem fogadja el üzeneteket RTP, megjelenítésére egyaránt egyszerű UDP.
6. lépés RTP kommunikáció
Tény, hogy megértsük, milyen irányba megy, sokáig tartott. Tettem egy csomó erőfeszítést, hogy olvassa újra az összes rendelkezésre álló műszaki és százszor, hogy ellenőrizze a zsákokat helyesen. A hetedik napon, éles szem az arcomon észrevette, hogy a szabványos RTP kommunikáció nem indul meg azonnal a DTMF-adatokat, és hogy megelőzi egy rövid adatcsomagok a szerver, ami kissé eltérhet.
Hasznosadatformátumot, kijelentette, a fejléc 0, nincs adat, de valójában nagyon hasznos teher (payload), amely úgy 160 bájt. Ez a készlet bájtok különbözik az összes bejövő és kimenő üzenetek tagjai és úgy néz ki, egészen véletlenül. Különben is, én nem találtam információt arról, hogyan kell beállítani, hogy minden egyes alkalommal szerezte véletlenszerűséget.
Egyszer elkezdtem küldeni ezeket támogató csomagot, mielőtt minden a DTMF-jel, Wireshark végül elismerte a RTP-formátumban. Úgy nézett ki jobban, de a kommunikáció is megszakad, de a szerver most örömmel is kezdett dobja rám „peylodnymi” csomagokat.
Azt sem tudtam, mi mást tehetne, de aztán eszembe jutott, hogy az RTP van egy testvére, törpepapagáj - RTCP. A probléma, úgy tűnik, tényleg benne: a szerver megpróbált nekem valamit küldeni, de rájöttem folyamatosan beszámol arról, hogy a megfelelő port zárva van. Mivel nem akartam zavarni küld több és RTCP-csomagot, kezdtem a nyitó egy port a csakrák:
Ez volt a döntő hatást: az előfizető megkapta az üzenetet „305 * 1 * 66” pager!
következtetés
Az utolsó sor az én szekerek szeretném hangsúlyozni, hogy ez az első post Habré, úgyhogy ne ítélj keményen. Nem tartom magam egy guru telematikai, vagy bármi más. Csak írásakor a forráskód sok időt töltött keres információt. Valami találtam a leírások, amelyek az elejétől a végéig egy ülő elég nehéz volt a mester, valami leírt normál nyelv, de valahogy homályosan apró betűs területeken, amit én tettem véletlenszerűen. Tehát egy bizonyos ponton, csak én úgy döntött, hogy ha én sikeres lesz, fogom leírni minden műveletet egy helyen, és hagyja, hogy indexelt valahol az interneten.