SendXMS^® V11.03 Handbuch

SendXMS ist das führende, skalierbare Programm zum Versenden und Empfangen von Kurznachrichten (SMS, EMS, MMS) an Mobiltelefone oder Pager mittels der Protokolle TAP, EMI/UCP (CMG), SMPP (Logica), CIMD (Nokia), OIS (SMS2000, SEMA), ES 201 912, OneAPI (GSMA) (SMS, MMS, Location, Capability, Payment), GSM, HTTP, MM1, MM7 oder EAIF (Nokia). SendXMS ist ebenfalls in der Lage Sprachnachrichten aufzunehmen/abzuspielen.

SendXMS (Standard-Edition) hat u.a. folgende Eigenschaften:

MNP fähig (Mobile Number Portability)
zusätzliche graphische Oberfläche durch Java-Frontend
verfügbar auf vielen verschiedenen Betriebssystemen
TAP-Protokoll
AIM-Erweiterungen für TAP
EMI/UCP-Protokoll (CMG)
SMPP-Protokoll (Logica)
OIS-Protokoll (SMS2000, SEMA)
CIMD-Protokoll (Nokia)
UAP-Protokoll (Huawei)
SMS im Festnetz (ETSI ES 201 912 (Protokoll 1 und 2); nur mit CAPI oder VoIP)
MMS im Festnetz (MMS-F)
Unterstützung für MM1 (WAP 1.x und 2.0)
Unterstützung für binäre Nachrichten¹⁾
Unterstützung für UCS-2 (Unicode; multibyte Zeichen) Nachrichten (auch Emojis)
Unterstützung für WAP Push¹⁾
Unterstützung für USSD¹⁾
Senden von DTMF-Sequenzen
GSM 07.05 (MO und MT; PDU-Mode)
Empfangen von Nachrichten (GSM, ETSI ES 201 912, MM1, MMS-F und UUS; in Professional-Edition auch mit UCP, SMPP, OIS, CIMD, OneAPI, EAIF)
UUS (User-User-Signaling) mit CAPI 2.0 (kostenloser Versand im D-Kanal; nur falls dies von verwendeter CAPI und Provider unterstützt wird)
bestätigte Übertragung von SMS
Statusabfrage von zuvor übertragenen SMS¹⁾
Löschen von zuvor übertragenen aber noch nicht ausgelieferten SMS¹⁾
direkte Anzeige (Flash SMS) auf dem Display des empfangenden Telefons möglich
Unterstützung der Option Reply-Path-Request
Unterstützung für lange Kurznachrichten (Aufteilen/Zusammensetzen einer Nachricht in bis zu 255 SMS)¹⁾
Emulation der CityRuf-Terminalschnittstelle
zeitversetztes Senden¹⁾
VoIP Unterstützung
CAPI 2.0 Unterstützung
RemoteCAPI Unterstützung (BINTEC-Erweiterung) (auch für Unix)
RemoteCAPI Unterstützung (AVM-Erweiterung; CAPIoTCP) (auch für Unix)
TAPI 2.0 Unterstützung
Aufzeichnen und Abspielen von Sprachnachrichten
Definition von beliebig vielen Zeichenübersetzungstabellen möglich
Unterstützung des erweiterten GSM-Zeichensatzes
Konvertierungsprogramm zum Lesen von .bmp, .png, .gif, .mng, .rtx, .rtttl, .imy, .htm, .mid, .smil und .xml (.xml ab Professional-Edition) Dateien¹⁾
Unterstützung für Nachrichten mit unterschiedlichen Prioritäten¹⁾
Unterstützung für (Sprach-, Fax, Email- und andere) 'Nachrichten verfügbar' Informationen (MWI)
Unterstützung für EMS 4.x und 5.x (Bilder, Melodien, Animationen, ...); mit EMS 5.x auch farbig bzw. polyphon
Unterstützung für SMIL
Unterstützung für Smart Messaging (wie z.B. Klingeltöne, Operator-Logos, Visitenkarten), auch für CDMA/TDMA¹⁾
Unterstützung für Nokia, EMS, Motorola und Sagem Klingeltönen¹⁾
Unterstützung für Siemens OTA Download Service¹⁾
beliebig konfigurierbar für weitere Dienstanbieter mit TAP, EMI/UCP, SMPP, OIS, CIMD, ES 201 912, MM1, MM7, MMS-F, EAIF oder GSM 07.05.
vorkonfiguriert für viele Provider in der ganzen Welt
Nachricht kann über Kommandozeile oder aus einer Datei angegeben werden (Batchmodus möglich)
einfache Installation und Konfiguration
einfache Einbindung in Email-Systeme, WWW-Server und/oder SNMP Überwachung
Gerät (Modem, ISDN-Karte) wird zwischen den Wahlversuchen nicht blockiert
Konfiguration für die meisten Modems (seriell, USB oder Ethernet), ISDN-Karten und ISDN-Terminaladapter möglich
Gebührenanzeige (CAPI)
Definition für mehrere Geräte möglich (falls eines nicht verfügbar ist, wird das nächste benutzt)¹⁾
Führen einer Protokolldatei (Logdatei) bzw. Protokollierung über syslogd¹⁾
auswertbare Returncodes (Errorcode oder Anzahl erfolgreich bearbeiteter Nachrichten)¹⁾
Definition der Anzahl der Wahlwiederholungen möglich¹⁾
frei definierbare Pause zwischen den Wahlversuchen¹⁾
Telefonbuch: anstelle der Telefonnummer können definierte Kürzel benutzt werden¹⁾
Versenden von Nachrichten an mehrere Empfänger auch über verschiedene Provider¹⁾
Versenden von Nachrichten an mehrere Empfänger während einer einzelnen Verbindung¹⁾
Multithreaded
Format von ein-/ausgehenden Nummern kann über Filter mit reguläre Ausdrücke automatisch gewandelt werden

Die Server-Edition hat alle Eigenschaften der Standard-Edition und zusätzlich noch folgende:

kann unter Windows als Service installiert werden¹⁾
über einen Userexit kann automatisch ein externes Programm (auch Batch-/Scriptfile), eine Funktion in einem SharedObject/DLL oder eine Methode einer Java-Klasse gestartet werden, wenn eine Nachricht empfangen oder gesendet wurde¹⁾
Nachrichten können gespoolt und im Servermodus mit einer minimalen Verbindungsanzahl, z.B. während günstiger Tarifzeiten, versendet werden¹⁾
White- und Blackliste (Nummern an die Nachrichten gesendet bzw. nicht gesendet werden dürfen)¹⁾
Allow- und Denyliste (Benutzer die SendXMS benutzen bzw. nicht benutzen dürfen)¹⁾

Die Professional-Edition hat alle Eigenschaften der Server-Edition und zusätzlich noch folgende:

