Object Exchange Protocol (OBEX), așa cum se aplică la telefoanele celulare

Vă mulțumim pentru sprijinul acordat!

Protocolul folosește doar câțiva operatori. Mai jos este descrierea lor:

specificația IRMC definește mai multe niveluri de schimb de informații:

Nivelul 1: Clientul trimite la serverul de un singur obiect, care este salvat cu numele original. Nici automatizare nu este implicată.
Nivelul 2: Clientul poate primi și trimite la server un set de obiect (director).
Nivelul 4: Clientul poate înregistra, șterge și modifica obiecte de pe server. Pentru obiectele furnizate indexurile statice.
Nivelul 8: Clientul poate obține o listă de obiecte modificate de la ultima sincronizare de timp și de a lucra numai cu aceste înregistrări, în scopul de a reduce timpul de sincronizare. Introduceți un indecși unic - Non-facilități.
Nivelul 16: La fel ca și nivelul de 8, dar cu suport pentru indexurile statice.

De fapt, aceste niveluri corespund gradului de automatizare pe server pe baza modificărilor de conținut.

dispozitive mobile caietul de sarcini definește directorul de stocare a datelor în mod implicit - Telecom. T. e. Toate obiectele fișierele sunt stocate în acest director. În acest caz, directorul nu este curent de telecomunicații pe umlochaniyu și este necesar să se treacă de 85h de comandă sau de acces la obiecte cu calea înaintea lor.

Numărul de serie, versiunea software, codificări sprijinite sprijinite de nivelul de schimb de informații, operațiunile sprijinite

Tekuschaee ora și data.

Accesul printr-un nivel de indice de schimb de 4 date unice

Acum, despre formatele acceptate de înregistrare.

«BEGIN: VCARD
«N;»";"' "
«FN;«";"' "
«TEL»
«X-IRMC-LUID:»
«END: VCARD»

«BEGIN: VEVENT»
«DTSTART:»
«DTEND:»
«AALARM:»
«CATEGORII:»
«REZUMAT;»";"' "

«LOCAȚIE;»";"' "
«X-IRMC-LUID:»
«END: VEVENT»

«BEGIN: VCALENDAR»
«VERSIUNEA:»
«PRODID:»
«BEGIN: VEVENT»
«END: VEVENT»
«BEGIN: VEVENT»
«END: VEVENT»
.
«END: VCALENDAR»

Cu toate acestea, atunci când încercați să le scrie în jos în corpul descompune câmpul nume. Prin urmare, pentru a introduce astfel de nume recomanda utilizarea unui Hayes-comandă AT + CPBW, care a fost înregistrat cu succes astfel de simboluri, spre deosebire de OBEX-înregistrare, în cazul în care este distorsionată litera de cod.

UTF-8 este recoded după cum urmează: în cazul în care caracterul din prima jumătate a tabelului de cod (caractere în engleză), codul său nu este schimbat, în cazul în care codul conține litere românești, pentru manipularea sa de codare Windows 1251, puteți face o conversie simplă.

Pentru caractere C0h-EFH - scrisoarea va fi codificată în UTF8, astfel: a D0h de mare octet, octet scăzut <значение в коде W1251>-30h. Pentru caractere F0h-EFH - scrisoarea va fi codificate în UTF8, astfel: a D1HSetările de mare octet, octet scăzut <значение в коде W1251>-70h. Encoding litera E este unic: pentru E-UTF8 cod - D081h, pentru e-UTF8 cod - D191h.

= D0 = A1 = D1 = 82 = D0 = B0 = D1 = 82 = D1 = 8C = D1 = 8F = D0 = BF = D1 = 80 = D0 = BE OBEX

Luați în considerare exemplele de o carte de vizită și o intrare de calendar (VEVENT).

