Megválaszolatlan hozzászólások | Aktív témák Pontos idő: csüt. márc. 28, 2024 22:41



Hozzászólás a témához  [ 48 hozzászólás ] 
SMS - PDU kódolások 
Szerző Üzenet
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás Re: SMS - PDU kódolások
Ritkán járok már erre, de akkor egy kis kiegészítés:

Idézet:
ugye 176 bájt egy SMS.


Egész pontosan ebből az első bájt az sms státuszát jelzi, hogy éppen a sim kártya vagy a telefon vagy a modem bejövő olvasatlanként, bejövő olvasottként, küldendőként vagy küldöttként kezelje vagy töröltként (lásd 00).

A többi 35 bájt a header rész, amibe nem tartozik bele magának az smsnek a tartalma. És a maradék 140 bájt az sms érdemi része.


hétf. jún. 15, 2015 13:31
Profil Privát üzenet küldése
vas-tag

Csatlakozott: kedd jún. 10, 2014 14:03
Hozzászólások: 5
Hozzászólás Re: SMS - PDU kódolások
Gyakorlatilag minden leírásban 3 összefűzés szerepel, lehet ebből gondoltam a hármat, és soha nem is próbáltam többet, bár ugyan úgy láttam, hogy 1 bájtos jelző miatt 255 küldhető ki. kipróbáltam, tényleg megy. valamelyik nap, kipróbálom a 255-öt is, mit szól hozzá maga a készülék is. Most 12 darab lett összefűzve, és volt még egy fura jelenség, egy androidos telefon, megjelenítette már az utolsó megérkezése előtt is az üzenetet. ezt is ki fogom próbálni, egy pár készülékre, hogy egy óra múlva küldöm rá az utolsót.
"Na most vodafonék és a többi két szolgáltató azért is mocskok, mert ők tökéletesen tisztában vannak vele....."
na igen lehet erről beszélni, mint sok hasonló multi cégről, de jelen esetben például ki is ehet számolni mekkora egy 'átverés' az SMS csak magához a beszélgetéshez viszonyítva.
ugye 176 bájt egy SMS. hány másodperc beszélgetés fér bele 176 bájtba?
igazából nem tudom a mobil szabvány hány Khz-en közvetíti a beszélgetéseket, de gondolom több mink 3 Khz, mert jobb a minőség, mint a régi 3Khz analóg telefonoknál. az adatok tudatában ki lehetne számolni, hány másodperc beszélgetésnek felel meg pontosan. De persze kell idő a kapcsolat felvételhez is. Nem beszélve az internetes kapcsolati árakról, hogy ott vissza osztva mennyibe is kerül ez a 176 bájt, mondjuk ha kér egy szolgáltató 1GB-os net használatért 3 ezer forintot, akkor 3000/1073741824 * 176 = 0,0005 forint, felkerekítve. tehát a nethez mérten, az 1 forint/sms is irracionálisan sok lenne.... nem hogy a néha 20-30 forint.


hétf. jún. 30, 2014 4:58
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás Re: SMS - PDU kódolások
Akárhányat össze lehet fűzni (de legalábbis több mint valószínű, hogy max. 255 smst), mert a concatenation részben megadható az aktuális üzenet sorszáma és hogy hány db smsből áll a teljes összefűzött üzenet.

Na most vodafonék és a többi két szolgáltató azért is mocskok, mert ők tökéletesen tisztában vannak vele, hogy mely karaktereket nem célszerű használni, mikor gsm abc szerinti 7 bites üzeneteket küldenek a kedves ügyfeleknek. Nehogymá itt tripla annyiba kerüljön nekik pl. az unicode karakterek miatt az üzenetküldés, szívjon csak ezzel az ügyfél.


pén. jún. 27, 2014 19:41
Profil Privát üzenet küldése
vas-tag

Csatlakozott: kedd jún. 10, 2014 14:03
Hozzászólások: 5
Hozzászólás Re: SMS - PDU kódolások
Próbálkozom, de valahogy a 8 bites kódolás, csak és kizárólag androidokon nem jól jelenik meg. Viszont igen érdekes számomra, a vodafontól kapott üzenet. majd megnézem pdu-ban is, ha hozzáférek, de addig is ez az üzenet:
"Kedves Ügyfelünk! A roaming dìjak csökkenek az EU-ban! 2014.07.01-töl a Lakossàgi ÅSZF Dìjszabàs Melléklet A/3.13.2; 5.1.1; 5.4.1; 5.7; 5.10.5.1; B/7.1.1; 7.5. és 7.8.1. pontjai mòdosulnak. ùj szolgàltatàsként kerül bevezetésre az ÅSZF 3.1.2.37. pontjàba az alternatìv roaming szolgàltatò vàlasztàsànak lehetösége. Jelen egyoldalù dìjcsökkentö mòdosìtàsok, ill. a kiegészülés felmondàsi jogot nem keletkeztetnek. Bövebb tàjékoztatàs: www.vodafone.hu/aszf oldalon. Vodafone"
ez 472 karakter....
tudtommal csak 3-at lehet összefűzni, de soha nem próbáltam 4-et vagy többet! majd ezt is holnap tudom kipróbálni.


pén. jún. 27, 2014 12:40
Profil Privát üzenet küldése
vas-tag

Csatlakozott: kedd jún. 10, 2014 14:03
Hozzászólások: 5
Hozzászólás Re: SMS - PDU kódolások
kezdem látni, hogy mindegy mit csinálok, androidos telefonokra ez nem akar rendesen megjelenni. lehetséges ilyen?


szer. jún. 11, 2014 8:26
Profil Privát üzenet küldése
vas-tag

Csatlakozott: kedd jún. 10, 2014 14:03
Hozzászólások: 5
Hozzászólás Re: SMS - PDU kódolások
cocka írta:
Ez nekem ezt adja vissza pduspyjal:

éáqúQóüö ÉÁpÚPÓÜÖ

Egyébként miért kell 8 bites kódolást használni? Szöveghez nem jó a 7 bites?

Úgy próbáltad már hogy a data coding scheme-nél beállítod a message classt 1-re, 2-re vagy 3-ra?


Mint írtam, némely esetben, pl a pannonnál egy régi sony eicsonon jól jelenik meg.
de ez nálad swm jó, mer a problémás karakterek (őűŐŰ) nem jelenik meg.
ha beállítom a message classt, akkor küldésnél hibát jelec 38-as kóddal.
igazából ezt a rész még nincs benne a kódban, mert először csak próbálom az online encoderekkel, hogy melyik a jó, mert akkor az alapján meg tudom íri a kódot. összetett, mert ez egy mikrokontrolleres saját készülék (a küldő) TELIT GL865 QUAD chippel.
azért kellene nyolc bites mertékezeteket szeretnék, és azt veséztem ki, hogy 8 biten mennie kellene az ominózus négy karakter kicsit más kinézetével, tehát hogy a őű egy felülvonással jelenik meg, és ebben az esetben egy sms 140 karakter lehetne, nem 70, mint a 16-bitesnél.


szer. jún. 11, 2014 7:28
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás Re: SMS - PDU kódolások
Ez nekem ezt adja vissza pduspyjal:

éáqúQóüö ÉÁpÚPÓÜÖ

Egyébként miért kell 8 bites kódolást használni? Szöveghez nem jó a 7 bites?

Úgy próbáltad már hogy a data coding scheme-nél beállítod a message classt 1-re, 2-re vagy 3-ra?


kedd jún. 10, 2014 17:55
Profil Privát üzenet küldése
vas-tag

Csatlakozott: kedd jún. 10, 2014 14:03
Hozzászólások: 5
Hozzászólás Re: SMS - PDU kódolások
Bár nagyon nagy itt a csend, de hátha azóta több az infó is, nagyon elakadtam.

sok minden megy már, de teljesen kiakaszt a 8 bites sms küldés, ugyan is az a helyzet, hogy egyik helyen jól jelenik meg, a másikon nem. a küldő szám vodafonos, amin jól jelenik meg, az egy pannonos szám, egy régi telefonnal, amiken rosszul azok vodafonosak, új androidos telefonok.
a teszt szöveg:éáűúőóüö ÉÁŰÚŐÓÜÖ
ebből az ASCII-ben ugye nincs őŐűŰ, de helyette vannak a felül vonásos megfelelői. ez í helyes megjelenítésben meg is jelenik, viszont a vodafonosoknál nem. pedig már próbáltam több netes online encoderrel, pl: http://smstools3.kekekasvi.com/topic.php?id=288
de ezáltal generált eredmény is ugyan az.
Tehát akkor a kérdésem hogy valami mást is kell állítani? osztályt?
a generált pdu
07 916307996905F0 11 00 0B 91 xxxxxxxxxxFx 00 04 AD 11 E9E171FA51F3FCF620C9C170DA50D3DCD6

ránézésre teljesen jó, meg el is megy, csak ahol nem jól jelenik meg, ott minden karakter helyén a fekete hátteres kérdőjel jelenik meg.
Mit rontok el?


kedd jún. 10, 2014 14:20
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Jól értettem, hogy a mikrokontroller az üzenetek automatikus küldéséhez kell? Mert a manuális egyszeri dolog kontroller nélkül is megy.

Mondjuk ebben nem vagyok otthon sajnos.


csüt. aug. 13, 2009 19:56
Profil Privát üzenet küldése
Moderátor
Avatar

Csatlakozott: szer. márc. 24, 2004 20:30
Hozzászólások: 14954
Tartózkodási hely: Itt ülök, Veled szemben.
Hozzászólás 
srami írta:
Én kb. két éve csináltam egy GPS-póráz szerű dolgot.
Egy M35 telefon egy GPS vevő és egy Atmel mc voltak összekötve.
Az Atmel időnként kiolvasta a tel-ból az SMS memória 1. helyén lévő üzenetet. Ha ez a "megfelelő" tartalmú volt, akkor az üzenetből kivette a küldő számát majd átkapcsolt a GPS vevőre és kiolvasta a kordinátákat és összeállította a küldendő üzenetet aminek tartalma a két kordináta volt viszonylag formázott kivitelbe . Majd átkapcsolt a tel-ra, elküldte az SMS-t oszt törölte az SMS memóriát és tovább figyelt.
A tel. 19200, a GPS vevő 4800 bauddal kommunikál a soros porton.
Nagyon jó ötlet!!!!


szomb. jún. 06, 2009 22:06
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: csüt. nov. 10, 2005 17:01
Hozzászólások: 21
Tartózkodási hely: Győr
Hozzászólás 
Én kb. két éve csináltam egy GPS-póráz szerű dolgot.
Egy M35 telefon egy GPS vevő és egy Atmel mc voltak összekötve.
Az Atmel időnként kiolvasta a tel-ból az SMS memória 1. helyén lévő üzenetet. Ha ez a "megfelelő" tartalmú volt, akkor az üzenetből kivette a küldő számát majd átkapcsolt a GPS vevőre és kiolvasta a kordinátákat és összeállította a küldendő üzenetet aminek tartalma a két kordináta volt viszonylag formázott kivitelbe . Majd átkapcsolt a tel-ra, elküldte az SMS-t oszt törölte az SMS memóriát és tovább figyelt.
A tel. 19200, a GPS vevő 4800 bauddal kommunikál a soros porton.