Unterstützung für Metriken (z.B. Prometheus)¹⁾
Unterstützung für SSL (OpenSSL notwendig)¹⁾
Unterstützung für SMS über HTTP (z.B. Twitter)¹⁾
Unterstützung (SMS, MMS, Location, Capability, Payment) für OneAPI (GSMA)¹⁾
Unterstützung SIP Extension for Instant Messaging (RFC3428)
Unterstützung für MM7¹⁾
Unterstützung für EAIF (Nokia)¹⁾
Unterstützung für asynchrone Kommunikation (Windowing)¹⁾
Unterstützung von Großkundenzugänge¹⁾
Unterstützung für permanente Verbindungen¹⁾
Unterstützung für KeepAlive (Enqire Link)¹⁾
Möglichkeit zur Angabe von Zeiten, zu denen bestimmte Nachrichten (z.B. Werbung) nicht versendet werden dürfen¹⁾
Compiler für WAP-Push Nachrichten (WAP/OMA Client Provisioning, OMA (SyncML) Device Management (Package#0), OMA Digital Rights Management (DRM) 1.0, OMA E-Mail Notification (EMN), MMS Notification, Service Indication (SI), Service Loading (SL), (Nokia/Sony Ericsson) OTA Service Settings, Bookmarks und SyncML Settings)¹⁾
Datendurchsatz (pro Session) mit X.25 oder TCP/IP über 500 SMS/Sekunde möglich, mit GSM (pro Modem) bis zu 1200 SMS/Stunde und mit X.31 (D-Kanal) bis zu 18000 SMS/Stunde.
Empfangen von Nachrichten (GSM, UCP, SMPP, OIS, CIMD, ETSI ES 201 912, OneAPI, MM1, MM7, MMS-F, EAIF)¹⁾
Unterstützung von SNMPv2 Traps¹⁾
X.25-Unterstützung¹⁾
X.31-Unterstützung¹⁾
TCP/IP-Unterstützung (IPv4 und IPv6)¹⁾
UDP-Unterstützung¹⁾
SCTP-Unterstützung¹⁾
RFC1086 (TCP/IP-X.25 Bridge) Unterstützung¹⁾
Priorisierung von Spooldatein möglich
Schreiben von Statistik-/Abrechnungsdaten¹⁾
Spool-API (standardmäßig werden Spooldateien im Filesystem abgelegt/gelesen; durch dieses API kann dies z.B. auf eine Datenbank umgelenkt werden) ¹⁾
Implementierung des Spool-APIs via ODBC enthalten (mit Beispielen für MySQL/MariaDB, PostgreSQL, Oracle und Microsoft SQL Server)¹⁾

Die VXMSC-Edition hat alle Eigenschaften der Professional-Edition und zusätzlich noch folgende:

Funktionalität (entsprechend der Professional-Edition) einer virtuelle SMSC/MMSC (VXMSC)¹⁾
kann als XMS-Gateway benutzt werden¹⁾
Annahme/Verteilung von XMS (per TCP) von/an beliebige andere Programme per UCP, SMPP, CIMD, OIS, MM7 oder EAIF¹⁾

¹⁾nur in der registrierten Version verfügbar

Lizenz

SendXMS darf kostenlos für eine Dauer von 20 Tagen getestet werden. Danach muss SendXMS für eine dauerhafte Nutzung lizenziert werden. Jeder Anwender erkennt unsere Lizenz- und Nutzungsbedingungen an.

Open-Source-/Drittanbieter-Software

Je nach Konfiguration und Verwendung kann es sein, dass SendXMS teilweise auch Open-Source-/Drittanbieter-Software verwendet. Solche Open-Source-/Drittanbieter-Software besitzt i.d.R. eigene Urheberrechte und Lizenzbedingungen, wird i.d.R in Form einer Shared-Library/DLL verwendet und muss i.d.R. nicht gesondert installiert werden. Im Folgenden wird eine (nicht notwendigerweise vollständige) Liste solcher Software aufgeführt (in alphabetischer Reihenfolge):

Software	URL	Lizenz
Info-ZIP	http://www.info-zip.org	http://www.info-zip.org/pub/infozip/license.html
libiconv	http://www.gnu.org/software/libiconv/	https://www.gnu.org/licenses/gpl-3.0.en.html
libmng	http://www.libpng.org/pub/mng/	http://github.com/LuaDist/libmng/blob/master/LICENSE
libre	http://creytiv.com/re.html	http://opensource.org/licenses/bsd-license.php
libTomCrypt	http://www.libtom.net/LibTomCrypt/	http://github.com/libtom/libtomcrypt/blob/develop/LICENSE
OpenSSL	http://www.openssl.org/	http://www.apache.org/licenses/LICENSE-2.0.txt
OSHDLC	http://github.com/bgb043/oshdlc	https://www.gnu.org/licenses/gpl-3.0.en.html
prometheus-client-c	https://github.com/digitalocean/prometheus-client-c	http://www.apache.org/licenses/LICENSE-2.0
zlib	http://zlib.net/	http://zlib.net/zlib_license.html

Installation

Laden sie für das zu verwendende Betriebssystem ein entsprechendes Installationsarchiv auf ihren Rechner und führen sie die geladene Datei aus (ggf. (Unix) die geladene Datei vor dem Ausführen mit 'gunzip -N ...' oder mit 'gzip -d ...' entpacken und mit 'chmod +x ...' ausführbar machen). Sofern Java auf dem System installiert ist wird ein Java Installer mit graphischer Oberfläche und ansonsten ein Konsoleinstaller gestartet. Durch Aufruf von 'setup --java' bzw. 'setup --console' kann man den jeweiligen Installationsmodus vorgeben. Das Installationsprogramm fragt nach den wichtigsten Parametern (um SendXMS zu testen) und kopiert die benötigten Dateien in ein anzugebendes Verzeichnis.

Nachdem setup durchlaufen wurde sollten Sie die Datei sendxms.pro editieren und dort alle von Ihnen nicht benötigten Providerdefinitionen löschen.

Testen Sie vor einem automatischen Aufruf von SendXMS unbedingt, ob der Auflegemechanismus (ESCAPE-Sequenz oder DTR zurücksetzen) funktioniert.

In den Unix-Versionen muss der Owner der Datei sendxms ausreichende Rechte besitzen um das definierte Device zu benutzen,um Dateien anzulegen (Spoolverzeichnis, Lockverzeichnis,...) und es sollte das Set-User-ID Bit gesetzt sein.

Konfiguration

In der Regel müssen nach der Installation mit dem Setup-Programm keine weiteren Konfigurationen zur Nutzung von SendXMS durchgeführt werden. Im einfachsten Fall kann nach der Installation bereits durch das Kommando 'sendxms <phone> <msg>' eine Nachricht versendet werden. SendXMS bietet jedoch die Möglichkeit durch seine Konfigurationsdateien und durch Kommandozeilenparameter das Programm auf die unterschiedlichsten Anwendungsfälle anzupassen. Alle Dateien müssen in UTF-8 kodiert sein.

In der Datei sendxms.cfg wird die allgemeine Konfiguration des Programms festgelegt.

In der Datei sendxms.pro werden die verschiedenen Provider (welches Provider benutzt TAP, UCP, ..., über welche Telefonnummer wird die Nachricht versendet und welche Vorwahlen haben die Nummern des entsprechenden Providers) konfiguriert.

In der Datei sendxms.pbk werden Kürzel zum Wählen mittels symbolischer Namen anstelle von Telefonnummern definiert.

Kommentare werden durch einen Strichpunkt (;) eingeleitet.

Sämtliche Konfigurationsdateien werden standardmäßig in dem Verzeichnis gesucht in dem auch das Programm selbst installiert ist. Dies gilt nicht, wenn per Kommandozeile explizit eine Konfigurationsdatei angegeben wurde, bzw. wenn die Umgebungsvariable SendXMS gesetzt wurde. In letzterem Fall wird der Wert dieser Umgebungsvariable als Verzeichnis für die Konfigurationsdateien benutzt.

sendxms.cfg

Hier wird im Kapitel [SendXMS] die allgemeine Konfiguration vorgenommen. Im Kapitel [Device] werden die Kommunikationsschnittstellen konfiguriert und im Kapitel [XMSGUI] wird die Nutzung des graphischen Frontends konfiguriert. Des Weiteren können in den Kapiteln [Allow] und [Deny] Benutzerbeschränkungen, bzw. in [Whitelist] und [Blacklist] Telefonnummern, an die Nachrichten versendet bzw. nicht versendet werden dürfen, definiert werden. Im Kapitel [SetEnv] können optional für SendXMS-Prozesse Umgebungsvariablen gesetzt oder geändert werden. In den Kapiteln [Audio Mime Types], [Image Mime Types] und [Video Mime Types] werden Dateiextensions für einen entsprechenden MIME Typ definiert. Optional können noch in den Kapiteln
[SSL] die Einbindung von OpenSSL,
[PPP] Parameter für PPP Verbindungen,
[ODBC] die Zugangsdaten zu einer ODBC-Datenbank zur Nutzung des integrierten ODBC-Spool-APIs,
[SNMP] die Benutzung von SNMP Traps
[Metrics] die Benutzung von Metriken (z.B. Prometheus)
und in
[Java] Parameter zur Nutzung einer Java VM (Java-Userexit)
konfiguriert werden.

Das Kapitel [Device] kann in der registrierten Version beliebig oft wiederholt werden. Beim Verbindungsaufbau wird immer versucht das als erstes definierte Device zu benutzen. Ist dieses Device gesperrt oder reagiert nicht, so wird das nächste benutzt. Sollte der Verbindungsaufbau mit allen Devices nicht funktionieren, so wird eine Pause (REDIALDELAY) eingelegt und das Ganze wiederholt (REDIALCOUNT).

Im Kapitel [SendXMS] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen.

BinLocks=false
Gibt an, ob die Lockdatei binär (true) oder ASCII angelegt wird (nur UNIX).

CachePhonebook=true
Gibt an, dass der Inhalt der Phonebook-Datei (Aliase) gepuffert werden soll. Im 'Normalfall' ist dies nicht notwendig. Dieser Parameter sollte nur benutzt werden wenn z.B. Spooldateien vom Anwender selbst generiert werden und in den Spooldateien ein Alias (anstatt einer Empängernummer) verwendet wird (nur in Professional-Edition und höher).

CountryCode=+49
Gibt die internationale Länderkennung (z.B. '+49' für Deutschland oder '+1' für Nord-Amerika) an. Dieser Parameter muss unbedingt korrekt angegeben werden, damit SendXMS eine zu wählende Nummer richtig bilden kann (ist dieser Wert falsch angegeben, wird bei der Anwahl einer nationalen Nummer die Länderkennung mitgewählt, was nicht funktioniert).

DontReassemble=true
Verhindert das Zusammensetzen von ankommenden langen Kurznachrichten (die in mehreren Teilnachrichten empfangen werden).

EnableVersionCheck=true
Schaltet eine automatische Überprüfung auf eine neuere SendXMS-Version ein. Falls eine neuere Version verfügbar ist wird dies protokolliert, ein automatisches Update erfolgt nicht.

InternationalPrefix=00
Gibt eine Ziffernfolge an, mit welcher ein '+'-Zeichen am Anfang einer Telefonnummer ersetzt wird und anhand derer eine internationale Nummer identifiziert werden kann (default: "00").

LocalIdDir=localids
Gibt ein Verzeichnis an, in dem Daten zur Zuordnung von LoaclIds (vom Benutzer vorgegeben) zu MsgIds (von einer SMSC zugeteilt) abgespeichert werden. Dies ist nur erforderlich falls für eine Nachricht ein StatusReport angefordert wird. In diesem Fall wird beim Versenden der Nachricht die LocalId zusammen mit der MsgId abgespeichert und beim Eintreffen eines Statusreports anhand der MsgId die entsprechende LocalId gelesen.

LockDir=/var/spool/uucp
Gibt das Verzeichnis an, in dem eine Lockdatei gesucht bzw. angelegt wird (nur UNIX).

LockFunction=
Gibt an, welche Systemfunktion zum Sperren von Dateien verwendet werden soll. Gültige Werte sind flock oder fcntl für Linux, Unix bzw. lockfile für Windows. Die Funktion flock ist nicht auf allen Systemen verfügbar und funktioniert ggf. nicht auf Netzwerk-Laufwerken. Falls fcntl (oder nichts) angegeben wurde, versucht SendXMS zu erkennen, ob das verwendete Betriebsystem Open file description locks unterstützt und verwendet ggf. diese Sperrmethode (F_OFD_SETLK). Falls diese Erkennung nicht erwünscht oder fehlerhaft ist kann durch Angabe von 'LockFunction=fcntl (arl)' die Verwendung von Advisory record locking (F_SETLK) erzwungen werden.

LogFile=sendxms.log
Gibt das Logfile an, in dem SendXMS alle Aktionen protokolliert werden. Wird der Dateiname ohne Pfad angegeben, so wird die Datei im Installationsverzeichnis angelegt. Wenn der Dateiname die Zeichenfolge $h oder $d enthält wird diese Zeichenfolge durch die aktuelle Stunde (yyyymmddhh) bzw. durch den aktuellen Tag (yyyymmdd) ersetzt und eine entsprechende Logdateien generiert. Zusätzlich wird ein symbolischer Link (gleicher Name aber ohne Datum) auf die generierte Logdatei angelegt, welcher bei gleichbleibendem Namen immer auf die aktuelle Logdatei zeigt. Wird als LogFile=syslog angegeben, so wird über den syslog-Dämon protokolliert (Facility=LOG_DAEMON, Priority=LOG_INFO; wichtige Alarmmeldungen zusätzlich noch mit Priority=LOG_ALERT). Mit LogFile=/dev/null kann das Logging unterdrückt werden. [nur in der registrierten Version]

LogMsgText=false
Unterdrückt das Loggen des Textes der Nachrichten (standardmäßig eingeschaltet). [nur in der registrierten Version]

LogLevel=255
Mit diesem Parameter kann angegeben werden welche Informationen in der Logdatei protokolliert werden. Der angegebene Wert wird als Bitfeld interpretiert, wobei z.Zt. folgende Bits interpretiert werden:

Bit0	informative Meldungen (z.B. dass eine Nachricht empfangen wurde)
Bit1	Warnungen (z.B. dass die SMSC das Gültigkeitsdatum überschrieben hat)
Bit2	Fehler (z.B. dass ein Provider nicht verfügbar ist)
Bit3	die Meldung 'looking for messages on...' bei Verwendung eines GSM-Geräts
Bit4	Keepalive Meldungen

[nur in der registrierten Version]

LongDistancePrefix=0
Gibt eine Ziffer(-nfolge) an, die für ein nationales Ferngespräch angegeben werden muss (wenn z.B. die internationale Nummer +49 123 4567890 innerhalb von Deutschland gewählt werden soll muss die Länderkennung '+49' durch den LONGDISTANCEPREFIX 0 ersetzt werden).

MaxErrors=
Gibt die max. Anzahl Fehler (Nachricht nicht gesendet) an, die bis zu einem Programmabbruch akzeptiert wird. Ist dieser Parameter nicht bzw. auf 0 gesetzt, so wird nach einer fehlerhaften oder nicht übertragenen Nachricht NICHT abgebrochen. Im Servermodus wird wird die aktuelle Verbindung beendet und das benutzte Gerät geschlossen.

MaxSplit=
Gibt die max. Anzahl Segmente an, in die eine lange SMS zerlegt werden soll. Dieser Wert kann durch Angabe des Parameters MaxSplit in einer Providerdefinition bzw. für jede Nachricht individuell mittels des Kommandozeilenparameter -N (Split= in einer Spooldatei) individuell überschrieben werden. Ist weder in der cfg-Datei noch in der Providerdefition noch für die Nachricht selbst ein Wert angegeben wird pro Nachricht nur eine einzelne SMS (ein Segment) versendet.

MNP= (siehe auch Mobile Number Portability (MNP))
Gibt eine Funktion in einer DLL bzw. in einem shared object an, mit welcher überprüft wird ob eine Empfängernummer portiert wurde oder nicht.

Phone=
Gibt die eigene Telefonnummer, von der die Nachricht ausgeht, an.

Phonebook=
Gibt den Namen der zu verwendenden Telefonbuch-Datei an (Standard ist sendxms.pbk). Dieser Wert kann mit dem Kommandozeilenparameter -b überschrieben werden.

PidFile=
Gibt den Namen der zu verwendenden PID-Datei an (Standard ist sendxms.pid). Dieser Wert kann mit dem Kommandozeilenparameter -P überschrieben werden.

Priority=-5
Hiermit kann die Priorität, mit der SendXMS ausgeführt wird, gesetzt werden. Der Bereich geht von -15 (hohe Priorität) bis 15 (niedrige Priorität).

RcZeroIfOK=true
Gibt an, dass der Returncode im Falle eines erfolgreichen Versendens gleich 0 sein soll. Dies ist unter Unix so üblich und sollte bei einer Einbindung in z.B. ein Emailsystem verwendet werden. Ist dieser Parameter nicht gesetzt, wird die Anzahl der übertragenen Nachrichten bzw. ein Fehlercode zurück gegeben.

ReceiveDir=received
Gibt ein Verzeichnis an, in welchem empfangene Kurznachrichten abgespeichert werden sollen. [nur registrierte Version]

RedialCount=3
Gibt die Anzahl von Wahlversuchen an (siehe auch RetryCount). [nur in der registrierten Version]

RedialDelay=60
Gibt die Anzahl Sekunden an, die bis zum nächsten Wahlversuch gewartet wird. In der Zeit bis zum nächsten Wahlversuch wird das Modem wieder freigegeben. [nur in der registrierten Version]

RetryCount=3
Gibt an, wie oft versucht wird eine Nachricht zu übertragen. Im Servermodus ist dies die Anzahl wie oft eine Nachricht max. im Spoolverzeichnis belassen wird (nach fehlerhafter Übertragung). Im Gegensatz zum RedialCount greift RetryCount immer, wenn die Übertragung nicht geklappt hat, während RedialCount nur greift, wenn kein Modem frei ist bzw. die Gegenstelle nicht abnimmt. [nur in der registrierten Version]

RetryDelay=60
Gibt die Anzahl Sekunden an, die bis zum nächsten Sendeversuch gewartet wird. In der Zeit bis zum nächsten Wahlversuch wird das Modem wieder freigegeben. [nur in der registrierten Version]

SentDir=unsent
Gibt ein Verzeichnis an, in welchem versendete Nachrichten archiviert werden. [nur in der registrierten Version]

SpoolDir=/var/spool/sendxms
Gibt das Verzeichnis an, in dem die Nachrichten gespoolt (zwischengespeichert) werden. [nur in der registrierten Version]

SpoolFilePrefix=
Gibt einen Prefix zur Erzeungung von Spooldateien an. Standardmäßig generiert SendXMS Spooldateien deren Name die Form sms* hat und bearbeitet alle Dateien in SPOOLDIR. Wenn aber dieser Parameter definiert ist werden die Spooldateien mit diesem Prefix angelegt und es werden auch nur noch Dateien mit diesem Prefix im Spoolverzeichnis bearbeitet.

SpoolSort=
Gibt an, in welcher Reihenfolge die Spooldateien abgearbeitet werden. Mit SpoolSort=Name werden die Spooldateien zur Bearbeitung alphabetisch (Dateiname) bzw. mit SpoolSort=Time nach dem Modifikationsdatum (FIFO) sortiert. Ist keiner dieser beiden Werte angegeben werden die Datein in der Reihenfolge des Filesystems abgearbeitet.

StatisticDir=statistic
Gibt ein Verzeichnis an, in welchem Statistik-/Billingdaten gespeichert werden. Die Daten werden im CSV-Format abgespeichert und können einfach mit einer Datenbank, Tabellenkalkulation oder anderer Software ausgewertet werden. Folgende Daten werden abgespeichert:

Datum/Zeit (z.B.: "2007-11-16, 10:42:07")
Art der Nachricht (0=gesendet, 1=empfangen, 2=Fehler)
Nummer des Empfängers
Nummer des Absenders
Nummer des Segments einer mehrteiligen Nachricht
Anzahl des benötigten Segmente bei einer mehrteiligen Nachricht
DCS der Nachricht
MessageClass der Nachricht
TariffClass der Nachricht
Dauer der Übertragung in Sekunden (Verweildauer der Nachricht im Spoolverzichnis)
Angabe ob die Nachricht (vom Userexit) abgelehnt wurde (1) oder nicht (0)

[nur in der registrierten Version]

TmpDir=tmp
Gibt ein Verzeichnis an, in welchem temp. Dateien zwischengespeichert werden sollen.

Umask=0x12
Gibt eine prozessspezifische umask (standard Zugriffsrechte für neue Dateien) an. Ist dieser Wert nicht definiert wird die umask der Prozessumgebung verwendet. [nur Linux/Unix]

UnsentDir=unsent
Gibt ein Verzeichnis an, in welchem Nachrichten die nicht gesendet werden konnten archiviert werden. [nur in der registrierten Version]

TimeFormat=%Y.%m.%d %H:%M:%S
Definiert das Format in dem Zeitwerte (ValidityPeriod oder DeferredDelivery) angegeben werden. Die Syntax entspricht den Formatangaben den C-Funktionen strftime/strptime. Siehe auch Zeitversetztes Senden und Gültigkeitsdauer. [nur in der registrierten Version]

UserExitVersion=
Gibt die Version des verwendeten Userexitformats an. Ist dieser Parameter nicht definiert wird automatisch die aktuellste definierte Aufrufsyntax benutzt. Falls sich die Aufrufsyntax des Userexits in einer neuen SendXMS-Version ändert (neue Parameter) wird dieser Definition eine neue Versionsnummer zugeordnet. Mit diesem Parameter kann ausgewählt werden, welche Syntax benutzt werden soll, so dass bei einer Erweiterung von SendXMS keine Änderungen am Userexit notwendig werden. In diesem Handbuch wird jeweils nur die aktuelle Version des Userexits beschrieben.

ACHTUNG: Ab dem nächsten Major-Release wird dieser Parameter nicht mehr unterstützt.

Im Kapitel [XMSConv] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen.

WapInitiatorUri=
Gibt einen Standardwert für den WSP Parameter X-WAP-Initiator-URI an. Dieser Parameter wird nur von XMSConv beim compilieren von WAP-Push Nachrichten verwendet (nur in Professional-Edition und höher).

WapPushFlag=
Gibt einen Standardwert für den WSP Parameter PushFlag an. Dieser Parameter wird nur von XMSConv beim compilieren von WAP-Push Nachrichten verwendet (nur in Professional-Edition und höher).

Im Kapitel [Device] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen. (Für die entsprechenden Modembefehle wird auf das Modemhandbuch verwiesen (soweit vorhanden)).

Address=
Gibt die IP-Adresse eines Gerätes (z.B. ISDN-Gerät mit RemoteCAPI, Modem mit At-over-Ethernet, VoIP, ...) an.

AtOverEthernet=
Gibt an, dass das Gerät per IP angesprochen wird. Als Parameterwert kann entweder TCP, UDP oder Telnet angegeben werden.

Baud=4800
Gibt die zu verwendende Baudrate an (300, 600, 1200, 2400, 4800 oder 9600). Dieser Wert wird nur verwendet, falls bei einem anzurufenden Provider keine Definition vorhanden ist. (wird nicht in Verbindung mit TAPI benutzt)

BC=
Bei Nutzung von CAPI2.0 kann (i.d.R. nicht notwendig) hier ein Wert für Bearer Capability (jeweils einzelne Bytes in Hex-Format (zwei Hexziffern)) angegeben werden. Die Kodierung kann der CAPI-Dokumentation entnommen werden.

BChannelInfo=
Bei Nutzung einer Standleitung mit CAPI2.0 werden hier die Leitungsparameter angegeben (jeweils einzelne Bytes in Hex-Format (zwei Hexziffern)). Die Kodierung kann der CAPI-Dokumentation entnommen werden.

Beep=AT#VTS=[960,0,6]
Gibt ein Kommando zum Generieren eines Signaltons (bei Aufnahme einer Sprachnachricht mit Voice-Modem) an. (wird nicht in Verbindung mit TAPI benutzt)

CalledPartyInFilter=
CalledPartyOutFilter=
CallingPartyInFilter=
CallingPartyOutFilter=
Mit diesen Parametern kann ein Filter (bzw. bei mehrfacher Angabe eine Kette von Filtern) definiert werden, mit welchen ein-/ausgehende Rufnummern automatisch geprüft und ggf. umgeformt werden. So ist es z.B. möglich pro Device eine führende '0' hinzuzufügen bzw. zu entfernen, falls die verwendete CAPI die Rufnummer falsch meldet oder bei Bedarf explizit TON/NPI zu setzen (<ton>:<npi>:<msisdn>). Siehe auch Filter für Nummernformate.

CapiConnectResponseDelay=0.5
Gibt eine Verzögerung (in Sekunden) an, bevor ein eingehender Ruf von einem CAPI Gerät angenommen bzw. abgelehnt wird. In der Regel ist diese Verzögerung nicht notwendig, aber für manche (interne) S0-Busse ist SendXMS zu schnell. In einem solchen Fall kann es vorkommen (falls CapiConnectResponseDelay nicht gesetzt ist), dass andere parallelgeschaltete ISDN-Geräte nicht erkennen, dass ein eingehender Ruf bereits von SendXMS angenommen wurde.

ConnectTimeout=40
Gibt die Zeitdauer (in Sekunden) an, die das SendXMS nach dem Wählen auf das Zustandekommen einer Verbindung wartet.

Controller=
Wenn Sie in Ihrem Rechner mehrere ISDN-Karten (mit CAPI) benutzen geben Sie hier an auf welche der Karten sich die Definition bezieht. Wenn sie keinen Controller explizit definieren werden alle verfügbaren Controller benutzt.

Databits=8
Gibt die Anzahl der Datenbits (7 oder 8) an. Dieser Wert wird nur verwendet, falls bei einem anzurufenden Provider keine Definition vorhanden ist. (wird nicht in Verbindung mit TAPI benutzt)

Device=
Gibt den Anschluss an, an dem das Modem hängt (unter Unix z.B. /dev/ttyS0). (Achtung: unter Unix muss darauf geachtet werden, dass der Besitzer der Datei sendxms berechtigt ist das Device zu benutzen).

Wird die Kommunikation mittels CAPI 2.0 abgewickelt, so wird hier der Pfad zur Capi-DLL/-Shared-Object (Windows, Linux) bzw. zum CAPI-Device (Unix) angegeben.

Unter Windows wird zunächst versucht das angegebene Device exclusiv zu öffnen. Sollte dies nicht gelingen (z.B. weil der Port von RAS benutzt wird) wird versucht das Device über die TAPI-Schnittstelle zu öffnen. Durch diese Vorgehensweise hat man die Möglichkeit ein Modem mit anderen Applikationen zu teilen, es stehen jedoch nicht alle Funktionen zur Verfügung, wenn das Device über die TAPI-Schnittstelle geöffnet wird.

DeviceType=Modem
Gibt die Art der verwendeten Hardware (VoIP, Modem, Voice-Modem, GSM 07.05, CAPI 2.0, CAPI 2.0 (BINTEC), RFC1086 oder SERIAL) an.

DialPrefix=ATDT0w
Gibt das Kommando zum wählen einer Nummer an (hier Tonwahl und nach einer '0' auf das Freizeichen warten).
Bei Verwendung der CAPI-Schnittstelle an einer Nebenstellenanlage wird hier die Ziffernfolge angegeben, um eine Amtsleitung zu erhalten (normalerweise 0). (wird nicht in Verbindung mit TAPI benutzt)

DialSuffix=
Bei manchen Modems/ISDN-Terminaladaptern muss an die zu wählende Nummer noch ein oder mehrere AT-Kommandos angehängt werden, um z.B. ein bestimmtes Protokoll auszuwählen. Diese Kommandos können hier definiert werden. Dieser Wert wird nur verwendet, falls bei einem anzurufenden Provider keine Definition vorhanden ist. (wird nicht in Verbindung mit TAPI benutzt)

Domain=bai.de
Bei Verwendung eines VoIP-Anschlusses müssen die Telefonnummern in SIP-Adressen umgewandelt werden (z.B. 0123456789 in sip:0123456789@bai.de). Standardmäßig wird hierzu die für den VoIP-Anschluss konfigurierte IP-Adresse verwendet. Falls der Parameter Domain gesetzt ist wird statt der IP-Adresse dieser Parameter verwendet.

DtmfTransfer=RTP
Dieser Parameter definiert wie DTMF-Töne bei Verwendung eines VoIP-Anschlusses signalisiert werden. Mögliche Werte sind RTP (RFC 4733, inband), INFO (SIP INFO, out-of-band) oder BOTH (RTP und INFO).

Escape=+++
Gibt die Fluchtsequenz an, welche zum Umschalten vom Datenmodus in den Befehlsmodus dient. ACHTUNG! Die Fluchtsequenz wird nur benutzt wenn sie explizit definiert ist. Ist sie nicht definiert so wird zum Auflegen des Modems das DTR-Signal für 1 Sekunde auf 0 gesetzt. Dies ist sicherer und schneller als die Fluchtsequenz und ein ATH. Definieren Sie also die Fluchtsequenz nur, wenn der DTR-Mechanismus bei Ihnen nicht funktioniert.

Hangup=ATH
Gibt das Kommando zum Auflegen an.

HLC=
Bei Nutzung von CAPI2.0 kann (i.d.R. nicht notwendig) hier ein Wert für High Layer Capability (jeweils einzelne Bytes in Hex-Format (zwei Hexziffern)) angegeben werden. Die Kodierung kann der CAPI-Dokumentation entnommen werden.

IMSI=
Gibt die IMSI der verwendeten SIM-Karte an (dient der Zuordnung zwischen Provider-Definition und GSM-Gerät).

Init=ATQ0E1V1L1
Gibt das Initialisierungskommando für das Modem an. Das Modem muss auf

Echo an
Antwort an
Antwort als Text

eingestellt werden. (wird nicht in Verbindung mit TAPI benutzt)

Init2=
Gibt ein zweites Initialisierungskommando für das Modem an. Dieses Kommando erfolgt nach der Standardinitialisierung des Modems (GSM-Modules). Bei Verwendung eines GSM-Modules ist es u.U. notwendig eine Speicheradresse anzugeben (z.B. AT+CPMS="ME"), wozu man diesen Parameter verwenden kann. (wird nicht in Verbindung mit TAPI benutzt)

KeepAlive=
Gibt die maximale Anzahl Sekunden an, die ein GSM-Gerät inaktiv bleiben darf. Ist dieses Limit erreicht wird überprüft, ob das Gerät noch in das GSM-Netz eingebucht ist und ggf. wird das Gerät neu angemeldet (nur in Professional-Edition und höher).

LineType=ANALOG
Gibt an, ob es sich bei der Leitung um eine analoge (ANALOG), um eine digitale (ISDN), eine X.25 (X.25), eine X.31-Leitung (X.31) oder eine Netzwerkverbindung (TCP, UDP, TLS oder DTLS) handelt. Dieser Parameter kann ebenfalls bei den Providerdefinitionen angegeben werden, wobei SendXMS automatisch ein passendes Device für einen entsprechenden Provider auswählt.

LLC=
Bei Nutzung von CAPI2.0 kann (i.d.R. nicht notwendig) hier ein Wert für Low Layer Capability (jeweils einzelne Bytes in Hex-Format (zwei Hexziffern)) angegeben werden. Die Kodierung kann der CAPI-Dokumentation entnommen werden.

MessageStorages=ME;SR
Gibt eine durch Kommata getrennte Liste von Nachrichtenspeichern an, von denen Nachrichten gelesen werden sollen (nur GSM 07.05). In der Regel wird nur von einem Speicher (SM oder ME) gelesen.

MsgDelay=<n>
Gibt eine Anzahl von Sekunden an (z.B. 0.2), welche zwischen dem Versenden von zwei Nachrichten innerhalb von einer Verbindung gewartet wird (wird normalerweise nicht benötigt).

MsnIn=
Dieser Parameter kann mehrfach angegeben werden. Es wird jeweils eine lokale Telefonnummer (MSN) des ISDN-Anschlusses (bei Verwendung von CAPI 2.0) angegeben für welche eingehende Rufe angenommen werden sollen (beim Empfang von Festnetz-SMS, DTMF oder UUS-Nachrichten). Ist dieser Parameter nicht definiert werden alle eingehende Anrufe angenommen (bei Festnetz-SMS nur Rufe von der SMSC).

MsnOut=
Gibt die Telefonnummer des ISDN-Adapters (bei Verwendung von CAPI 2.0 und nur für ausgehende Verbindungen) an. Hier können Sie die (bei Verwendung einer Nebenstellenanlage die interne) Nummer eintragen, die dem entsprechenden ISDN-Anschluss zugeordnet ist. Wenn Sie hier keine oder eine falsche Nummer angeben kann es sein, dass keine Verbindungen aufgebaut wird. Dieser Parameter kann durch die Kommandozeilenoption -m überschrieben werden.

Name=Modem1
Dient zur eindeutigen Identifizierung eines Devices. Wenn dieser Name mit dem Kommandozeilenparameter -d angegeben wird, kann schon beim Aufruf von SendXMS ein spezielles Devices vorgegeben werden. Dies ist nur notwendig, wenn mehrere Devices konfiguriert sind und die automatische Deviceauswahl umgangen werden soll.

RegisterNetwork=
Gibt das Kommando an, mit dem sich ein GSM-Gerät bei einem Netz anmelden soll (default: AT+COPS=0). Dieses Kommando wird benutzt, wenn das GSM-Gerät beim Öffnen des Modems bei keinem Netz angemeldet ist bzw. wenn der Parameter KEEPALIVE definiert ist und das Modem zwischenzeitlich aus dem Netz ausgebucht wurde.

OriginatingAddress=01234..
Gibt die Absenderadresse (lokale Nummer) an.

PacketLen=128
Gibt die X.25-Paketlänge bzw. die X.31-Paketlänge (Standard: 128) an.

Parity=NONE
Gibt die Art der Parität an (NONE, EVEN oder ODD). Dieser Wert wird nur verwendet, falls bei einem anzurufenden Provider keine Definition vorhanden ist. (wird nicht in Verbindung mit TAPI benutzt)

Password=
Gibt ein optionales Passwort an (z.B. zur Benutzung in Verbindung mit VoIP oder interner Remote-CAPI).

PDUWithoutSCA=true
Einige (sehr alte) GSM-Modems benötigen eine PDU ohne vorgestellte SCA (in Kontrast zu GSM 07.05). Dieser Parameter ist z.B. für Siemens M1, Falcom A1 oder Xircom CreditCard, aber nicht für neuere Geräte notwendig.

Phone=
Gibt die Anschlußnummer des entsprechenden Modems bzw. der in dem entsprechenden GSM-Modul verwendeten SIM an.

PIN="1234"
Gibt die PIN für Ihre SIM an (GSM-Device). Falls Sie eine GSM-Karte verwenden, bei welcher man keine PIN eingeben braucht/kann (AT+CPIN? funktioniert nicht), darf dieser Parameter nicht belegt werden. Bei manchen Devices muss die PIN in Hochkommata angegeben werden, wohingegen dies bei anderen Devices zu Fehlern führt.

PlayDTMF=AT#VTS=
Gibt ein Kommando zum Abspielen einer DTMF-Sequenz (numerische Zeichen) (nur Voice-Modem) an. (wird nicht in Verbindung mit TAPI benutzt)

Port=
Gibt einen TCP/UDP-Port zur Verwendung mit einer IP-Adresse an.

PowerOn=
Gibt ein Kommando zum Einschalten eines GSM-Gerätes an (Default: AT+CFUN=1).

PowerOff=
Gibt ein Kommando zum Ausschalten eines GSM-Gerätes an (Default: AT+CFUN=0).

PppInit=
Gibt ein zusätzliches Initialisierungskommando für das Modem für PPP-Verbindungen an. Dieses Kommando erfolgt nach der Standardinitialisierung des Modems (GSM-Modules).

PppMmsProfile=
Gibt die Zeichenfolge an, die benötigt wird um eine PPP Verbindung über das MMS Profil aufzubauen (bei Verwenung eines GSM-Geräts). Ist dieser Parameter nicht gesetzt versucht SendXMS ihn automatisch zu bestimme bzw. verwendet den Standardwert *99***1#.

Provider=
Für ein GSM-Gerät können Sie hier einen standard Providernamen eintragen. Per default werden über ein GSM-Gerät eingehende Nachrichten in SpoolDir in einem Unterverzeichnis, welches der Nummer der verwendeten SMSC entspricht, abgelegt. Falls für das GSM-Gerät der Parameter Provider definiert ist wird statt der SMSC-Nummer ein Unterverzeichnis mit entsprechendem Namen verwendet (dies bedeutet, dass alle Nachrichten die über diese GSM-Gerät empfangen wurden in einem einzelnen Verzeichnis abgelegt werden).

PUK="1234"
Gibt den PUK für Ihre SIM an (GSM-Device). Falls Sie eine GSM-Karte verwenden, bei welcher man keine PIN eingeben braucht/kann (AT+CPIN? funktioniert nicht), darf dieser Parameter nicht belegt werden. Bei manchen Devices muss der PUK in Hochkommata angegeben werden, wohingegen dies bei anderen Devices zu Fehlern führt.

Reset=ATZ
Gibt das Kommando zum Zurücksetzen des Modems an (normalerweise ATZ).

RtpPorts=10000-10050
Bei Verwendung eines VoIP-Anschlusses kann mit diesem Parameter ein lokaler Portbereich für RTP (und RTCP) angegeben werden (pro Verbindung sind 2 Ports notwendig). Sollte die Verbindung zum SIP-Server über einen NAT-Router erfolgen muss der Router so konfiguriert werden, dass diese Ports an SendXMS weitergeleitet werden.

RtsCts=true
Gibt an, dass die Hardwareflußkontrolle benutzt werden soll.

SetMsnOut=
Gibt ein (AT-) Kommando zum Setzen der (ausgehenden) MSN, EAZ, CallingPartyNumber an. Falls dieses Kommando definiert ist und eine MsnOut angegeben wurde, wird vor dem Verbindungsaufbau versucht die Nummer, über die die Verbindung aufgebaut werden soll, zu selektieren. Die MSN wird am Ende des Kommandos bzw. für den Platzhalter $msn eingesetzt.

SipAlwaysRegister=True
Gibt an, dass bei Verwendung eines VoIP-Anschlusses immer (auch wenn nur ausgehende Verbindungen nötig sind) eine Registrierung erfolgt.

SipRegistrationInterval=300
Gibt die Anzahl Sekunden an, nach der eine SIP-Registrierung erneuert wird.

StartVoicemode=AT#CLS=8
Gibt das Kommando an mit dem ein Voice-Modem in den Voice-Modus gesetzt wird. Dies ist zum Abspielen/Aufnehmen von Sprachnachrichten nötig. (wird nicht in Verbindung mit TAPI benutzt)

Stopbits=1
Gibt die Anzahl der Stopbits an (1 oder 2). Dieser Wert wird nur verwendet, falls bei einem anzurufenden Provider keine Definition vorhanden ist. (wird nicht in Verbindung mit TAPI benutzt)

StopVoicemode=AT#CLS=0
Gibt das Kommando an mit dem bei einem Voice-Modem der Voice-Modus beendet wird. (wird nicht in Verbindung mit TAPI benutzt)

StunRfc=3489
Gibt an, dass der unter StunServer angegeben STUN-Server dem RFC 3489 (und nicht den neueren RFC 5389) entspricht (z.B.: stun.t-online.de).

StunServer=10.11.12.13 3478
Gibt die Adresse (und Port) eines STUN-Servers an. Bei Verwendung von VoIP über einen NAT-Router wird ein STUN-Server zum Ermitteln der externen IP-Adresse benötigt.

SuppressReinit=true
Verhindert, dass ein Devices im Servermodus bei jedem Öffnen erneut initialisiert wird. Ist dieser Parameter gesetzt, so wird das Device nur beim ersten Öffnen initialisiert (nur im Servermodus). Hierdurch kann man einen wesentlich höheren Durchsatz erreichen. Der Parameter sollte nur benutzt werden, wenn sichergestellt ist, dass keine andere Applikation zwischenzeitlich auf das Device zugreift und u.U. die Einstellungen verändert.

TEI=1
Gibt den TEI (Terminal Endpoint Identifier; wird vom Netzbetreiber zugewiesen) an, der zum Verbindungsaufbau über X.31 verwendet werden soll.

UseDChannel=true
Gibt an, dass die Verbindung (X.31) über den D-Kanal erfolgen soll. Ist dieser Wert nicht oder gleich 0 gesetzt wird ein B-Kanal benutzt.

UserId=
Gibt eine optionale UserID an (z.B. zur Benutzung in Verbindung mit VoIP oder interner Remote-CAPI).

VoiceCompression=ALAW
Wenn dieser Parameter definiert ist werden aufgenommene Sprachnachrichten als WAV-Datei gespeichert und es können WAV-Dateien abgespielt werden, falls diese in einem unterstützten Format vorliegen. Z.Zt. werden die Formate ALAW (ISDN in Europa) und ULAW (ISDN in USA) unterstützt (8kHz, 1 Kanal, 8 Bit).

VoiceReceive=AT#VRX
Gibt das Kommando an mit dem bei einem Voice-Modem der Sprachempfangsmodus gestartet wird (Aufzeichnen von Sprachnachrichten). (wird nicht in Verbindung mit TAPI benutzt)

VoiceTransmit=AT#VTX
Gibt das Kommando an mit dem bei einem Voice-Modem der Sprachsendemodus gestartet wird (Abspielen von Sprachnachrichten). (wird nicht in Verbindung mit TAPI benutzt)

WaitAfterWrite=1
Gibt die Anzahl Sekunden an, die nach jedem Schreiben auf das Device gewartet wird (kann meistens auf 0 gesetzt werden).

WindowSize=2
Gibt die Fenstergröße für X.25 (Standard: 7) bzw. die B3-Fenstergröße für X.31 (Standard: 2) an.

X31Channels=0,0,1,1,0,0
Gibt die zu verwendenden X.31-Kanäle an. Es werden durch Kommata getrennt die Werte für den

kleinsten eingehenden Kanal
größten eingehenden Kanal
kleinsten bidirektionalen Kanal
größten bidirektionalen Kanal
kleinsten ausgehenden Kanal
größten ausgehenden Kanal

angegeben. Wird dieser Parameter nicht spezifiziert wird der Standard (0,0,1,1,0,0) verwendet, welcher in den meisten Fällen funktioniert.

XonXoff=true
Gibt an, dass die Softwareflußkontrolle benutzt werden soll.

Im Kapitel [XMSGUI] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen.

cfgEditable=true
Gibt an, ob die Datei sendxms.cfg von einem Endbenutzer des graphischen Frontends modifiziert werden darf (=true) oder nicht (=false). Selbst wenn dieser Parameter auf true gesetzt ist kann der Endbenutzer die Konfiguration nur modifizieren, wenn er auch Schreibrecht auf die Datei sendxms.cfg hat.

proEditable=true
Gibt an, ob die Datei sendxms.pro von einem Endbenutzer des graphischen Frontends modifiziert werden darf (=true) oder nicht (=false). Selbst wenn dieser Parameter auf true gesetzt ist kann der Endbenutzer die Providerdefinitionen nur modifizieren, wenn er auch Schreibrecht auf die Datei sendxms.pro hat.

showLogfile=false
Gibt an, ob ein Endbenutzer des graphischen Frontends die Logdatei von SendXMS anzeigen lassen kann (=true) oder nicht (=false). Selbst wenn dieser Parameter auf true gesetzt ist kann der Endbenutzer die Logdatei nur anzeigen lassen, wenn er auch Leserecht auf die Logdatei hat.

In den Kapiteln [Allow] und [Deny] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen. Es wird immer nur eine von beiden Listen benutzt, sind beide definiert so wird die Allow-Liste benutzt.

UserId=
Dieser Parameter kann mehrfach angegeben werden. Es wird jeweils eine UserID angegeben, welche SendXMS benutzen bzw. nicht benutzen darf. Werden im Kapitel [ALLOW] eine oder mehrere UserIDs angegeben, darf SendXMS nur von diesen Benutzern benutzt werden. Werden die UserIDs im Kapitel [DENY] angegeben, dürfen alle Benutzer, außer den aufgelisteten, das Programm benutzen.

In den Kapiteln [Blacklist] und [Whitelist] stehen die im Folgenden aufgeführten Schlüsselworte zur Verfügung. Jedes Schlüsselwort muss in einer neuen Zeile stehen. Sind sowohl eine White- als auch ein Blacklist definiert hat die Whitelist Vorrang.

Phone=
Dieser Parameter kann mehrfach angegeben werden. Es wird jeweils eine Telefonnummer angegeben, an welche Nachrichten versendet (Whitelist) bzw. nicht versendet (Blacklist) werden dürfen. Wenn die angegebene Nummer mit dem Zeichen '*' endet, so handelt es sich um einen Präfix, d.h. es werden alle Nummern, die mit dem angegeben Wert beginnen, benutzt.

Das Kapitel [SSL] dient zur optionalen Integration von OpenSSL (i.d.R. nicht notwendig). Es stehen folgende Parameter zur Verfügung:

AcceptSelfSignedCertificates=true
Gibt an dass auch self-signed Zertifikate akzeptiert werden sollen.

CALocation=
Gibt an, wo vertrauenswürdige CA Zertifikate (PEM coded) gespeichert sind. Dies kann ein Verzeichnis (ended mit /) oder eine Datei, welche mehrere Zertifikate enthalten kann, sein.

CertChainFile=
Gibt den Dateinamen einer Zertifikatskette mit ihrem eigenen Zertifikat an (PEM coded; das eigene Zertifikat muß an erster und das Zertifikat mit dem höchsten Level an letzter Stelle stehen).

CertFile=
Gibt den Dateinamen ihres eigenen Zertifikats (PEM coded) an.

KeyFile=
Gibt den Dateinamen ihres eigenen privaten Keys (PEM coded) an (für ihr Zertifikat CertFile).

LibCrypto=
Mit diesem Parameter kann der Name der crypto-Library (mit oder ohne Pfad) angegeben werden (Default ist libeay32.dll für Windows und libcrypto.so sonst).

LibSsl=
Mit diesem Parameter kann der Name der SSL-Library (mit oder ohne Pfad) angegeben werden (Default ist libssl32.dll für Windows und libssl.so sonst).

Password=
Gibt das Passwort (passphrase) ihres eigenen privaten Keys an (KeyFile).

VerifyPeer=true
Gibt an, dass bei eingehenden SSL Verbindungen ein Zertifikat vom Peerrechner angefordert und überprüft wird.

Das Kapitel [PPP] dient zur Konfiguration von PPP Verbindungen (in den meisten Fällen nur für MM1-Verbindungen notwendig). Es stehen folgende Parameter zur Verfügung:

Chat=
Gibt den kompletten Pfad zu chat an (nur Unix/Linux). Ist dieser Parameter nicht angegeben wird versuchet chat über den standard PATH aufzurufen.

IpUp=
Gibt eine optionale Script-/Batchdatei (oder Executable) an, welche nach dem Herstellen einer PPP-Verbindung aufgerufen wird. Diese Datei kann genutzt werden um ein eigenes Roting zu definieren. Als Parameter werden folgende Daten übergeben:

IP-Adresse der Gegenstelle (MMSC)
IP-Adresse des lokalen PPP Interfaces
IP-Adresse des PPP-Servers

NoDefaultRoute=true
Mit diesem Parameter wird verhindert, dass beim Aufbau einer PPP-Verbindung eine Defaultroute über das eingerichtete PPP-Interface angelegt wird (andernfalls würde - solange die Verbindung offen ist - sämtlicher IP-Verkehr über dieses Interface geleitet werden). Ist dieser Parameter gesetzt wird stattdessen nur die Adresse der Gegenstelle über das PPP-Interface geroutet. Allerdings ist es hierfür notwendig, dass SendXMS unter dem root Account (bzw. unter Windows als Administartor) ausgeführt wird.

Pppd=
Gibt den kompletten Pfad zu pppd an (nur Unix/Linux). Ist dieser Parameter nicht angegeben wird versuchet pppd über den standard PATH aufzurufen.

Das Kapitel [ODBC] dient zur Angabe von optionalen Zugangsdaten zur Nutzung des integrierten ODBC-Spool-APIs (i.d.R. nicht notwendig). Es stehen folgende Parameter zur Verfügung:

DSN=
Gibt den DataSourceName der zu verwendenden ODBC-Verbindung an. Der DSN wird auf Systemeben (unter Unix z.B. in /etc/unixODBC/odbc.ini) konfiguriert.

UID=
Gibt die zu verwendende (ODBC) UserId an.

PASSWORD=
Gibt das zu verwendende (ODBC) Passwort an.

LibOdbc=
Mit diesem Parameter kann der Name der ODBC-Library (mit oder ohne Pfad) angegeben werden (Default ist libodbc32.dll für Windows und libodbc.so sonst).

UseInternalSpoolApi=true
Gibt an, dass die interne ODBC SpoolAPI-Implementierung genutzt werden soll.

Das Kapitel [SNMP] dient zur Konfigurationur der optionalen Nutzung von SNMP (v2c) Traps (Notifications). Es stehen folgende Parameter zur Verfügung:

Address=
Gibt die IP-Adresse eines SNMP-Daemons an, an den die Traps gesendet werden sollen.

Community=
Gibt den zu verwendenden Community String an (Default ist public).

InitializeTrap=false
Deaktiviert die Generierung eines Traps bei der (Re-)Initialisieren eines SendXMS-Prozesses.

KeepaliveTrap=false
Deaktiviert die Generierung eines Traps beim Versenden/Empfangen eines KeepAlives.

PingDelay=
Gibt den Zeitabstand (in Sekunden) zwischen zwei aufeinander folgenden Ping-Traps an (Default ist 60).

PingTrap=false
Deaktiviert die Generierung von Ping-Traps (regelmäßige Traps).

Port=
Gibt den (UDP) Port an auf dem der SNMP-Daemon auf Traps wartet (Default ist 162).

ProcessTrap=false
Deaktiviert die Generierung eines Traps beim Starten/Beenden eines SendXMS-Prozesses.

SessionTrap=false
Deaktiviert die Generierung eines Traps beim Auf-/Abbau einer Protokolsitzung.

SourceAddress=
Gibt die zu verwendende abgehende IP-Adresse an.

SourcePort=
Gibt den zu verwendenden abgehenden (UDP) Port an.

Das Kapitel [Metrics] dient zur Konfigurationur der optionalen Nutzung von Metriken mittels z.B. Prometheus. Es stehen folgende Parameter zur Verfügung:

EnableMetrics=true
Mit diesem Parameter kann die Bereitstellung von Metriken durch SendXMS aktiviert werden. Es werden nur Metriken für permanente Verbindungen (ab Professional-Edition) unterstützt.

Allow=127.0.0.1/32
Gibt eine IP-Adresse bzw. einen Adressbereich an, der die von SendXMS gesammelten Metriken abrufen darf. Falls dieser Parameter angegeben ist werden Abfragen von allen nicht passenden Adressen abgelehnt. Dieser Parameter kann mehrfach angegeben werden.

Deny=128.0.0.0/24
Gibt eine IP-Adresse bzw. einen Adressbereich an, der die von SendXMS gesammelten Metriken NICHT abrufen darf. Dieser Parameter wird nur angewendet, falls kein Allow= angegeben ist. Dieser Parameter kann mehrfach angegeben werden.

HttpPorts=8001-8100
Gibt einen einzelnen HTTP-Port bzw. einen Portbereich an, über den die Metriken zur Abfrage bereitgestellt werden. Jeder SendXMS-Prozess verwendet einen der angegebenen Ports. Die Metriken können über die URL .../metrics abgefragt werden. Dieser Parameter kann mehrfach angegeben werden.

PidDirectory=metrics/pids
Gibt ein Verzeichnis an, in welchem die aktuell benutzten PIDS (zusammen mit dem HTTP-Port) gespeichert werden.

Das Kapitel [Java] dient zur optionalen Konfigurationur einer Java VM (bei Verwendung eines Java-Userexits). Es stehen folgende Parameter zur Verfügung:

JniVersion=0x00010006
Gibt die zu benutzende JNI-Version an (hier 1.6).

LibJvm=
Gibt den Pfad zu libjvm.so bzw. jvm.dll (Java Virtual Machine) an.

VmOption=
Gibt eine Option (z.B.: -D<name>=<value>) zum Start einer Java VM an. Dieser Parameter kann mehrfach angegeben werden.

In den Kapiteln [Audio Mime Types], [Image Mime Types] und [Video Mime Types] können Dateiextensions für einen entsprechenden MIME Typ definiert werden, z.B.:

  
    [Audio Mime Types]

    mid=audio/midi

    midi=audio/midi

    amr=audio/amr

sendxms.pro

Hier werden die verschiedenen Dienstanbieter konfiguriert. Für jeden Dienstanbieter muss ein 'Kapitel' angelegt werden. In der Datei sind viele Dienstanbieter bereits vorkonfiguriert und können direkt übernommen werden. Nicht benötigte Dienstanbieterdefinitionen sollten jedoch gelöscht werden. Für manche Dienstanbieter sind verschiedene Definitionen (Modem, ISDN, GSM) vorhanden. Hiervon sollten Sie die nicht benötigten Definitionen löschen bzw. die für Ihre Device zutreffende Definition an den Anfang der Datei stellen. Eine Definition erfolgt durch eine Zeile mit dem Namen des Dienstanbieters in eckigen Klammern ([]) eingeklammert und den folgenden Parametern: (es sollte bei allen Providern mit UCP-Protokoll der Parameter MODEMINIT so gesetzt werden, dass das Modem zu V.42/LAPM gezwungen wird)

AdcInFilter=
Mit diesem Parameter kann ein Filter (bzw. bei mehrfacher Angabe eine Kette von Filtern) definiert werden, mit welchem eingehende Rufnummern (Empfänger) automatisch geprüft und ggf. umgeformt werden. Siehe auch Filter für Nummernformate.

AdcOutFilter=
Mit diesem Parameter kann ein Filter (bzw. bei mehrfacher Angabe eine Kette von Filtern) definiert werden, mit welchem ausgehende Rufnummern (Empfänger) automatisch geprüft und ggf. umgeformt werden. Siehe auch Filter für Nummernformate.

Address=<ip-address>
Dieser Parameter ist äquivalent zu dem Parameter PHONE, nur dass hier eine IP-Adresse für eine TCP/IP-Verbindung anstelle einer Telefonnummer angegeben wird. Optional kann durch ein Leerzeichen getrennt auch eine Portnummer angehängt werden. Dieser Parameter kann mehrfach angegeben werden. Falls die erste Adresse nicht erreichbar ist wird die nächste verwendet.

AddressRange=
Gibt den Address Range an (nur SMPP). Fragen Sie bei Ihrem Provider nach dem entsprechenden Wert.

APN=
Gibt den Access Point Name (MM1) an.

AutoAlert=<telefonnummer>
Dieser Parameter wird nur benutzt, wenn SendXMS im Servermodus läuft und mit dem Parameter -aRECEIVE (zum Lesen von ankommenden SMS) aufgerufen wurde. In diesem Fall gibt der Parameter eine Telefonnummer an, für welche bei jedem Abarbeiten der SMS-Warteschlange des entsprechenden Providers der Servicerechner angerufen wird und nach ankommenden Nachrichten aktiv gefragt wird (dies kann bei kurzen Abfrageintervallen per X.25/X.31 teuer werden). Bei CIMD muss zwar eine Telefonnummer angegeben werden, diese hat jedoch keine Bedeutung. Bei Verwendung von UCP kann die Telefonnummer in der Form <pid>:<phone> angegeben werden.

AutoConnect=<n>
Dieser Parameter wird nur benutzt, wenn SendXMS im Servermodus läuft und mit dem Parameter -aRECEIVE (zum Lesen von ankommenden SMS) aufgerufen wurde. In diesem Fall gibt der Parameter eine Anzahl Sekunden an, die nach einem automatischen Verbindungsaufbau zum Servicerechner des entsprechenden Providers auf ankommende Nachrichten gewartet wird. Der Unterschied zu AUTOALERT ist der, dass kein überflüssiger Datenverkehr stattfindet und somit bei z.B. X.25/X.31-Verbindungen keine Kosten entstehen.

B1Protocol=64K-HDLC
Mit diesem Parameter geben Sie das zu verwendende B1-Protokoll (ISDN, physical layer) an. Dies ist nur notwendig, wenn der entsprechende Provider vom Standard abweichende Protokolle benutzt und die Verbindung per CAPI aufgebaut wird. Bei Verwendung eines ISDN-Terminaladapters muss das entsprechende Protokoll mit einem AT-Befehl in ModemInit ausgewählt werden. Es stehen folgende Auswahlmöglichkeiten zur Verfügung:

64K-HDLC	64 kbit/s with HDLC framing
64K-TRANS	64 kbit/s bit-transparent operation with byte framing from the network
V.110-ASYNC	V.110 asynchronous operation with start/stop byte framing
V.110-SYNC	V.110 synchronous operation with HDLC framing
T.30-FAX3	T.30 modem for fax group 3
64K-INVERT	64 kbit/s inverted with HDLC framing
56K-TRANS	56 kbit/s bit-transparent operation with byte framing from the network
MODEM-NEGOTIATION	Modem with full negotiation
MODEM-ASYNC	Modem asynchronous operation with start/stop byte framing
MODEM-SYNC	Modem synchronous operation with HDLC framing

B2Protocol=X.75-SLP
Mit diesem Parameter geben Sie das zu verwendende B2-Protokoll (ISDN, data link layer) an. Dies ist nur notwendig, wenn der entsprechende Provider vom Standard abweichende Protokolle benutzt und die Verbindung per CAPI aufgebaut wird. Bei Verwendung eines ISDN-Terminaladapters muss das entsprechende Protokoll mit einem AT-Befehl in ModemInit ausgewählt werden. Es stehen folgende Auswahlmöglichkeiten zur Verfügung:

X.75-SLP	ISO 7776 (X.75 SLP)
TRANS	Transparent
SDLC	SDLC
LAPD-X.25	LAPD in accordance with Q.921 for D channel X.25
T.30-FAX3	T.30 for fax group 3
PPP	Point-to-Point Protocol
IGNORE	Transparent (ignoring framing errors of B1 protocol)
MODEM	Modem with full negotiation
X.75-SLP-V.42	ISO 7776 (X.75 SLP) with V.42 bis compression
V.120-ASYNC	V.120 asynchronous mode
V.120-ASYNC-V.42	V.120 asynchronous mode with V.42 bis compression
V.120-TRANS	V.120 bit-transparent mode
LAPD	LAPD in accordance with Q.921

B3Protocol=TRANS
Mit diesem Parameter geben Sie das zu verwendende B3-Protokoll (ISDN, network layer) an. Dies ist nur notwendig, wenn der entsprechende Provider vom Standard abweichende Protokolle benutzt und die Verbindung per CAPI aufgebaut wird. Bei Verwendung eines ISDN-Terminaladapters muss das entsprechende Protokoll mit einem AT-Befehl in ModemInit ausgewählt werden. Es stehen folgende Auswahlmöglichkeiten zur Verfügung:

TRANS	Transparent
T.90NL	T.90NL with compatibility to T.70NL
X.25-DTE-DTE	ISO 8202 (X.25 DTE-DTE)
X.25-DCE	X.25 DCE
T.30-FAX3	T.30 for fax group 3
T.30-FAX3-EXT	T.30 for fax group 3 extended
MODEM	Modem

Baud=4800
Gibt die zu verwendende Baudrate an (300, 600, 1200, 2400, 4800 oder 9600). Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

BDataLen=1024
Gibt die maximale Länge von Datenblöcken (CAPI; hat nichts mit der Länge einer Nachricht zu tun) an. Der Wert muss im Bereich zwischen 128 und 2048 liegen.

CallUserData=
Gibt die CallUserData für eine X.25/X.31-Verbindung an. Es können max. 16 Byte jeweils als zwei Hex-Ziffern kodiert angegeben werden.

ChargedParty=
Über den angegebenen Wert wird gesteuert, wer die Gebühren für eine MMS übernimmt (Sender, Recipient, Both oder Neither).

ChargedPartyID=
Gibt die Adresse einer dritten Partei an, welche die MMS bezahlen soll.

CIP=UNRESTRICTED-DIGITAL
Mit diesem Parameter kann (normalerweise nicht notwendig) der CIP-Wert (Compatibility Information Profile) zum Verbindungsaufbau per CAPI angegeben werden. Bei Verwendung eines ISDN-Terminaladapters muss der entsprechende Wert mit einem AT-Befehl in MODEMINIT ausgewählt werden. Es stehen folgende Auswahlmöglichkeiten zur Verfügung:

SPEECH	Speech
UNRESTRICTED-DIGITAL	unrestricted digital information
RESTRICTED-DIGITAL	restricted digital information
3.1KHZ-AUDIO	3.1 kHz audio
7KHZ-AUDIO	7 kHz audio
VIDEO	Video
PACKET-MODE	packet mode
56KBIT-RATE-ADAPTATION	56 kbit/s rate adaptation
UNRESTRICTED-DIGITAL-WITH-TONES	unrestricted digital information with tones/announcements
TELEPHONY	Telephony

Databits=8
Gibt die Anzahl der Datenbits an (7 oder 8). Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

DataOverVoip=True
Gibt an, dass der entsprechende Provider auch Daten- (entspricht 64kHz bei ISDN) über VoIP-Verbindungen unterstützt (z.B. Annyway_ucp und Cityruf). Dieses Feature wird aktuell nur von wenigen Providern und nicht bei allen Netzübergängen (zwischen unterschiedlichen VoIP-Anbietern) unterstützt. Sollte eine Hardwarelösung (z.B. VoIP-Gateway mit CAPI-Schnittstelle, ISDN-Anlage mit CAPI- oder VoIP.Schnittstelle, ...) zur Verfügung stehen ist dies die bessere Alternative.

Device=
Hier kann der Name eines Devices (so wie er in sendxms.cfg unter NAME definiert ist) angegeben werden um die Nutzung des entsprechenden Devices für diesen Provider zu erzwingen.

Detach=
Gibt an, dass die entsprechenden Providerdefinition gesondert behandelt wird. In Abhängigkeit des angegebenen Parameterwertes wird für diesen Provider ein eigener Kindprozess gestartet um eine permanente Verbindung aufzubauen. Gültige Parameterwerte sind:

Send	Es wird eine permanente Verbindung aufgebaut über welche Nachrichten versendet werden (kein Empfang).
Receive	Es wird eine permanente Verbindung aufgebaut über welche Nachrichten empfangen werden (kein Versand).
All	Es wird eine permanente Verbindung aufgebaut über welche Nachrichten gesendet und empfangen werden.
Ignore	Diese Providerdefinition wird nur bei expliziter Auswahl mit dem Kommandozeilenparameter -p verwendet. Ansonsten (Servermodus ohne explizite Providerangabe) wird dieser Provider komplett ignoriert.
AcceptXME (nur mit LineType=TCP)	Es wird auf eingehende Verbindungen einer XMSC auf der (den) angegebenen Adresse(n)/Port(s) gewartet. Ggf. wird eine XME Session gestartet.
AcceptVXMSC (nur mit VXMSC-Edition und LineType=TCP)	Es wird auf eingehende Verbindungen einer XME auf der (den) angegebenen Adresse(n)/Port(s) gewartet. Ggf. wird eine VXMSC Session gestartet.

Nachrichten können nur Empfangen werden falls der Serverprozess mit dem Parameter -aRECEIVE aufgerufen wurde.

DetachQueueDelay=
Falls für den entsprechenden Provider ein eigener Kindprozess gestartet wird (siehe auch Detach=) kann mit diesem Parameter ein eigener QueueDealy Wert definiert werden. Standardmäßig wird der Kindprozess mit dem gleichen QueueDelay (Komanndozeilenparameter -q<n>) gestartet wie der aufrufende Serverprozess.

DetachUserexit=
Falls für den entsprechenden Provider ein eigener Kindprozess gestartet wird (siehe auch Detach=) kann mit diesem Parameter ein eigener Userexit angegeben werden. Standardmäßig wird der Kindprozess mit dem gleichen Userexit (Komanndozeilenparameter -u) gestartet wie der aufrufende Serverprozess.

DialSuffix=
Bei manchen Modems/ISDN-Terminaladaptern muss an die zu wählende Nummer noch ein oder mehrere AT-Kommandos angehängt werden, um z.B. ein bestimmtes Protokoll auszuwählen. Diese Kommandos können hier definiert werden. Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

DirName=
Hier kann ein Unterverzeichnis (in ReceiveDir, SpoolDir, ...) angegeben werden, welches anstelle des Providernamens benutzt wird. Mit dieser Option kann man erreichen, daß verschieden Providereinträge (mit verschiedenen Namen) das gleiche Spoolverzeichnis verwenden.

DlrOnlyForFirstSegment=True
Wenn dieser Parameter gesetzt ist, werden optionale Status Report Requests bei mehrteiligen Nachrichten nur für das erste Segment angefordert (ansonsten für alle Segmente).

DoNotDisturbTime=
Mit diesem Parameter können Zeiten definiert werden, zu denen bestimmte Nachrichten (z.B. Werbung) nicht versendet werden dürfen. Dieser Parameter kann mehrfach angegeben werden. Dieser Parameter wird nur bei Nachrichten berücksichtigt, bei denen der (Spoolfile-)Parameter DoNotDisturb=true gesetzt ist. Entsprechende Nachrichten werden dann später, sobald die aktuelle Zeit ausserhalb der definierten DoNotDisturbTime Zeiten liegt, versendet. Das Format für die Angabe von Zeiten ist wie folgt:

<DoNotDisturbTime> ::= <start> "-" <end>



<start> ::= <date>"."<time>

<end> ::= <date>"."<time>



<date> ::= <week day> | <year><month><day>



<week day> ::= <every day> | <sunday> | <monday> | <tuesday> | <wednesday> | <thursday> | <friday> | <saturday>



<every day> ::= "*"

<sunday> ::= "0"

<monday> ::= "1"

<tuesday> ::= "2"

<wednesday> ::= "3"

<thursday> ::= "4"

<friday> ::= "5"

<saturday> ::= "6"



<year> ::= <digit><digit><digit><digit>

<month> ::= <digit><digit>    ; 01-12

<day> ::= <digit><digit>      ; 01-31



<time> ::= <hour><minute><second>



<hour> ::= <digit><digit>     ; 00-24

<minute> ::= <digit><digit>   ; 00-59

<second> ::= <digit><digit>   ; 00-59



<digit> ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | "9"



Example:

DoNotDisturbTime=*.000000-*.080000   ; every day between 00:00 and 08:00

DoNotDisturbTime=0.000000-0.240000   ; every Sunday (the whole day)

DoNotDisturbTime=20110101.000000-20110101.240000   ;  New Year 2011 (the whole day)

(nur Professional-Edition oder höher).

DtmfDelay=
Gibt die Länge (in Millisekunden) eines DTMF Tones an (nur Protocol=DTMF).

DtmfGap=
Gibt die Länge (in Millisekunden) der Pause zwischen zwei aufeinander folgenden DTMF Tönen an (nur Protocol=DTMF).

ErrorFilter=
Bei Verwendung eines SMS über HTTP Dienstanbieters kann man mittels dieses Parameters einen Filter definieren, welcher anhand der vom Dienstanbieter zurückgegebenen Antwort (die nicht standardisiert ist) erkennt, ob der Versand gescheitert ist (der Filter passt auf die Antwort) oder erfolgreich war (der Filter passt nicht). Wenn der Dienstanbieter z.B. folgende Antwort auf einen Senderequest sendet:
ERROR: invalid recipient
kann man z.B. mit folgendem Filter den Misserfolg erkennen:
MsgIdFilter=/^ERROR:(.*)/\1/
(siehe auch Filter für Nummernformate und SMS über HTTP).

HexDigits=lower
Gibt an, dass bei binären Nachrichten die Hex-Ziffern als Kleinbuchstaben übertragen werden (per Default werden Großbuchstaben benutzt).

HttpAuthType=Basic
Gibt den Typ der HTTP-Authentifizierung (Basic, Digest oder None) an.

KeepAlive=
Gibt die maximale Anzahl Sekunden an, die die Leitung inaktiv bleiben darf. Ist dieses Limit erreicht wird eine Protokollaktion ausgelöst um zu testen ob die Verbindung noch besteht und um zu verhindern, dass diese automatisch abgebaut wird (nur ab Professional-Edition).

Kennung=
Gibt die Vielnutzerkennung für einen TMobil-Vielnutzerzugang (CityRuf, Skyper) an (nur ab Professional-Edition).

LineType=ANALOG
Gibt an, ob es sich bei der Telefonnummer/Adresse das Providers um einen analogen (ANALOG), einen digitalen (ISDN), eine TCP/IP Verbindung (TCP), eine PPP (PPP_TCP), einen X.25- (X.25) oder einen X.31-Anschluss (X.31) handelt. Dieser Parameter kann ebenfalls bei den Devicedefinitionen angegeben werden, wobei SendXMS automatisch ein passendes Device für einen entsprechenden Provider auswählt. LLC=
Bei Nutzung von CAPI2.0 kann (i.d.R. nicht notwendig) hier ein Wert für Low Layer Capability (jeweils einzelne Bytes in Hex-Format (zwei Hexziffern)) angegeben werden. Die Kodierung kann der CAPI-Dokumentation entnommen werden. Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

MapUserValue=
Mit diesem Parameter können benutzerdefinierte Parameter anbieterspezifischen Erweiterungen zugeordnet werden. Manche Protokolle bieten spezielle Parameter zur Unterstützung von anbieterspezifischen Erweiterungen an. So können z.B. bei SMPP (ab 3.4) die optionalen TLV-Parameter 0x1400 bis 0x4000, bei CIMD die Tags 600 bis 900 und bei UCP (EMI) die XSer Type of services 0x0E bis 0xFF hierzu verwendet werden. Wenn der zu definierende Dienstanbieter eine solche Erweiterung anbietet kann dies mit diesem Parameter definiert werden. So kann z.B. mittels MapUserValue=TariffOption|0x1500 für einen SMPP-Dienstanbieter angegeben werden, dass der Inhalt des benutzerspezifischen Spoolfileparameters TariffOption mittels des optionalen TLV-Parameters 0x1500 ausgetauscht (gesendet und/oder empfangen) wird. Bei Verwendung von MM1, MM7 oder EAIF können hiermit zusätzliche HTTP-Header-Parameter angegeben werden (z.B. MapUserValue=uaprofile|X-WAP-PROFILE um ein User Agent Profile mitzusenden bzw. zu empfangen). Bei Verwendung eines SMS über HTTP Anbieters können auch die standard Spoolfileparameter den vom Anbieter vorgegebene URI-Parametern zugeordnet werden (nur ab Professional-Edition).

MaxAllowedConnections=
Gibt die maximale (gleichzeitige) Anzahl eingehender Verbindungen an, die für den entsprechende Provider-Definition erlaubt ist. Mit diesem Parameter kann die Anzahl der gleichzeitigen Verbindungen pro Kunde (Providerdefinition) limitiert werden (nur ab VXMSC-Edition).

MaxMsg=
Gibt die maximale Anzahl von Nachrichten an, die innerhalb einer einzelnen Verbindung versendet werden können. Ist dieser Parameter definiert, so werden bis zu der entsprechenden Anzahl Nachrichten versendet und danach automatisch die Verbindung beendet und falls erforderlich eine neue Verbindung aufgebaut. Dies ist nötig, da einige Provider nur eine begrenzte Anzahl Nachrichten pro Verbindung zulassen. Im Servermodus bewirkt dieser Parameter, dass max. entsprechend viele Nachrichten bearbeitet werden und der Server dann zum nächsten Provider wechselt.

MaxSplit=
Gibt die max. Anzahl Segmente an, in die eine lange SMS zerlegt werden soll. Dieser Wert kann für jede Nachricht mittels des Kommandozeilenparameter -N (Split= in einer Spooldatei) individuell überschrieben werden. Ist weder in der cfg-Datei noch in der Providerdefition noch für die Nachricht selbst ein Wert angegeben wird pro Nachricht nur eine einzelne SMS (ein Segment) versendet.

MaxThroughput=
MaxThroughputIn=
MaxThroughputOut=
Gibt (optional) den maximalen Durchsatz für einen bestimmten Provider an. Standardmäßig bezieht sich der Wert auf den max. Durchsatz pro Sekunde. Dies kann verändert werden indem durch einen Schrägstrich (/) getrennt ein anderes Zeitintervall angegeben wird (z.B.: MaxThroughput=100 bedeutet max. 100 Nachrichten/Sekunde; MaxThroughput=1200/60 bedeutet max. 1200 Nachrichten/Minute).
MaxThroughput limitiert den ein- UND ausgehenden Verkehr auf den jeweils angegeben Wert. Mit MaxThroughputIn= und MaxThroughputOut= können diese Werte unabhängig voneinander gesetzt werden.

MessagingMode=
Gibt bei SMPP 3.4 den Messaging Mode (zwischen 1 und 3) an oder bei UCP 4.0 ob es sich um eine 'SingleShot' Nachricht handelt (0 oder 1).

MM7Schema=
Gibt das für MM7 verwendete Schema an, z.B.:

http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-6-MM7-1-4

MNP= (siehe auch Mobile Number Portability (MNP))
Hier steht die Portierungskennung des entsprechenden Netzes. Anhand dieser Portierungskennung wird - falls in der cfg-Datei eine MNP-Funktion definiert wurde - beim Aufruf von SendXMS mit einer Telefonnummer (kein Alias aus dem Telefonbuch) überprüft, zu welchem Netz die entsprechende Telefonnummer gehört. Dieser Parameter kann pro Provider mehrfach definiert werden.

ModemInit=
Gibt ein zusätzliches Initialisierungskommando an. Dieses Kommando wird nach dem entsprechenden Kommando aus der Datei sendxms.cfg aufgerufen und ersetzt dieses nicht. In den meisten Fällen kann dieser Parameter entfallen. Er wird nur benötigt, wenn z.B. für einen Provider das Modem auf ein bestimmtes Protokoll eingestellt werden soll. Z.B. sollte bei einem Provider mit UCP-Protokoll das Modem auf V.42/LAPM eingestellt werden.

MsgDelay=<n>
Gibt eine Anzahl von Sekunden an (z.B. 0.2), welche zwischen dem Versenden von zwei Nachrichten innerhalb von einer Verbindung gewartet wird (wird normalerweise nicht benötigt).

MsgIdFilter=
Bei Verwendung eines SMS über HTTP Dienstanbieters kann man mittels dieses Parameters einen Filter definieren, welcher aus der vom Dienstanbieter zurückgegebenen Antwort (die nicht standardisiert ist) die vergeben MsgId extrahiert. Wenn der Dienstanbieter z.B. folgende Antwort auf einen erfolgreichen Senderequest sendet:

SUCCESS: SMS was scheduled for delivery (MessageIdentifier=30106CCE)

kann man z.B. mit folgendem Filter die MsgId extrahieren:

MsgIdFilter=/^SUCCESS: SMS was scheduled for delivery \(MessageIdentifier=([0-9,A-F]*)\)/\1/i

(siehe auch Filter für Nummernformate und SMS über HTTP).

MsgLen=
Hier wird die maximale Länge einer Nachricht (Anzahl Zeichen bzw. Anzahl Sekunden) angegeben. Bei dem Protokoll SKYPER wird dieser Parameter automatisch bestimmt. In der unregistrierten Version ist die maximale Länge auf 60 Zeichen bzw. 5 Sekunden beschränkt.

MsgType=
Gibt an, ob die Nachricht nur Ziffern (NUMERIC), beliebige Zeichen (ALPHANUMERIC) oder gar keine Zeichen (TONE) enthalten darf (ALPHANUMERIC ist der Standard). Bei dem Protokoll SKYPER wird dieser Parameter automatisch bestimmt.

MTBillingInterface=
Gibt an ob und welches Interface zum MT Billing benutzt werden soll. Momentan stehen 'IC3S' und 'Whatever Mobile' zur Auswahl.
IC₃S bedeutet, dass die T-Mobile Micropayment Platform benutzt wird. Der Parameter bewirkt, dass das Feld TariffClass (BillingIdentifier) vor dem Versenden geparst wird und ggf. die Platzhalter $y und $z durch die max. Anzahl von Teilsegmenten bzw. die Nummer des aktuellen Teilsegments ersetzt werden.
Whatever Mobile bedeutet, dass das Billing-Interface des Dienstanbieters Whatever Mobile GmbH benutzt wird. Wie die Nachrichten gebillt werden kann man über den Parameter MTBillingMode genauer definieren.

MTBillingMode=
Über den angegebenen Wert kann man steuern, ob kein Nachrichtensegment (1), alle Nachrichtensegmente (2), nur das erste Segment (3) oder nur das letzte Segmente (4) gebillt werden sollen.

Network=
Gibt den Netzwerktype (GSM, CDMA, TDMA, ...) an.

NoHttpAuthentication=true
Standardmäßig wird bei einer HTTP-Verbindung (sofern eine UsereId oder ein Password definiert wurde) die Basic Access Authentication verwendet. Da die meisten Anbieter von SMS über HTTP Diensten diese Authentifizierung nicht unterstützen kann man dies mit diesem Parameter verhindern (siehe auch SMS über HTTP) (nur ab Professional-Edition).

NoKeepAlive=
Gibt die maximale Anzahl Sekunden an, die die Leitung inaktiv bleiben darf. Ist dieses Limit erreicht wird die Verbindung abgebrochen. Dieser Wert muss größer als der ProtocolTimeout sein (nur ab Professional-Edition).

NotificationAddress=
Gibt eine Adresse an, an die die SMSC eine Bestätigung senden soll [nur UCP Funktion 51; nicht in Standard-Edition].

NotificationPID=<n>
Gibt den Typ der NotificationAddress an [nur UCP Funktion 51; nicht in Standard-Edition].

Folgende Wert sind für <n> definiert:

0100	Mobile Station
0122	Fax Group 3
0131	X.400
0138	Menu over PSTN
0139	PC appl. over PSTN (E.164)
0339	PC appl. over X.25 (X.121)
0439	PC appl. over ISDN (E.164)
0539	PC appl. over TCP/IP

NotificationType=<n>
Gibt an, welche Bestätigungen gesendet werden sollen [nur UCP Funktion 51, CIMD, SMPP und OIS].

Folgende Werte sind für UCP, CIMD und OIS für <n> zulässig:

0	none (default value)
1	Delivery Notification (DN)
2	Non-delivery Notification (ND)
3	DN + ND
4	Buffered message notification (BN)
5	BN + DN
6	BN + ND
7	all

Für SMPP 3.4 können beliebige Werte gemäß der Protokollspezifikation angegeben werden.

NotifyURL=
Gibt eine URL an, welche von einem OneAPI-Server zur Versendung von Notifications verwendet werden soll.

OadcInFilter=
Mit diesem Parameter kann ein Filter (bzw. bei mehrfacher Angabe eine Kette von Filtern) definiert werden, mit welchem eingehende Rufnummern (Absender) automatisch geprüft und ggf. umgeformt werden. Siehe auch Filter für Nummernformate.

OadcOutFilter=
Mit diesem Parameter kann ein Filter (bzw. bei mehrfacher Angabe eine Kette von Filtern) definiert werden, mit welchem ausgehende Rufnummern (Absender) automatisch geprüft und ggf. umgeformt werden. Siehe auch Filter für Nummernformate.

OkFilter=
Bei Verwendung eines SMS über HTTP Dienstanbieters kann man mittels dieses Parameters einen Filter definieren, welcher anhand der vom Dienstanbieter zurückgegebenen Antwort (die nicht standardisiert ist) erkennt, ob der Versand erfolgreich war (der Filter passt auf die Antwort) oder nicht (der Filter passt nicht). Wenn der Dienstanbieter z.B. folgende Antwort auf einen Senderequest sendet:

SUCCESS: SMS was scheduled for delivery (MessageIdentifier=30106CCE)

kann man z.B. mit folgendem Filter den Erfolg erkennen:

MsgIdFilter=/^SUCCESS:(.*)/\1/

(siehe auch Filter für Nummernformate und SMS über HTTP).

OriginatingAddress=01234..
Gibt die Absenderadresse (Telefonnummer) an, die für diesen Provider benutzt werden soll (nur ab Professional-Edition und nur wenn vom Provider/Device unterstützt).

Parity=NONE
Gibt die Art der Parität an (NONE, EVEN oder ODD). Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

Password=
Für manche Provider wird ein Passwort benötigt (bei UCP ist dies der Wert für Authentication Code), welches hier angegeben werden kann.

Phone=
Hier wird die Telefonnummer, über die Nachrichten an das entsprechende Netz gesendet werden können, angegeben. Ist das letzte Zeichen der Nummer ein '&', so bedeutet dies, dass beim Anwählen des Providers an diese Nummer die Nummer des Empfängers angehängt wird.
Bei Benutzung eines GSM-Zugangs geben Sie hier die SMSC-Adresse in der Form +<a><b><c> an, wobei <a> die Landesvorwahl (ohne Nullen), <b> die Ortsvorwahl (ohne Null) und <c> die Telefonnummer angibt. Bei vielen GSM-Modems kann auch einfach Phone=<SIM> angegeben werden. In diesem Fall wird versucht die SMSC-Adresse aus dem Modem auszulesen.
Dieser Parameter kann pro Provider mehrfach definiert werden.

PIN=
Gibt die PIN für einen TMobil-Vielnutzerzugang (CityRuf, Skyper) an (nur ab Professional-Edition).

PLMN=
Gibt die PLMN für den MM1 Provider an (dient der Zuordnung zwischen Provider-Definition und GSM-Gerät).

Port=<n>
Gibt den zu verwendenden Port (auf dem Zielrechner) für eine TCP/IP-Verbindung an. Der Port wird Ihnen vom Provider mitgeteilt.

PPPPhone=
Hier wird die Rufnummer angegeben, über welche eine PPP Verbindung aufgebaut werden soll. Dieser parameter wird nur in Verbindung mit LineType=PPP_TCP benötigt.

Prefix=
Hier steht die Vorwahl des entsprechenden Netzes. Anhand dieser Vorwahl wird beim Aufruf von SendXMS mit einer Telefonnummer (kein Alias aus dem Telefonbuch) überprüft, zu welchem Netz die entsprechende Telefonnummer gehört. Wenn PREFIX=* angegeben wird werden alle Nummern als gültig erkannt. Dieser Parameter kann pro Provider mehrfach definiert werden.

Priority=
Gibt eine Standardpriorität an, welche verwendet werden soll falls einer Nachricht nicht explizit eine Priorität (-I) zugeordnet wurde.

Protocol=
Hier muss TAP (Telocator Alphanumeric Protocol), TAPAIM (TAP-Protokoll mit AIM-Erweiterungen), SMPP (Short Message Peer to Peer; Logica), CIMD (Computer Interface to Message Distribution; Nokia), UCP (Universal Computer Protocol; CMG), OIS (Open Interface Specification; SMS2000 SEMA), ES201912_1, ES201912_2, GSM (Global System for Mobile communication), HTTP (SMS über HTTP (proprietär); siehe auch SMS über HTTP), UAP (USSD Service Protocol; Huawei), SIP_IM (SIP Instant Messaging; RFC3428), MM1 (Multimedia Messaging protocol 1) MM7 (Multimedia Messaging protocol 7), EAIF (External Application Interface; Nokia), ONEAPI_SMS, ONEAPI_MMS, ONEAPI_LOCATION, ONEAPI_CAPABILITY, ONEAPI_PAYMENT, UUS (User-User-Signaling), Voice, DTMF, Skyper oder CITYRUF stehen. UUS ist ein Euro-ISDN Dienstmerkmal, welches nicht in allen Ländern unterstützt wird und mit SendXMS nur über CAPI 2.0 genutzt werden kann. DTMF ist für Pagerdienste gedacht, bei welchen man über Tastentelefone Nachrichten für den Empfänger eingeben kann (CAPI 2.0 oder Voicemodem). Im Falle von Skyper muss das Modem so konfiguriert werden, dass XON/XOFF-Zeichen nicht gefiltert werden (zur Gegenstelle übertragen werden).

Bei UCP kann zusätzlich zwischen verschiedenen Sendefunktionen gewählt werden, indem in eckigen Klammern eingerahmt der zu verwendende Funktionscode (UCP[01], UCP[30] oder UCP[51]; im Falle eines Großkundenzugangs ist i.d.R. die Funktion 51 zu benutzen) angegeben wird. Bei den Funktionen 30 und 51 wird die Telefonnummer des Absenders und - falls definiert - eine Validity Period übertragen. Diese Funktionen werden aber nicht von allen Providern unterstützt.

Bei SMPP (ab Version 3.4) kann mit dem zusätzlichen Parameter UseAlwaysTransceiver=True angegeben werden, dass die Verbindung zur SMSC in jedem Fall mit einem BIND_TRANSCEIVER, anstelle eines BIND_TRANSMITTERs oder BIND_RECEIVERs, eröffnet wird (nur in seltenen Fällen nötig, wenn die SMSCs nur BIND_TRANSCEIVER akzeptiert).

Bei CIMD kann zusätzlich zwischen einer SMSC und einer USSD (CIMD[USSD]) Verbindung unterschieden werden.

Bei OIS kann zusätzlich zwischen dem General Access (OIS) und dem Direct Access (OIS[Direct]) unterschieden werden.

Bei MM1 kann zwischen MM1 über HTTP (MM1[HTTP] oder einfach MM1) (MMS-F oder WAP 2.0) und MM1 über WSP (MM1[WSP]) (WAP 1.x) gewählt werden.

ProtocolVersion=
Dient zur Unterscheidung von verschiedenen Protokollversionen (z.B. Protocol=CIMD, ProtocolVersion=2.0).

ProtocolTimeout=60
Gibt die Zeitdauer (in Sekunden) an, die das Programm auf eine Antwort vom Servicerechner wartet. Wenn dieser Wert nicht definiert wurde werden folgende Standardwerte benutzt, welche über den vom Protokoll vorgeschriebenen Grenzen liegen:

Für X.25, X.31 und TCP/IP-Verbindungen immer 10 Sekunden, ansonsten:

CIMD	30 Sekunden
ES201912_1	10 Sekunden
ES201912_2	10 Sekunden
GSM	160 Sekunden
OIS	30 Sekunden
SMPP	30 Sekunden
TAP	30 Sekunden
UCP	120 Sekunden

ReconnectDelay=<n>
Gibt eine Zeitspanne (in Sekunden) an, in der nach einem Verbindungsabbau keine neue Verbindung zu diesem Provider aufgebaut werden kann (nur im Servermodus).

SourceAddress=<w.x.y.z>
Gibt die zu verwendende IP-Adresse (des Ausgangsrechners) für eine TCP/IP-Verbindung an.

SourcePort=<n>
Gibt den zu verwendenden Port (auf dem Ausgangsrechner) für eine TCP/IP-Verbindung an. Der Port wird Ihnen vom Provider mitgeteilt.

SslCertChainFile=
Gibt den Dateinamen einer Zertifikatskette mit ihrem eigenen Zertifikat (nur für den entsprechenden Provider) an (PEM coded; das eigene Zertifikat muß an erster und das Zertifikat mit dem höchsten Level an letzter Stelle stehen) und überschreibt den Wert CertChainFile im Kapitel [SSL] in sendxms.cfg.

SslCertFile=
Gibt den Dateinamen ihres eigenen Zertifikats (PEM coded) (nur für den entsprechenden Provider) an und überschreibt den Wert CertFile im Kapitel [SSL] in sendxms.cfg.

SslKeyFile=
Gibt den Dateinamen ihres eigenen privaten Keys (PEM coded) (für ihr Zertifikat SslCertFile) an und überschreibt den Wert KeyFile im Kapitel [SSL] in sendxms.cfg.

SslPassword=
Gibt das Passwort (passphrase) ihres eigenen privaten Keys an (SslKeyFile) und überschreibt den Wert Password im Kapitel [SSL] in sendxms.cfg.

SslServerNameIndication=<domain>
Gibt den Namen der Domain (z.B.: smpp.sendxms.com) an, dessen Zertifikat der Server verwenden soll. Bei Servern, die mehrer Domains unter der gleichen IP hosten, ist dies ggf. notwendig um das richtige Zertifikat zu verwenden.

Stopbits=1
Gibt die Anzahl der Stopbits an (1 oder 2). Dieser Wert, falls vorhanden, überschreibt den Wert in sendxms.cfg.

SwapDlrAddresses=true
Gibt an, dass beim Empfang eines MM7-Statusreports (DeliverReportReq) die Absender- und Empängeradresse vertauscht werden sollen. Manche MMSCs vertauschen beide Adressen schon selbst, andere nicht.

SystemDescription=
Gibt eine SystemDescription (zwischen 0 und 9) an (nur für CIMD), welche standardmäßig benutzt wird.

SystemId=
Gibt die System ID an (nur SMPP). Fragen Sie bei Ihrem Provider nach dem entsprechenden Wert.

SystemType=
Gibt den System Type an (nur SMPP). Fragen Sie bei Ihrem Provider nach dem entsprechenden Wert.

TariffClass=
Gibt eine TariffClass (CIMD, zwischen 0 und 99) bzw. den BillingIdentifier (UCP 4.0) an, welche standardmäßig benutzt wird.

ThrottledDelay=
Gibt eine Anzahl Sekunden an, die nach einem Throttled-Error (nur SMPP und UAP) gewartet wird bis weitere Protokollaktionen gestartet werden.

TimeOffset=
Gibt die Zeitdifferenz zwischen der lokalen Zeit und der der SMSC in Minuten an. Mit diesem Parameter werden die Werte für Validity- und DeferredDelivery korrigiert (nur bei UCP und CIMD; die anderen Protokolle unterstützen direkt verschiedene Zeitzonen).

TransTable=tap.ctt
Gibt eine Zeichenübersetzungstabelle an (siehe Zeichenübersetzungstabellen). Im Falle von SMS über HTTP kann mit diesem Parameter ein spezielles Encoding (für die URL) definiert werden (Standard ist UTF-8).

UCP60Password=
Falls von einem UCP-Provider die Passwort-Option benutzt wird, wird hier das Passwort angegeben, welches zum Beginn einer Sitzung mit der UCP-Funktion 60 übertragen wird. Dies ist i.d.R. nur - wenn überhaupt - bei Großkundenzugängen notwendig. In diesem Fall muss auch noch der Parameter USEUCP60=true gesetzt werden (nur ab Professional-Edition).

URI=
Gibt den URI für einen HTTP Post Request (z.B. MM1, MM7, EAIF) an. Für eingehende Verbindungen muss die von der Gegenstelle angeforderte URI /SendXMS/<provider> (<provider> entspricht dem Namen des Providereintrags) lauten.

UseAimCharacterTranslation=true
Schaltet die erweiterte Zeichensatzkodierung ein (nur TAPAIM) ein.

UseOtoA=true
Schaltet die Benutzung des OTOA Parameters (nur UCP) ein. Dieser Parameter wird für alphanumerische und internationale Absendenummern benötigt, aber zumindest von D2 nicht über den öffentlichen Zugang unterstützt.

UserId=
Für manche Provider (CIMD oder UCP (Funktion 60)) wird eine UserID benötigt, welche hier angegeben werden kann. Im Falle von UCP kann die UserId in der Form <opid>:<userid> (aber auch einfach nur <userid>) angegeben werden.

UseUCP60=true
Gibt an, dass vor dem Versenden von SMS eine Sitzung (mit UCP-Funktion 60) eröffnet werden muss. Weiterhin sollte der Parameter UCP60PASSWORD gesetzt werden (nur ab Professional-Edition).

VASID=
Gibt die Value Added Service Identification (nur ab Professional-Edition).

VASPID=
Gibt die Value Added Service Provider Identification (nur ab Professional-Edition).

WaitAfterConnect=
Bei manchen Providern (mit UCP-Protokoll) muss nach dem Connect, bevor die erste Nachricht versendet wird, noch eine Pause eingelegt werden. Dieser Parameter gibt die Länge der Pause (in Sekunden) an. Dies ist anscheinend nur nötig, wenn das Modem nicht auf V.42/LAPM gesetzt ist. Falls möglich ist es der bessere Weg, in ModemInit (s.u.) einen entsprechendes AT-Kommando anzugeben.

WindowSize=
Gibt die max. Anzahl von Nachrichten an, welche gleichzeitig gesendet werden können ohne auf eine entsprechende Bestätigung warten zu müssen (Default=1). Gegenüber der synchronen Übertragung (nach jeder übertragenen Nachricht wird auf die entsprechende Bestätigung gewartet) ergibt dies eine bessere Performance (nur ab Professional-Edition).

WspEncodingVersion=1.3
Setzt die WSP Encoding-Version z.B. bei Benutzung von EAIF oder MM1.

sendxms.pro Beispiel:

  
    [D1]

    Phone=01712092522

    Protocol=TAP

    Prefix=+49171

    MsgType=ALPHANUMERIC

    MsgLen=160

sendxms.pbk

Hier können zu den einzelnen in sendxms.pro definierten Telefonnetzen (jeweils ein eigens Kapitel) Kürzel (Alias) für Telefonnummern definiert werden. Jedes Kürzel steht in einer eigenen Zeile und danach durch '=' getrennt die zugehörige Nummer (mit Vorwahl). Das Telefonbuch steht nur in der registrierten Version zur Verfügung!!!!

sendxms.pbk Beispiel:


    [D1]

    max=01711234567        ; Max Müller

Zeichenübersetzungstabellen

Da die verschiedenen von SendXMS unterstützten Protokolle per Definition verschiedene Zeichensätze verwenden und viele Provider diese Zeichensätze nochmals modifizieren, bietet SendXMS die Möglichkeit für jeden Provider eine eigen Übersetzungstabelle zu definieren. Ist zu einem Provider keine explizite Tabelle angegeben wird eine Standardtabelle benutzt. Um eine Tabelle einem Provider zuzuordnen wird eine Datei mit folgendem Format definiert und als Parameter TransTable bei der entsprechenden Providerdefinition angegeben:
Die Standardzeichen werden in einer Tabelle CharacterTable=00 angegeben. Der hier angegeben Wert 00 steht für das standard GSM-Alphabet. Es können mehrere Tabellen mit verschiedenen Codes (Language Identifier) definiert werden (siehe 3GPP TS 23.038).
Für jedes einzelne Zeichen wird je eine Zeile mit zwei durch Komma getrennte Hex-Codes eingegeben. Der erste Code gibt den Zeichencode (UCS-2) des zu wandelnden Zeichens (a) an. Der zweite Wert den vom Provider benutzten Code für das in der ersten Spalte angegebene Zeichen.
Da das GSM-Alphabet 7 Bits benutzt können nur 128 Zeichen kodiert werden. Für einige wichtige Zeichen gibt es die Möglichkeit diese Zeichen mittels einer Escape-Sequenz zu kodieren (bei Nutzung solcher Zeichen verringert sich die max. Anzahl von Zeichen pro SMS). Hierzu muß zunächst mit dem Parameter EscapeChar=1B ein spezielles Zeichen (hier Escape) definiert werden. Die Zeichen selbst werden in einer Tabelle ExtensionTable=00 im gleichen Format wie oben angegeben.
Als Beispiele können die Dateien ctt/gsm.ctt und ctt/cimd.ctt betrachtet werden. Bitte ändern sie diese Dateien nicht. Falls erforderlich kopieren sie bitte eine Originaldatei und modifizieren sie diese Kopie.

Filter für Nummernformate

Da bei manchen Verbindungen zu einer SMSC/MMSC die übertragenen Nummern ein ganz bestimmtes Format haben müssen (z.B. immer im internationalen Format, internationales Format ohne führende '00' oder nationales Format) bietet SendXMS die Möglichkeit pro Providerdefinition verschiedene Filter zu definieren. Durch Mehrfachangabe können ganze Ketten aufgebaut werden, welche in der angegebenen Reihenfolge abgearbeitet werden, bis ein Filter auf die entsprechende Zeichenkette (z.B. die Zielrufnummer) passt. Es lassen sich sowohl für die Zielrufnummer als auch für die Absendenummer Filter(-listen) definieren, sowohl für eingehende Nachrichten als auch für ausgehende Nachrichten. So ist es z.B. möglich dass beim Versenden einer Nachricht die Zielrufnummer (falls die SMSC dies benötigt) automatisch immer in ein internationales Format ohne ein führendes '+' bzw. ohne führende '00' umwandeln zu lassen. Der Benutzer kann die Zielrufnummer in einem beliebigen Format (z.B. 0049..., +49... oder 0...) angeben. Bei eingehenden Nachrichten kann man ggf. Filter definieren, welche grundsätzlich ein '+' vor jede eingehende Zielrufnummer setzen.

Ein Filter wird als regulärer Ausdruck (POSIX 1003.2) angegeben. Der Filter besteht immer aus zwei Teilen, welche durch einen Delimiter ('/') getrennt angegeben werden. Der erste Teil des Filters ist der reguläre Ausdruck (RE). Falls dieser RE auf die Zeichenkette (Zielrufnummer oder Absendenummer) passt, wird die Zeichenkette durch den im zweiten Teil angegebenen Ausdruck ersetzt. Innerhalb des zweiten Ausdrucks können feste Ziffernfolgen und/oder Rückwärtsreferenzen angegeben werden. Eine Rückwärtsreferenz wird in der Form \<n> angegeben, wobei <n> Werte zwischen 1 und 9 annehmen kann. Die Rückwärtsreferenz \1 bezieht sich auf den ersten Teilausdruck (erste öffnende Klammer) im RE. Am Ende einer Filterdefinition können noch folgende Attribute angegeben werden:

i	Groß-/Kleinschreibung ignorieren
g	Globales Matchen, d.h. alle Vorkommnisse finden
m	Interpretation der Zeichenkette als mehrere Zeilen
c	Fahre mit der nächsten RE in der Liste fort, auch wenn die aktuelle RE passt

Hier einige Beispiele:


AdcOutFilter=/^(\+|00)([0-9]*)/\2/

AdcOutFilter=/^(0)([0-9]*)/49\2/

Diese Filter bewirken, dass vor dem Versenden einer Nachricht überprüft wird ob die Zielrufnummer im internationalen Format (+... oder 00...) angegeben ist (erster Filter) oder im nationalen Format (0...) (zweiter Filter). Wenn der erste Filter passt wird die Nummer mittels \2 in eine international Nummer ohne Prefix (ohne + bzw. 00) gewandelt. Wenn der erste Filter nicht passt wird der zweite Filter geprüft und falls dieser passt (Nummer beginnt mit einer 0) wird mittels 49\2 der Nummer ohne die führende 0 die Zeichenfolge '49 vorangestellt.
Aus +491711234567, 00491711234567 oder 01711234567 wird also jeweils 491711234567.
Aus +123456789 wird 123456789.


AdcOutFilter=/^(\+49|0049|0)(164|168|1691)([0-9]*)/\3/

Dieser Filter bewirkt, dass vor dem Versenden einer Nachricht überprüft wird ob die Zielrufnummer eine der deutschen Vorwahlen 0164, 0168 oder 01691 (im internationalen oder im nationalen Format) hat. Falls der Filter zutrifft wird die komplette Vorwahl gelöscht.
Aus +491681234567 oder 01681234567 wird also jeweils 1234567.
Aus +123456789 wird +123456789 (bleibt unverändert).


AdcInFilter=/^(\+491|00491)([0-9]{5})(0*)/\2/

Dieser Filter bewirkt, dass bei eingehenden Nummern (Zielrufnummern), welche mit +491 oder 00491 beginnen, 5 weitere Ziffern haben und mit einer beliebigen Anzahl Nullen enden die 5 Ziffern (Kurzwahl) ausgefiltert werden.
Aus +49112345000, 00491123450 oder +49112345 wird also jeweils 12345.
Aus +112345000 wird +112345000 (bleibt unverändert).


OadcOutFilter=/(^([0-9]{0,3}:){0,2})?((\+?[0-9]+)$|(([A-Z0-9]*)([^A-Z0-9]*)))/\1\4\6/ig

Dieser Filter bewirkt, dass bei der Absendenummer alle Zeichen, die keine Ziffern oder Buchstaben sind, gelöscht werden. Ein führendes +-Zeichen oder die Angabe von TON/NPI bleiben erhalten.

Sprachnachrichten

SendXMS kann außer mit Mobiltelefonen und Pagern auch mit "gewöhnlichen" Telefonen kommunizieren und Sprachnachrichten abspielen bzw. aufnehmen. Hierzu ist es nötig ein Voicemodem, VoIP oder CAPI 2.0 zur Kommunikation zu benutzen. In der Providerdatei (sendxms.pro) sind Einträge zur Sprachkommunikation vordefiniert. Um eine Sprachnachricht abzuspielen muss die entsprechende Nachricht im nativen Kodierungsformat des zu benutzenden Devices vorliegen (diese Formate unterscheiden sich leider zwischen den verschiedenen Modemherstellern). Um eine Nachricht in einem anderen Format abzuspielen müssen entsprechende Konvertierungsprogramme vorgeschaltet werden. Solche Konvertierungsprogramm sind in großer Zahl frei erhältlich (z.B. sox oder mgetty+sendfax). Zum Abspielen einer Sprachnachricht wird SendXMS genau wie zum Versenden einer Textnachricht aufgerufen, nur dass explizit der vordefinierte Provider VOICE angegeben werden muss:


sendxms -pVOICE 07246942484 -fvoice.dat

oder


sendxms -pVOICE 07246942484 < voice.dat

In beiden Fällen wird die angegeben Nummer angerufen und die Sprachnachricht, die unter der Datei voice.dat gespeichert ist, abgespielt.

Bei Verwendung von VoIP oder CAPI 2.0 können WAV-Dateien direkt abgespielt werden, wenn Sie im aLaw oder uLaw Format mit 8 kHz, 1 Kanal und 8 Bit vorliegen. Bei anderen Geräten muss die Nachricht im nativen Kodierungsformat des Gerätes vorliegen, welches man am Besten mit SendXMS selbst mit folgendem Aufruf aufnimmt:


sendxms -pVOICE 07246942484 -fvoice.dat -aRECEIVE

Servermodus

In der registrierten Version (ab Server-Edition) von SendXMS gibt es einen zusätzlichen Servermodus (-q<n>). Mit diesem haben Sie die Möglichkeit eine SendXMS-Instanz laufen zu lassen, welche in regelmäßigen Abständen ein Spoolverzeichnis kontrolliert und eventuell vorhandene Nachrichten versendet. Hierdurch ist es möglich Nachrichten zu sammeln und zusammen, innerhalb einer einzelnen Verbindung, zu versenden, was die Performance erhöht und Geld spart. Sobald eine SendXMS-Instanz im Servermodus läuft werden von allen weiteren Instanzen deren Nachrichten automatisch gespoolt, anstatt sie direkt zu versenden. Durch zusätzliche Parameter kann SendXMS aber auch, unabhängig davon ob ein Server läuft oder nicht, dazu gebracht werden, die Nachrichten zu spoolen bzw. sie direkt zu versenden.

Ggf. (z.B. bei Verwendung eines GSM-fähigen Devices bzw. in Verbindung mit einem Großkundenzugang) ist es auch möglich Nachrichten (und Notifications (DLRs)) zu empfangen (SIM auslesen) und zu speichern (-aRECEIVE).

Um Nachrichten zu spoolen, kann man einfach SendXMS aufrufen oder die Spooldateien selbst generieren (z.B. durch ein kleines Programm; Datei währen der Generierung exklusiv sperren). Die Spooldateien müssen in dem Verzeichnis <SPOOLDIR> (aus sendxms.cfg) abgelegt werden, wobei es in diesem Verzeichnis für jeden Provider ein Unterverzeichnis (mit gleichem Namen wie in sendxms.pro definiert) gibt. Die Spooldateien müssen UTF-8 kodiert sein und sollten mit der Zeile
; encoding=UTF-8
beginnen. Pro Nachricht wird jeweils eine eigene Spooldatei angelegt. Im Folgenden ist eine einfache Beispielspooldatei angegeben:


; encoding=UTF-8

[D1]

Phone=491711234567

XMS=Dies ist eine Beispielspooldatei.

Folgende Schlüsselworte werden interpretiert (die meisten sind optional):

Action=
Gibt den Type der Anforderung an. Mögliche Werte sind SEND, DELETE, RECEIVE, QUERY (Kommandozeilenparameter -a).

AddCodes=
AddInfo=
AddCodes und AddInfo beinhaltet ggf. zusätzliche protokollspezifische Informationen und werden wie folgt belegt:

negative response
Protokoll	addCodes	addInfo
GSM	error code	"CME ERROR" or "CMS ERROR"
CIMD	Error Code (900)	Error Text (901)
SMPP	Command Status
OIS	result
UCP	Ec (error code)
HTTP	HTTP response code
OneAPI_SMS	HTTP response code
MM1	StatusCode	StatusText
MM7	StatusCode	StatusText
EAIF	StatusCode	StatusText
OneAPI_MMS	HTTP response code
status report
Protokoll	addCodes	addInfo
GSM	TP-Status	TP-Service-Center-Time-Stamp; TP-Discharge-Time
CIMD	status code (061); status error code (062)	discharge time (063)
SMPP	message_status; Error_code	done_date
OIS	SM status; delivery failure reason	completition/intermediate time
UCP	Dst; Rsn
OneAPI_SMS		deliveryInfo
MM1	'DeliveryReport' oder 'ReadReply': (Read)Status; StatusExtension
MM7	'DeliveryReport' oder 'ReadReply': MMStatus; MMStatusExtension
EAIF	'DeliveryReport' oder 'ReadReply': (Read)Status; StatusExtension
OneAPI_MMS		deliveryInfo

AllowAdaptations=
Gibt an ob VASP eine Adaptierung des Inhalts einer MMs erlaubt (true oder false).

ChargedParty=
Gibt an welcher Seite eine MMS berechnet werden soll (Sender, Receiver, Both, Neither oder ThirdParty).

ChargedPartyID=
Die Adresse einer dritten Partei die eine MMS bezahlen soll.

Count=
Gibt die Anzahl der bisherigen Sendeversuche an. Falls die Nachricht nicht erfolgreich übertragen werden kann wird dieser Parameter von SendXMS automatisch erhöht, bis er das erlaubte Maximum (RetryCount) erreicht hat.

Date=
Gibt den ServiceCenterTimeStamp (z.B.: Tue, 09 Jan 2001 11:22:19 +0000) an.

DCS=
Gibt das zu verwendende DataCodingScheme (dezimal) an (siehe GSM 03.38).

DeferredDelivery=
Gibt Datum/Uhrzeit an, wann die Nachricht von der SMSC/MMSC ausgeliefert werden soll (Kommandozeilenparameter -D). Siehe auch Zeitversetztes Senden und Gültigkeitsdauer.

Device=
Gibt das zu verwendende Device an (Kommandozeilenparameter -d).

DistributionIndicator=
Gibt an ob der Inhalt einer MMS verteilt werden darf (true oder false).

DoNotDisturb=true
Falls für den verwendeten Dienstanbieter (Providerdefinition) DoNotDisturbTime Werte definiert sind müssen diese für die entsprechende Nachricht berücksichtigt werden. Hiermit kann z.B. verhindern werden, dass Werbenachrichten Nachts versendet werden. Solche Nachrichten werden erst versendet sobald die aktuelle Zeit ausserhalb der angegebenen DoNotDisturbTime Definitionen liegt (nur in Professional-Edition und höher).

LocalId=
Gibt die UserID des Absenders (default) oder eine eindeutige (lokale) Id für die Nachricht an (Kommandozeilenparameter -o). Dieser Parameter hat nichts mit der Absendernummer (die beim Empfänger angezeigt wird zu tun) und kann für interne Zwecke benutzt werden.

MaxRecipients=
Gibt die max. Anzahl Empfänger (zwischen 1 und 256) an, die innerhalb eines Datenpakets erlaubt sind. Sind für eine Nachricht mehr Empfänger angegeben, so werden nacheinander mehrere Datenpaket mit der jeweils erlaubten max. Anzahl versendet.

MessagingMode=
Gibt bei SMPP 3.4 den Messaging Mode (zwischen 1 und 3) an oder bei UCP 4.0 ob es sich um eine 'SingleShot' Nachricht handelt (0 oder 1).

MmsMessageClass=
Gibt bei MMS den Wert der Nachrichtenklasse (X-Mms-Nessage-Class) an.

MsgId=
Gibt die MsgID einer Nachricht an (Kommandozeilenparameter -G). Die MsgID wird von der SMSC/MMSC vergeben und wird z.B. zum Löschen einer Nachricht oder zur Statusabfrage benötigt.

MsnOut=
Gibt die zu verwendende (ausgehende) MSN an (Kommandozeilenparameter -m, nur bei ISDN).

OriginatingAddress=
Gibt die Absendernummer an, die beim Empfänger angezeigt wird (Kommandozeilenparameter -O).

Phone=
Gibt die Empfängernummer an. Ab der Professionl-Edition kann dieser Parameter mehrfach angegeben werden. Sofern mehrere Empfänger angegeben sind, wird versucht (abhängig vom verwendeten Protokoll) die Nachricht an möglichst viele Empfänger auf einmal zu versenden. Falls dies nicht möglich ist wird die Nachricht mehrfach versendet (immer an soviele Empfänger wie möglich).
Bei MMS-Nachrichten können auch noch die Felder To, Cc und Bcc (als durch Komma getrennte Liste) angegeben. Dies erfolgt aber nur informativ, für das Routing ist alleine das Feld Phone relevant.

PID=
Gibt den zu verwendende ProtocolIdentifier an (z.B.: PID=0x40 für eine PING Nachricht oder PID=0x5F für eine Return Call Message; siehe GSM 03.40).

ReplyPathRequest=true
Gibt an ob der Parameter ReplyPathRequest gesetzt werden soll (Kommandozeilenparameter -R).

Priority=
Gibt die Priorität der Nachricht an (Kommandozeilenparameter -I).

ReplaceIfPresent=1
Gibt an, dass eine alte Nachricht an die gleiche Zieladresse überschrieben werden soll (nur SMPP).

ServiceCode=
Gibt den ServiceCode der MMS an.

ServiceDescription=
Gibt einen Wert zwischen 0 und 99 an, welcher zur Abrechnung verwendet werden kann (nur CIMD).

ServiceType=
Gibt den service_type der Nachricht an (nur SMPP).

Split=
Gibt die max. Anzahl von SMS an, in die die angegebene Nachricht zerlegt werden soll (Kommandozeilenparameter -N). Ggf. kann dieser Parameter auch angeben (z.B. bei einem Userexitaufruf), dass es sich bei dem angegebenen Inhalt um das n-te Segment einer mehrteiligen Nachricht handelt. In diesem Fall wird der Parameter im Format x/y/z angegeben, wobei x die Anzahl der benötigten Segmente, y die Nummer des aktuellen Segments und z eine Referenznummer (bei allen Segmenten einer einzelnen Nachricht gleich) angibt.

StartTime=
Gibt Datum/Uhrzeit an, wann die Nachricht an das SMSC/MMSC übertragen werden soll (Kommandozeilenparameter -S). Siehe auch Zeitversetztes Senden und Gültigkeitsdauer.

StatusReportRequest=true
Gibt an ob der Parameter StatusReportRequest gesetzt werden soll (Kommandozeilenparameter -F).

Subject=
Gibt das Subject einer MMS an (Kommandozeilenparameter -U).

TariffClass=
Gibt eine TariffClass (CIMD, zwischen 0 und 99) bzw. den BillingIdentifier (UCP 4.0) an.

Template=
Gibt den absoluten Pfad zu einer Datei an, in welcher die zu übertragende Nachricht enthalten ist. Dies kann sinnvoll sein, wenn z.B. der gleiche Nachrichteninhalt an viele Tausend Empfänger versendet wird. Der Inhalt der angegebenen Datei überschreibt ggf. den unter XMS angegebenen Nachrichteninhalt.
Der Inhalt der angegebenen Datei muss UTF-8 kodiert sein.

TemplateSuffix=
TemplatePrefix=
Gibt den absoluten Pfad zu einer Datei an, in welcher der Anfang/das Ende der zu übertragende Nachricht enthalten ist. Dies kann sinnvoll sein, wenn z.B. der gleiche Nachrichteninhalt an viele Tausend Empfänger versendet wird. Zwischen dem Prefix und dem Suffix wird der unter XMS angegebenen Inhalt eingefügt. So kann z.B. eine Nachrichtenkampagne (MMS) generiert werden, welche immer ein gleiches Bild und/oder Video aber unterschiedlichen Text enthält.
Der Inhalt der angegebenen Datei muss UTF-8 kodiert sein.

UDH=
Gibt (für SMS oder EMS) den UserDataHeader (ohne Längenangabe) an (Kommandozeilenparameter -U). Es sollte nur der Teil, der sich in jedem Segment einer langen Nachricht wiederholt, angegeben werden. Die Teile die nur in einem einzelnen Segment vorkommen (EMS) werden im Nachrichtentext innerhalb der Tags <UDH>...</UDH> angegeben (mit XMSConv können solche Inhalte einfach generiert werden).

UsedDevice=
Gibt das Device (aus sendxms.cfg) an, welches für die Nachricht benutzt wurde.

UsedProtocol=
Gibt das Protocol an, welches zur Übertragung der Nachricht benutzt wurde.

UssdServiceCode=
Gibt einen USSD Service Code (SMPP, CIMD und UAP; 0-255) an.

ValidityPeriod=
Gibt Datum/Uhrzeit an, bis wann die Nachricht gültig bleiben soll (Kommandozeilenparameter -V). Siehe auch Zeitversetztes Senden und Gültigkeitsdauer.

XMS=
Die Nachricht selbst. Die Zeichen <TAB> (0x09), <LF> (0x0A), <CR> (0x0D) und <Backslash> (0x5C) werden mit einer Escapesequenz als '\t', '\n', '\r' bzw. '\\' angegeben.

Bei Benutzung von ONEAPI_Payment können zusätzlich die in der GSMA Protokolldefinition angegebenen Parameternamen als Schlüsselworte verwendet werden.

ODBC Interface

Standardmäßig werden Spooldateien von SendXMS im Dateisystem abgelegt/gesucht. Unabhängig von dem unten beschriebenen Spool-API besteht ab der Professional-Edition die Möglichkeit die Spooldateien per ODBC direkt mit einem Datenbanksystem auszutauschen. Hierzu müssen die Zugangsdaten für das verwendete Datenbanksystem in der cfg-Datei konfiguriert werden (siehe auch Konfiguration). Die ODBC Datenquelle muss natürlich auch auf Betriebssystemebene konfiguriert (und getestet) werden. Auf Datenbanksystemebene muss eine Datenbank mit den entsprechenden Tabellen und StoredProcedures angelegt werden. Nach erfolgreicher Installation von SendXMS befindet sich im Unterverzeichnis samples (im Installationsverzeichnis) die Datei spoolapi.mysql welche eine Datenbankdefinition zur Nutzung mit MySQL/MariaDB (und MyODBC) enthält und welche natürlich entsprechend an andere Datenbanksystem angepasst werden kann. Unter Unix/Linux sollte unixODBC als ODBC-Manager verwendet werden.

Spool-API

Standardmäßig werden Spooldateien von SendXMS im Dateisystem abgelegt/gesucht. Ab der Professional-Edition steht ein Spool-API zur Verfügung, über welches man dies abändern kann und somit z.B. in der Lage ist die Daten direkt mit einer Datenbank auszutauschen. Hierfür muss ein SharedObject (eine DLL) mit bestimmten Funktionen zur Verfügung gestellt werden. Der Name des SharedObjects (der DLL) wird mit dem Parameter SpoolAPI in der verwendeten .cfg-Datei angegeben (im Kapitel [SendXMS]). Wird die dort angegeben Datei nicht gefunden oder kann eine (oder mehrere) Funktion nicht geladen werden wird das standard Spool-API (Dateisystem) verwendet.

Eine Implementierung des Spool-APIs muss threadsafe sein! Jede Funktion gibt im Falle einer erfolgreichen Ausführung eine 0 als Returncode zurück. In der Initialisierungfunktion des Spool-APIs kann ein Zeiger auf eine interne Struktur zurückgegeben werden, welcher von SendXMS bei jedem weiteren Aufruf als Parameter verwendet wird. Über diese (beliebige) Struktur kann die Nutzung von globale Variablen vermieden werden.

Das Spool-API bildet in etwa die Architektur nach, die auch mit dem Dateisystem benutzt wird. So wird auch hier zwischen SPOOLDIR, RECEIVEDIR, SENTDIR und UNSENTDIR unterschieden. Ob diese Unterscheidung tatsächlich in der Implementierung verwirklicht wird is irrelevant.

Die Datenübergabe erfolgt im Spoolfileformat (UTF-8 kodiert) (siehe auch Servermodus). Ob die Daten genau in diesem oder einem beliebigen anderen Format abgespeichert werden ist ebenfalls irrelevant.

Datensätze müssen jeweils exklusiv (pro Thread) gelockt werden um eine Mehrfachbearbeitung zu verhindern.

Folgende Funktionen müssen von einer Implementierung des Spool-APIs zur Verfügung gestellt werden:

#define XMS_SPOOLDIR 0     /* messages to send */

#define XMS_RECEIVEDIR 1   /* received messages */

#define XMS_UNSENTDIR 2    /* messages which couldn't be sent */

#define XMS_SENTDIR 3      /* already sent messages */



/* initialise the API; returns a pointer to any Userdata and the version of the implemented API */

int xmsSpoolApiInit (void **userdata, int *version);



/* release locks, memory, ... */

int xmsSpoolApiExit (void *userdata);



/* generate a list with keys of messages in the given dir; return -1 if the list is empty */

int xmsSpoolApiOpenMsgList (void *userdata, int dir, char *provider);



/* lock the next messages, allocate memory (sets *xmsLen to the size of the message) and return it; return -1 if no more messages are available  */

int xmsSpoolApiGetNextMsg (void *userdata, int dir, char *provider, char *key, int maxKeyLen, char **xms, int *xmsLen);



/* free the memory allocated in xmsSpoolApiGetNextMsg (but do not release the lock!)*/

int xmsSpoolApiFreeMsg (char *xms);



/* free the previously generated list */

int xmsSpoolApiCloseMsgList (void *userdata, int dir, char *provider);



/* unlock the given record */

int xmsSpoolApiUnlock (void *userdata, int dir, char *provider, char *key);



/* inserte a new record; returns the generated primary key */

int xmsSpoolApiInsert (void *userdata, int dir, char *provider, char *key, int maxKeyLen, char *xms, int xmsLen);



/* update the given record and unlocks it */

int xmsSpoolApiUpdate (void *userdata, int dir, char *provider, char *key, char *xms, int xmsLen);



/* delete the given record */

int xmsSpoolApiDelete (void *userdata, int dir, char *provider, char *key);

SNMP

Ab der Professional-Edition kann SendXMS so konfiguriert werden, dass bei bestimmten Ereignissen SNMP Traps (Notifications) an einen SNMP-Dämon gesendet werden. Bei einem Trap handelt es sich um einen unbestätigten Alarm, mit welchem ein Überwachungssystem automatisch über eine Zustandsänderung informiert wird. SendXMS verwendet hierzu SNMPv2c. Traps werden nur bei Verwendung einer Professional-Edition (oder höher) unterstützt und nur verwendet, wenn SendXMS im Servermodus (Queuedelay >= 0) läuft. Traps werden für folgende Ereignisse unterstützt:

ein SendXMS-Prozess wurde gestartet oder beendet
ein SendXMS-Prozess wurde (re-)initialisiert
eine Protokolsitzung (z.B. SMPP) wurde auf- oder abgebaut
eine KeepAlive wurde empfangen oder versendet
Ping (regelmäßiger Versand eines Traps in festen Zeitabständen)

Die Konfiguration der SNMP Traps erfolgt in der Datei sendxms.cfg im Kapitel [SNMP]. Wenn in diesem Kapitel eine Zieladresse/-port definiert ist werden standardmäßig alle o.g. Traps versendet. Jeder einzelne Trap kann jedoch manuell durch Angabe eines entsprechenden Parameters (z.B. KeepaliveTrap=false) deaktiviert werden. Zusätzlich kann eine zu verwendende Community sowie der Abstand zwischen zwei Ping-Traps (Default ist 60 Sekunden) definiert werden.

Die von SendXMS generierten Traps können folgende Informationen enthalten:

die PID (ProcessID)
das aktuelle Datum/Uhrzeit (GMT)
den Namen des verwendeten Providereintrags
das verwendete Device

Die entsprechende MIB-Datei (bai.mib) befindet sich nach der Installation von SendXMS im Unterverzeichnis samples (im Installationsverzeichnis).

Userexit

Mit dem Parameter -u kann ein Userexit angegeben werden. Dies ist eine Funktion in einem Shared-Object/DLL (empfohlen), ein externes Programm oder eine Batch-/Scriptdatei, die von SendXMS immer dann aufgerufen wird, wenn eine Nachricht erfolgreich versendet oder empfangen wurde, eine Nachricht nicht gesendet werden konnte, eine Verbindung auf- oder abgebaut wurde, ... Mit einem Userexit kann somit z.B. eine Integration eines Datenbanksystem, einer Netzwerküberwachung (z.B. mittels Net-SNMP), eines Billingsystems oder ähnlichem erfolgen.

Wenn der Userexit ein externes Programm (also ein Executable oder eine Script-/Batchdatei) ist, erhält der Userexit als ersten und einzigen Eingabeparameter einen Code (cause), welcher angibt warum der Userexit aufgerufen wird. Der cause Code kann folgende Werte annehmen:

1	Nachricht erfolgreich versendet
2	Nachricht empfangen
3	Nachrichtenstatus (DLR) empfangen
4	Nachricht wurde gelöscht
8	MMS Notification Indication empfangen
98	Verbindung wurde gestartet
99	Verbindung wurde beendet
100	Programm wurde (re-)initialisiert
-1	Nachricht konnte nicht gesendet werden
-2	Hardwareproblem

Über eine Pipe (stdin) erhält der Userexit zudem den kompletten Inhalt einer Spooldatei übergeben. Das Spooldateiformat ist im Kapitel Servermodus beschrieben. Der Inhalt dieses Formats kann einfach interpretiert werden und beinhaltet alle zur Verfügung stehenden Informationen, welche beliebig vom Userexit verwendet werden können.

Der Userexit darf keine Ausgaben auf stdout (ebenfalls eine Pipe) machen. Sollten Ausgaben nötig sein müssen diese über stderr erfolgen. Ein Userexit sollte immer möglichst zeitnah beendet werden, da es ansonsten zu Timeouts bei der Verbindung zu einer SMSC kommen könnte. Der Userexit muss als Returncode eine 0 zurückgeben, damit die Transaktion korrekt beendet werden kann. Wenn der Userexit eine Wert ungleich 0 zurück gibt wird die entsprechende Transaktion abgebrochen (also eine empfangene Nachricht nicht gespeichert und auf der SMSC/MMSC nicht gelöscht). Bei einem Returncode < 0 ist wird eine Standardfehlermeldung (abhängig vom verwendeten Protokoll) an den Kommunikationspartner zurückgegeben. Bei einem Returncode > 0 und < 256 ist wird dieser Wert als ein UCP-Errorcode interpretiert und in einen, vom verwendeten Protokoll abhängigen, entsprechenden Retunrcode übersetzt. Bei einem Returncode > 255 ist wird dieser als ein protokollspezifischer Returncode interpretiert und dieser Wert minus 255 zurückgegeben.

Als Userexit kann auch eine Funktion (muss threadsafe sein) aus einer DLL bzw. aus einer so-Library (shared object) angegeben werden. Hierzu werden der Name der DLL bzw. der so-Library und der Name der Funktion durch ein Masterspace (@) getrennt (-u<dll>@<function>; für einen Java Userexit -ujava@<class>@<function>). Ein solcher Userexit bekommt den Inhalt der Spooldatei nicht über eine Pipe sondern direkt als zweiten Parameter (als Zeichenkette) übergeben. Der dritte Parameter gibt die Länge der Zeichenkette an. Der Inhalt des Spoolfiles (die übergebene Zeichenkette) darf NICHT verändert werden. Sollten Änderungen erforderlich sein müssen diese Änderungen (nur Schlüssel und Inhalt des geänderten Parameters) über den vierten Parameter zurück gegeben werden.

Ein Prototyp für einen Userexit-Funktion in einem shared object ist:

  
    int UserExit (int cause, char *xms, int xmsLen, char *changedXms);

Unter Windows sollte die Funktion wie folgt definiert werden:

  
    Borland-Compiler:    int __stdcall __declspec(dllexport) UserExit (...)
    

    MS-Compiler:         extern "C" int __declspec(dllexport) __stdcall UserExit (...)

/* Der MS-Compiler dekoriert die Funktion. Dies bewirkt, dass beim Aufruf also _UserExit@<n> angegeben werden muss (oder eine def-Datei verwendet werden muss, welche die Funktion mit dem richtigen Namen exportiert). */

Im Samples-Verzeichnis sind einfache Beispiele für einen Userexit sowie für ein Programm zum extrahieren der Attachments einer empfangenen MMS enthalten.

VXMSC-Edition

Mit der VXMSC-Edition ist es möglich eine virtuelle SMSC/MMSC zu emulieren. Z.Zt. wird hierfür sowohl UCP, SMPP, CIMD, OIS als auch TAP über TCP/IP unterstützt (mit z.B. einem CISCO-Router ist ebenfalls X.25, FrameRelay, ... möglich). Der Funktionsumfang entspricht dem Umfang der auch von der SendXMS-Professional-Edition unterstützt wird. Mit der VXMSC-Edition kann man sich natürlich auch weiterhin ganz normal als Client (XME) mit einer beliebigen SMSC/MMSC verbinden.

Eingehende Requests werden standardmäßig, wie bei den anderen Editionen auch, als Spooldateien (RECEIVEDIR) abgelegt. Die vom Anwender gewünschte Logik (z.B. die eines Gateways) muss entweder durch ein externes Programm oder (besser) durch einen entsprechenden Userexit implementiert werden. Der Userexit erhält gegenüber den anderen Editionen (siehe Userexit) auch folgende zusätzliche Status-Codes:

6	Nachricht wurde ausgeliefert
7	DeliverNotification wurde ausgeliefert
129	SubmitRequest wurde empfangen (Nachricht soll versendet werden)
130	StatusReportRequest wurde empfangen (Statusreport wird angefordert)
131	DeleteRequest wurde empfangen (vorhandener SubmitRequest soll gelöscht werden)
133	StartSessionRequest wurde empfangen
134	StopSessionRequest wurde empfangen

Bei eingehenden Submit-Requests wird weiterhin die von der VXMSC-Edition vergebene MsgID als localId übergeben.

Bei einem Verbindungsauf-/abbau und beim Starten/Stoppen einer Session enthalten die Felder adC bzw. oAdC die IP-Adresse und die Portnummer (lokal bzw. remote).

Bei einem StartSessionRequest (UCP Funktion 60, SMPP BIND Operation oder CIMD Funktion 1) wird die UserId der XME in der Variablen localId und das Passwort in addCodes übergeben.

Bei SMPP wird weiterhin in addInfo RECEIVER, TRANSMITTER oder TRANSCEIVER übergeben, je nachdem was für ein BIND-Request von der SME gesendet wurde. Die SME muss den SYSTEMTYPE=SendXMS verwenden.

Bei MM7/EAIF muss die von der Gegenstelle angeforderte URI /SendXMS/<provider> (<provider> entspricht dem Namen des Providereintrags (der VXMSC) mit dem der Request bearbeitet wird) lauten. Bei eingehenden MM7/EAIF Requests enthält addInfo die VASPID und addCodes die VASID.

Soll die Verbindungsanforderung abgelehnt werden muss der Userexit -1 als Rückgabewert übergeben.

Um eingehende Verbindungen als VXMSC anzunehmen wird einfach in der entsprechenden Providerdefinition der Parameter Detach=AcceptVXMSC angegeben. Dies bewirkt, dass SendXMS an den angegebenen Adresse(n)/Port(s) auf eingehende Verbindungen gewartet wird und ggf. eine entsprechende VXMSC-Session gestartet wird. Alternativ können eingehende Verbindungen auch über Tools wie inetd oder xinetd gestartet werden. Dies wird z.B. (inetd) in der Datei /etc/inetd.conf (und /etc/services) wie folgt definiert:


vxmscd     stream     tcp     nowait     root       /usr/local/sendxms/sendxms /usr/local/sendxms/sendxms -pTEST -aRECEIVE -Q0 --HANDLE=-1

ACHTUNG: meistens ist es besser von inetd aus ein Script aufrufen zu lassen, welches wiederum das o.g. Kommando aufruft. Falls in dem Kommando Dateien (userexit, cfg-Datei, ...) mitangegeben werden, sollte ein absoluter Pfad verwendet werden).

Der hier angegeben Provider TEST muss natürlich in sendxms.pro mit dem Protokoll UCP[51], SMPP, CIMD, OIS oder TAP definiert werden (kein DETACH angeben).

Damit die VXMSC Nachrichten zu einem Client übertragen kann müssen diese Nachrichten mit der Option -aDELIVER (Kommandozeile) gespoolt werden bzw. in den generierten Spooldateien jeweils die Zeile ACTION=DELIVER aufgenommen werden.

Zeitversetztes Senden und Gültigkeitsdauer

SendXMS bietet die Möglichkeit Nachrichten zu einem späteren Zeitpunkt, welcher über einen Kommandozeilenparameter (-S) angegeben wird, zu versenden. Wenn die Nachricht direkt gesendet (nicht gespoolt) werden soll, wartet SendXMS bis der angegebene Zeitpunkt erreicht ist und sendet die Nachricht dann. Falls die Nachricht gespoolt wird, wird sie vom Server erst zu dem angegeben Zeitpunkt bearbeitet.

Alternativ kann man zu einer Nachricht, welche sofort übertragen wird, mit dem Parameter -D einen Zeitpunkt angeben, zu dem die Nachricht von dem Servicerechner ausgeliefert werden soll.

Mit dem Parameter -V kann man eine Gültigkeitsdauer für eine Nachricht definieren. Ist diese angegeben wird eine Nachricht automatisch gelöscht, falls sie bis zu dem angegebenen Zeitpunkt nicht an den Empfänger ausgeliefert werden konnte.

Die entsprechenden Zeitpunkte werden jeweils entweder relativ (Anzahl Sekunden mit einem vorgestellten Plus-Zeichen (+), z.B. -S+3600) oder absolut (Uhrzeit und Datum in dem Format YYYYMMDDhhmmss (hh = Stunde, mm = Minute, ss = Sekunde, DD = Tag, MM = Monat, YYYY = Jahr), z.B. -V20080507170000) angegeben. Diese Parameter werden nicht von allen Protokollen/Providern unterstützt.

Funktionsauswahl

Mit SendXMS können nicht nur Kurznachrichten versendet, sondern auch der Status einer zuvor versendeten Nachricht abgefragt, eine noch nicht ausgelieferte Nachricht wieder gelöscht bzw. Nachrichten empfangen werden. Diese zusätzliche Funktionalität ist jedoch vom verwendeten Protokoll (UCP, TAP, GSM, ...) und vom verwendeten Provider abhängig. So sind diese Möglichkeiten in der Regel nur bei Mobilfunk-Netzen (GSM, CDMA, TDMA) und nicht bei Pager-Diensten verfügbar. Für diese erweiterte Funktionalität ist es weiterhin in der Regel notwendig, dass der verwendete Telefonanschluss über das Dienstmerkmal CLI (Calling Line Identifikation) verfügt (z.B. ISDN).

Die Auswahl der auszuführenden Funktion erfolgt auf der Kommandozeile mit dem Parameter -a<action>. Wird dieser Parameter nicht angegeben wird der Wert für <action> automatisch auf SEND gesetzt. Wird er angegeben kann zwischen SEND, RECEIVE, QUERY, DELETE und CHGPWD gewählt werden. Hierbei bedeutet:

SEND	es soll eine Nachricht versendet werden
QUERY	es soll der Status einer zuvor übertragenen Nachricht abgefragt werden
DELETE	es soll eine zuvor übertragene aber noch nicht ausgelieferte Nachricht gelöscht werden (nicht ausgeliefert werden)
RECEIVE	es sollen Nachrichten und/oder Notifications (DLRs) empfangen UND (im Servermodus) Nachrichten versendet werden
CHGPWD	es soll das Passwort für einen Provider, welcher UCP und zum Start einer Sitzung die UCP-Funktion 60 benutzt, geändert werden
CLEAN	es sollen alte Datein in den Spoolverzeichnissen (SpoolDir, ReceiveDir, SentDir, UnsentDir, StatisticDir, LocalIdDir, TmpDir) gelöscht werden. Standardmäßig werden bei einem solchen Aufruf (ohne weitere Parameter) alle Dateien die älter als 5 Tage sind gelöscht. Durch Verwendung des Parameters -q kann die Anzahl Tage verändert werden. ACHTUNG: eine falsche Konfiguration könnte dazu führen dass die gesamte Platte gelöscht wird!

In (fast) allen Fällen muss die Telefonnummer des Empfängers angegeben werden. Zum Löschen einer Nachricht muss zusätzlich die Identifikationsnummer/Timestamp der Nachricht (wurde nach dem Übertragen angezeigt) angegeben werden. Im Kapitel Aufrufsyntax sind einige Aufrufbeispiele angegeben.

Zum Empfang von Festnetz-SMS (oder auch bei UUS Nachrichten) muss eine SendXMS Instanz permanent auf eingehende Rufe von dem entsprechenden SMS-Gateway warten. Diese Instanz wird mit folgendem Kommando gestartet:
sendxms -p<provider> -aReceive
Wobei <provider> den Name der entsprechenden Providerdefinition (in sendxms.pro) des FestnetzSMS Gateways angibt. Die so gestartete Instanz wartet auf eingehende Rufe von einer der in der Providerdefinition angegebenen Rufnummern und nimmt diese an. Alle anderen eingehenden Rufe (von anderen Nummern) werden ignoriert. Sollen die Nachrichten im Servermodus empfangen werden ist es ausreichend in der Providerdefinition den Parameter Detach=Receive anzugeben.

Zum Empfang von MMS per MM7 oder EAIF muss dem MMSC-Betrieber ein Port mitgeteilt werden auf welchem SendXMS auf eingehende Verbindungen wartet. Dieser Port muss in sendxms.pro in einer eigenen Providerdefinition definiert werden. In dieser Providerdefinition müssen zusätzlich die Parameter Detach=AcceptXME, UserId=, Password= und URI=/SendXMS/<provider> gesetzt sein.

Aufrufsyntax

SendXMS wird wie folgt aufgerufen (in über 95% der Fälle einfach nur mit 'sendxms <nummer> <sms>'):

sendxms [Optionen] {<phoneNo> | <alias> -g<groupFile>} [{<message> | -f<msgFile>}]

Optionen sind (bitte beachten Sie die Groß-/Kleinschreibung; zwischen dem Optionsselektor und Optionswert keine Leerzeichen angeben (z.B.: -aSend und nicht -a Send)):

-a<action>	gibt die auszuführende Aktion an (SEND, RECEIVE, QUERY, DELETE oder CHGPWD)
-b<pbkFile>	gibt den Namen der Telefonbuchdatei an (sendxms.pbk)
-c<cfgFile>	gibt den Namen der Konfigurationsdatei an (sendxms.cfg)
-C<msgClass>	Nachrichten Klasse (SMS, EMS: 0-3; MMS: 128-131)
-d<device>	hiermit kann die Benutzung eines bestimmten Devices vorgegeben werden
-D<Sendezeit>	gibt den Zeitpunkt an, wann die Nachricht (vom Servicerechner) ausgeliefert werden soll
-f<msgFile>	gibt den Namen eines Files an, dessen Inhalt als Nachricht verschickt werden soll
-F	Status Report Request
-g<groupFile>	gibt den Namen einer Datei an, welche die Empfängernummern beinhaltet
-G<msgId>	gibt eine MsgID einer Nachricht an, welche gelöscht bzw. deren Status abgefragt werden soll
-h	zeigt die Hilfe an
-H	zeigt die Versionsnummer von SendXMS an
-i	installiert SendXMS (Servermode) als einen Service (nur Windows; falls in dem Kommando Dateien (userexit, cfg-Datei, ...) mitangegeben werden, sollte ein absoluter Pfad verwendet werden)
-I<priority>	gibt die Priorität der Nachricht an (0 (nieder) - 3 (hoch))
-l<spool file name>	gibt den Namen der Spooldatei (mit Pfad), die verarbeitet/versendet werden soll, an ('-' um Spooldatei von stdin zu lesen))
-m<MSN>	gibt die zu verwendende (ausgehende) MSN an (nur bei CAPI 2.0)
-M<SMS>	gibt die zu versendende Nachricht an (wird benötigt, wenn die Nachricht mit einem '-' beginnt)
-n	SendXMS sendet die Nachricht(en) direkt über das Modem, auch wenn z.Zt. ein Server läuft
-N<n>	zerlegt die angegeben Nachricht in bis zu <n> SMS (Standard ist 1)
-o<lokale Id>	setzt die sendende User-ID oder eine lokale Nachrichten-ID
-O<Absendernummer>	Angabe einer Absendernummer, welche beim Empfänger angezeigt wird (nur in Professional-Edition und höher)
-p<provider>	gibt den Provider zur angegebenen Telefonnummer an
-P<pid-Datei>	gibt den Namen der zu verwendenden PID-Datei an (Standard ist sendxms.pid)
-q<n>	startet SendXMS im Servermodus (Spoolverzeichnis wird alle <n> Sekunden überprüft); bei Verwendung zusammen mit dem Parameter -aCLEAN gibt <n> das Mindestalter (Anzahl Tage) von zu löschenden Nachrichten an
-Q<n>	startet SendXMS als VXMSC (Spoolverzeichnis wird alle <n> Sekunden überprüft)
-r<proFile>	gibt den Namen der Providerdatei an (sendxms.pro)
-R	Reply Path Request (siehe GSM 03.40)
-s	SendXMS spoolt die Nachricht(en), auch wenn z.Zt. kein Server läuft
-S<Startzeit>	gibt den Zeitpunkt an, wann die Nachricht versendet werden soll (vom lokalen Rechner)
-u<userexit>	gibt ein SharedObject (Windows DLL), ein Programm oder eine Batch-/Scriptdatei an die gestartet wird, wenn eine Nachricht gesendet oder empfangen wurde (Servermodus)
-U<userdataheader/subject>	für SMS, EMS: hexkodierter UserDataHeader (siehe GSM 03.40) ohne Längenangabe; nur der Teil des UDH der sich in jedem Teilsegement einer langen Nachricht wiederholt für MMS: Subject
-v	verbose; SendXMS zeigt die Kommunikation mit dem Kommunikationsdevice am Bildschirm an
-V<validity period>	gibt den Zeitpunkt an, bis wann die Nachricht gültig bleiben soll
-x	deinstalliert den Service SendXMS (nur Windows)
--ChargedParty=<cp>	gibt an welcher Partei die MMS berechnet werden soll (None, Sender, recipient, Both, ThirdParty
--ChargedPartyID=<cp>	gibt die Adresse einer dritten Partei an, welcher die MMS berechnet werden soll
--DCS=<dcs>	gibt das zu verwendenden DataCodingScheme an (siehe GSM 03.40; nicht in Verbindung mit -Z und -C verwenden)
--DCS=<dcs>	gibt das zu verwendenden DataCodingScheme an (siehe GSM 03.40; nicht in Verbindung mit -Z und -C verwenden)
--Distribution=<di>	gibt den DistributionIndicator an (true or false; only MMS)
--MessagingMode=<mm>	gibt den zu verwendende Messaging Mode (SMPP 3.4, 0-3) oder den Parameter SingleShot (UCP 4.0, 0-1) an
--ChargedPartyID=<cp>	gibt die Adresse einer dritten Partei an, welche die MMS bezahlen soll
--ReplaceIfPresent=1	gibt an dass eine alte Nachrichten an die gleiche Zielnummer ersetzt werden sollen (nur SMPP)
--ServiceCode=<sd>	gibt den ServiceCode der MMS an
--ServiceDesc=<sc>	gibt die ServiceDescription an (0-99; nur CIMD)
--ServiceType=<st>	gibt den service_type der Nachricht an (nur SMPP)
--TariffClass=<tc>	gibt die zu verwendende TarifClass (CIMD, 0-99) oder den BillingIdentifier (UCP 4.0) an
--UssdServiceCode=<sc>	gibt einen USSD Service Code (SMPP, CIMD und UAP; 0-255) an
-z<Zeichencodierung>	gibt die Zeichencodierung, in der die angegebene Nachricht kodiert ist, an (entweder einen wohldefinierten Singlebyte Zeichensatz wie (z.b. iso-8859-1), utf-8, utf-16 oder hex (für hexkodierte Nachricht))
-Z<Datencodierung>	gibt die Datencodierung für die ausgehende Nachricht an (GSM (7 Bit), binary (8 Bit) oder ucs2/utf16))