BEGIN: VCARD
VERSIUNEA: 2.1
N; quoted-NEIMPRIMABILĂ; CHARSET = UTF-8: = D0 = AF = D0 = BC = D1 = 89 = D0 = B8 = D0 = BA = D0 = BE = D0 = B2
FN; text tipăribil; CHARSET = UTF-8: = D0 = AF = D0 = BC = D1 = 89 = D0 = B8 = D0 = BA = D0 = BE = D0 = B2
TEL: 3332233322
X-IRMC-LUID: 000000000000
END: VCARD

Zvonok v po povodu stipendi Institut: 3627795

Cerere pentru a deschide o sesiune

80 00 13 10 00 40 00 46 00 49 52 43 0C 2D 4D 53 59 4E 43

Indică versiunea protocolului OBEX 1.0 (10 00h), lungimea maximă a pachetului de 16.384 octeți (40 00h) și numele serviciul «IRMC-SYNC». În mod firesc, după o valoare de doi octeți de comandă 80h - lungime de interogare. Nedocumentat: nu se poate specifica nici un parametru, și pur și simplu trimite un singur octet 80h pentru a începe OBEX-sesiune.

Răspunsul la deschiderea sesiunii

A0 07 10 00 00 00 FF

Un răspuns de funcționare cu succes a 7 octeți. Versiunea OBEX - 1.0, iar lungimea maximă a pachetelor de server - 255 de octeți.

83 00 2E 01 00 2B 74 00 65 00 00 65 00 6C 00 63 00 6E 6D 00 00 2F 64 00 65 00 00 76 00 69 00 00 66 00 6E 6F 2E 00 74 00 00 78 00 74 00 00

După 83h doi octeți - lungimea pachetului. 01h - parametru numele. După el - numele de lungime în octeți. Apoi, - într-un format de nume de fișier UNICODE Telecom / devinfo.txt. se termină cu un octet nul. Pentru fiecare caracter din numele dat doi octeți, dintre care prima este zero, taxe, conform regulii de codificare a caracterelor engleză. În schimb devinfo.txt poate specifica orice alt fișier. Format de comandă nu este schimbat.

Primul răspuns la această solicitare,

CE 90 00 48 00 CB

Simptom operațiune de succes (în așteptare pachete informații suplimentare) și două octet de lungime a întregului răspuns. După acest parametru de pornire a solicitat corpul obiect care indică lungimea obiectului.

De fapt, obiect soberzhimoe. Modificări 90h la A0h, atunci când este vorba de ultimul pachet cu conținutul cererii.

02 00 3D 01 00 2D 00 74 00 65 00 6C 00 65 00 63 00 6F 00 6D 00 2F 00 70 00 62 00 2F 00 6C 00 75 00 69 00 64 00 2F 00 2E 00 76 00 63 00 66 00 00 C3 00 7C 4C 00 00 00 08 11 03 31 31 31

Răspunsul la această solicitare,

Simptom operațiune de succes (în așteptare pachete informații suplimentare) și două octet de lungime a întregului răspuns.

Următorul pachet la scrierea fișierului

Răspunsul la această solicitare,

Simptom operațiune de succes (în așteptare pachete informații suplimentare) și două octet de lungime a întregului răspuns.

Ultimul pachet atunci când scrieți fișierul

82 00 06 49 00 03

Echipa 82H pentru ultimul pachet de înregistrare fișier care indică lungimea pachetului. Mai mult, parametrul 49h - la sfârșitul indicatorul al corpului de fișiere.

Răspunsul la cel mai recent pachet service pack

A0 00 19 00 4C 16 ianuarie 0 ° C 30 30 30 30 30 30 30 30 30 30 30 36 02 03 31 31 31

Un semn de succes a operațiunii (ultimul pachet) și doi octeți din lungimea întregului răspuns. Setările aplicației După aceea vozvarschayutsya suplimentare (semna 4Ch). parametru 01h cu o lungime 0Ch (12 bytes), returnează un număr unic atribuit cardului. parametru 02h cu o lungime de 3 octeți: se pare că valoarea curentă a cc.log. Această valoare trebuie să fie înlocuit în parametrul de înregistrare corespunzător la 11h (vezi mai sus). Acest lucru se face în XNTD Connect PC.

