Solange das Mobiltelefon mit dem Pocket PC verschmolzen ist (Phone Edition), versteckt Microsoft diesen Telefonbutler hinter drei Türen, auf denen TAPI, POOM und Interop-Layer steht. TAPI ist die Telefonieschnittstelle [Microsoft Übersicht zu TAPI 2.0], über die auch Sprachanrufe gemakelt werden, und POOM das Pocket-Outlook-Objektmodell [Microsoft Übersicht zum Pocket Outlook Object Model] für SMS. Erst entsprechende Interop-Layer [TAPI Interop von Alex Feinman/POOM Interop von In The Hand Ltd] ermöglichen C# oder VB den Zugriff auf diese Schnittstellen. Läuft die Kommunikation zwischen PDA und Mobilfunker hingegen über einen seriellen Kanal, so sitzt der Butler hinter nur einer Tür mit der Aufschrift AT-Protokoll. Dabei ist es gleichgültig, wie das Handy angebunden ist, solange der Pocket PC einen Zugriff auf den Kanal über COMx: bereitstellt. Dieser Artikel stellt die Nutzung des AT-Protokolls unter Steuerung des Compact Framework vor.

Mein TA spricht AT

Die Wurzeln des heute gültigen AT-Protokolls gehen in die Zeit zurück, in der zwei digitale Systeme über ein 25-poliges serielles Kabel Daten miteinander austauschten. Wurde die Entfernung zwischen den beiden Partnern zu groß, so wurde das öffentliche analoge Telefonnetz als Verlängerungskabel verwendet. Ein Modem auf jeder Seite sorgte dafür, dass digitale und analoge Übertragungsstrecken zusammenpassten. Damit die Verbindung nicht jedes Mal, bevor der Datenaustausch losging, von Hand über das Telefon aufgebaut werden musste, statteten die Modem-Hersteller ihre Geräte mit der Fähigkeit aus, die Telefonnummer des Partners wie ein normales Telefon zu wählen. Während in Europa lange Zeit das Impulswählverfahren vorherrschte, kam in Amerika das Mehrtonwählverfahren zum Einsatz, das zwischenzeitlich auch in den verbleibenden europäischen Analognetzen vorherrscht. War das Modem nicht Ursprung, sondern Ziel eines Verbindungsaufbaus, so musste es eingehende Anrufe erkennen und annehmen oder ablehnen können. Und ebenso wichtig, wie der Einbau dieser Telefonfähigkeiten in Modems, war deren Steuerung über das angeschlossene digitale System. Da viele der damaligen digitalen Systeme noch „dumme Terminals“ waren, die keinerlei Programme lokal ausführen konnten, sollten die Befehle zur Fernbedienung der Modems auch für Menschen einfach zu merken sein. Den Entwicklern des Hersteller Hayes gelang dies mit den AT-Kommandos am besten. Diese Kommandos wurden über dieselbe serielle Schnittstelle übermittelt, über die später der Datenaustausch lief, und begannen immer mit der Zeichenkombination AT, der unmittelbar das spezifische Kommando folgte – vielmehr folgte der erste Buchstabe des Kommandos D für Dial, A für Accept und H für Hook oder Hangup. Sollte ein Kommando ein oder mehrere Argumente benötigen, so folgten diese unmittelbar auf die Kommandokennung. So wählt das AT-Kommando ATD05111234567 die Teilnehmerkennung 1234567 im Ortsnetz Hannover 0511 und versucht den Aufbau einer Datenverbindung. Die Gegenstelle nimmt diesen Anruf durch ATA entgegen und beendet die Verbindung mit ATH. Das Modem meldet den Erfolg oder Misserfolg eines Kommandos durch OK oder ERROR. Gerade für Datenverbindungen muss eine Reihe von Einstellungen erfolgen, damit die Partner in derselben Geschwindigkeit und derselben Kompression miteinander sprechen, da ansonsten nur Kauderwelsch ausgetauscht und ein Arbeiten unmöglich wird. Diese Aspekte vernachlässigen der Artikel und die zugehörige Anwendung, weil hier Sprachverbindungen und der Austausch von Kurznachrichten im Vordergrund stehen sollen.