Z.B.: sendxms 0123456789 "Ich teste SendXMS."

Es ist immer mindestens ein Parameter - die Telefonnummer (ohne Leerzeichen; bei Verwendung von SMPP oder OIS kann die Telefonnummer (oder die Absendernummer (-O)) in der Form <ton>:<npi>:<phone> angegeben werden) des Empfängers bzw. ein Alias (Eintrag im Telefonbuch) - notwendig. Alternativ kann auch mit dem Parameter -g der Name einer Datei angegeben werden, welche die Nummern von mehreren Empfänger beinhaltet. Mit solch einer Datei kann eine Nachricht an beliebig viele Empfänger, welche auch über verschiedene Netze erreichbar sind, versendet werden. Eine entsprechende Datei muss folgendes Format haben:

  
    [<provider1>]

    PHONE=<nummer1>

    PHONE=<nummer2>

    PHONE=<nummer3>

    PHONE=<alias1>

    PHONE=<alias2>

    

    [<provider2>]

    PHONE=<nummer4>

Durch eckige Klammern eingerahmt werden Provider (müssen in der Datei sendxms.pro vorhanden sein) angegeben, zu welchen in den folgenden Zeilen Telefonnummern für Empfänger folgen. Pro Zeile wird eine Nummer (PHONE=...) bzw. ein Alias angegeben. In obigem Fall wird die Nachricht also an 5 Nummern des ersten Providers (während der selben Verbindung) gesendet. Außerdem wird die Nachricht auch noch an einen Empfänger von <provider2> gesendet.