szomb. jún. 06, 2009 22:01
Profil Privát üzenet küldése
vas-tag

Csatlakozott: hétf. máj. 04, 2009 20:09
Hozzászólások: 2
Hozzászólás 
Köszönöm a gyors válaszokat! F-Bus-ról tudtok valamit mondani? NOKIA telefonokon láttam, a soros vonal helyett/mellet. Gondolom valami saját szabvány lehet.


szer. máj. 06, 2009 21:01
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
én /// t65-öt és t68-at használok, igaz PC-rõl. Átvitel a szokásos 9600/8/N/1. Az RTS-t "1"-be kell állítani, különben rövid idõn belül megszakad a kommunikáció.

uC: pic16f688-at használtam, persze a 16f690 és tsai is ugyanazt tudják ebbõl a szempontból. PIC kész szívás a maga programmemória lapozgatásával, az EGY karakteres kimeneti és KÉT karakteres bemeneti pufferével. Mert - ugye - kiírsz, egy at parancsot, pl. "at+cmgdl...", de minden egyes byte kiküldése után ellenõrizgetheted, hogy jött-e válasz, nehogy beteljen a bemeneti puffer. Vagy írhatsz megszakításkezelést rá, de az se lesz egyszerû.
Na, amit még tudnia kell a tti és rs232 szintek nem csak feszültségben nem egyeznek, hanem egymás inverzei!!! Tehát be kell rakni hardwares szintillesztõt, pl max232-öt!!!


kedd máj. 05, 2009 8:41
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Hát igen. Csak azok a telefonok jók, amikben van GSM modem.

De mikrokontroller ügyben aztán végképp nem tudok segíteni. Én csak összeollóztam a netről, amiket találtam. :roll: :oops:


hétf. máj. 04, 2009 21:14
Profil Privát üzenet küldése
vas-tag

Csatlakozott: hétf. máj. 04, 2009 20:09
Hozzászólások: 2
Hozzászólás 
Sziasztok!
Remélem még aktív a téma, bár elég régen volt már hozzászólás:(

Elkezdett érdekelni a dolog, sok lehetőséget látok benne... Szeretnék róla többet megtudni. Sokat keresgéltem a neten, de messze ez a leghasznosabb topic amit találtam! Gratulálok mindenkinek, főleg Neked cocka

Nos, sajnos már az elején elakadtam. Mobil telefont szeretnék SMS küldésre használni, úgy, hogy egy mikrokontrollerrel vezérlem... A kontroller kezelése már megy, elméletben a telefont is tudom kezelni az AT parancsokkal. De nem tudom, hogy fizikailag hogyan tudom összekötni a telefont a kontrollerrel. Sok kapcsolás az UART-ot használja. De sehol sem találtam a kapcsolat sebességét és adatformátumát. Egyes telefonokon FBUS és MBUS csatlaozást találtam ilyen célra, de ezeknek semmilyen értelmes leírására nem leltem.

Másik problémám, hogy melyik telefnok alkalmasak a dologra? Szerintem azok, amikben van GSM modem, de ez csak az elméletem, jó enne ha valaki meg tudna erősíteni benne. Illetve ha tudnátok ajánlani olyan telefonokat, amik lehet így használni, olcsóak, és könnyű a beszerzésük...

Tudom, hogy ezek nagyon alapkérdések, de nekem nagy akadályt jelentenek. Örülnék ha tudnátok segíteni!


hétf. máj. 04, 2009 20:33
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka írta:
Ezt is leírtam már egyszer ide.

A válasz az, hogy ha telefonról vagy gsm modemrõl akarod, akkor sehogy. Ha pedig netrõl mittomén sms gatewayen keresztül, azzal bármi megoldható.


igen, olvastam. Gondoltam, hogy hátha azóta változott valami.


pén. nov. 30, 2007 17:37
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Ezt is leírtam már egyszer ide.

A válasz az, hogy ha telefonról vagy gsm modemről akarod, akkor sehogy. Ha pedig netről mittomén sms gatewayen keresztül, azzal bármi megoldható.

Régen mentek a trükközések, hogy ha #a# meg mittomén milyen karaktereket írsz az sms elejére, akkor feladó nélkül érkezik meg vagy anoním számmal stb.. Nem tartom valószínűnek, hogy ma még működnek ezek a kódok.


pén. nov. 30, 2007 17:36
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka írta:
Na ja, de végül is az anyagok elérhetõk angolul is a fenti linken. :)


na ja, csak mint mondtam jó lenne egy összefoglalót írni...

Tudsz valamit mondani arról, hogy hogy lehet a feladó telszámának tetszőleges számot vagy pedig szöveget küldeni?


pén. nov. 30, 2007 4:13
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Na ja, de végül is az anyagok elérhetők angolul is a fenti linken. :)


csüt. nov. 29, 2007 18:06
Profil Privát üzenet küldése
arany tag
Avatar

Csatlakozott: szer. júl. 28, 2004 7:56
Hozzászólások: 263
Tartózkodási hely: A számítógép előtt, telefon mellett
Hozzászólás 
Én is kíváncsian szoktam olvasni írásaidat. Az egy másik dolog, hogy ennyire nem vagyok tudós, így marad a néma hallgatás, othon kísérletezés.

:wink:


csüt. nov. 29, 2007 11:20
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka írta:
Na most írhattam volna hogy hexában, de azt hittem evidens a D0-ából adódóan.

http://www.dreamfabric.com/sms/type_of_address.html

Itt le vannak írkálva a dolgok, a D0 úgy jön ki, hogy ugye binárisban: 11010000

7. bit a doksi szerint mindig 1
6-5-4. bit 101 esetén alfanumerikus karaktersorozat
3.-0. bitig meg lásd a linkelt anyag szerint :)


köszi a linket!

****************


szomb. nov. 24, 2007 3:17
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Na most írhattam volna hogy hexában, de azt hittem evidens a D0-ából adódóan.

http://www.dreamfabric.com/sms/type_of_address.html

Itt le vannak írkálva a dolgok, a D0 úgy jön ki, hogy ugye binárisban: 11010000

7. bit a doksi szerint mindig 1
6-5-4. bit 101 esetén alfanumerikus karaktersorozat
3.-0. bitig meg lásd a linkelt anyag szerint :)


pén. nov. 23, 2007 20:29
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka írta:
Hello!

Nos hát errõl már mintha egyszer írtam volna.

Elsõ kérdésedre válaszolva: 7 bites kódolás vagyis GSM abc

Másodikra pedig: Egy SMS-DELIVER üzenetben az SMSC utáni 3. bájt az ahol definiálhatod, hogy milyen típusú szám vagy karaktersorozat legyen a feladó száma.

Ha D0 akkor alfanumerikus cucc van, ha 91, akkor meg a szokásos nemzetközi formátum.


köszi, igen, közben rájöttem, hogy hol kell figyelni a 91-et, de az $91!!! Azaz hexa! A D0 és a többi kód hol van leírva?


pén. nov. 23, 2007 2:07
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Hello!

Nos hát erről már mintha egyszer írtam volna.

Első kérdésedre válaszolva: 7 bites kódolás vagyis GSM abc

Másodikra pedig: Egy SMS-DELIVER üzenetben az SMSC utáni 3. bájt az ahol definiálhatod, hogy milyen típusú szám vagy karaktersorozat legyen a feladó száma.

Ha D0 akkor alfanumerikus cucc van, ha 91, akkor meg a szokásos nemzetközi formátum.


csüt. nov. 22, 2007 23:49
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
na, kartácsak aktuális lett 1 dolog.

A pannon bevezette, hogy telefonszám helyett feladónak azt küldi el, hogy "Pannon".

Ezzel csak az a baj, hogy szemi-oktet kódolás helyett user datagrammot használ. Kérdés

1. a user datagram GSM-abcben van, vagy ASCII-ben? (ugyanis a "Pannon"-ból pont nem lehet eldönteni, mivel annak mindkét kódolásban ugyanaz a kódja)

2. honnan tudja(m) a program eldönteni, hol szerepel az az SMS-ben, hogy a kapott érték telefonszámot tartalmaz szemi-oktetben vagy pedig szöveget user-datagramban?


csüt. nov. 22, 2007 20:48
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Idézet:
csak nem erről az oldalról


Hanem melyikről?

Idézet:
Másképp struktúrálva sokkal hasznosabb lenne.


És hogy? :roll:

Idézet:
mit lehet egyátalán egy SMS küldéssel elérni.


Elérni? Na ezt nem igazán értem. :?

Idézet:
mit lehet egyidejűleg egy sms-ben elérni


Elérni? Megint nem értem. Fejtsd ki bővebben. Ez így elég homályos.


kedd aug. 07, 2007 9:39
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka:

engem is érdekel a téma, csak nem erről az oldalról, nem úgy, hogy gépisen felsorolsz néhány dolog, mert az a doksikból is ki tudom olvasni. Másképp struktúrálva sokkal hasznosabb lenne.

Legelsőként egy olyan összefoglaló kéne, hogy mit lehet egyátalán egy SMS küldéssel elérni. Utána ezeket a lehetőségeket csoportosítani aszerint, hogy mit lehet egyidejűleg egy sms-ben elérni. És legvégül azt, hogy az hogyan kell megvalósítani.


kedd aug. 07, 2007 1:37
Profil Honlap
arany tag
Avatar

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 239
Tartózkodási hely: Budapest
Hozzászólás 
cocka írta:
Különösebben most nincs túl sok kedvem folytatni a témát, mert látom, nem túl sok embert érdekel rajtam kívül, de azért egy valamit megnéztem.

Ha az sms feladóját nem is lehet átírni alfanumerikus karaktersorozattá, de a címzett számát igen, hát megpróbáltam elküldeni így egy smst, de azt írja a teló, hogy +CMS ERROR: 38

Vagyis network out of order. Mondjuk ez az, ami nem valószínű, inkább az lehet, hogy egyáltalán nem lehet így smst küldeni. Azért megpróbáltam. :wink:

Én mindig elolvasom a topikot, ha van új info. Csak egyelőre nincs időm ezzel foglalkozni. Szóval ne takargasd, ha valamire rájöttél, nekem még a hasznomra lehet. :)


hétf. aug. 06, 2007 18:38
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Különösebben most nincs túl sok kedvem folytatni a témát, mert látom, nem túl sok embert érdekel rajtam kívül, de azért egy valamit megnéztem.