Damit der Anrufer nicht eine Daten-, sondern eine Sprachverbindung aufbaut, muss der Rufnummer noch ein Semikolon angefügt werden: ATD05111234567;. Das Modem quittiert dieses Kommando unmittelbar mit OK und meldet damit, dass die geforderte Aktion erfolgreich abgeschlossen, der Verbindungsaufbau also an das Telefonnetz weitergeleitet wurde und jetzt auf die Reaktionen der Gegenstelle gewartet werden muss. Das Schöne an AT-Befehlen ist ihre Einfachheit und große Verbreitung, da die Telekommunikationsbranche den Hayes-Dialekt als Industriestandard anerkannt und ihn in neueren Protokollen weiterentwickelt hat. Seitdem immer mehr Telefonnetze als digitale Netze ausgeführt werden – ISDN, GSM und UMTS sind drei bekannte Vertreter dieser Entwicklung – benötigt die Kopplung von digitalen Endgeräten über diese Netze keine Wandlung von digitalen in analoge Signale und umgekehrt mehr. Von daher heißen die Modems der digitalen Netze Terminal-Adapter (TA), da sie nach wie vor serielle Datenkanäle transparent über die Telefone der Partner miteinander verbinden. Und da es immer noch viele Anwender gibt, die die Einfachheit des AT-Protokolls schätzen, haben die Entwickler der GSM-Technologie im Gegensatz zu ISDN entschieden, dass die TA ein erweitertes AT-Protokoll beherrschen sollen, das die neuen Fähigkeiten von Netzen und Endgeräten steuert. Auch bei der Weiterentwicklung in Richtung UMTS haben sich die Entwicklungspartner erneut auf eine Erweiterung des AT-Protokolls verständigt, die sie in umfangreichen Dokumenten spezifiziert und veröffentlicht haben [Dokumentationsbereich des 3rd Generation Partnership Project]. Dabei wurde immer eine Abwärtskompatibilität beachtet, die ein Zusammenspiel der modernen Mobiltelefone mit Altanwendungen sicherstellt, solange ein serieller Kanal zwischen Anwendung und TA aufgebaut werden kann. Angebunden über einen virtuellen Bluetooth-Kanal (Serial Port Profile) wählt ein GSM-Handy immer noch Teilnehmer 1234567 im Ortsnetz Hannover, wenn eine Anwendung ATD0511123456; über den Kanal schickt und antwortet mit OK, sobald die Verbindungsanforderung an das GSM-Netz übermittelt wurde.

Mobile Gegenstellen

Dreh- und Angelpunkt für die Kommunikation über serielle Kanäle ist die Port-Klasse aus dem OpenNETCF.IO.Serial-Namespace des Smart Device Framework in der Version 1.4 [Udo Killermann, Zauberei – Tastatur und Maus mit einem Pocket-PC simulieren, in: Der Entwickler 4.2005]. Ein Port-Objekt ist immer genau einer seriellen Schnittstelle auf dem Pocket PC oder einem anderen Smart Device zugeordnet. Dabei ist es für die Programmierung unerheblich, ob COM8: mit seiner Gegenstelle über Kabel, Infrarot oder Bluetooth verbunden ist, solange das Serial-API eingehalten wird. Daten, die über die serielle Schnittstelle geschickt werden sollen, müssen als Byte-Folge an die Output-Eigenschaft übergeben werden. Also muss sich die Anwendung um eine geeignete Kodierung der Daten kümmern, was bereits bei einer einfachen Zeichenkette, die in einem String steckt, viele Möglichkeiten für Fehler liefert. Ebenso bietet das Port-Objekt die eingetroffenen Daten über die Input-Eigenschaft als Byte-Folge an, die von der Anwendung für die Weiterverarbeitung in das gewünschte Format gebracht werden müssen. Da die Behandlung von Sonderzeichen (z.B. öäüßÖÄÜ) über ASCIIEncoding fehlschlug, muss die Anwendung über den Aufruf von Encoding.GetEncoding die korrekte Codepage anfordern. (Listing 1)