Bei Verwendung von SMPP kann eine Nachricht auch eine auf der SMSC gepflegte Empfängerliste (Distribution List) gesendet werden. In diesem Fall muss der Name dieser Liste in der Form 999:0:<distribution list name> angegeben werden (anstelle einer Empfängernummer).

Als zweiter Parameter wird die zu versendende Nachricht in Hochkommata angegeben (ACHTUNG: Je nach verwendeter Shell werden bestimmte Zeichen von dieser interpretiert und ersetzt (z.B. '!') und/oder müssen anstatt Hochkommata doppelte Hochkommata angegeben werden). Eine auf der Kommandozeile angegebene Nachricht darf nicht mit einem Bindestrich beginnen (in diesem Fall muss die Nachricht mit dem Parameter -M angegeben werden). Alternativ kann die zu versendende Nachricht auch über eine Umleitung aus einer Datei angegeben werden (< msgFile) oder mit dem Parameter -f<msgFile>, wobei <msgFile> den Namen einer Datei angibt, deren Inhalt als Nachricht (zumindest die ersten n Zeichen) versendet wird. Wird beim Aufruf von SendXMS nur ein Parameter (Empfänger) angegeben, so wird die zu versendende Nachricht von der Konsole eingelesen. Soll eine Nachricht an einen Provider gesendet werden, welcher anhand der Nummer des Empfängers nicht eindeutig zu identifizieren ist, so muss über den Parameter -p<provider> der entsprechende Provider angegeben werden (Name wie er in der Datei 'sendxms.pro' definiert ist). Beispiel: Es soll eine Nachricht an einen Cityruf-Empfänger gesendet werden. Da SendXMS anhand der Cityruf-Nummer (7-stellige Nummer ohne Vorwahl) nicht erkennen kann, was dies für eine Nummer ist, muss zusätzlich beim Aufruf -pCityruf angegeben werden (bei D1-Nummern wird anhand der Vorwahl (z.B. 0171) erkannt, dass es sich um eine D1-Nummer handelt).