Ha az sms feladóját nem is lehet átírni alfanumerikus karaktersorozattá, de a címzett számát igen, hát megpróbáltam elküldeni így egy smst, de azt írja a teló, hogy +CMS ERROR: 38

Vagyis network out of order. Mondjuk ez az, ami nem valószínű, inkább az lehet, hogy egyáltalán nem lehet így smst küldeni. Azért megpróbáltam. :wink:


hétf. aug. 06, 2007 17:35
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Most pedig rátérnék magára a User Data részre, ami az sms adattartalma.

Az első postomban már kész kódokat adtam meg, nos nézzük hogyan épülnek fel a különböző adattartalmú smsek és hogyan kell őket PDU-ban kódolni.

Első smstípus a hagyományos szöveg lesz. Ezt háromféleképpen írhatjuk: 7, 8 és 16 bites kódolással.

07916302390090F931000B91630XXXXXXXFX0000FFA0<ide jön a 160 karakteres üzenet>

Nézzük külön-külön az egyes részek jelentését (ezekről már korábban volt szó, most csak a példák kedvéért tárgyalom újra):

07 91 63 02 39 00 90 F9

07 Az SMSC (vagyis üzenetközpont) száma + a számformátumának hossza. Itt azt jelenti, hogy maga az adat 7 bájtból áll.

91 Ez a nemzetközi hívószám jelölése.

63 02 39 00 90 F9 A telefonszám fordított félbájtsorrendben. A küldő smscjének száma. vagyis átírva: +36209300099 (a pannoné)

Ennek mintájára, ha magyar simről küldjük az smst, akkor a 07 91 63 0X XX XX XX FX formátum alkalmazható. Az X-ek helyére a telefonszám jegyeit írjuk fordított félbájt sorrendben.

A következő bájt 31. Ez az smsc száma utáni első bájt. Jelentését már korábban leírtam. A 31-et konvertáljuk bináris alakba: 00110001

A 7. bit szerint a válasz nem érkezhet a saját üzenetközpontunkon keresztül.
6. bit szerint az üzenetnek nincs UDH vagyis User Data Header fejléce. Ami érthető is, hiszen egy sima szöveges smshez általában nincs rá szükség.
Az 5. bit jelzi, hogy a feladó kér kézbesítési jelentést.
A 4. és 3. bit 1 0, ami azt jelzi, hogy az érvényességi idő relatív formátumban lesz megadva.
A 2. bit jelzi, hogy az smsc fogadhat ugyanazzal az azonosítóval és címzett telefonszámmal rendelkező smseket egy bizonyos időintervallumon belül.
Az 1. és 0. bit pedig SMS-SUBMIT típust jelöl.

A következő bájt 00, ez a korábban említett referencia szám, a telefon állítja be küldéskor.

0B91630XXXXXXXFX

A 0B azt jelzi, hogy összesen 11 számból áll a telefonszám.

91 a szokásos nemzetközi hívószámjelző

630XXXXXXXFX Az X helyére a címzett telefonszámának jegyei kerülnek fordított félbájtsorrendben. Az F itt szintén kitöltő félbájt.

00 protokoll azonosító

00 adatkódolás mód: Ez az általános adatkódolás jelzője, az 5. bitje jelzi, hogy a szöveg tömörítetlen, a 4. bit jelzi, hogy nem tartozik üzenet osztályba, a 3. - 0. bitek a 7 bites gsm abct jelentik és itt most a Class 0 típustól el kell tekinteni.

FF érvényesség ideje: 63 hét

A0 Ha pontosan 160 karakteres az üzenet, akkor az értéke A0, egyébként pedig annyi, ahány karaktert/szeptetet az sms tartalmaz.

A következőkben annyit írok csak, hogy a 8 és 16 bites SMS-ek miben különböznek a 7 bitestől.

07916302390090F931000B91630XXXXXXXFX0004FF8C<ide jön a 140 karakteres üzenet>

Ez a 8 bites kódja, szinte teljesen ugyanaz, mint a 7 bitesé, csak az adatkódolási mód bájtja változott 04-re. Binárisban ez: 00000100

A 3. és 2. bit 01 vagyis csak annyi változott, hogy az sms 8 bites adatot tartalmaz. Az 1. és 0. bit által meghatározott Class 0 típus itt sem számít, mivel a 4. bit 0 vagyis az üzenetben nincs Message Class információ.

Az utolsó bájt 8C, ami itt a bájtok számát jelöli vagyis max. 140 bájtot tartalmazhat és egyúttal mivel 8 bites kódolásról van szó ez 140 karaktert jelent.

A 16 bites sms teljesen hasonló:

07916302390090F931000B91630XXXXXXXFX0008FF8C<ide jön a 70 karakteres üzenet> (villogtató karakter be/ki:0001)

De itt az adatkódolási mód 08 vagyis binárisban 00001000 ami azt jelenti, hogy a 3. bit 1. Ez az UCS2-es vagy Unicode kódolásra utal. Ezért itt ilyen smsbe feleannyi karakter írható, mint ahány bájtból áll.
A villogtató karakter kódja 0001 mely kizárólag 16 bites kódolási módban érhető el. Lényege, hogy a 0001 után írt szöveget villogtatja az arra alkalmas típusú telefon kijelzőjén (régebbi Nokiák). Két 0001 karakter által közrefogott szövegrész villog. Vagyis minden páratlan sorszámú helyen álló 0001 az utána következő szövegrészt a következő páros sorszámú helyen álló 0001 karakter előfordulásáig villogtatja.

A példa kedvéért tehát, ha olyan smst írunk, melyben minden páratlan sorszámú helyen álló karaktert villogtatni akarunk, akkor ha páratlan karakterből áll az sms, akkor 2*karakterek látszólagos száma+1 db 16 bites karakterből áll valójában az sms. Ha viszont páros karakterekből áll az sms, akkor 2*karakterek látszólagos száma db 16 bites karakterből áll valójában az sms. Ha viszont minden páros sorszámú helyen álló karaktert akarunk villogtatni, akkor ha páratlan karakterből áll az sms, akkor 2*karakterek látszólagos száma-1 db 16 bites karakterből áll valójában az sms. De ha páros karakterekből áll az sms, akkor 2*karakterek látszólagos száma db 16 bites karakterből áll valójában az sms.

Tehát végül is maximum 35 karakterből állhat egy ilyen sms.

Karakterek látszólagos száma: minden karakter kivéve a villogtató karaktereket

A következő alkalommal rátérek a flash smsekre is, sokan kérdik hogy kell küldeni.


szer. júl. 25, 2007 18:46
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Azért ha jól megnézi az ember a fentebb belinkelt táblázatot lehet látni, hogy van egy kis turpisság a dologban. Van néhány karakter: € [ ] { } \ ~ ^ | amelyek nem tartoznak a GSM abcbe, de egyesek úgy gondolták, hogy nem igazán lehet ezeket nélkülözni. Így ha az ember 7 bites sms írásakor ezen karaktereket használja (már ha egyáltalán ad erre a telefon lehetőséget), akkor ezekből egy-egy pontosan 14 bitet foglal. Ezért aztán ha csupa ilyen karakterekből álló smst írnánk, akkor egy üzenetbe (7 bites kódolás ide vagy oda) csupán 80 karaktert lehetne írni. A helyzetet viszont nem bonyolítja, ha az smst Unicode-ban írjuk, mivel ott egy-egy karakter amúgy is 16 bitet foglal.

Az igazságoshoz hozzátartozik, hogy ha 7 bites szöveget szeretnénk írni ékezetekkel úgy, hogy 160 karakter valóban 160 karakter legyen, akkor váltsuk a szövegbeviteli módot angolra, ha erre a készülék lehetőséget ad. Ugyanis bizonyos készülékek esetén (főleg az újabbaknál) előfordulhat, hogy a 7 bites szöveg írásakor olyan karakterek is használhatóak, amelyek nincsenek a gsm abcben. Az ilyen karakterekről az ékezet és minden egyéb extra jelölés el lesz távolítva és sima a d e stb. betűkként fognak a címzetthez megérkezni úgy, hogy erről mi nem is tudunk. Ha egy bizonyos karaktert nem találunk meg a fent belinkelt táblázatban, akkor az nem tagja a gsm abcnek, így a karakter használatát kerüljük és lehetőség szerint váltsuk a bevitel nyelvét angolra vagy bármilyen olyan nyelvre, amelyben megtalálhatók többek közt a balra dőlő ékezetes karakterek is. Ha viszont a telefon a korhű megoldásokat követve csak Unicode módban enged írni, akkor szimplán felejtsük el az ékezetes betűket.

Az a bizonyos 27. karakter egyébként önmagában egy tabulátor karakter.

A táblázat mellesleg annyiban hibás, hogy a 9. C betű alul egy kis vonással az nem nagy betű, hanem kicsi. A nagy betűs verziója nincs a gsm abcben. Bizonyos telefontípusoknál elő lehet varázsolni egy N-t két vesszővel. A két vessző elvileg egy tilde jel.


kedd júl. 24, 2007 10:21
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Most jön tehát a legérdekesebb rész. Ahhoz, hogy a 7 bites szöveget 8 bitessé alakítsuk szükségünk lesz egy ASCII-hez hasonló táblázatra, nevezetesen tudnunk kell, hogy melyik karakternek mi a kódja.

7 biten a legnagyobb ábrázolható pozitív egész a 127. Mivel a számozás 0-ától kezdődik, ezért összesen 128 karakterből áll a 7 bites GSM abc.

Nézzük melyek ezek a karakterek. :arrow: http://www.dreamfabric.com/sms/default_alphabet.html

Ezen táblázat segítségével átkódolható a szöveg 8 bitessé.

A módszer a következő:
Jegyezzük le minden egyes karakterhez a hozzá tartozó decimális számot és konvertáljuk bináris számrendszerbe. Fontos, hogy az így kapott szeptetek elejét ne egészítsük ki 0-ával.

Az első szeptetből úgy lesz bájt, hogy a második szeptet jobb oldalából elvesszük a legutolsó bitet és az első szeptet elé rakjuk. A maradék 6 bithez már 2 bit kell, hogy 8 legyen, ezért a 3. szeptet végéből lecsípünk 2 bitet és a második szeptet elé rakjuk. Aztán a fennmaradó 5 bithez már 3 bit kell, ezért a 4. szeptet végéből lecsípünk 3 bitet és a harmadik szeptet elé írjuk. Ezt az eljárást addig folytatjuk, amíg el nem fogy mind a hét bit, ha elfogyott, akkor ismét rendelkezésünkre áll egy új hét bites karakter, amivel újrakezdhetjük az eljárást. Minden 8*k+1-edik karakternél újrakezdődik az eljárás.