Listing 1:

1. Using OpenNETCF.IO.Serial;
2. Using System.Text;
3. …
4. Encoding myEncoding=Encoding.GetEncoding(850);
5. Port myPort=new Port("COM3:");
7. myPort.Open();
9. string messageStr="Hänschen klein\r\n";
10. …
11. // Ausgabe von Text mit Sonderzeichen
12. myPort.Output=myEncoding.GetBytes(messageStr);
13. …
14. // Einlesen von Text mit Sonderzeichen
15. int messageLen=myPort.InBufferCount;
16. messageStr= myEnc.GetString(myPort.
17. Input,0,messageLen);

Die Codepage (hier: 850) ist entscheidend für die richtige Sonderzeichenbehandlung

Für den Empfang der Antworten registriert die LineControl-Klasse ihre QueuePump-Methode als DataReceived-Delegaten des Port-Objektes. Damit ruft der Empfangs-Thread des Port-Objektes QueuePump auf, sobald mehr Bytes empfangen wurden als in seiner RThreshold-Eigenschaft festgelegt wurden. Für die weitere Entwicklung der Empfangslogik muss immer bedacht werden, dass die mit dem DataReceived-Delegaten verkettete Logik im Kontext des Empfangs-Thread aufgerufen und damit nebenläufig zur Anwendung ausgeführt wird.

Listing 2:

1. void processAlertQueue(Queue feedQ)
2. {
3. // just read each and every message from the reception queue
4. // (owned by PhoneControl) and
5. // stuff it into the answer queue (owned by form)
6. while(feedQ.Count>0)
7. answerQ.Enqueue((string)feedQ.Dequeue());
8. // invoke EventHandler to update form’s properties
9. this.Invoke(new EventHandler(this.update_textBox2));
10. }

Netzzustände

Damit wären alle bisher bekannten Anforderungen durch ein bisschen Anwendungslogik in der LineControl-Klasse erfüllt – mit der eine Anwendung AT-Kommandos an den TA übertragen kann und anschließend den Status über einen Delegaten gemeldet bekommt und man kann diesen auswerten. Bisher erhält jedoch die Anwendung keinerlei Informationen über einen Anrufversuch, schließlich hört sie den TA nicht klingeln. Dieser sendet bei eingehenden Anrufen in Intervallen die Zeile RING über den seriellen Kanal, solange die Gegenstelle nicht auflegt. Diese Klingelzeilen heißen „unaufgeforderte Nachrichten“ (unsolicited messages), mit denen das Mobiltelefon über den TA Zustandsinformationen an die Anwendung übermittelt. Moderne Protokolle sprechen davon, dass die Anwendung Nachrichten über bestimmte Zustandsveränderungen abonniert und so über das Eintreten dieser Veränderung informiert wird. Einige Abonnements sind im Grundzustand des TA fest eingerichtet und können auch nicht abbestellt werden, während zusätzliche Abonnements bei Bedarf eingerichtet und auch wieder abbestellt werden können. Für den Empfang von SMS muss die Anwendung zusätzliche Benachrichtigungen abonnieren (Listing 3 zeigt exemplarische Benachrichtigungen).

Neben der Klingelanzeige ist außerdem NO CARRIER im Standardabo enthalten, mit dem das Netz über das Verbindungsende oder einen fehlerhaften Verbindungsaufbau („kein Anschluss unter dieser Nummer“) informiert. Welcher von beiden Zuständen eingetroffen ist, muss die Anwendung entscheiden, die diese Zeile auswertet. Da diese Auswertungen nicht mehr zur Basissteuerung des TA gehören, wurden sie in die Klasse PhoneControl ausgelagert, die sich zusätzlich um die Komposition der Kommandozeilen und einige Grundeinstellungen kümmert.

Listing 3:

1. // Grundzustand
2. RING
4. // Internationale Rufnummer und Anrufart
5. +CLIP: "+49511123456", 145
6. +CRING: VOICE
8. // Nationale Rufnummer und Anrufart
9. +CLIP: "0511123456", 129
10. +CRING: VOICE
12. // SMS wird mit Kopfzeile weitergemeldet
13. +CMT: "+491707923900",,"dasdasdasda"
14. The quick brown fox jumps over the lazy dog! üöäßÜÖÄ