Binäre Nachrichten müssen in hexadezimaler Kodierung angegeben werden. Für jedes binäre Zeichen müssen also zwei Zeichen (0-9 und A-F) angegeben werden. Die Nachricht "ABC" entspricht z.B. in hexadezimaler Kodierung "414243". Für z.B. Klingeltöne oder Operator-Logos muss zusätzlich noch mit dem Parameter -U ein hexkodierter UserDataHeader (ohne Längenangabe) angegeben werden. Für einen (Smart Messaging) Klingelton ist dies z.B. -U050415811581 (siehe GSM 03.40 und Narrowband Sockets Specification (Intel, Nokia)). Anstelle des hexkodierten UserDataHeaders kann auch eine dieser vordefinierten Konstanten -URingtone, -UOperatorLogo, -UGroupLogo, -UPicture, -UvCard, -UvCalendar bzw. -UWapOTA verwendet werden (nur falls der Empfänger die Smart Messaging Spezifikation erfüllt).

Werden EMS-Nachrichten verschickt, so wird der EMS-spezifische UDH-Teil (der der nicht in jedem Segment einer langen Nachricht wiederholt wird) im Nachrichtenteil an der entsprechenden Stelle innerhalb der Tags <UDH>...</UDH> angegeben. Sofern dieser UDH-Teil Positionsinformationen enthält sind diese nicht relevant, da sie von SendXMS neu berechnet werden. Entsprechende Nachrichten können am einfachsten mit XMSConv generiert werden.