Az üzenetnek bármikor vége lehet, ilyenkor az eljárás a következő: Az utolsó előtti karakter fennmaradó bitjei elé csapjuk az utolsó karakter végéből a 8 bit meglétéhez szükséges mennyiségű bitet, majd az utolsó karakterből megmaradt biteket meghagyjuk és elé annyi 0-át szúrunk be, hogy az 8 bites legyen.

Példa: Legyen példánk az árvíztürö tükörfúrógép (ű és ő nincs a gsm abcben)

Decimális karakterkódja: 127 114 118 7 122 116 126 114 124 32 116 126 107 124 114 102 6 114 8 103 5 112

Ez binárisba alakítva:
1111111 | 1110010 | 1110110 | 0000111 | 1111010 | 1110100 | 1111110 | 1110010 | 1111100 | 0100000 | 1110100 | 1111110 | 1101011 | 1111100 | 1110010 | 1100110 | 0000110 | 1110010 | 0001000 | 1100111 | 0000101 | 1110000

Most pedig a fenti eljárást elvégezve kapjuk az alábbi végeredményt:

01111111 | 10111001 | 11111101 | 10100000 | 10100111 | 11111011 | 11100101 | 01111100 | 00010000 | 11011101 | 10111111 | 11100110 | 11001011 | 11001101 | 00000110 | 00111001 | 11100010 | 01011100 | 10000000 | 00000011

Amit átkonvertálunk hexadecimális számrendszerbe, hogy beilleszthessük a PDU kódba:

7F | B9 | FD | A0 | A7 | FB | E5 | 7C | 10 | DD | BF | E6 | CB | CD | 06 | 39 | E2 | 5C | 80 | 03

A visszakonvertálás ugyanígy zajlik, bár tény, hogy igényel némi ötletet.


hétf. júl. 23, 2007 14:11
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
A fentiekből kiderül egyébként, hogy elméletben lehetséges, hogy a címzett telefonszámaként egy alfanumerikus karaktersorozatot adsz meg. Csak kérdés, hogy működik-e. Meg kérdés, hogy azonosítható-e az adott szöveghez tartozó telefonszám.

Ezt majd kipróbálom és tájékoztatlak az eredményről.

Mondjuk ettől függetlenül a számodat, mint küldő számát fogja kiírni a címzettnek, szóval ezt mondhatni képtelenség átírni. Egyébként engem is érdekelne a megoldás, mert mint látható a PDU kód nem ad semmiféle lehetőséget arra vonatkozóan, hogy szöveges feladóval küldjünk smst.

No meg még az időzített smsre se kaptam választ. Hogy az tulajdonképpen a telefon/ netes sms küldő szolgáltatása vagy beleírható a PDU kódba, hogy mikor küldje a telefon az smst. Bár gyanítom, hogy nem, mivel maga a küldés többek között pl. AT parancsokkal történik és magát a küldésre vonatkozó információt nem tartalmazza a PDU kód.


vas. júl. 22, 2007 23:03
Profil Privát üzenet küldése
a fórum lelke
Avatar

Csatlakozott: szomb. márc. 27, 2004 13:41
Hozzászólások: 5647
Tartózkodási hely: A gép előtt.
Hozzászólás 
cocka írta:
Pontosan ezt kérdeztem az első hsz.-em végén. Csak akkor ezek szerint az itteniek se tudják. :)


THX. :(


vas. júl. 22, 2007 22:44
Profil Privát üzenet küldése Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Az SMS-DELIVER üzenet szintén az üzenetközpont számával kezdődik. De azt érdemes megemlíteni, hogy ez a feladó üzenetközpontjának száma, nem a sajátunk. Ez teljesen megegyezik az SMS-SUBMIT üziknél említettekkel.

Az üzenetközpont száma utáni első bájt meghatározhat SMS-DELIVER formátumú üzenetet is.

Erről a bájtról már volt szó, most csak az eltéréseket szeretném ismertetni.

7 6 5 4 3 2 1 0

A 7. és 6. bit ugyanaz, mint a SUBMIT üzeneteknél.

5. bit A kézbesítési jelentés jelzője. A bit értéke 1, ha a kézbesítési jelentést kérte a feladó és az üzenetközpontnak vissza kell küldenie egy kézbesítési jelentést a feladó telefonjára. Különben 0.

4. és 3. bit: Ezen bitek értéke mindig 0, mivel nem használatosak. (A küldendő smseknél ez a két bit, mint említettem az érvényességi idő formátumát hivatott meghatározni.)

2. bit: 1-nél több üzenet fogadása, értéke 0, ha több üzenet is várható. Különben 1.

1. és 0. bit: Jelen esetben az SMS-DELIVER jelzője. Már korábban írtam róla.

A következő bájt a küldő számának hossza. Megmutatja, hogy a telefonszám hány jegyű avagy hány félbájtból áll.

A következő bájt pedig ennek a számnak a formátuma. Ezt a számtípus bájtot már korábban is kifejtettem.

És e két bájt után következik maga a szám, melynek hossza attól függ, hogy a küldő szám hosszára utaló bájt, hány félbájtot határoz meg. Az F kitöltő félbájt nem számít!

A következő bájt a protokoll azonosító, ami általában 00. Erről már volt szó.

A következő bájt az adatkódolási mód. Mai beszámolómat ezzel kezdtem.

Az ezt követő 7 bájt az sms fogadásának időpontját jelöli. Ennek a 7 bájtnak a formátuma teljesen megegyezik az abszolút időpontmegadásnál ismertetettekkel.

Vagyis év, hónap, nap, óra, perc, másodperc és időzóna és ugyanúgy érvényes rá a fordított félbájtsorrend is.

Az ezutáni bájt a User Data rész hossza. 7 bites sms esetén maximális értéke A0h vagyis 160 szeptet, 8 vagy 16 bites sms esetén maximális értéke 8Ch vagyis 140 bájt.

A következő bájtsorozat hossza a User Data hosszánál megadott értékkel meg kell egyezzen. Tuladjonképpen ez az SMS tartalma és soha sem lehet több 140 bájtnál. Ebből következően egy 140 bájtos üzenet esetén a 140 bájtot megelőző header hossza maximum 35 bájt lehet.

Tehát most nézzük a különböző tartalmakat:

A kérdés már csak az, hogy hogyan írjunk meg egy 7 bites kódolású szöveget úgy, hogy mind a 8 bitet kihasználjuk. Erről majd holnap fogok írni. :D


vas. júl. 22, 2007 21:05
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Idézet:
lehetséges egy telóról úgy SMS-t írni, hogy a fogadó félnél ne jelenjen meg a telefonszám, vagy más telefonszám jelenjen meg?


Pontosan ezt kérdeztem az első hsz.-em végén. Csak akkor ezek szerint az itteniek se tudják. :) A nowsms honlapját tartom sms illetve mms ügyben a legautentikusabb honlapnak.

Onnan annyit tudtam meg, hogy GSM modemről vagy telefonról ilyen nem küldhető. Csak SMS gatewayjel küldhető. olcsosms, 999sms, meg ozeki és nem utolsó sorban nowsms stb.

Az SMS-SUBMIT üzenet PDU kódjában összesen kettő db telefonszám található. Az egyik az üzenetközponté, a másik pedig a címzett telefonszáma. A másféle telefonszámról küldésnek nem sok értelme van, mert csak galibát okozna, pláne ha létező telefonszám. Viszont ha 7 bites szöveg van a feladó helyén, annak már több értelme van.

Egyébként az elképzelésemet nem csak a nowsms fóruma támasztja alá, hanem máshol is láttam, hogy ha (szintén SMS gatewayes szolgáltatás kapcsán olvastam) szöveges feladóval küldjük az üzenetet, akkor arra nem lehet válaszüzenetet küldeni. Ezért gondolom, hogy ha telefonról nem küldhető szöveges feladójú smsre válasz, akkor egyáltalán nem küldhető telefonról olyan sms, aminek a feladója bármi más, mint a saját telefonszámod.

Akkor ahogy ígértem. Most nézzük, hogy az adatkódolási mód névre hallgató bájtban ha bitekre lebontjuk mi mit jelent.

7 6 5 4 3 2 1 0

Ha a 7. és 6. bit 0, akkor ez általános adatkódolási jelet takar, a további bitek a következőket jelentik:

5. bit: 0, ha a szöveg tömörítetlen (általában az) és 1, ha tömörített

Na erről a tömörítésről nem szól a fáma, lehet, hogy egy olyan funkció, amit nem valósítottak meg? :roll: Régebbi típusú készülékeknek egy tömörített üzenet nyilván csak egy összefüggéstelen adathalmaz lenne, amit vagy krikszkrakszokban jelenít meg a telefon, vagy közli, hogy ez az üzenet nem jeleníthető meg.
De az is lehet, hogy ez magának az üzenetközpontnak egy jelzés, hogy a feladó telefonjáról érkező smst kódolja be, majd ott azt kódolva tárolja és végül, amikor továbbküldésre kerül a sor a címzett telefonjára, akkor a küldés előtt ismét kódolja ki. Aki tudja írja. :)

4. bit: 0, ha az első és a nulladik bit nem jelent üzenetosztályozást és 1, ha igen.

3. és 2. bit:

0 0 7 bites gsm abc szerinti kódolás
0 1 8 bites adatkódolás a 7 bites gsm abc karakterek használatával (bár ez általában nem szöveg)
1 0 16 bites kódolás az UCS2 avagy Unicode karakterek használata
1 1 lefoglalva

1. és 0. bit: az üzenetek osztályozásait adják meg:

0 0 Class 0 azonnal megjelenik a telefon kijelzőjén
0 1 Class 1 telefonspecifikus kb. annyit jelent, hogy az adattartalom a telefonmemóriába mentődik, ha létezik ilyen memória
1 0 Class 2 SIM specifikus ez pedig annyit jelent, hogy az adattartalom mindenképp a kártyára mentődik
1 1 Class 3 Terminál specifikus gondolom a terminálprogrammal van összefüggésben, egyebet nem tudok róla

Ha a 7. és 6. bit 1 1-gyel kezdődik, akkor azok a szakirodalom szerint általában valami message waiting indication group-ot jelölnek. Túl sokat erről nem tudok. Aki ismeri, hogy ezek a jelzők hogy működnek, írjon róla bátran.

Egyetlen kivétel az, ha a 7. és 6. bit 1 1-gyel kezdődik és a további 5. és 4. bit is 1 1-gyel folytatódik. Ezek szintén adatkódolást ill. üzenetosztályt határoznak meg.

7 6 5 4 3 2 1 0

1 1 1 1 0 X X X

A 3. bit mindig 0.

A 2. bit 0, ha 7 bites gsm abc szerinti kódolás és 1, ha 8 bites adatkódolás.

Az 1. és 0. bit szórul szóra ugyanazokat az üzenetosztály kódokat jelenti, amiket fentebb leírtam: azonnal megjelenő, telefonspecifikus, simspecifikus és terminálspecifikus (Class 0-3)