Benachrichtigung über eingehende Sprachanrufe und SMS

Erweiterte Zustände

Ein Klingelzeichen, das ohne zusätzliche Informationen übermittelt wird, weckt den Argwohn des Angerufenen. Schließlich unterdrückt der Anrufer die Übermittlung seiner Teilnehmerkennung und auch die Information, ob es sich um eine Sprach-, FAX- oder Datenverbindung handeln soll. Ein digitales Telefonnetz übermittelt diese Infos und wenn die entsprechenden Abos vereinbart sind, übermittelt das Telefon diese Zusatzinfos auch an eine Anwendung. Die Anwendung registriert ihr Interesse an Rufnummern durch die Übermittlung des Kommandos AT+CLIP=1. Das Format dieses Kommandos identifiziert es als moderne Erweiterung für Mobiltelefonie, die alle durch die Zeichenfolge AT+C eingeleitet werden und die eigentlichen Kommandos als Kombination aus mehreren Alpha-Zeichen abkürzen. CLIP steht als Abkürzung für die Eigenschaft Cellular Line Identification Protocol, die durch die nachfolgende Zuweisung aktiviert wird. Bei eintreffenden Anrufen erscheint nun im selben Intervall eine zusätzliche Zeile, die mit +CLIP: beginnt, die Rufnummer des Anrufers enthält und einen Hinweis kodiert, ob die Rufnummer in nationaler oder internationaler Notation übermittelt wird. Ein Abo für die Anrufart wird durch das Setzen der Eigenschaft Cellular Result Code registriert: AT+CRC=1. Diese Eigenschaft tauscht die Standardklingel RING gegen eine +CRING:-Zeile aus, die VOICE, FAX und verschiedene Datenarten unterscheidet. Wenn sowohl CLIP als auch CRC aktiviert sind, erhält die Anwendung ausreichend Informationen über die Gegenstelle, auf deren Basis sie über Annahme oder Ablehnung entscheiden kann. Textnachrichten SMS sind in Europa eng mit GSM-Mobiltelefonen verbunden, sodass es nicht verwundert, dass alle zugehörigen Kommandos mit AT+C beginnen. Ein Mobiltelefon empfängt in seiner Grundeinstellung die Textnachrichten, sortiert diese in den voreingestellten Speicherbereich und schweigt darüber. In dieser Einstellung muss eine Anwendung in regelmäßigen Intervallen diese Speicherbereiche durchsuchen und empfangene Texte gemäß den eingestellten Regeln löschen oder beibehalten. Dieses Vorgehen setzt eine eingehende Analyse voraus, welche Speicherbereiche das jeweilige Mobiltelefon unterstützt, damit die Anwendung diese anschließend überwachen kann. Glücklicherweise geht es auch einfacher, indem die Anwendung eine Benachrichtigung über eingehende SMS abonniert. Dieses Abo wird über die Optionen des Kommandos Cellular New Message Indication (CNMI) festgelegt. Dabei wird der TA so konfiguriert, dass er die Anwendung direkt informiert – er erfährt darüber hinaus, in welcher Form die SMS-Details übermittelt werden sollen. Mit dem Kommando AT+CNMI=2,2 teilt die Anwendung mit, dass neu eingetroffene SMS ohne Verzögerung übermittelt werden sollen. In dieser Einstellung schickt der TA für jede SMS zwei Zeilen, deren erste mit +CMT: beginnt und zusätzlich die Absenderkennung und den Absendezeitpunkt als Strings übermittelt. Die zweite Zeile enthält ohne weitere Markierung die SMS. Das Kommando AT+CMGF=1 schaltet den TA dauerhaft in den Textmodus um. Ansonsten werden die Textnachrichten im Protocol-Data-Unit-Modus (PDU) übermittelt, der für den Austausch von binären Inhalten (z.B. MMS, Klingeltöne) eingesetzt wird. So konfiguriert, erhält die Anwendung für jede eingehende SMS genügend Informationen (Listing 3), die sie zur weiteren Verarbeitung heranziehen kann.