Wird SendXMS mit dem Parameter -q<n> gestartet, so läuft SendXMS als Server und überprüft alle <n> Sekunden das Spoolverzeichnis (SPOOLDIR). Ist <n> nicht angegeben wird SendXMS nach einmaligem abarbeiten des Spoolverzeichnisses beendet. Falls Dateien vorhanden sind werden diese innerhalb einer minimalen Anzahl von Verbindungen versendet. Sobald ein SendXMS-Server läuft werden alle weiteren Instanzen automatisch im Spoolmodus gestartet. Mit den Parameter -n (direkt versenden) bzw. -s (auf jeden Fall spoolen) kann dieses Verhalten geändert werden. Mit diesen Mechanismen hat man die Möglichkeit Nachrichten über eine Zeitdauer zu sammeln und diese mit einer minimalen Anzahl von Verbindungen innerhalb der günstigsten Tarifzeiten zu versenden.

Mit dem Parameter -z wird angegeben in welchem Zeichensatz die zu versendende Nachricht angegeben wird. Standardmäßig benutzt SendXMS den Systemzeichensatz. Wenn die zu versendende Nachricht nicht mit dem standard Zeichensatz angegeben wird, so muss dies mit diesem Parameter angezeigt werden.

Beispiele:
sendxms 0123456789 test
Die Nachricht "test" wird an die angegebene Nummer gesendet.