Cerere de închidere a sesiunii

Închide sesiune de comandă 81h și lungimea pachetului. Nedocumentat: nu se poate specifica nici un parametru, și pur și simplu trimite un singur octet 81h pentru a începe OBEX-sesiune.

Răspunsul la cererea

A0 00 03 0D 0A 4F 4B 0D 0A

răspuns de succes A0 (ultimul pachet de răspuns) care indică lungimea pachetului. Iar în modem Hayes-mode de caractere newline, «OK» din nou și newline de caractere.

> Deschiderea COM-portului
> AT + CGM
> AT + CGMI
> AT * EOBEX
> 80. (OBEX-Deschiderea sesiunii)
> Telecom / devinfo.txt lectură fișier
> Citește fișier Telecom / Pb / info.log
> Citește fișier Telecom / devinfo.txt (a doua oară)
> Read / fișierul devinfo.txt Telecom (a treia oară)
> Citire Telecom / Pb / fișier info.log (a doua oară)
> Citește fișier Telecom / Pb / luid / cc.log
> Telecom / pb.vcf lectură fișier
> Citește Telecom / Pb / fișier info.log (a treia oară)
> AT + CGMI (acest lucru nu se termină OBEX-a sesiune! Sesiunea de ce se rupe, având în vedere răspunsul corect)
> AT + CGSN
> AT * EOBEX (după această sesiune au uitat să deschidă!)
> Scriere încercare de telecomunicații / Pb / luid / 000000000001.vcf fișier obiect fără parametru lungime (desigur, cererea nu este recunoscută)
> 81. Închiderea sesiunii (desigur, cererea nu este recunoscut, pentru că sesiunea nu este deschis)
> Închiderea COM-portului
> Deschiderea COM-portului
> AT + CGM
> AT + CGMI
> AT * EOBEX
> 80. (OBEX-Deschiderea sesiunii)
> 02. (Fișier de înregistrare normală)
>.
> 81. (Închidere OBEX-sesiune)
> Închiderea COM-portului

Și încă o lipsă de programe: în timp ce eu nu știu comanda de intrare în conexiunea în infraroșu OBEX-mode. Conexiunea în sine este identificat de comandă ATI ca răspuns la care R320, în funcție de modul în care acesta este conectat la PC, produce sau «modem R320 IR» sau «R320 modem de cablu». Nu contează la ce port COM este conectat modulul IR (testat cu ASUS-GIR modulul 100 și un dispozitiv TekRam Mate IR 210B extern), XTND Connect funcționează într-un fel în jurul portului de ascultare a funcției care utilizează PortMon98. De asemenea, nu a fost posibil să se verifice munca R320 cu BlueTooth-modem (există așa natură, probabil, a fost cel care vine cu Handsfree Bluetooth Ericsson HPB-15), din moment ce nici unul dintre modem sau card, în cazul în care acesta poate fi conectat la un desktop PC-ul, eu nu fac.

Și, în sfârșit, să raporteze că accesul la OBEX și Hayes-mode pentru elementele de meniu rapid și numele de profile din Ericsson R320 în limba rusă nu este posibilă. Prin urmare, pentru a organiza ecranul în sincronizare unele inscripție chirilică în locul numelui profilului nu poate - caractere să fie obținute. Cu toate acestea, cu ajutorul AT * -command la Ericsson poate seta tonul pentru a informa utilizatorul cu privire la începutul și sfârșitul de sincronizare. De asemenea, nu poate fi considerat un standard înseamnă Ericsson R320 listă de e-mail-uri și înregistrări vocale, cu toate protocoalele descrise în acest material sunt folosite pentru transmiterea de fișiere audio între terminalul mobil.

Acum câteva cuvinte despre responsabilitate eschiveze