Textnachrichten

SMS sind in Europa eng mit GSM-Mobiltelefonen verbunden, sodass es nicht verwundert, dass alle zugehörigen Kommandos mit AT+C beginnen. Ein Mobiltelefon empfängt in seiner Grundeinstellung die Textnachrichten, sortiert diese in den voreingestellten Speicherbereich und schweigt darüber. In dieser Einstellung muss eine Anwendung in regelmäßigen Intervallen diese Speicherbereiche durchsuchen und empfangene Texte gemäß den eingestellten Regeln löschen oder beibehalten. Dieses Vorgehen setzt eine eingehende Analyse voraus, welche Speicherbereiche das jeweilige Mobiltelefon unterstützt, damit die Anwendung diese anschließend überwachen kann. Glücklicherweise geht es auch einfacher, indem die Anwendung eine Benachrichtigung über eingehende SMS abonniert. Dieses Abo wird über die Optionen des Kommandos Cellular New Message Indication (CNMI) festgelegt. Dabei wird der TA so konfiguriert, dass er die Anwendung direkt informiert – er erfährt darüber hinaus, in welcher Form die SMS-Details übermittelt werden sollen. Mit dem Kommando AT+CNMI=2,2 teilt die Anwendung mit, dass neu eingetroffene SMS ohne Verzögerung übermittelt werden sollen. In dieser Einstellung schickt der TA für jede SMS zwei Zeilen, deren erste mit +CMT: beginnt und zusätzlich die Absenderkennung und den Absendezeitpunkt als Strings übermittelt. Die zweite Zeile enthält ohne weitere Markierung die SMS. Das Kommando AT+CMGF=1 schaltet den TA dauerhaft in den Textmodus um. Ansonsten werden die Textnachrichten im Protocol-Data-Unit-Modus (PDU) übermittelt, der für den Austausch von binären Inhalten (z.B. MMS, Klingeltöne) eingesetzt wird. So konfiguriert, erhält die Anwendung für jede eingehende SMS genügend Informationen (Listing 2), die sie zur weiteren Verarbeitung heranziehen kann.

Weitere Ausbaustufen

Die Weiterverarbeitung und Auswertung der Antwortzeilen erfolgt mit Standard-String-Operationen und regulären Ausdrücken und ist auf keinen Fall spezifisch für das AT-Protokoll. Der interessierte Leser kann dies im zugehörigen Programmcode nachvollziehen. Das mitgelieferte Projekt veröffentlicht im Namespace UKiller.IO.Phone (in PhoneControl. cs) die Klasse PhoneControl, deren Methoden und Eigenschaften einigen Komfort beim Umgang mit dem Mobiltelefon bieten. So verbergen Dial, AcceptCall und HangUpCall die notwendigen AT-Kommandos für die Sprachtelefonie und Send-SMS kapselt die Kommandofolge für die Übermittlung von Textnachrichten. Daneben verbergen die Eigenschaften Echo, Verbose, Clip, Crc, Cnmi und SMSText, die als bool ausgelegt sind, ebenfalls die hierfür notwendigen Kommandozeilen. Eine Anwendung muss jetzt nur noch einen Delegaten für handleModemAlert-Event registrieren und schon erhält sie die Benachrichtigungszeilen des TA zur Verarbeitung weitergeleitet. Ferner enthält das Projekt noch eine Dialogoberfläche (phoneButler.cs), die ein PhoneControl-Objekt im Einsatz zeigt. Vom zu Beginn gewünschten Telefonbutler trennt uns jetzt noch eine Regeleinheit, die Inhalt eines weiteren Artikels werden kann. Getreu dem Motto: „Wenn Du das aktuelle Problem nicht lösen kannst, such Dir ein neues Problem!“ noch folgender Hinweis: Selbst Geräte der Phone Edition können durch entsprechende Steuerbefehle mit dieser leichtgewichtigen Lösung zum Laufen gebracht werden (Kasten „Verborgener TA“).

Zusammenspiel von Pocket-PC und Mobiltelefon