sendxms 0123456789 "<UDH>0A03002740</UDH>Dies ist eine formatierte EMS Nachricht"
Die formatierte Nachricht (unterstrichen) wird an die angegebene Nummer gesendet.

sendxms -F -pD1 0123456789 "Dies ist eine Testnachricht"
Die Nachricht "Dies ist eine Testnachricht" wird an die angegebene Nummer gesendet. Der zu verwendende Provider wird explizit angegeben. Nach dem Versenden der Nachricht wird auf eine Bestätigung gewartet, welche angibt, ob die Nachricht ausgeliefert oder auf dem Servicerechner gespeichert wurde.

sendxms 0123456789 -fmsg.txt
sendxms -dModem1 0123456789 < msg.txt
In beiden Fällen wird der Inhalt der Datei msg.txt an die angegeben Nummer gesendet. Im zweiten Fall wird die Benutzung des Devices Modem1 (Parameter NAME im Kapitel [Device] in sendxms.cfg) vorgegeben.

sendxms -ggroup "Alarm an alle"
Es wird die Nachricht "Alarm an alle" an alle Nummern, die in der Datei group aufgelistet sind, versendet. Eine Gruppendatei hat folgendes Format:

  
   [D1]

   PHONE=0170...

   PHONE=0171...

   

   [D2]

   PHONE=0172...

   

   [EPLUS]

   PHONE=0177...

   PHONE=0177...

sendxms -pVOICE 0123456789 < voice.dat
sendxms -pVOICE 0123456789 -fvoice.dat
Es wird eine Sprachnachricht (Voice-Modem, VoIP oder CAPI 2.0) an die angegebene Nummer gesendet. Die Datei voice.dat muss eine Voice-Datei in dem nativen Format des benutzen Devices sein.

sendxms -pUUS 0123456789 "Dies ist eine Testnachricht"
Es wird die Nachricht "Dies ist eine Testnachricht" per UUS (nur mit CAPI 2.0) an die Nummer 1234567 gesendet. Dies funktioniert nur wenn der Dienst UUS vom Netzbetreiber und von beiden Kommunikationsseiten unterstützt wird. Die Übertragung erfolgt im D-Kanal und ist kostenlos.

sendxms -pVOICE 0123456789 -aRECEIVE -fvoice.dat
Es wird die angegebene Nummer angerufen und eine Sprachnachricht im nativen Deviceformat in der Datei voice.dat abgespeichert.

sendxms -aQUERY 0123456789 -G1141863480
Es wird der Status der Nachricht 1141863480 (diese Nummer wurde nach dem Absenden der Nachricht angezeigt) für die Nummer 0123456789 abgefragt.

sendxms -aDELETE 0123456789 -G1141863480
Es wird die Nachricht 1141863480 für die Nummer 0123456789 gelöscht (falls die Nachricht noch nicht ausgeliefert wurde).

sendxms -q5
Started SendXMS im Servermode mit Überprüfung des Spoolverzeichnisses alle 5 Sekunden.

sendxms -q5 -aRECEIVE
Started SendXMS im Servermode mit Überprüfung des Spoolverzeichnisses alle 5 Sekunden. Falls GSM-Modems definiert sind oder bei einem Provider der Parameter AUTOALERT oder AUTOCONNECT gesetzt ist werden diese zusätzlich auf ankommende Nachrichten überprüft.

sendxms -aCHGPWD -pD1_X31 password
Es wird eine Verbindung zum Provider (mit UCP-Protokoll) hergestellt und das Passwort geändert. Danach wird die Verbindung gleich wieder beendet.

Integration in Email-Systeme

Folgende .forward-Datei soll als Beispiel dienen, wie einfach es ist SendXMS in ein Email-System (Unix) zu integrieren. Sie legen einfach nur eine .forward Datei mit folgendem Inhalt in Ihrem Homeverzeichnis ab:


\wobo, "| /usr/local/sendxms/forward.sms"

Diese Datei bewirkt, dass alle für Sie ankommenden Emails an die UserId wobo (hier geben Sie Ihre eigen UserId an) weitergeleitet werden (das heißt, die Email ist für Sie weiterhin ganz normal verfügbar, so wie auch ohne .forward Datei) und dass automatisch das folgende Script forward.sms aufgerufen wird. Dieses Script sendet eine Nachricht (mit dem Absender und dem Subject der Email) durch SendXMS an die angegebene Nummer.


#! /bin/sh

egrep -ih '^From:|^Subject:' | /usr/local/sendxms/sendxms 0123456789 > /dev/null

exit 0

Nach erfolgreicher Installation von SendXMS liegt im samples Unterverzeichnis ein Perl-Script, welches mittels einer .forward Datei benutzt werden kann um alle Emails an einen bestimmten Account an eine im Subject anzugegebende Telefonnummer zu sendet. Diese Script sendet in der vorliegenden Variante jeweils die ersten 500 Zeichen von Nachrichten mit dem dem Content-Type="text/plain" und berücksichtigt gegebenenfalls automatisch die in der Email angegebene Zeichenkodierung.

Eine direkte Integration in sendmail ist ebenfalls sehr einfach möglich. Hierzu definiert man einfach einen MTA in sendmail.cf (z.B. Msendxms, ...) und im 'Rule Set 0' eine Regel, welche angibt wann SendXMS bzw. ein Script - ähnlich dem o.a. forward.sms - aufgerufen werden soll.

Unter Windows ist eine entsprechende Benachrichtigung durch SendXMS bei eintreffenden Emails z.B. mit dem Freeware-Produkt POSTIE oder mit dem Shareware-Mailer The Bat! möglich.

Mit dem Tool mail2sms kann man eine komplette MIME Mail vor dem Versand in reinen Text konvertieren.

Integration in WWW-Server

SendXMS kann auf einfache Art und Weise in einen WWW-Server integriert werden. SendXMS erkennt automatisch ob es von einem http-Server aufgerufen wurde und passt sich an die Umgebung an. Als Beispiel für eine Integration dient das Perl-Script (Perl5) sendxms.cgi. Zur Installation dieses Beispiels müssen die Dateien sendxms.cgi und sendxms.ini in das cgi-bin Verzeichnis des http-Servers kopiert und die Datei sendxms.ini angepasst (Pfade, Sprache und Konfigurationsdateien angeben) werden. Unter Umständen muss auch noch in der ersten Zeile der Datei sendxms.cgi der Pfad zu Ihrem Perl-Interpreter angepasst werden. Bitte beachten Sie, dass die UserId unter der der http-Server läuft zum Zugriff auf SendXMS berechtigt sein muss.

Aufgerufen wird das Beispielscript einfach indem Sie in der Adressen-Zeile Ihres Browsers Folgendes eingeben:
http://<server>/cgi-bin/sendxms.cgi
bzw. einen entsprechenden Link in Ihre Seiten einbauen.

Graphische Benutzeroberfläche