Mondjuk az nem világos e bájttal kapcsolatban, hogy miért van szükség kétszer majdnem ugyanarra a kódra. pl. a fentebb említett classokra. Aki tudja, elmesélheti. :D

A következő bájt vagy bájtsorozat az érvényességi időt jelöli vagyis hogy az üzenet meddig tárolódhat az üzenetközpontban, amíg nem törlik. 1 vagy 7 bájt lehet formátumtól függően. Ha az SMS-SUBMIT-ot jelölő bájtban nem rögzítettük a létezését, akkor a bájt elhagyható.

Ahogy azt már korábban is említettem három típusa van, de a leggyakoribb a relatív használata, mivel ez csak 1 bájtot igényel.

Értéke 0-255-ig terjed az alábbi felosztást figyelembe véve:

0-143 (0 és 143 közti érték)* 5 perc (5 percenkénti ugrás 12 óráig)
144-167 12 óra + ((érték a megadott intervallumból - 143)* 30 perc) (30 percenkénti ugrás 24 óráig)
168-196 (érték a megadott intervallumból - 166) * 1 nap (naponkénti ugrás 30 napig)
197-255 (érték a megadott intervallumból - 192) * 1 hét (hetenkénti ugrás 63 hétig)

Az abszolút időmegadás 7 bájtból áll és a következőképpen áll össze:

1. bájt: Az évet jelöli. Értéke: 00-99 között mozog.
2. bájt: A hónapot jelöli. Értéke: 01-12 közt mozog
3. bájt: Napot jelöli. Értéke: 01-31
4. bájt: Óra, Értéke: 00-23
5. bájt: Perc, Értéke: 00-59
6. bájt: Másodperc, Értéke: 00-59
7. bájt: Időzóna, Értéke: -48 és +48 között 1 egység +/-0.25 órányi eltérés a GMT-hez képest.

Minden ilyen bájt fordított félbájtsorrendben van írva. Vagyis pl. 59 perc az 95. stb..

Az időzónánál pedig a GMT értéket szorozzuk meg 4-gyel, így megkapjuk a -48..48 közti névleges értéket.
Ha az érték 0-48 között van, akkor ezek átkonvertálása a PDU kódba szintén megfordítással történik: 48-ból 84 lesz stb..

De 0-tól mínusz 48-ig másként alakul a konverzió:

Ha a névleges érték negatív, akkor vegyük annak abszolútértékét és adjuk a 80h hexadecimális számhoz. A kapott értéken alkalmazzuk a félbájtok cseréjét.

Vagyis például vegyük a GMT -6 időzónát. Kb. USA keleti partja. A fentiek
alapján, hogy a névleges értéket megkapjuk, ha szorozzuk 4-gyel. Vagyis a névleges érték -24. Hogy ezt a PDU kódba beírhassuk, mint hexadecimális értéket, adjunk hozzá a 24h számhoz 80h-t. Kapjuk, hogy A4h. Az A4-et megfordítva a kódba beírandó érték tehát 4A.

Továbbfejlesztett időpont megadása:

Szintén 7 bájtot foglal és ha nincs megadva érvényesség, akkor mind a 7 bájt értéke 00.

Ha az 1. bájt értéke 01, akkor az időpont relatív formátumú és a 2. bájt reprezentálja pontosan úgy, ahogy azt a relatív időmegadásnál leírtam.

Ha az 1. bájt értéke 02, akkor az időpont szintén relatív formátumú, de a 2. bájt ezúttal kizárólag másodperceket jelent. Például: FF = 255 másodperc

Ha az 1. bájt értéke 03, akkor az iődpont szintén relatív formátumú, de az így beállított üzenet érvényességi ideje maximum 1 nap lehet.

A 03-mat követő 3 bájt (2. 3. és 4.) az órát, percet és másodpercet jelöli. A megadás és intervallumok az abszolút időpontmegadásnál ismertetettekkel szinte azonos. (a fordított félbájtsorrend itt is érvényes)
Azaz
2. bájt: 00-23-ig
3. és 4. bájt: 00-59-ig

Ennyit az érvényességről. A következő bájt létfontosságú, ugyanis ez határozza meg a User Data rész (vagyis a tényleges tartalom) hosszát.

Ha az sms 7 bites kódolású az adatkódolási mód bájtja szerint, akkor ez a bájt az üzenetben előforduló szeptetek számát jelöli vagyis maximális értéke A0h lehet. Ha az üzenet 8 vagy 16 bites kódolású, akkor ennek maximális értéke 8Ch lehet.

Most pedig miután eddig csak a küldendő smsek formátumáról volt szó, rátérnék a bejövő smsek formátumára is, illetve hogy miben különböznek a küldendő smsek formátumától.


vas. júl. 22, 2007 20:25
Profil Privát üzenet küldése
a fórum lelke
Avatar

Csatlakozott: szomb. márc. 27, 2004 13:41
Hozzászólások: 5647
Tartózkodási hely: A gép előtt.
Hozzászólás 
Ha már itt boncolgatjátok az SMS-eket: lehetséges egy telóról úgy SMS-t írni, hogy a fogadó félnél ne jelenjen meg a telefonszám, vagy más telefonszám jelenjen meg?


vas. júl. 22, 2007 16:40
Profil Privát üzenet küldése Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
No igen. Hát gondoltam írok róla kicsit bővebben magyarul, hogy érthető legyen, de inkább nem vállalkozok rá. Nincs is túl nagy jelentőssége egyébként, úgyhogy hagyom a fenébe. Majd folyt. köv.


vas. júl. 22, 2007 10:03
Profil Privát üzenet küldése
gyémánt tag
Avatar

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 2670
Hozzászólás 
> csak annyit írnak, hogy Numbering Plan Identifiation.
> Hogy aztán ez micsoda, azt nem tudom. Itt megint jó
> lenne, ha valaki adna ezügyben egy kis felvilágosítást.
> Általában a 0 0 0 1 használatos, az vonatkozik az
> ISDN/telefon készülékekre.

http://en.wikipedia.org/wiki/E.164

0 0 0 0 Unknown.
0 0 0 1 ISDN/telephone numbering plan (E.164/E.163).
0 0 1 1 Data numbering plan (X.121).
0 1 0 0 Telex numbering plan
1 0 0 0 National numbering plan
1 0 0 1 Private numbering plan
1 0 1 0 ERMES numbering plan (ETSI DE/PS 3 01-3)
1 1 1 1 Reserved for extension

Hat igen, a 0001 az esetunkre vonatkozo ertek....


vas. júl. 22, 2007 8:14
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Idézet:
végre egy komoly topic!


Köszi. Annak viszont tényleg örülnék, ha más is írna valamit a témában legalább annyit, hogy itt ezt és ezt nem jól tudod, mert ez így és így van. Aztán módosítanám utólag és kapnánk egy magyar nyelvű szép kis anyagot az sms kódolásról, amit más is nyugodtan felhasználhat.

Az előbbi szám formátum bájtot nemes egyszerűséggel elintéztem annyival, hogy leggyakrabban a 91-es értéket kapja. (természetesen itt egy hexa értékről van szó)

De most nézzük meg mi mit jelent a bájton belül. Ehhez le kell bontanunk bitekre a bájtot.

A 8 bitet balról jobbra csökkenő sorrendben a hetessel kezdve megszámozom.

7 6 5 4 3 2 1 0

A 7. bit mindig 1.

A 6. 5. és 4. bit együttesen meghatározza a szám típusát az alábbiak szerint:

6. 5. 4.

0 0 0 - ismeretlen szám
0 0 1 - nemzetközi szám
0 1 0 - belföldi szám
0 1 1 - hálózatspecifikus szám
1 0 0 - előfizetői szám
1 0 1 - alfanumerikus szám, a szöveg 7 bites kódolású (mondjuk megnézném azt az üzenetközpontszámot, ami esetleg csak betűkből áll)
1 1 0 - rövid hívószám
1 1 1 - további fejlesztésekhez lefoglalva

Azt hiszem ehhez különösebb kommentárt nem érdemes fűzni.

A fennmaradó 4 bitről (3., 2., 1. és 0.) a külföldi honlapok csak annyit írnak, hogy Numbering Plan Identifiation. Hogy aztán ez micsoda, azt nem tudom. Itt megint jó lenne, ha valaki adna ezügyben egy kis felvilágosítást. Általában a 0 0 0 1 használatos, az vonatkozik az ISDN/telefon készülékekre.

Tehát a 91h lebontva így néz ki:

1 001 0001 vagyis nemzetközi szám és aki bővebbet tud erről a numbering planről az írja.

Akkor tehát nézzük az smsc száma utáni első bájtot. Ennek értéke is az sms tartalmától függően változik. Értelmezni ezt is bitekre lebontva lehet.

SMS-SUBMIT (küldendő) üzenet esetén a bitek következőket jelentik:

7 6 5 4 3 2 1 0 Az előbbihez hasonló felbontást használok itt is.

7. bit: Jelzi, hogy a címzettnek engedélyezzük-e, hogy válaszüzenetét a saját üzenetközpontunkon keresztül küldje. (válasz útvonala) Értéke 0, ha nem, és 1, ha igen.

6. bit: A User Data Header létezése. A User Data az smsnek pontosan az a része, ahová a tényleges adattartalom kerül, ami smsenként maximum 140 bájt lehet vagy 160 szeptet. Ha az értéke 1, akkor a User Data résznek van fejléce, ha 0, akkor nincs. Ez sok esetben szükséges a speciális smsek küldéséhez.

5. bit: Kézbesítési jelentés kérése. Értéke 1, ha a küldő kér kézbesítési jelentést, 0, ha nem. Erre találták ki a szolgáltatók a különböző sms szövegébe beírható kódokat (ha esetleg maga a telefon nem támogatná a kézbesítési jelentések fogadását), melyek segítségével tőlük is lehet kézbesítési jelentést kérni smsben. Persze a kézbesítési jelentés csak akkor érkezik meg, ha az smst érvényességi időn belül megkapja a címzett.

4. és 3. bit: Az érvényességi idő formátuma. Maga az érvényességi idő megmutatja, hogy az adott sms meddig tárolható az üzenetközpontban, mielőtt törlik. Nyilván ennek akkor van jelentőssége, ha a címzett telefonja ki van kapcsolva vagy vmi miatt nem elérhető.

4 3

0 0 nincs érvényességi idő, gondolom ilyenkor az üzenetközpontban beállított default értékig lesz az üzenet érvényes
1 0 relatív formátum, 1 bájtot foglal, ez a leggyakoribb, (a formátumok felépítéséről majd később)
0 1 továbbfejlesztett formátum 7 bájtot foglal
1 1 abszolút formátum szintén 7 bájtot foglal