Zu SendXMS wird auch eine graphische Benutzeroberfläche ausgeliefert. Diese Oberfläche ist in Java implementiert und benötigt die Java Runtime Environment (JRE) (http://www.java.com/download/). Zum Aufruf der graphischen Oberfläche liegen Scriptdateien bzw. Batchdateien (xmsgui) bei. Die Oberfläche ist so gestaltet, dass beim ersten Aufruf die notwendigsten Eingabefelder angezeigt werden. Nach Eingabe einer Telefonnummer und einer Nachricht und drücken auf den 'Senden' Knopf in der Menüleiste wir SendXMS aufgerufen und die Ausgabe von SendXMS auf einer automatisch selektierten Seite angezeigt. Die versendeten Nachrichten werden pro Benutzer in einem Journal gespeichert, über welches man mittels eines Kontextmenüs den Status einer Nachricht abfragen kann bzw. eine Nachricht wieder löschen kann. Über den Menüpunkt "Einstellungen/Expertenmodus" kann man sich weitere Optionen anzeigen lassen.

Voice Over IP (VoIP)

Durch die zunehmend Umstellung von ISDN- auf VoIP-Anschlüsse, ist auch der Versand von SMS über Telefonanschlüsse betroffen. Bei Verwendung eines VoIP-Anschlusses müssen SMS mittels eines 'SMS im Festnetz' Anbieters (in Deutschland z.B. Telekom oder Anny Way) verwendet werden. Das Versenden über digitale SMS-Protokollen (TAP, UCP, ...) ist (momentan) über VoIP-Anschlüsse nicht mehr möglich. Sprach- und DTMF-Nachrichten können auch weiterhin über VoIP-Anschlüsse versendet werden.

Um einen VoIP-Anschluß nutzen zu können muss dieser als Device in der Datei sendxms.cfg konfiguriert werden. Hierbei wird ein SIP-Server mit den üblichen Parametern definiert. In der Regel ist die einfachste Methode eine lokal (im gleichen Subnetz) vorhandene Telefonanlage als SIP-Proxy zu verwenden. Sollte die (VoIP-)Telefonanlage auch über einen internen ISDN-Bus verfügen, kann die Kommunikation mit der Telefonanlage natürlich auch weiterhin per CAPI erfolgen. Bei einer lokal vorhandenen (und bereits konfigurierten) Telefonanlage sind ansonsten keine weiteren Maßnahmen erforderlich.

Bei Verwendung eines externern SIP-Servers müssen unter Umständen auch noch die Firewall und/oder der Router konfiguriert werden.

Wird ein Router mit NAT (aber ohne ALG) verwendet muss in der Devicedefinition (in sendxms.cfg) auch noch ein STUN-Server angegeben werden, damit die externe IP-Adresse ermittelt werden kann. Der Router muss so konfiguriet werden, dass die zwischen SendXMS und dem SIP-Server ausgehandelten RTP/RTCP-Ports an SendXMS weitergeleitet werden. In der Providerdefinition (in sendxms.cfg) kann hierfür ein Portbereich vorgegeben werden (siehe auch RtpPorts).

Beispiel (VoIP):

sendxms.cfg
[Device] DeviceType=VOIP Address=10.11.12.13 5060 User=<userid> Password=<password> ;LineType=TCP ;RtpPorts=10000-10050 ;SipAlwaysRegister=True ;DtmfTransfer=Rtp ;StunServer=stun1.l.google.com 19302 ;StunRfc=3489

X.25/X.31

Die SendXMS-Professional-Edition ist auch in der Lage Nachrichten per X.25 oder X.31 (X.25 über ISDN) zu übertragen. Dies bietet sich vorallem bei hohen Stückzahlen an, da die Übertragung mittels X.25/X.31 schnell und kostengünstig erfolgt. Um X.25 nutzen zu können muss eine TCP-X.25-Bridge (nach RFC1086 oder z.B. von CISCO) benutzt werden. Um X.31 nutzen zu können benötigt man ein X.31 fähiges Device (nicht jede ISDN-Karte unterstützt X.31). Weiterhin muss der Dienst X.25 bzw. X.31 beim Netzbetreiber und ein Zugang zu einem SMSC beantragt werden. Sind diese Voraussetzungen erfüllt muss in der Datei sendxms.pro ein entsprechender Provider und in sendxms.cfg ein entsprechendes Device definiert werden (siehe Beispiel). Die weitere Handhabung erfolgt wie mit einem Wählzugang auch.

Beispiel (X.25):

sendxms.cfg	sendxms.pro
[Device] DeviceType=RFC1086 LineType=X.25 Device=ex25.dll ConnectTimeout=5 ;PacketLen=2048 ;WindowSize=7 OriginatingAddress=<lokale Adresse>	[D1_X25] Phone=012345.... LineType=X.25 ;KeepAlive=300 ; für permanente Verbindung ;Detach=ALL ; für permanente Verbindung ;WindowSize=10 ; für asynchrone Übertragung (windowing) Protocol=UCP[51] UseOtoA=true Prefix=+49160 Prefix=+49170 Prefix=+49171 Prefix=+49175 MsgType=ALPHANUMERIC MsgLen=160 UseUCP60=true ; falls die Funktion 60 vom Provider benutzt wird UCP60Password=<password> ; falls die Passwortoption eingeschaltet ist UserId=<large account>

sendxms.cfg

sendxms.pro

[Device]
DeviceType=RFC1086
LineType=X.25
Device=ex25.dll
ConnectTimeout=5
;PacketLen=2048
;WindowSize=7
OriginatingAddress=<lokale Adresse>

[D1_X25]
Phone=012345....
LineType=X.25
;KeepAlive=300 ; für permanente Verbindung
;Detach=ALL ; für permanente Verbindung
;WindowSize=10 ; für asynchrone Übertragung (windowing)
Protocol=UCP[51]
UseOtoA=true
Prefix=+49160
Prefix=+49170
Prefix=+49171
Prefix=+49175
MsgType=ALPHANUMERIC
MsgLen=160
UseUCP60=true ; falls die Funktion 60 vom Provider benutzt wird
UCP60Password=<password> ; falls die Passwortoption eingeschaltet ist
UserId=<large account>

Beispiel (X.31):

sendxms.cfg	sendxms.pro
[Device] DeviceType=CAPI 2.0 LineType=X.31 Device=capi2032.dll ConnectTimeout=5 UseDChannel=true TEI=1 X31Channels=0,0,1,1,0,0 MsnOut=25	[D1_X31] Phone=012345.... LineType=X.31 Protocol=UCP[51] UseOtoA=true Prefix=+49160 Prefix=+49170 Prefix=+49171 Prefix=+49175 MsgType=ALPHANUMERIC MsgLen=160 UseUCP60=true ; falls die Funktion 60 vom Provider benutzt wird UCP60Password=<password> ; falls die Passwortoption eingeschaltet ist UserId=<large account>

TCP/IP, SSL

Die SendXMS-Professional-Edition ist auch in der Lage Nachrichten per TCP/IP zu übertragen. Um TCP/IP-Verbindungen nutzen zu können muss TCP/IP auf dem Computer installiert und konfiguriert sein und in der Datei sendxms.pro ein entsprechender Provider (siehe Beispiel) definiert werden. Ein spezielles Device muss für TCP/IP-Verbindungen nicht definiert werden. Die weitere Handhabung erfolgt wie mit einem Wählzugang auch. Falls auf dem Computer OpenSSL installiert ist kann auch eine SSL-Verbindung aufgebaut werden. Hierzu wird anstelle von LineType=TCP einfach LineType=SSL angegeben. Zur weiteren Konfiguration von SSL-Verbindungen siehe auch Konfiguration

Beispiel:

sendxms.pro
[D1_TCP] Address=127.1.1.1 12345 LineType=TCP ;LineType=SSL ; für SSL Verbindung ;KeepAlive=300 ; für permanente Verbindung ;Detach=ALL ; für permanente Verbindung ;WindowSize=10 ; für asynchrone Übertragung (windowing) Protocol=UCP[51] UseOtoA=true Prefix=+49160 Prefix=+49170 Prefix=+49171 Prefix=+49175 MsgType=ALPHANUMERIC MsgLen=160 UseUCP60=true ; falls die Funktion 60 vom Provider benutzt wird UCP60Password=<password> ; falls die Passwortoption eingeschaltet ist UserId=<large account>

sendxms.pro

[D1_TCP]
Address=127.1.1.1 12345
LineType=TCP
;LineType=SSL ; für SSL Verbindung
;KeepAlive=300 ; für permanente Verbindung
;Detach=ALL ; für permanente Verbindung
;WindowSize=10 ; für asynchrone Übertragung (windowing)
Protocol=UCP[51]
UseOtoA=true
Prefix=+49160
Prefix=+49170
Prefix=+49171
Prefix=+49175
MsgType=ALPHANUMERIC
MsgLen=160
UseUCP60=true ; falls die Funktion 60 vom Provider benutzt wird
UCP60Password=<password> ; falls die Passwortoption eingeschaltet ist
UserId=<large account>

PPP

In manchen Fällen (z.B. MMS im Festnetz) ist es nötig eine Verbindung mittels PPP aufzubauen. Hierfür verwendet SendXMS Funktionen des verwendeten Betriebssystems (pppd bzw. RasDial unter Windows). Das Ganze geschieht zwar für den Anwender transparnet jedoch möchten wir auf ein paar Besonderheiten hinweisen.

Standardmäßig wird beim Aufbau einer PPP-Verbindung eine Defaultroute auf das angeleget PPP-Interface gesetzt. Dies bedeutet, dass während die PPP-Verbindung offen ist der gesamte IP-Verkehr des Rechners standardmäßig über dieses Interface geleitet wird. Da dies nicht unbedingt sinnvoll ist besteht die Möglichkeit mittels des Parameters NoDefaultRoute=true (im Kapitel [PPP] in der .cfg Datei) dies zu unterbinden. Ist dieser Parameter gesetzt versucht SendXMS die notwendige Route (und nur diese) selbst einzurichten. Hierfür ist es allerdings notwendig, dass SendXMS mit priviligierten Rechten ausgeführt wird (unter Windows als Administrator, sonst als root). Unter Unix/Linux ist außerdem darauf zu achten, dass pppd nur ausgeführt werden kann, falls SendXMS vom Benutzer root ausgeführt ist oder bei pppd das s-Bit gesetzt ist.

Returncodes

SendXMS gibt als Returncode die Anzahl der erfolgreich bearbeiteten Nachrichten zurück (Returncode 0 bedeutet, dass SendXMS zwar regulär beendet wurde, aber keine Nachricht versenden oder empfangen konnte). Ist der Returncode negativ, so handelt es sich um einen Errorcode, welcher in der Datei sendxms.err erläutert wird. Dieses Feature ist nur in der registrierten Version verfügbar. Bei manchen Unix-Shells kann es sein, dass die Shell den Returncode als 'unsigned Byte' übergibt. Dies bedeutet, dass der Wert zwischen 0 und 255 liegt, wobei alle Werte ab 128 Fehlercodes (Zweierkomplement) sind.

Falls in der Datei sendxms.cfg der Parameter RCZEROIFOK=true gesetzt ist wird im erfolgsfall eine 0 als Returncode zurück gegeben. Dies ist hilfreich, wenn SendXMS in Zusammenhang mit z.B. einem Emailsystem benutzt wird.

SMS über HTTP

Obwohl für den Versand von SMS über HTTP kein Standardprotokoll existiert (von OneAPI abgesehen), bieten dies viele Dienstanbieter an. Wegen des fehlenden Standards wird von jedem Dienstanbieter eine eigene Syntax definiert, welche sich oft untereinander ähneln, aber eben doch unterschiedlich sind. Aus diesem Grund haben wir uns entschieden ebenfalls eine eigene Syntax zu definieren, jedoch mit dem Unterschied, dass man diese konfigurieren und somit auch mit einer Vielzahl der proprietären Dienstanbieter nutzen kann. Falls möglich raten wir jedoch von der Nutzung eines solchen Dienstes ab und empfehlen ein standard SMS-Protokoll zu verwenden. Mit unserer SMS über HTTP Implementierung ist es (zur Zeit) nur möglich SMS zu versenden. Der Empfang wird (momentan) nicht unterstützt.

Sollte die Verwendung eines standard SMS-Protokolls nicht möglich sein definieren sie einfach in ihrer .pro Datei einen entsprechenden Provider mit Protocol=HTTP und LineType=TCP. Weiterhin müssen sie ein URI für den verwendeten Dienst mit URI=... angeben. Bei einer solchen Providerdefinition würde sich SendXMS mit der angegebenen Adresse/Port (Address=) verbinden und zum Versand einen GET-Request senden. Sollte der Dienstanbieter einen POST-Request benötigen können sie dies durch Angabe von Protocol=HTTP[POST] erreichen. In diesem Fall würde ein POST-Request mit Content-Type application/x-www-form-urlencoded gesendet werden. Als Zeichensatz wird immer UTF-8 verwendet.

Die einzelnen Datenfelder der SMS (Empfängernummer, Absendenummer, Nachrichtentext, ...) werden in dem Request standardmäßig mit dem gleichen Namen spezifiziert wie sie in einer SendXMS Spooldatei angegeben werden (siehe auch Servermodus). Da die Wahrscheinlichkeit, dass der Dienstanbieter die gleichen Parameterbezeichnungen wie SendXMS verwendet, relativ gering ist kann man mittels des Parameters MapUserValue= die Bezeichnungen entsprechend anpassen.

Da auch das Response-Format zum Versenden von SMS über HTTP nicht standardsiert ist kann man mittels der Parameter OkFilter, ErrorFilter und MsgIdFilter Filterdefinieren anhand welcher erkannt wird, ob der Versand erfolgreich war oder ein Fehler aufgetreten ist und ggf. welche MsgId der Dienstanbieter der SMS zugewiesen hat (siehe auch Filter für Nummernformate).

Im Folgenden sind zwei Beispiele für eine entsprechende Definition für SMS über HTTP angegeben:


[smstrade]

ProtocolTimeout=5

Address=gateway.smstrade.de:80

LineType=TCP

Protocol=HTTP

URI=/

MsgLen=160

Password=xxx

TariffClass=basic

MapUserValue=XMS|message

MapUserValue=Password|key

MapUserValue=Phone|to

MapUserValue=OriginatingAddress|from

MapUserValue=ValidityPeriod|/dev/null

MapUserValue=DeferredDelivery|/dev/null

MapUserValue=TariffClass|route

NoHttpAuthentication=true

AdcOutFilter=/^(\+|00)([0-9]*)/\2/

AdcOutFilter=/^(0)([0-9]*)/49\2/

oAdcOutFilter=/^(\+|00)([0-9]*)/\2/

oAdcOutFilter=/^(0)([0-9]*)/49\2/

okFilter=/^100$/\1/


[Twitter]

ProtocolTimeout=5

Address=twitter.com 80

URI=/statuses/update.xml

LineType=TCP

Protocol=HTTP [POST]

MsgLen=140

UserId=xyz

Password=xyz

MapUserValue=XMS|status

MapUserValue=Phone|/dev/null

MapUserValue=OriginatingAddress|/dev/null

MapUserValue=DCS|/dev/null

MapUserValue=StatusReportRequest|/dev/null

MapUserValue=TariffClass|/dev/null

MapUserValue=ValidityPeriod|/dev/null

MapUserValue=DeferredDelivery|/dev/null

MapUserValue=UDH|/dev/null

ErrorFilter=#(.*)<error>(.*)</error>(.*)#\2#

OkFilter=#(.*)<status>(.*)</status>(.*)#\2#

MsgIdFilter=#<id>([0-9,A-F]*)</id>#\1#

MMS, Klingeltöne, Logos, WAP Push (OMA Provisioning, OMA DRM, OMA EMN, Bookmarks, MMS Notifications, ...)

Um MMS Nachrichten (MIME-Datei (die erste Zeile muss den ContentType angeben) mit BASE64 kodierten Teilen) bzw. (im Fall von SMS/EMS) formatierte Nachrichten, WAP-Push Nachrichten (z.B. Browser Settings, Bookmarks oder SyncML Settings), Klingeltöne, Operatorlogos, Gruppenlogos, Bildmitteilungen oder Animationen (Nokia Smart Messaging Spezifikation, EMS, Motorola, Sagem, Siemens) versenden zu können müssen die Daten jeweils in einem im bestimmtenFormat angegeben werden. Da die Daten i.d.R. in einem Fremdformat vorliegen, müssen diese Formate konvertiert werden. Hierzu dient das zusätzliche Programm XMSConv (nur in registrierter Version). Mit diesem Programm können z.B. .bmp, .png, .gif, .mng, .htm, .smil, .xml, imy, .mid, .rtx, .rtttl, .xms Dateien gelesen werden.

Nur bei Verwendung von EMS 5.x kann ein Logo farbig sein, ansonsten müssen alle Logos schwarz/weiß sein. Nokia-Logos haben die Größen:

72 x 14 (Betreiberlogo oder Gruppenlogo)
78 x 21 (Betreiberlogo groß)
72 x 28 (Bildmitteilung oder Screensaver)

EMS Grafiken haben folgende Größen:

8 x 8 (Bild klein)
16 x 16 (Bild groß)
n x m, wobei (n, m > 0) und (bei EMS4 (nicht EMS5): n * m / 8 <= 128) (Bild variable)

Eine EMS Animation besteht aus jeweils 4 Bildern mit den Größen 8 x 8 oder 16 x 16. Eine Nokia-Animation besteht aus bis zu 16 Bildern einer der o.g. Größen.

Beim Siemens OTA Download Service wird eine Bitmap-Datei oder eine Midi-Datei auf das Telefon geladen. Die Formate sind vom Modell abhängig (z.B. hat ein Screensaver für ein S45 die Größe 101x64).

Für WAP Push Nachrichten besteht zusätzlich die Möglichkeit spezifische Daten (weiters in den entsprechenden Normen) wie z.B. die WSP-Header Parameter PushFlag oder X-Wap-Initiator-Uri anzugeben. Hierfür kann in der cfg-Datei (Kapitel [XMSConv]) ein Standardwert angegeben werden weöcher aber auch mit den Kommandozeilenparametern --PushFlag bzw. --InitiatorUri überschrieben werden kann. Für WAP/OMA Client Provisioning Nachrichten kann auch noch ein Sicherheitsmechanismus angegeben werden (z.B.: --SEC=0 --IMSI=123456789012345; dies bedeutet, dass die Nachricht nur auf dem Gerät mit der angegebenen IMSI gültig ist).

Im Folgenden sind einige Beispiele enthalten:

xmsconv -f<mms.smil> -FMMS -W<phone>
versendet eine MMS.

xmsconv -f<picture.gif> -FSMIL -M"Just a picture" -W<phone>
versendet eine MMS, wobei eine einfache SMIL Datei (Präsentation) generiert wird.

xmsconv -f<mms.smil> -FMMS -W<phone> -W-pt-com_mms
versendet eine MMS per MMS-Gateway der Deutschen Telekom (MMS im Festnetz).

xmsconv -f<logo.bmp> -UGROUPLOGO -FNokia -W<phone>
versendet ein Gruppenlogo im Nokia-Format.

xmsconv -f<logo.bmp> -m<mcc> -n<mnc> -UOPERATORLOGO -W<phone>
versendet ein Operatorlogo im Nokia-Format.

xmsconv -f<logo.bmp> -UOPERATORLOGO -m262 -n1 -W<phone>
versendet ein Operatorlogo im Nokia-Format. Da die Grafik eigentlich ein Gruppenlogo ist wird sowohl der Grafiktyp als auch der Netzcode des entsprechenden Providers explizit angegeben.

xmsconv -f<picture.png> -M"dies ist eine Bildmitteilung" -UPICTURE -W-V+180 -W<phone>
versendet eine Bildmitteilung mit den Text "dies ist eine Bildmitteilung".

xmsconv -f<ringtone.rtx> -URINGTONE -FMOTOROLA -W<phone>
versendet einen Klingelton im Motorola-Format.

xmsconv -f<bitmap.bmp> -FSIEMENS -W<phone>
versendet eine Bitmap-Datei per Siemens OTA-Download.

xmsconv -f<melody.mid> -FSIEMENS -W<phone>
versendet eine Midi-Datei per Siemens OTA-Download.

xmsconv -f<push.xml> -W<phone>
oder
xmsconv -f<push.xml> -W<phone> --WapInitiatorUri=http://www.sendxms.com/ --WapPushFlag=3 --UserPIN=1234 --SEC=1
versendet eine WAP-Push Nachricht. Im zweiten Beispiel werden zusätzlich die WSP-Header Parameter X-Wap-Initiator-Uri (wird auf manchen Geräten als Absender angezeigt) und PushFlag sowie ein Userpin gesetzt. Die Datei muss der entsprechenden Document Type Definition (DTD) entsprechen, z.B.:


<?xml version="1.0"?>

<!DOCTYPE wap-provisioningdoc PUBLIC "-//WAPFORUM//DTD PROV 1.0//EN" "http://www.wapforum.org/DTD/prov.dtd">

<wap-provisioningdoc version="1.0">

 <characteristic type="PXLOGICAL">

  <parm name="PROXY-ID" value="PROXY"/>

  <parm name="NAME" value="Proxy"/>

  <characteristic type="PORT">

   <parm name="PORTNBR" value="8080"/>

  </characteristic>

  <characteristic type="PXPHYSICAL">

   <parm name="PXADDR" value="13.22.45.55"/>

   <parm name="PXADDRTYPE" value="IPV4"/>

   <parm name="TO-NAPID" value="Browsing_CSD"/>

  </characteristic>

 </characteristic>

 <characteristic type="NAPDEF">

  <parm name="NAPID" value="Browsing_CSD"/>

  <parm name="BEARER" value="GSM-CSD"/>

  <parm name="NAME" value="Browsing CSD"/>

  <parm name="NAP-ADDRESS" value="+5555555555"/>

  <parm name="NAP-ADDRTYPE" value="E164"/>

  <parm name="CALLTYPE" value="ANALOG-MODEM"/>

  <parm name="LINKSPEED" value="9600"/>

  <characteristic type="NAPAUTHINFO">

   <parm name="AUTHTYPE" value="PAP"/>

   <parm name="AUTHNAME" value="name2"/>

   <parm name="AUTHSECRET" value="password2"/>

  </characteristic>

 </characteristic>

 <characteristic type="APPLICATION">

  <parm name="APPID" value="w2"/>

  <parm name="TO-PROXY" value="PROXY" />

  <characteristic type="RESOURCE">

   <parm name="NAME" value="Bookmark Name"/>

   <parm name="URI" value="http://wap.com"/>

   <parm name="STARTPAGE"/>

  </characteristic>

 </characteristic>

</wap-provisioningdoc>

oder


<?xml version="1.0"?>

<!DOCTYPE CHARACTERISTIC-LIST SYSTEM "file://c:/settingspush/settings.dtd" >

<CHARACTERISTIC-LIST>

 <CHARACTERISTIC TYPE="ADDRESS">

  <PARM NAME="BEARER" VALUE="GSM/CSD"/>

  <PARM NAME="PROXY" VALUE="123.45.123.67"/>

  <PARM NAME="CSD_DIALSTRING" VALUE="+4583572"/>

  <PARM NAME="PPP_AUTHTYPE" VALUE="PAP"/>

  <PARM NAME="PPP_AUTHNAME" VALUE="wapuser"/>

  <PARM NAME="PPP_AUTHSERCRET" VALUE="wappassw"/>

  <PARM NAME="CSD_CALLTYPE" VALUE="ANALOGUE"/>

  <PARM NAME="CSD_CALLSPEED" VALUE="AUTO"/>

 </CHARACTERISTIC>

 <CHARACTERISTIC TYPE="URL" VALUE="http://wap.dk"/>

 <CHARACTERISTIC TYPE="NAME">

  <PARM NAME="NAME" VALUE="ABC Service"/>

 </CHARACTERISTIC>

 <CHARACTERISTIC TYPE="BOOKMARK">

   <PARM NAME="NAME" VALUE="Wap"/>

   <PARM NAME="URL" VALUE="http://wap.dk"/>

 </CHARACTERISTIC>

</CHARACTERISTIC-LIST>

oder


<?xml version="1.0"?>

<!DOCTYPE CHARACTERISTIC-LIST SYSTEM "file://c:/settingspush/settings.dtd" >

<CHARACTERISTIC-LIST>

 <CHARACTERISTIC TYPE="BOOKMARK">

  <PARM NAME="NAME" VALUE="Wap"/>

  <PARM NAME="URL" VALUE="http://wap.dk"/>

 </CHARACTERISTIC>

</CHARACTERISTIC-LIST>

oder


<?xml version="1.0"?>

<!DOCTYPE si PUBLIC "-//WAPFORUM//DTD SI 1.0//EN" "http://www.wapforum.org/DTD/si.dtd">

<si>

 <indication href="http://www.yxz.com/email/123/abc.wml" created="1999-06-25T15:23:15Z" si-expires="2010-06-30T00:00:00Z">You have 4 new emails</indication>

</si>

oder


<?xml version="1.0"?>

<!DOCTYPE sl PUBLIC "-//WAPFORUM//DTD SL 1.0//EN" "http://www.wapforum.org/DTD/sl.dtd">

<sl href="http://www.yxz.com/email/123/abc.wml" action="execute-low"></sl>

oder


<?xml version="1.0"?>

<!DOCTYPE SyncSettings>

<SyncSettings>

 <Version>1.0</Version>

 <HostAddr>http://www.syncserver.com/sync</HostAddr>

 <Port>8080</Port>

 <RemoteDB>

  <CTType>text/x-vcard</CTType>

  <CTVer>2.1</CTVer>

  <URI>./Contacts?CLASS&EQ;PRIVATE</URI>

  <Name>Private Contact DB</Name>

  <Auth>

   <AuthScheme>1</AuthScheme>

   <Username>james</Username>

   <Cred>cHdk</Cred>  <!-- Base64 coded 'pwd' -->

  </Auth>

 </RemoteDB>

 <RemoteDB>

  <CTType>text/x-vcalendar</CTType>

  <CTVer>1.0</CTVer>

  <URI>./Calendar</URI>

  <Name>Calendar DB</Name>

 </RemoteDB>

 <Name>PIM Service</Name>

 <Auth>

  <AuthLevel>2</AuthLevel>

  <AuthScheme>1</AuthScheme>

  <Username>james</Username>

  <Cred>Ym9uZA==</Cred>   <!-- Base64 coded 'bond' -->

 </Auth>

 <Auth>

  <AuthLevel>1</AuthLevel>

  <AuthScheme>1</AuthScheme>

  <Username>bond</Username>

  <Cred>Ym9uZA==</Cred>   <!-- Base64 coded 'bond' -->

 </Auth>

 <ConRef>

  <ConType>1</ConType>

  <RefID>My AP</RefID>

 </ConRef>

</SyncSettings>

oder


<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE o-ex:rights PUBLIC "-//OMA//DTD DRMREL 1.0//EN" "http://www.oma.org/dtd/dr"> 

<o-ex:rights xmlns:o-ex="http://odrl.net/1.1/ODRL-EX" xmlns:o-dd="http://odrl.net/1.1/ODRL-DD" xmlns:ds="http://www.w3.org/2000/09/xmldsig#/">

 <o-ex:context>

  <o-dd:version>1.0</o-dd:version>

 </o-ex:context>

 <o-ex:agreement>

  <o-ex:asset>

   <o-ex:context>

    <o-dd:uid>cid:4567829547@foo.com</o-dd:uid>

   </o-ex:context>

   <ds:KeyInfo>

    <ds:KeyValue>vUEwR8LzEJoeiC+dgT1mgg==</ds:KeyValue>

   </ds:KeyInfo>

  </o-ex:asset>

  <o-ex:permission>

   <o-dd:play/>

  </o-ex:permission>

 </o-ex:agreement>

</o-ex:rights>

oder


<?xml version="1.0"?>

<!DOCTYPE emn PUBLIC "-//OMA/DTD EMN 1.0//EN" "http://www.openmobilealliance.com/tech/DTD/emn.dtd">

<emn mailbox="mailat:user@wapforum.org" timestamp="2006-04-16T06:40:00Z"/>

xmsconv -f<mms.ind> -UWapPush -W<phone>
Versendet eine MMS-Notification-Indication (SMS) als WAP-Push (informiert ein MMS-Gerät über eine abzuholende Nachricht). Die Datei muss einen gültigen MMS Header enthalten, z.B.:

X-Mms-Message-Type: m-notification-ind


X-Mms-Transaction-Id: abcdef

X-Mms-Version: 1.0

From: +123456789/TYPE=PLMN

Subject: one more mms

X-Mms-Message-Class: Personal

X-Mms-Message-Size: 1234

X-Mms-Expiry: 86000; type=relative

X-Mms-Content-Location: http://www.xyz.com/m1.mms

xmsconv -f<oma_dm.xml> -W<phone>
Versendet ein OMA (SyncML) Device Management Initiation Package (Package#0) als WAP-Push (informiert ein Gerät darüber, dass dieses eine Device Management Session starten soll). Die Datei muss folgendem Format entsprechen:

<?xml version="1.0" encoding="UTF-8"?>


<!DOCTYPE SyncML-DM-Notification SYSTEM "http://www.syncml.org/docs/syncml_dm_ddf_v11_20020213.dtd">

<SyncML_DM_Notification xmlns='SYNCML:SYNCML1.1'>

 <SyncHdr>

  <VerProto>DM/1.1</VerProto>

  <UiMode>not-specified</UiMode>    <!-- not-specified, background, informative or user-interaction -->

  <Initiator>server</Initiator>     <!-- client or server -->

  <SessionID>1</SessionID>

  <ServerIdentifier>http://www.syncml.org/mgmt-server</ServerIdentifier>

  <Password>password</Password>

  <Nonce>nonce</Nonce>

  <VendorSpecific></VendorSpecific> <!-- only hex digits allowed -->

 </SyncHdr>

</SyncML_DM_Notification>

UCS-2

Mit SendXMS können auch Nachrichten im UCS-2 Zeichensatz (Multibyte) versendet werden. In diesem Fall werden je zwei Bytes pro Zeichen benötigt, so dass sich die maximale Nachrichtenlänge bei GSM auf 70 Zeichen reduziert. Um UCS-2 Nachrichten zu versenden muss der Parameter -Zucs2 angegeben werden. Weiterhin sollte mit dem Parameter -z angegeben werden in welchem Zeichensatz die Nachricht angegeben wird (die Nachricht muss in einem singlebyte Zeichensatz oder in UTF-8 angegeben werden und wird automatisch nach UCS-2 übersetzt):

sendxms -zutf8 -Zucs2 0123456789 "bla bla bla..."

Mobile Number Portability (MNP)

SendXMS ist schon seit Jahren MNP-fähig, indem Sie einfach beim Aufruf (bzw. bei der Generierung der Spooldatei) den zu verwendenden Provider angeben.

Da der Benutzer i.d.R. aber nicht weiß, ob die Empfängernummer portiert wurde oder nicht, bietet SendXMS auch die Möglichkeit eine automatisierte Abfrage einzubauen. Wie das MNP-Verfahren in den einzelnen Ländern geregelt wird ist unterschiedlich. In der Datei sendxms.cfg kann über den Parameter MNP= eine Funktion in einer DLL bzw. in einem shared object angegeben werden, welche von SendXMS bei Bedarf aufgerufen wird. Diese Funktion erhält als Parameter eine Variable in der sie die Portierungskennung zurückgeben kann und die Nummer die abgefragt wird. Falls für die abgefragte Nummer eine Portierungskennung existiert (in Deutschland wird von den Mobilfunkbetreibern eine Datenbank zur Verfügung gestellt) setzt die Funktion die Portierungskennung im ersten Parameter und gibt den Wert 0 zurück. Falls keine Portierungskennung existiert gibt die Funktion einen Wert ungleich 0 zurück.

Falls eine Portierungskennung gesetzt und eine 0 zurückgegeben wurde sucht SendXMS in der Providerdatei (standardmäßig in sendxms.pro) nach einem passenden Providereintrag bei dem mit MNP= die entsprechende Portierungskennung definiert ist. Wurde keine Portierungskennung gesetzt oder ein Wert ungleich 0 zurückgegeben arbeitet SendXMS wie gewohnt und sucht sich anhand der Vorwahl einen Provider.

Ein Prototyp für einen MNP-Funktion in einem shared object ist:


int Mnp (char *id, char *adC);

Unter Windows sollte die Funktion wie folgt definiert werden:

  
    Borland-Compiler:    int __stdcall __declspec(dllexport) Mnp (...)
    

    MS-Compiler:         extern "C" int __declspec(dllexport) __stdcall Mnp (...)

/* Der MS-Compiler dekoriert die Funktion. Dies bewirkt, dass beim Aufruf _Mnp@<n> angegeben werden muss (oder eine def-Datei verwendet werden muss, welche die Funktion mit dem richtigen Namen exportiert). */