2. bit: A duplán küldött üzenetek elvetése. Ez a tulajdonság a következő módon működik: Küldünk egy (a példa kedvéért) A jelű smst. Majd küldünk egy B jelűt is, melyben ugyanaz a hivatkozási szám és a címzett telefonszáma, mint az A jelű smsben. Ha az értéke 1, akkor az üzenetközpont elveti/törli a B jelű smst. Ha az értéke 0, akkor megtartja.

1. és 0. bit: Az üzenet típusát jelöli. Lehet SMS-SUBMIT illetve SMS-DELIVER vagy COMMAND.

1 0

0 1 SMS-SUBMIT vagyis küldendő üzenet
0 0 SMS-DELIVER vagyis bejövő üzenet
1 0 SMS-COMMAND erről nem sokat tudok, de valami vezérlő sms

A következő bájt egy referencia avagy hivatkozási számot jelöl. Az smsnek definiálnak egy értéket, amivel hivatkozni lehet rá. Ha ez a bájt 00, akkor ezt az értéket a telefon maga állítja be az sms küldésekor. Ha az érték 00-tól különböző, akkor a megadott érték lesz az üzenet referenciaszáma.

A következő bájt megmutatja, hogy a címzett telefonszáma hány jegyű vagyis hogy maga a szám hány félbájtból áll.

A következő bájt a címzett telefonszámának formátuma. Az értékek teljesen azonosak az üzenetközpont számformátumának részletezésénél említettekkel.

A következő bájtsorozat hossza attól függ, hogy hány félbájtot mutat a feljebb említett jelzőbájt. pl. 63 02 87 45 21 F3 Itt is fordított bájtsorrendben vannak írva a számjegyek és az F mint kitöltő félbájt van jelen. Az eredeti szám tehát 36 20 78 54 12 3. Ezt már csak egybe kell írni és megkapjuk a telefonszámot.

A következő bájt az esetek 95%-ában mindig 00. Valami protokoll azonosító, de többet nem tudok róla írni, mert elég homályosak a magyarázatok. Aki ezügyben tud valamit, esetleg érti mire való ez a bájt jelezze.

A következő bájt az adatkódolási mód lesz.


pén. júl. 20, 2007 13:24
Profil Privát üzenet küldése
gyémánt tag

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 1075
Hozzászólás 
végre egy komoly topic!


csüt. júl. 19, 2007 21:51
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Nos annak a 176 bájtnak, ami egy-egy adatmezőben/memóriahelyen van az legelső bájtja a már korábban is említett állapotjelző bájt.

Ötféle értéke lehet, attól függően, hogy milyen smsről van szó és az kimenő vagy bejövő üzenet-e.

Nézzük sorban:

00 Ez azt jelenti, hogy az adott hely felülírható új smsekkel. Szabvány szerint a további 175 bájtnak FF-nek kell lennie. Manapság sok telefon az sms tartalmát nem törli, csak a jelzőbájtot írja át 00-ára, a többi bájtot változatlanul hagyja. Így lehetséges a törölt smsek esetenkénti visszaállítása.

01 Ez a korábban említett "REC READ" -nek felel meg, vagyis bejövő olvasott üzenet

03 "REC UNREAD" azaz bejövő olvasatlan üzenet

05 "STO SENT" kimenő, tárolt, de már elküldött üzenet

07 "STO UNSENT" kimenő, tárolt, de még el nem küldött üzenet

Ez azt jelenti, hogy a 01 és 03-mal kezdődő smsek a bejövő mappában tárolódnak, a 05 és 07 kezdetűek pedig a kimenő mappában. Ám ezeknek újabban nincs jelentőssége, miután a mostani telefonok közül kevés olvas be kártyáról kimenő smseket. Az ilyen későbbi küldés végett elmentett üzenetek leginkább a telefonmemóriába mentődnek.

A későbbiekben kiderül majd, hogy az üzenetközpont száma utáni első bájt kiemelt fontossággal bír, hiszen többek között az határozza meg az sms formátumát is, hogy az SUBMIT, DELIVER vagy COMMAND sms. A SUBMIT sms tul.képp kimenő sms, a DELIVER pedig bejövő. A formátumuk eléggé eltérő. Tehát egy SMS-DELIVER üzenetet ne lássunk el kimenő üzenetre vonatkozó jelzőbájttal illetve fordítva, mert a telefon megkergül az smsektől. :D

Még annyit érdemes tudni, hogy ezt a legelső jelzőbájtot a PDU beolvasásnál csak a fejlécben lehet látni, magában a kódban viszont nem. A korábban leírt értékek nem azonosak e jelzőbájt értékeivel. Ott 0, 1, 2, 3 (a 4 most itt nem számít) számokkal történt a besorolás, itt viszont 0, 1, 3, 5 és 7.

A kölcsönös megfeleltetések a következők:

00 - ennek nincs megfelelője, mivel törölt, azaz a jelzőbájt szerint nem létező smseket AT parancsokkal nem lehet beolvasni.

01 - ennek az AT parancsoknál megismert megfelelője az 1-es avagy "REC READ"

03 - az AT parancsos megfelelője a 0 avagy "REC UNREAD"

05 - az AT parancsos megfelőlje a 3 avagy "STO SENT"

07 - az AT parancsos megfelelője a 2 avagy "STO UNSENT"

Az SMS-DELIVER headerje alapvetően eltér az SMS-SUBMIT headerjétől, ezért először az SMS-SUBMIT-et fogom tárgyalni.

A fenti jelzőbájtot követő első pár bájt az üzenetközpontot határozza meg.

példa: 07 91 63 02 39 00 90 F9

Itt a bájtok a következőket jelentik:

07 - az üzenetközpont információ hossza, azaz a formátumának és a számának hossza

91 - nagyon ritka, hogy más az értéke; a nemzetközi hívószám formátum vagyis a +-okkal kezdődő számokat jelöli. Ezenkívül használatos még a 81 és az A1. A 81 az ismeretlen formátum, de általában a + nélküli számokat, az A1 pedig a nemzeti hívószámokat jelöli.

63 02 39 00 90 F9

Ez maga az üzenetközpont száma. Fordított félbájtsorrendben kell írni vagyis: Ahhoz hogy az eredeti számot megkapjuk minden egyes bájtnál az első helyiértéken álló számjegyet írjuk a második helyiérték helyére és fordítva. Tehát 36 20 93 00 09 9F Írjuk egybe és megkapjuk a pannon smsc számát. Az F egy pótérték, mivel a telefonszám csak 7 jegyű.

Az üzenetközpont száma utáni első bájtról majd a következő postban írok. Mára ennyi.


csüt. júl. 19, 2007 17:31
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Tehát ha az AT+CMGL-lel szöveges módban lekérjük az smseket, akkor minden üzenet fejléce hasonlóképp fog kinézni.

Példa:

+CMGL: 10,"REC READ","+36309400700",,"05/04/01,07:00:43+08",145,116

Ezek jelentése pedig a következő:

+CMGL: <memóriahely száma>
"REC READ" (azt jelenti, hogy bejövő olvasott smsről van szó)
"+36..." (a küldő/feladó száma)
"05/04/01,07:00:43+08" év/hó/nap,óra:perc:másodperc+időzóna
145 a feladó számának formátuma decimális számrendszerben
116 az üzenet hossza (a szeptetek száma) decimálisban

A +CMGR is hasonlóan listáz, de picit több adatot szolgáltat. AT+CMGR=<memóriahely száma>

Példa:

+CMGR: "REC READ","172",,"07/07/13,20:55:12+08",129,4,0,0,"+36209300099",145,99

Itt nincs memóriahely, mivel csak egy üzenetet íratunk ki.
"REC READ" (megint csak az üzenet állapotát jelzi vagyis jelen esetben azt, hogy bejövő olvasott)
"172" a küldő/feladó száma
"07/07/13,20:55:12+08" ugyanaz, mint az előbb (dátum)
129 a küldő számának formátuma decimálisban
4 az SMS (üzenetközpont száma utáni) első bájtja, mely többek közt jelzi, hogy SMS-DELIVER üzenetről van szó
0 protokoll azonosító
0 adatkódolási mód (itt pl. azt jelzi, hogy normál 7 bites sms)
"3620930..." az üzenetközpont vagy smsc száma
145 az üzenetközpont számának formátuma decimálisban
99 a karakterek/szeptetek száma

PDU módban ezek a fejlécadatok következőképpen módosulnak:

Példa:
+CMGL: 6,1,,150

6 A memóriahely száma
1 ugyanaz, mint a "REC READ", de PDU-ban számmal jelölik
150 Megmutatja, hogy az üzenetközpont száma, hossza és formátuma nélkül hány bájtot foglal az sms. PDU módban ezt a számot kell megadni az AT+CMGS= parancsnál az = jel után, ha az üzenetet szeretnénk azonnal elküldeni. Szöveges módban ugyanide a karakterek/szeptetek számát kell írni. A parancs az alábbiakban ismertetett +CMGW-vel azonos módon működik. A különbség csak annyi, hogy ez a parancs az smst egyből elküldi, míg a +CMGW csak az adott memóriahelyre írja.

+CMGR esetén ugyanezt jelentik a számok, csak nincs memóriahely

Az AT+CMGW=<üres memóriahely száma> a következőképp működik PDU módban:

Ha összeállítottuk a PDU kódot, akkor próbáljuk meg lementeni pl. a 3-mas memóriahelyre vagy korábban ahogy hívtam adatmezőbe.

AT+CMGW=3 Ha már van ott sms, akkor hibaüzenetet kapunk, ha nincs akkor megjelenik egy > jel, mely után beilleszthetjük a PDU kódot. Majd a Ctrl + Z megnyomásával menthetjük a kártyára a kódot. Vigyázni kell vele, mert nem mindig sikerül elsőre a mentés, többször kell próbálkozni, főleg a kód nem megfelelő hosszából vagy a helytelen hosszmegadásból származhatnak problémák.

A sikeres mentés után küldhető is az üzenet az AT+CMSS=3 paranccsal, aminek elküldése után visszaigazolás is megjelenik a terminál programban. Néha előfordulhatnak +CMS ERROR hibák. A leggyakoribb az 50-es. Ez azt jelenti, hogy nincs elég pénz a kártyán.

Még 3 AT parancsról érdemes szót ejteni, ami szervesen az üzenetküldéshez kapcsolódik:

AT+CSCS, AT+CPMS, AT+CMGD

A +CMGD=<memóriahely száma> az adott helyen lévő smst törli.

A +CSCS kilistázza, hogy milyen kódolási módban jelenítse meg a terminálprogram az üzeneteket

AT+CSCS=? megmutatja, hogy milyen kódolási módokat ismer a telefon
AT+CSCS? megmutatja, hogy milyen kódolási mód van jelenleg beállítva

Példa: +CSCS: ("GSM","PCCP437","UCS2")

Az +CPMS kilistázza a különböző smsek memóriahelyét. Szintén van =?-s és sima ?-es változata is. Példa:

+CPMS: "SM",18,25,"SM",18,25,"SM",18,25

A 25 a maximálisan tárolható smsek száma a kártyán. A 18 a tárolt smsek száma. Megmutatja, hogy hány hely van lefoglalva smssel.

És ezek után rátérek arra a bizonyos 176 bájtra, mely az smst alkotja. :wink:


A hozzászólást 1 alkalommal szerkesztették, utoljára cocka hétf. júl. 23, 2007 14:26-kor.



csüt. júl. 19, 2007 16:20
Profil Privát üzenet küldése
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Úgy gondolom ahhoz, hogy itt a PDU kódolásba komolyabban is belemenjünk először a SIM kártyáról kéne adni némi infót, hogy tulajdonképpen hány bájt lehet maximum egy SMS úgy mindenestül a kártyán stb..

Elvileg minden szolgáltatótól származó SIM tartalmaz egy fájlstruktúrát. Ez a fájlstruktúra három fájltípusból épül fel. Master file, Dedicated file és elementary file. Master file összesen egy van, azonosítója: 3F00 neve SIM.

Minden egyéb fájl ezen belül található. A master file és dedicated file a könyvtárakhoz/mappákhoz hasonlóan viselkednek. A master file legalább 3 db dedicated file-t tartalmaz és legalább egy elementary file-t. Ez utóbbi tartalmazza a kártya ICCID-jét, amit egyébként magán a kártyaplasztikon is olvashatunk.

Tehát minden fájlnak van egy azonosítója, típusa és neve. Az azonosító egy 4 jegyből álló hexaszám, a típus a fent említett háromféle lehet, a név pedig magáért beszél.
Most nagyon nem térnék ki a fájlstruktúra részletezésére, annyit viszont érdemes megemlíteni, hogy a fent említett 3 db dedicated file azonosítói és nevei a következők:

7F10 - Telecom
7F20 - GSM
7F21 - DCS1800

Ez utóbbi két "mappa" tartalma megegyezik. A Telecom mappában vannak eltárolva azok a fájlok, ahová a névjegyzék és az SMS-ek menthetők.

A 6F3A - ADN (Abbreviated Dailing Numbers) nevű fájl tartalmazza a neveket és telefonszámokat.
A 6F3C - SMS pedig az smseket.

Minden elementary típusú fájl a gépünkön lévő fájlokhoz hasonló módon viselkedik. Minden elementary file besorolható egy-egy fájlstruktúratípusba. Ezek: lineárisan fix, ciklikus és transzparens. Ezekről aki bővebbet tud leírhatja. (hogy miért ez a nevük, hogyan viselkednek stb.) Annyit sikerült megtudnom, hogy a lineárisan fix és a ciklikus 1 adatmezőnél jóval többet tartalmazhat, míg a transzparens legfeljebb egyet.

Az adatmezőket, mint kis fakkokat kell elképzelni, amelyek fix bájthosszal rendelkeznek. Max. annyi bájt írható az egyes adatmezőkbe, amennyit a kártyagyártáskor felprogramoztak. A lineárisan fix és a ciklikus fájlok teljes mérete = az adatmezők darabszáma * az egyes adatmezőkbe maximálisan írható bájtmennyiség

Itt is ugyanúgy végezhetők fájlműveletek, mint a számítógépen, csak van egy pár különbség.

Az alapfájlműveletek a következők:

Olvasás/Keresés, Írás, Növelés, Invalidálás és Rehabilitálás

A növelésről nem tudok nyilatkozni, ha valaki ezt megteszi helyettem, fogom tudni értékelni, mert engem is érdekelne, hogy mi az.

Az invalidálás olyan, mintha törölnéd a fájlt, de itt tul.képp nem törlésről van szó, hanem érvénytelenítésről. Magyarán a továbbiakban úgy viselkedik a kártya, mintha az adott fájl nem is létezne rajta. Hogy közérthetőbb legyen maga a mobiltelefon is tud ilyen invalidálást végezni az ADN fájllal a PIN2 kódot segítségül hívva, amikor a titkos második hívószámlistát hívjuk elő a kártyáról. Ilyenkor ugyebár egyéb telefonszámok nem elérhetők/tárcsázhatók és a normális 250 neves telefonkönyv is megszűnik létezni egész addig, amíg vissza nem aktiváljuk (rehabilitáljuk) az eredeti telefonkönyvet.

Ebből következően a rehabilitálás pedig a fájl újraérvényesítését jelenti, vagyis ismét úgy működik a kártya, mintha az adott fájl mindig is ott lett volna.

Minden fájlművelethez tartozik egy-egy hozzáférési szint, ettől függ az adott művelet végrehajthatósága. Ezek a következők lehetnek:
Mindig, CHV1, CHV2, CHV4, CHV5, CHV6, Soha

A CHV itt a Cardholder verification rövidítése vagyis kártyabirtokos hitelesítése. A CHV1 és CHV2 más néven PIN1 és PIN2-ként ismeretes. A többi CHV érték pedig bizonyos ADM vagyis admin kódokat takar. Ilyen típusú kódból legalább kétféle van és nem módosíthatók, nem törölhetők. A megadásuk APDU parancsokkal történik. Ha jól tudom ezeket ismeri a szolgáltató és ezen kódok ismeretében megváltoztathatók a PUK kódok. De erről mintha K-Roy már írt volna e fórumon bővebben.

Természetesen minden egyes fájlhoz más-más jogosultsági szint tartozik és olyan fájl is van, ami pl. soha nem olvasható vagy csak a CHV4 ismeretében, ami tul.képp majdhogynem egyenértékű a sohával. :)

Ideje az ADN és az SMS fájlokról bővebben is írnom. Az ADN fájl mérete általában 7500 bájt vagyis 250 * 30 bájt. 250 db adatmezőből áll (ugye a 250 telefonszámnak) és ezek az adatmezők egyenként 30 bájtosak.

Az SMS fájl mérete 4400 illetve 8800 lehet attól függően, hogy a kártya 25 vagy 50 db SMS-t tud-e tárolni. Az sms fájl egy adatmezőjébe max. 176 bájt fér. Így jön ki a 25 és 50 db sms. 25 * 176 bájt és 50 * 176 bájt

Az SMS PDU kódolás főtémája e 176 bájt lesz.

De még mielőtt belevágnék ismertetnem kell néhány alapvető AT parancsot is amellyel rávehetjük modemes telefonunkat speciális smsek küldésére.

Ha rendelkezünk mindazon felszereléssel, amit egy korábbi hsz.-ben már leírtam, akkor a terminál program indítását követően első dolgunk az legyen, hogy teszteljük a telefont egy AT paranccsal. A telefon elvileg OK-val válaszol. Ha nem látjuk, amit írunk, akkor vagy a terminál programban kapcsoljuk be a helyi visszhangot vagy a telefonnak adjuk ki a következő parancsot: ATE0 vagy ATE1
Vigyázni kell a backspace használatával, mert itt törölni nem sokat fog, csak visszaugrik egy helyet.

Az AT parancsoknak kétféle megadása létezik:

1. Az AT parancsnak nincsenek egyéb paraméterei, ezért nem kell azokat megadni. Példa: AT+CGMI gyártó információ vagy AT+CGMM modellinfó

2. Az AT parancsnak vannak paraméterei. Ilyen parancs pl. az AT+CMGR=<memóriahely száma> Ez a kártyán lévő megadott adatmezőből olvassa ki az smst hexában/PDU-ban.

AT+CMGF -> Ez a parancs lényeges, hiszen ez határozza meg, hogy szöveges vagy PDU módban szeretnék az üzenetet megírni/megjeleníteni.

A parancs utáni =? mindig az összes lehetséges értéket adja vissza. Ha a kérdőjel helyére számot írunk, akkor az adott értéknek megfelelő utasítás lesz végrehajtva.

A parancs utáni sima ? az aktuális értéket kérdezi le.

Az AT+CMGF=0 tehát PDU módba kapcsolja a megjelenítést
Az AT+CMGF=1 pedig szöveges módba

A későbbi problémák elkerülése végett célszerű előre elmenteni a kártyára a küldendő smst. Ahhoz, hogy megtudjuk hol van a kártyán üres hely az smsnek, nézzük meg a következő parancsot:

AT+CMGL=? A válasz PDU módban ennyi lesz: +CMGL: (0-4) Hogy ez az öt érték mit jelent, azt könnyű kideríteni.

Ha átkapcsolunk szöveges módba és végrehajtjuk ugyanazt a parancsot, akkor a válasz így módosul:

+CMGL: ("REC UNREAD","REC READ","STO UNSENT","STO SENT","ALL")

0 "REC UNREAD" az olvasatlan bejövő üzenetet jelöli
1 "REC READ" az olvasott bejövő üzenetet jelöli
2 "STO UNSENT" az el nem küldött, de mentett kimenő üzeneteket jelöli (nyilván itt ez attól is függ, hogy a telefon ment-e a simre kimenő smseket vagy csak a telefonmemóriába; hogy honnan olvassa be a terminál program az smseket, azt is AT parancsokkal lehet megadni)
3 "STO SENT" a már elküldött simre mentett kimenő smsek
4 "ALL" az összes típusú üzenet listázása egyszerre

folyt. köv. mert elég hosszú lett ez is. :)


csüt. júl. 19, 2007 14:42
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
cocka írta:
...


beraktam az előző sort is.


szer. júl. 18, 2007 20:23
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás 
Idézet:
Egyébként tényleg jó lenne egy összefoglaló az egészről,


OK, majd megpróbálok írkálni dolgokat. Viszont, ha jól tudom a CMGS-es küldéshez telefonszámot is meg kell adni és így az elején az üzenetközpont száma el is hagyható, meg akkor a címzett telefonszáma is.

Ebben az előre eltárolós módszerben viszont az a jó, hogy a küldéskor már semmit sem kell megadni, csak hogy az adott memóriahelyen lévő smst úgy kompletten minden különösebb utólagos beállítás nélkül küldje az smsc-nek.

És ez PDU módban megy vagy sima txtben? Mert én az AT+CMGF=1-et max. akkor használtam, ha az sms szövegét is el akartam olvasni, egyéb esetben PDU módot. És ott akkor mi a hossz? Az egésznek a hossza headerekkel együtt vagy ahonnan csak az adat rész kezdődik?


szer. júl. 18, 2007 19:13
Profil Privát üzenet küldése
a fórum lelke

Csatlakozott: szer. márc. 24, 2004 13:43
Hozzászólások: 12729
Tartózkodási hely: FLF
Hozzászólás 
volt már ilyen topic, illetve foglalkoztunk a témával. Én írtam is egy SMS kódolót. (PDU-t)

Azt nem értem, hogy miért nem megy neked az

at+cmgs=hossz, mert nekem megy, konkrétan így használom:

St:= CreatePDU(Telszam, StToGSMHUN(Szoveg));
Result:= (RightStr(Kiir('AT+CMGS=' + IntToStr(Length(St) div 2) + CrLf), 2) = '> ');
if Result
then begin
St:= '00' + St + #26;
Reply:= Kiir(St, LongWait);


Egyébként tényleg jó lenne egy összefoglaló az egészről, mert a szabvány, és annak leírása úgy ****, ahogy van.


A hozzászólást 1 alkalommal szerkesztették, utoljára T68m szer. júl. 18, 2007 20:21-kor.



szer. júl. 18, 2007 18:31
Profil Honlap
ezüst tag

Csatlakozott: szer. júl. 18, 2007 15:19
Hozzászólások: 89
Hozzászólás SMS - PDU kódolások
Sziasztok!

Nos remélem ilyen topic még nem volt. Ennek az lenne a lényege, hogy az SMS-ek PDU kódolásait megvitassuk. Mi mit jelent, miért úgy van stb.

Meg persze kérdést is szeretnék feltenni nektek, hátha tudja valaki rá a választ.

A neten utána keresgéltem a dolgoknak és sok mindent találtam is az smsek kódolásáról, viszont ilyen anyag nem igazán érhető el magyarul, ezért jött létre ez a topic. Miután a régi telómban beépített modem is van, megismerkedtem az AT parancsok zömével, de leginkább azokkal, amikkel smst lehet küldeni. Tehát elég a művelethez egy aktív SIM kártya, egy modemes mobilteló, hozzá egy adatkábel és egy terminál program, ahol az AT parancsokat tudod neki megadni. (talán még ez a legolcsóbb megoldás, tekintve, hogy egy GSM modem jóval drágább, az sms gatewayre előfizetés szintén elég borsos) Nekem soha nem akart működni az AT+CMGS=<szöveg hossza> kód, úgyhogy azt általában hanyagoltam. Helyette az AT+CMGL paranccsal kikerestem, hogy hol van a kártyán üres memóriahely és oda mentettem a PDU kódot az AT+CMGW-vel. Majd pedig az AT+CMSS=<memóriahely száma> kóddal elküldtem.

Hogy ne kelljen állandóan fejből összerakni a kódot írtam magamnak egy txt-t, amiben tételesen leírtam, hogy hogyan kell a normál és az összes többi speciális smseket elküldeni. Ezekből kiderül pl. hogy hogy lehet flash vagy villogó smst küldeni vagy egyéb adattartalmat pl. egy üres oplogót stb.. Itt az üzenetközpont száma történetesen a pannoné, de nyilván módosítható.

Íme:

SMS írás PDU-ban:
Hagyományos 7 bites szöveg írása:

07916302390090F931000B91630XXXXXXXFX0000FFA0<ide jön a 160 karakteres üzenet>

Hagyományos 8 bites szöveg írása:

07916302390090F931000B91630XXXXXXXFX0004FF8C<ide jön a 140 karakteres üzenet>

Hagyományos 16 bites (Unicode) szöveg írása: villogtató karakter be/ki:0001

07916302390090F931000B91630XXXXXXXFX0008FF8C<ide jön a 70 karakteres üzenet>

7 bites kódolású, azonnal megjelenő flash SMS:

07916302390090F931000B91630XXXXXXXFX0010FFA0<ide jön a 160 karakteres üzenet>

8 bites kódolású, azonnal megjelenő flash SMS:

07916302390090F931000B91630XXXXXXXFX0014FF8C<ide jön a 140 karakteres üzenet>

16 bites (Unicode), azonnal megjelenő flash SMS: villogtató karakter be/ki:0001

07916302390090F931000B91630XXXXXXXFX0018FF8C<ide jön a 70 karakteres üzenet>

7 bites hosszú SMS: Első rész: 1 SMS = max. 153 karakter

07916302390090F971000B91630XXXXXXXFX0000FFA0050003C70201<ez a 7 biten kódolt szöveg első része>

Második rész:
07916302390090F975000B91630XXXXXXXFX0000FFA0050003C70202<ez a 7 biten kódolt szöveg második része>

(A 050003stb. is 7 biten van bekódolva, de ezek mindig fixek, ezért nehéz az ilyen üzenetet bekódolni. Csak PDU spy-jal lehet.)

8 bites hosszú SMS: Első rész: 1 SMS = max. 134 karakter

07916302390090F971000B91630XXXXXXXFX0004FF8C050003C70201<ez a 8 bites szöveg első része=134 byte>

Második rész:
07916302390090F975000B91630XXXXXXXFX0004FF8C050003C70202<ez a 8 bites szöveg második része=134 byte>

16 bites (Unicode) hosszú SMS: Első rész: 1 SMS = max. 67 karakter

07916302390090F971000B91630XXXXXXXFX0008FF8C050003C70201<ez az Unicode szöveg első része=134 byte>

Második rész:
07916302390090F975000B91630XXXXXXXFX0008FF8C050003C70202<ez az Unicode szöveg második része=134 byte>

Operátor logó küldése: Méret: 72x14

07916302390090F975000B91630XXXXXXXFX00F5FF8C0605041582000012F61000480E01<OTA bitmap=126 byte>

Operátor logó küldése 2 SMS-ben: Méret: 72x14 Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B05041582000000030102013012F6100A00480E01<OTA bitmap=119 byte>

Második rész:
07916302390090F975000B91630XXXXXXXFX00F5FF8C0B0504158200000003010202<OTA bitmap=128 byte>

Operátor logó küldése 2 SMS-ben: Méret: 78x21 Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B05041582000000030102013012F6100A004E1501<OTA bitmap=119 byte>

Második rész:
07916302390090F975000B91630XXXXXXXFX00F5FF8C0B0504158200000003010202<OTA bitmap=128 byte>

Csoport logó küldése: Méret: 72x14

07916302390090F975000B91630XXXXXXXFX00F5FF8C0605041583000000480E01<OTA bitmap=129 byte>

Csengőhang küldése:

07916302390090F975000B91630XXXXXXXFX00F5FF8C06050415811581<ringtone=133 byte>

Hosszú csengőhang küldése: Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B0504158115810003E50201<ringtone=128 byte>

Második rész:

07916302390090F975000B91630XXXXXXXFX00F5FF8C0B0504158115810003E50202<ringtone=128 byte>

Operátor logó visszaállítása:

07916302390090F975000B91630XXXXXXXFX00F5FF1006050415820000300000000A00000001

Vagy:
07916302390090F975000B91630XXXXXXXFX00F5FF8C0605041582000000F00000480E01<üres OTA bitmap>

Szöveges képüzenet küldése: Méret: 72x28+121 8 bites karakter Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B0504158A0000000301030130000079<a 8 bites szöveg helye>02010000481C01<OTA bitmap első része>

Második rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B0504158A00000003010302<OTA bitmap második része>

Harmadik rész:

07916302390090F975000B91630XXXXXXXFX00F5FF8C0B0504158A00000003010303<OTA bitmap harmadik része>

Képernyővédő küldése: Méret: 72x28 statikus Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B0504158A000000030103013006010000481C01<OTA bitmap első része>

Második rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C0B0504158A00000003010302<OTA bitmap második része>

Harmadik rész:

07916302390090F975000B91630XXXXXXXFX00F5FF8C0B0504158A00000003010303<OTA bitmap harmadik része>

EMS: 72x14-es kép+121 karakter Első rész:

07916302390090F971000B91630XXXXXXXFX00F5FF8C8800031B0201128100090E<OTA bitmap=128 byte>0A

Második rész:

07916302390090F975000B91630XXXXXXXFX00F5FF8C0500031B0202<8 bites szöveg helye=134 byte>

Névjegykártya küldése:

07916302390090F975000B91630XXXXXXXFX00F5FF8C060504157D0000<8 bites szöveg helye>


Az X helyére a fogadó telefonszámát kell fordított félbyte-sorrendben írni.
Az FF --> érvényességi idő utáni rész változhat az üzenet hosszától függően.
Ahol csak két rész volt írva, ott előfordulhat 3 vagy több rész is.
A 0A a sorváltó karakter.

A következő üzenetben tételesen leírom majd, hogy melyik szám mit jelent stb.. illetve tervezem, hogy írok még a simen tárolt névjegyzékről is egy pár szót.

A kérdéseim pedig a következők:

Többször is kaptam már olyan smseket, amelyben a feladó száma helyén szöveg van. Ezt meg is néztem, a kérdéses rész a simen kódolva így néz ki: 0E D0 C3 A4 10 24 0C 3A 97
Itt az első bájt itt a feladó "számának" hossza félbájtokban, ha jól tudom ezt hívják WORD-nek
A D0 elvileg azt jelenti, hogy a feladó száma alfanumerikus érték.
A többi 7 bájt pedig a CIB BANK szavak 7 bites kódolása. És ugye azért 7 bájt, mert a CIB BANK az összesen 8 db szeptet vagyis 56 bit, azaz 7 bájt.
Na most nyilván a CIB BANK-ot telefonszámként nem lehet eltárolni, tehát ilyen smsre elvileg válaszolni sem lehet. A kérdésem viszont az, hogy hogyan lehet ilyen smst a PDU kódolás segítségével, GSM modemmel vagy telefonnal küldeni? Milyen kódot kellene használni egy SMS-SUBMIT üzenetben? Mert a kódban csak a címzett telefonszáma adható meg, ami viszont muszáj, hogy telefonszám legyen. :)

A másik kérdésem pedig az, hogy hogyan lehet a PDU kódolást felhasználva időzített smseket küldeni? Van-e valami kód rá, amit egy SMS-SUBMIT üzenetben megadva annak elküldését időzíteni lehet? Konkrét időpontot egy helyen találtam az SMS kódjában, de az az üzenet érvényességére vonatkozik. Megadható, hogy konkrétan (év/hó/nap/óra/perc) meddig legyen érvényes az üzenet. Ez az abszolút hivatkozás, elvileg a relatív használata a gyakoribb. Vagyis ha ki van kapcsolva x.y.-nak a telója, akkor az smsc meddig próbálgassa elküldeni az üzit. Gyanítom, hogy ezt a magyar szolgáltatók nem támogatják, bár sose lehet tudni. :)

Szóval mit szóltok a témához? :?:


szer. júl. 18, 2007 17:30
Profil Privát üzenet küldése
Hozzászólások megjelenítése:  Rendezés  
Hozzászólás a témához   [ 48 hozzászólás ] 

Ki van itt

Jelenlévő fórumozók: nincs regisztrált felhasználó valamint 14 vendég


Nem nyithatsz témákat ebben a fórumban.
Nem válaszolhatsz egy témára ebben a fórumban.
Nem szerkesztheted a hozzászólásaidat ebben a fórumban.
Nem törölheted a hozzászólásaidat ebben a fórumban.

Keresés:
Ugrás:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group.
Designed by ST Software for PTF.
Magyar fordítás © Magyar phpBB Közösség