T.38 Fax und Modems

VoIP ist in aller Munde und wird die klassischen analogen und ISDN-Leitungen ablösen. Das hat natürlich Auswirkungen auf die Übertragung von Faxseiten, denn beim Fax werden nun mal eingescannte Daten als TIFF-Datei binär übertragen. ähnlich ist es für die Datenübertragung mit Modems. Sicher wird auch dieser Bereich durch IP-Verbindungen abgelöst (Stichwort Internet der Dinge) aber auch hier werden sicher noch einige Jahre im Feld analoge Modems zu bedienen sein, sei es als Remotezugang, Alarmmeldern, Portomaschinen und natürlich "Entwicklungsländer" in jeder Form. Diese Seite widmet sich der Übertragung von digitalen Daten über VoIP und den Dienstübergängen.

Fax und Modem auf die Töne geschaut

Schon sobald die ersten Töne über Sprachkanäle (Drahtgebunden und Drahtlos) übertragen werden konnten, haben findige Bastler auch digitale Informationen in "Töne" umgesetzt und über entsprechende Entfernungen übertragen. Das muss und sollte natürlich auch mit VoIP möglich sein, auch wenn die Endgeräte gar nichts von Internet oder TCP/IP verstehen. Gefordert ist also eine Übertragung von "Tönen", die nicht unbedingt menschlicher Natur sind. Schon im Namen "VoIP" steckt der Begriff "Voice" drin und nicht "Daten". Die meisten Codecs sind also darauf ausgelegt die analogen Töne so zu digitalisieren, dass diese auf der anderen Seite möglichst verständlich wieder analog wiedergegeben werden können. Es liegt in der Natur der Sprache und Menschen, dass die auch dann noch verständlich ist, wenn ein paar Millisekunden fehlen, die Sprache verzögert ankommt oder etwas verzerrt oder "dumpf" ist.

  • Frequenzen und Bitrate
    Gerade das "Dumpf" ist ein wichtiger Faktor, da mit damals in meinem Nachrichtentechnikanteil (1988) beigebracht wurde, dass Telefonie nur 300-3400 Hz überträgt und alles andere von der Post per Tiefpass gefiltert wurde, um z.B. Störungen zu verhindern oder Steuersignale (Gebührenimpuls) zu schützen. Entsprechend war lange Zeit die Modemtechnik bei 2400Baud oder weniger gestanden bis durch eine geänderte Modulation mehrere Bits parallel übertragen werden konnten. Kaum vorstellbar, was heute über die letzten km "Kupferdraht" übertragen werden kann. Bei VoIP mit Ethernet könnte man ja viel mehr übertragen, aber man muss dennoch die "analogen" Signale irgendwo umsetzen.
  • Bidirektional und unidirektional
    Was gerne auch mal übersehen wird, ist die Intensität pro Richtung. Beim Fax ist der Sender in der Regel deutlich aktiver als der Empfänger, der nur ab uns an ein "OK" zurück sendet. Entsprechend belastet das auch die SIP-Systeme (Bandbreite) aber auch deren Modems, die eine Digitalisierung durchführen. Letztlich sind das alles heute CPUs und ASICs und keine diskreten Schwingkreise mehr. Wer aber auch Datenmodems über VoIP-Verbindungen betreiben will, muss wissen, dass hier bidirektionale Verkehre anliegen können. Heute ist das aber weniger ein Problem, da die VoIP-Gateways mittlerweile schon deutlich besser geworden sind.
  • ISDN Daten (B-Kanal und D-Kanal)
    Ganz anders sieht es aber mit Datenübertragungen aus, die gar nicht per "Ton" ankommen, sondern dank der ISDN-Technik schon eine Datenübertragung ist. Die Entwicklung hat zwar gezeigt, dass z.B. G4-Fax (64kbit) sich nie richtig durchgesetzt hat. aber Datenübertragungen über den B-Kanal (z.B. Euro-Filetransfer) oder VPN-Dialin wurde lange genutzt und gibt es immer noch, selbst wenn das Internet und Modulfunk mittlerweile viel mehr Bandbreite bereit stellen.
    Aber auch der D-Kanal wurde in der Vergangenheit zur Übertragung von sehr kleinen Daten oft genutzt, z.B. SMS-Meldungen o.ä. Diese ISDN-Dienstmerkmale werden mit VoIP eigentlich nicht mehr unterstützt. Das merken insbesondere die Telekom-Kunden, die mittlerweile einen "IP-Anschluss" bekommen, d.h. bei denen die ISDN-Leitung auch nur noch eine Router mit VoIP-Umsetzung ist.
    Technisch macht es natürlich auf jeden Fall Sinn, Daten auch gleich per IP zu übertragen statt diese erst in ISDN-Pakete umzusetzen. Er aber solche "Geräte" noch hat, wird diese mit dem Wegfall von ISDN dann auf analoge Modems oder IP umstellen.
  • Latenzzeit
    Was gerne übersehen wird, ist dass Datenübertragung und insbesondere Fax auf unterschiedliche oder zu lange Laufzeiten empfindlich reagieren. Man kann da schon "Echtzeitübertragung" dazu sagen. Wenn da nun ein VoIP-System dazwischen ist, dann müssen die Daten auf der einen Seite "gesampled" werden und dann als Paket auf die Leitung gehen und am Ziel muss das Paket eventuell sogar wieder analog umgewandelt werden. Da addieren sich sehr schnell dann längere Laufzeiten. Es kann sogar sein, dass z.B. beim Weg von Carrier zu Carrier VoIP-Zwischenstrecken dazwischen sind, die so eine Übertragung weiter verzögern. VoIP heißt ja nicht zwingend, dass die Endpunkte direkt per IP miteinander reden.
  • Echo unterdrückung (Echo Suppression) bzw. Echo-Auslöschung (Echo Cancellation) und •Rausch-Unterdrückung (Noise Reduction)
    Gerade im Bereich VoIP wird gerne mit diesen Techniken gearbeitet um die Datenrate zu drücken (Silence) aber bei Fax und Modemübertragungen natürlich extrem stören. Zumindest solange die analogen Daten per Audiocodec übertragen werden.

Im folgenden schauen wir uns die Übertragung von analog anliegenden Signalen über VoIP an:

CNG und CED - Faxe erkennen

Jede Fax-Verbindung startet mit einer Audioverbindung. Da Fax ja bislang immer "Töne" genutzt hat und es bei der analogen Telefonie keine Dienstmerkmale gibt, kann die Anlage, an de rein Fax angeschlossen ist nicht von vorneherein wissen, dass hier ein Fax kommt. Es gibt bei ISDN zwar die Dienstmerkmale und bei ISDN-Anschlüssen konnte man damit auch "Fax" statt "3.1k Audio" an Ports und Geräten einstellen, aber praktisch genutzt wurde das eher nicht. ein Fax beginnt also immer mit einem Audioanruf und den ersten Tönen. Davon gibt es zwei:

  • CNG: Origination Fax Calling Tone
    Ein G3 Faxgerät sollte automatisch einen 1100Hz Tone mit 0,5 sec Dauer und 3 Sek pause an die Gegenseite senden. Der angerufene Teilnehmer kann damit also erkennen, dass eine Faxübertragung ansteht. Darauf basierend funktionieren z.B. viele Faxweichen, die unter einer Nummer auch Faxe annehmen und andere Anrufe auf einen Anrufbeantworter lenken oder ein Telefon klingeln lassen
  • CED: Fax Answering Tone
    Wenn ein Faxgerät den Anruf annimmt, dann antwortet es automatisch mit einem 2100Hz Ton von 3 Sek Dauer

Beide Töne sind auch über einen Audiocodec wie G711 problemlos zu übertragen, so dass die beiden Partner sich schon mal hören und den Faxhandshake einleiten könnten. Viel wichtiger ist aber, dass Gateways, die zwischen VoIP und TDM umsetzen, diesen Ton ebenfalls erkennen und die SIP-Partner damit einen Codec-Wechsel einleiten, so dass die Daten dann digital übertragen werden.

Weiter unten sehen Sie dann in einem WireShark mitschnitt, dass die Fax-Kennzeichnungen wie CNG, CED aber auch DIS (Digital identification signal, Daten zum Empfänger), DCS (Digital command signal, Stammdaten des Senders), TCF (Training check function, Testdaten um die Funktion zu prüfen), CFR (Confirmation to receive, Quittung, dass der Empfänger alles verstanden hat), EOP (End of procedure, Abschlussmeldung vorher übertragener Daten), MCF (Message confirmation, Bestätigung des Empfangs) und DCN (Disconnect, Ende der Verbindung)

Lokale Umsetzung

Für die weitere Betrachtung schauen wir uns einmal an, wie ein per Telefonleitung ankommendes Fax z.B. auf einen Faxserver übertragen wird, der virtuell angebunden ist. Die letzten Meter sind daher über VoIP zu übertragen und müssen von einem Gateway umgesetzt werden. Relevant ist hier also der Teil zum internen per IP angebundenen FaxServer

Hier gibt es zwei Wege mit drei Unterarten:

  • Fax over G711 (Audiocodec)
    Wenn das Gateway nicht erkennt, dass es sich um ein Fax handelt, dann reicht es die "Töne" einfach als "Sprache" weiter. Da Faxtöne über einen G711 Codec natürlich nicht vollständig übergeben werden können, ist die Datenrate meist auf 2400 Baud beschränkt und die Stabilität eher gering. Wenn dann der Faxserver z.B. noch virtuell läuft, wird es noch schwerer das korrekte FAX-Timing einzuhalten. Diese Option ist daher maximal ein Notnagel. Vor allem sollten sie bei dieser Option nicht mit komprimierenden Codec (z.B. G.729) einsetzen, da die Kompression weitere Informationen abschneidet. Bei vielen Softwareprodukten wird diese Lösung als als "Soft-FAX" bezeichnet (z.B. XCAPI)
  • Fax over T.38
    Besser ist die Übertragung per T.38, d.h. das Gateway an der Schnittstelle zwischen den Welten verhält sich wie das Faxgerät und setzt hier schon die analogen Töne in binäre Daten um. Über das LAN laufen dann die bereits digitalisierten Informationen. Überspitzt gesagt: "TIFF over IP". Der Faxserver kann dann sehr viel entspannter die Daten vorverarbeitet annehmen oder versenden. Voraussetzung ist natürlich, dass das Gateway und die VoIP Gegenstelle auch T.38 unterstützt. Das Problem dabei ist aber, dass im Moment des "Klingelns" ja noch gar nicht klar ist, dass da ein Fax kommt. Der "INVITE" zum oder vom Faxserver ist erst mal einfach ein "Telefonat" welches über einen Audiocodec den ersten Ton meldet. Irgendwie muss etwas den CNG-Tone erkennen und dann wechsel. dazu gibt es drei Optionen:
    1. Gateway erkennt Faxtone und wechselt Codec on the fly
      Auch wenn im SDP der T.38-Codec gar nicht enthalten ist, kann das Gateway per RTP den Codec ändern. Die meisten Codecs haben eine fest Nummer (0=PCMU-Law, 6=PCMA-LAW, 101=DTMF) und es tatsächlich möglich mit T.38 den Codec zu wechseln, obwohl er nicht im SDP enthalten war. Voraussetzung ist aber, dass der Empfänger dieses Verhalten unterstützt. Tut er dies nicht und das Gateway wechselt, dann bricht der Call ab.
    2. ReINVITE durch Zielpunkt (Hier ein Faxserver)
      Der Call startet erst einmal als normaler AudioCall. Damit kann das Ziel natürlich den Fax-Ton des Anrufers (CNG-Tone) oder auch den CED-Antworttone des antwortenden Faxgeräts hören. Wenn der Faxempfänger diesen Ton hört, kann er einen ReINVITE an das Gateway absetzen, damit diese auf T.38 umschaltet.
    3. ReINVITE durch Quellpunkt (hier ein Gateway)
      Aber auch das Gateway, welches Anrufer von der Anrufer-Seite die Töne digitalisiert per AudioCall zum Faxempfänger sendet, kann den CNG-Tone sehr früh erkennen und auch in der Antwort den CED-Ton und eine Faxübertragung per T.38 mit einem ReINVITE anstoßen.

Die Erkennung eines FAX kann sowohl anhand des CNG als auch der CED-Tons erfolgen und auf beiden Seiten initiiert werden.

Verlassen Sie sich nicht darauf, dass es irgendwie geht. Legen Sie idealerweise fest, welches Device für die Faxerkennung zuständig ist und dann den ReINVITE an die andere Seite sendet. Es kann auch anders gehen aber die Fehlersuche ist aufwändiger und was passiert, wenn sich zwei zeitgleiche ReINVITE überschneiden ?.

Aus meiner Erfahrung ist der Weg über T.38 zu bevorzugen, wenn die Software dies korrekt unterstützt und dann ist die Variante 2 oder 3 meist am einfachsten umzusetzen und bei Fehlern zu analysieren. Hier sieht man die SIP-Pakete während man den Codec-Wechsel schwieriger verfolgen kann.

Fax mit SIP-Trunk

Interessant wird das Thema Fax und Daten natürlich auch mit der immer öfter genutzten SIP-Trunks. Das gilt nicht nur für all die privaten Telefonanschlüsse, bei denen Neuanschlüsse mittlerweile fast nur noch als "IP-Anschlüsse" (d.h. DSL-Leitung mit Router als SIP-Box) angeboten werden. Wer hier ein Faxgerät anschließt, könnte Probleme bekommen wenn der Netzabschlusspunkt und der Provider kein passendes Protokoll einstellen. Natürlich kann ein Fax auch über einen unkomprimierten Codec wie G.711 übertragen werden, wenngleich langsamer und mit mehr Ausfällen.

T.38 erfordert aber, dass in der Konfiguration der Anschluss als "Fax" bekannt gegeben wird oder der Router den Faxtone (CNG) erkennt und auf T.38 umschaltet und auf der anderen der Provider auch T.38 wieder annimmt.

Bei Firmen ist es vergleichbar, wobei hier die FAX-Verbindung per SIP-Trunk übertragen werden. Der Übergang vom klassischen TDM-Netz mit T.30 erfolgt beim Carrier, welcher dann den Faxtone per G.711 durchreicht bis das Endgerät, also der Faxserver diesen erkennt und einen ReINVITE bis nach vorne zum Gateway sendet.

Das muss natürlich auch über einen SBC hinweg funktionieren. Wenn Sie statt eines Faxservers dann ein Faxgerät an einem AB-Adapter angeschlossen haben, dann sollte dieses Gerät den CNG-Ton erkennen und den ReINVITE senden.

Daten und VoIP

Wie sieht es aber mit Mode-Verbindungen aus? Im Gegensatz zu einer Faxübertragung, bei der in der Regel ein kleiner Rückkanal für die wenigen Meldungen ausreicht und auf dem Hinweg die Grafik übertragen wird, ist der Einsatz von Modems zur Datenübertragung oft durch eine symmetrische Datenübertragung gekennzeichnet. die früheren 2400Baud-Modems haben sogar in beide Richtungen die identische Geschwindigkeit gefahren aber spätestens bei 56kbit (V32bis) ist der Download höher als der Upload aber beide können parallel übertragen werden. Anders als bei Sprache und bei Fax kann eine Datenübertragung aber eher mit Verzögerungen umgehen. Insofern könnte über VoIP die Paketgröße erhöht werden, um die Anzahl zu reduzieren. Paketverluste hingegen sind absolut intolerabel bei der Übertragung von Daten. Leider leiden analoge Modem-Verbindungen natürlich darunter, dass die wenigsten VoIP-Gateways hier einen besseren Support liefern. Ich kenne keines, welches V32bis selbst unterstützt, so dass hier dann doch wieder G.711 (64kbit) zum Tragen kommt und die Datenrate entsprechend begrenzt ist.

ISDN 64k Daten und VoIP - CLEARMODE

Etwas anders sieht es aus, wenn die Daten schon digital eingeliefert werden. Wer eine ISDN-Karte an einen ISDN-Anschluss eines VoIP-Gateways anschließt, kann hier natürlich ein oder zwei B-Kanäle nicht nur mit Sprache (Bearer 31kAudio) sondern z.B. auch mit Daten (64k Data) füllen. Hier gibt es dann keine Analog/Digital-Wandung. Allerdings muss es nun einen Codec geben, der diese Daten übertragen kann. Sicher könnte man auch mit G.711 einfach die Daten 1:1 umsetzen, aber RTP über UDP heilt keine Datenverluste. Zudem sollte verhindert werden, dass ein solches "DatenModem" per Rufnummer einen Analogteilnehmer anruft und die 64kBit Daten auf der anderen Seite als Audio interpretiert und abgespielt werden. Bei ISDN haben die Endgeräte ja auch die "Bearer"-Einstellung überprüft. So konnten Datenmodems und Telefone sogar auf der gleichen Rufnummer am gleichen ISDN-Bus störungsfrei betrieben werden. Jeder nahm nur an, was er verarbeiten konnte

Bestandschutz ist in der TK-Welt ein wichtiger Faktor, da Gerät eben nicht wie Smartphones in wenigen Jahren ausgetauscht werden. So ist es auch nicht verwunderlich, dass ein Mitarbeiter von Siemens an der RFC4040 maßgeblich mit gearbeitet hat und den Codec "CLEARMODE" eingebracht hat

Gateways überall

Wenn Sie ein Fax von einer Firma über die "TK-Schnittstelle" zu einer anderen Firma übertragen, dann können die Informationen durchaus mehrere Stationen durchlaufen. Sie sollten einfach davon ausgehen, dass die meisten "Telefonate" auf der Ebene der Carrier mittlerweile per IP vermittelt werden und die klassische TK-Anlage mit analogen und ISDN-Anschlüssen samt TDM-Switchboard nur noch bei Firmen vorhanden ist. Wir sollten also davon ausgehen, dass bei den meisten Telefonverbindungen irgendwo mindestens eine VoIP-Strecke dazwischen ist und damit auf beiden Seiten ein Gateway im Einsatz ist. Aktuell gibt es wohl nur ganz weniger Drucker oder Scanner mit Ethernet, die per SIP direkt faxen können. An folgenden Stellen können Gateways sein

  • Direkt am Faxgerät
    Ein Faxgerät hat einen analogen Anschluss und beim Einsatz von VoIP in Firmen ist eine AnschlussMöglichkeit der Einsatz eines ATA-Adapters (Siehe auch MSXFAQ.DE:AC MP112 oder MSXFAQ.DE:HT502). Im Home Office kann dies auch der DSL-Router sein, der über VoIP die Daten dann schon per IP weiter gibt.
  • Die TK-Anlage
    Firmen mit klassischen TK-Anlagen können Faxgeräte auch über analoge Leitungen direkt an die TK-Anlage anschließen. Wenn die TK-Anlage dann über einen SIP-Trunk "nach extern" geht, dann ist quasi die Gateway-Funktion "in der TK-Anlage" eingebaut.
  • Gateway zwischen TK und Amt
    Wenn die TK-Anlage aber z.B. aufgrund ihres Alters kein IP kann oder eine Aufrüstung teuer wäre, dann wird gerne auch ein Gateway zwischen TK-Anlage und VoIP-Anbindung geschaltet. Das machen manchmal sogar Carrier aus eigenem Interesse, z.B. Um einen Kunden auf die für den Carrier günstigere VoIP-Anbindung umzustellen ohne dass der Kunde an seiner TK-Technik etwas ändern muss.
  • Gateway in der Vermittlungsstelle
    Sollte die TK-Anlage noch über ISDN klassisch an ein Amt angeschlossen sein, dann dürft in der Vermittlungsstelle meist Schluss sein. Dort wird ein Gateway die ISDN-Daten auf VoIP umsetzen, weil die Carrier natürlich über ein bestehendes IP-Backbone viel günstiger die Informationen übertragen können
  • Zwischen Carriern
    Nun ist es ja so, dass es mehrere Firmen gibt, die Telekommunikationsdienste anbieten. Es muss also Übergänge (Peerings) zwischen den verschiedenen Anbietern geben, sonst könnte ja z.B. ein Telekom-Kunde nicht mit einem Kabel-Deutschland-Kunde eine Verbindung aufbauen. Auch zu den Mobilfunknetzen gibt es entsprechend Übergänge. Ich habe keine Detaildaten aber die meisten Peerings dürfte mittlerweile auch per IP erfolgen. Allerdings könnte es durchaus noch "analoge Strecken" geben, z.B. von Carriern in Entwicklungsländer oder schwach angebundene Regionen. Ich könnte mir daher schon vorstellen, dass Ein Carrier die VoIP Daten an einem Gateway wieder umsetzen muss, um diese in ein anderes Netz zu leiten.
  • SBC
    Idealerweise sprechen die VoIP-Endpunkte direkt miteinander. Auch wenn der SIP-Signalisierungsverkehr über verschiedene Relay-Stationen geht, wird per SDP (Siehe ICE und Kandidaten) der direkte Weg für die Media-Daten gesucht. Oft werden aber VoIP-Bereiche durch Session Border Controller getrennt. Diese setzen aber nicht nur SIP sondern auch SDP um. Ideal ist, es, wenn die beiden entfernten VoIP-Stationen T.38 sprechen und der SBC die Pakete nicht umcodieren muss. Das kostet Zeit, Ressourcen und vor allen wäre die Frage, welcher andere Codec außer T.38 genutzt werden könnte.

Es gibt also eine ganze Menge von Stellen, an denen eine Umsetzung auf T.38 erfolgen und entsprechend auch fehlschlagen kann. Mittlerweile haben aber die meisten Anbieter die Anfangsprobleme bei VoIP und insbesondere bei Fax über VoIP in den Griff bekommen, so dass die meisten Probleme an dem neu eingerichteten Ende einer Verbindung zu erwarten sind. Also wenn z.B. der virtuelle FaxServer über VoIP nicht mit dem Gateway oder TK-Anlage harmoniert, an die er gerade angebunden werden soll.

Idealerweise wird das Audiosignal bei einem Wechsel von TDM auf VoIP nur einmal gleich richtig umgesetzt. Das ist innerhalb eines Carriers auch die Regel aber wenn die Verbindung über verschiedene Carrier geht, kann es durchaus dazu kommen, dass auch auf Zwischenstrecken noch mal umgesetzt wird. "Sehen" können Sie dies als Admin an einem Ende der Leitung aber nicht. Eventuell könnte statistische Werte , die aus dem RTCP-Stream und QoS-Reports ermittelt werden, erste Hinweise liefern. Gehen Sie aber nicht davon aus, dass ein Carrier hier viele Daten liefert.

T38 und Lync

Der Lync Server selbst ist kein Lync Server, aber kann natürlich SIP-INVITEs routen. Auf der Seite Analoge Telefone habe ich z.B. beschrieben, wie ein analoges Fax quasi "hinter Lync" arbeiten kann. Aber es kann durchaus sein, dass ein Anrufer auf einem Faxgerät aus Versehen die Telefonnummer statt der Faxnummer eingeben. Dann "klingelt" es natürlich zuerst mal beim Teilnehmer und wenn der ran geht, wird auch die Audio-Verbindung aufgebaut. Sobald das Gateway aber den CNG-Ton hört und entsprechend konfiguriert ist, dann sendet es einen ReINVITE mit den T.38 Parametern. Das kann der Lync Mediation Server natürlich nicht und hinterlässt eine entsprechende Meldung im Eventlog.

Log Name:      Lync Server
Source:        LS Mediation Server
Event ID:      25039
Task Category: (1030)
Level:         Error
Keywords:      Classic
Description:
SDP negotiation failed with the Trunk.

Trunk FQDN gate.msxfaq.net;trunk=gate.msxfaq.net, Reason The offer from Gateway
     during a re-INVITE has changed an existing m-line
Cause: The Trunk is either not configured correctly, incompatible with Mediation 
     Server, or not certified.
Resolution:
Check that the Mediation server and Trunk are configured correctly.

Ich habe mir dann die entsprechenden Zeilen aus dem Gateway-Log gefischt gebe diese hier verkürzt wieder:

2014-08-20 16:51:26 <133>(   lgr_psbrdex)(32789713  )  recv <-- DETECT_FAX_ANSWER_TONE Ch:31, AnswerToneDetectionOrigin=0, AnswerToneDetectionDirection=0
2014-08-20 16:51:26 <133>(      lgr_flow)(32789724  )  ---- Outgoing SIP Message to 192.168.100.100:5068 from SIPInterface #0 ---- 
2014-08-20 16:51:26 <133>INVITE sip:nawlync001.netatwork.de:5068;maddr=192.168.100.100;transport=tcp SIP/2.0
Via: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac754744046;alias
Max-Forwards: 70
From: <sip:+xxxxxxxxxx@nawm1000.netatwork.de;user=phone>;tag=1c1518234574
To: <sip:+xxxxxxxx@192.168.100.100;user=phone>;tag=b14d30ab54;epid=2C5259A1C3
CSeq: 3 INVITE
Contact: <sip:192.168.100.107:5060;user=phone;transport=tcp>
Supported: em,timer,replaces,path,resource-priority
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE user-Agent: Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004
Content-Type: application/sdp
Content-Length: 325

v=0
o=AudiocodesGW 1518208284 1518207985 IN IP4 192.168.100.107
s=Phone-Call
c=IN IP4 192.168.100.107
t=0 0
m=image 6922 udptl t38
c=IN IP4 192.168.100.107
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:238
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
 [Time: 08-20-2014@15:51:25]

Der Lync Mediation Server sendet natürlich ganz schnell erst mal ein "100 Trying", damit das Gateway den Timeout verlängert.

2014-08-20 16:51:26 <133>SIP/2.0 100 Trying
FROM: <sip:+4937468696354@nawm1000.netatwork.de;user=phone>;tag=1c1518234574
TO: <sip:+495251304638@192.168.100.100;user=phone>;tag=b14d30ab54;epid=2C5259A1C3
CSEQ: 3 INVITE
CALL-ID: 15182334492082014145337@192.168.100.107
VIA: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac754744046;alias
CONTENT-LENGTH: 0

Aber noch in der gleichen Sekunde kommt dann schon der "488 Invalid SDP" zurück.

2014-08-20 16:51:26 <133>SIP/2.0 488 Invalid SDP: The offer from Gateway during a re-INVITE has changed an existing m-line
FROM: <sip:+4937468696354@nawm1000.netatwork.de;user=phone>;tag=1c1518234574
TO: <sip:+495251304638@192.168.100.100;user=phone>;epid=2C5259A1C3;tag=b14d30ab54
CSEQ: 3 INVITE
CALL-ID: 15182334492082014145337@192.168.100.107
VIA: SIP/2.0/TCP 192.168.100.107;branch=z9hG4bKac754744046;alias
CONTENT-LENGTH: 0
SUPPORTED: 100rel
SERVER: RTCC/5.0.0.0 MediationServer

Der Lync Mediation Server unterstützt kein T.38. Anders sieht es aus, wenn das Fax als "Analog Device" eingebunden ist. (Siehe Analoge Telefone). Hier sendet Lync dann einen "REFER" an das Gateway, um die Verbindung direkt zum Fax zu übergeben.

Audiocodes und XCAPI

Sehr viele Faxserver sind selbst gar nicht in der Lage, SIP oder T.38 zu bedienen und so hat sich die Software XCAPI der Firma TE-Systems als Quasistandard bei vielen Servern etabliert. Diese Software kann z.B. per SIP entsprechende Audio und FAX-Verbindungen aufbauen und an die Software als ISDN-CAPI weiter reichen. So wird jeder FaxServer, der bislang mit ISDN-Karten arbeiten konnte, zum FaxServer über VoIP. Und das sind einige Produkte im Markt. Exemplarisch habe ich die Konfiguration mit einem Audiocodes Gateway beschrieben und welche Tücken dabei zu beachten sind. Denn sowohl Audiocodes als auch TE-Systems haben entsprechende White Papers für die Einrichtung von Fax publiziert. Dummerweise sind die Einstellung darin nicht übereinstimmend, so das man sich die "richtige" Einstellung zusammendenken muss.

  • Codec
    TE-Systems besteht darauf, dass man im Audiocodes auch den T.38 Codec in der Coder-Liste aufnimmt. Audiocodes bietet dann auch brav den Codec im SDP an aber TE-Systems bietet ihn seinerseits nicht in der SDP-Antwort an. Anscheinend wusste man bei TE-Systems nicht, dass Audiocodes auch T.38 macht, wenn der Codec nicht in der Liste explizit offeriert wird.
  • Baudrate
    Audiocodes empfiehlt die Geschwindigkeit beim Fax auf 33600Baud zu setzen. Damit kommt aber TE-Systems nicht zurecht und beschwert sich, dass die Baudrate zu hoch ist. 14400 Baud ist hier der kompatible richtige Wert, den TE-Systems auch in in ihrer Dokumentation vorschlägt.

Wenn man auf die Funktion "Softfax" verzichtet, dann hat sich bei mir folgend Einstellung bewährt:

Auf der Ebene des Controllers wird die Funktion Softfax abgeschaltet und die "Enhanced Call Transfer (ETC)" deaktiviert:

Auf den Codecs muss T.38 UDP aktiviert sein.

Und auf dem T38 selbst sollte "XCAPI preferred" aktiv sein.

Auf der Seite von Audiocodes habe ich mit folgenden Einstellungen gute Erfahrungen gemacht

Der "Fax Transport Mode" muss auf 1 = RelayEnable stehen, damit T.38 genutzt wird. Der CNG Detector bleibt auf Disabled. Die Baudrate ist mit 14400 schnell genug und ECM kann man aktivieren. Je nach Umgebung und Netzwerk kann es sinnvoll sein, die "Fax Relay Redundancy Depth auf 2 (Default 0) und die "Fax Relay Enhanced Redundancy Depth" auf 2 (Default = 4) zu stellen. Das gilt es auszuprobieren, wenn es zu Problemen kommt.

Es gibt noch einen weiteren Parameter, der von TE-Systems aber gezielt im Bezug auf SoftFax und virtuelle Server aufgeführt wird. Man kann den Parameter "Dynamic Jitter Buffer Minimum Delay" oder pro IP-Profil anpassen. Per Default sind hier 10ms hinterlegt. TE-Systems empfiehlt den auf 80ms zu setzen.

Ich würde das aber nicht global, sondern in einem IP-Profil für das Fax-Ziel machen und dies in der Routingtabelle referenzieren.

Wie schon anfangs erwähnt beschreibt die XCAPI-Anleitung die Addition des T.38 Codecs. Auch hier würde ich dies nie global, sondern in einer eigenen "CoderGroup" machen, die auf das IP-Profile gebunden wird, welches dann wieder in der Routingtabelle referenziert wird.

Interessanterweise liefert XCAPI im SDP kein T.38 als Codec-Option mit und bei mir mir funktioniert der Faxempfang damit problemlos. Der G.729-Codec ist per Default ebenfalls nicht in der Liste. Hier ist er nicht wegen Fax addiert, sondern weil ein SIP-Trunk mit G.729 Bandbreite spart verwendet.

Fax mit Ferrari

Die EinstellMöglichkeiten eines Audiocodes gibt es in ähnlicher Form auch bei Ferrari. Hier macht aber der Hersteller sich etwas mehr Arbeit und ermittelt die passenden Einstellungen.

Zitat einer Mail von Ferrari
Wir testen das mit verschiedenen Gegenstellen (SIP Trunks, IPBX) und haben dann Parameterprofile für die bekannten Gegenstellen, die das regeln. Kann aber auch gezielt manuell in den Regeln eingestellt werden

Das macht es natürlich einfacher für die Anbindung, wobei natürlich die Einstellungen auf der Gegenseite weiterhin vorzunehmen sind, wenn diese abweichend konfiguriert sind. Hier zwei Einstellungen, die mit Fax relevant sind:

Das Gateway sendet per Default hier kein T.38 ReINVITE und der Echo Canceller ist ausgeschaltet. Weitere Einstellungen sind dann in der Routingtabelle möglich.

Wichtig ist einfach, dass beide Seiten einer SIP-Verbindung sich darüber geeinigt haben, wer das ReINVITE sendet. Wenn beide es versuchen, dann hängt es vom Timing ab, wer seinen Ton zuerst erkennt und erschwert die Fehlersuche, wen nur eine Richtung ein Problem haben sollte.

Swyx und T.38

Mittlerweile habe ich keine Swyx-PBX mehr im Einsatz, aber aus einer alten Dokumentation habe ich noch ein Bild gefunden, in dem ich damals die Konfiguration eines SIP-Trunks dokumentiert hatte.

Bei Swyx ist T.38 per Default aktiviert aber man kann Abschalten, das das Swyx Gateway den ReINVITE verhindert. Zudem könnte man den T.38 Codec beim ersten INVITE verbergen, so dass er nicht von Anfang an genutzt wird, sondern erst nach einem ReINVITE. Die gleiche Einstellung gibt es natürlich noch für VoIP-Endgeräte.

T.38 und DSL-Router (Fritz!Box u.a.)

Mittlerweile installiert die Telekom nur noch "IP-Anschlüsse" und auch die Kabelanbieter (Kabel Deutschland, unity Media) setzen natürlich voll auf VoIP mit entsprechenden Boxen. Wer hier ein Faxgerät anschließt, sollte darauf bauen können, dass dieses Gerät auch die CNG/CED-Töne erkennt und auf T.38 schaltet. Zudem muss natürlich die Gegenseite, d.h. das VoIP-System des Anbieters ebenfalls T.38 verarbeiten können. Bei meiner Fritz!Box (Fritz!OS 6) ist die Einstellung unter Telefonie - Eigene Rufnummern - Anschlusseinstellungen. Hier ein Bild:

AVM hat das Problem erkannt, dass verschiedene Provider kein T.38 unterstützen. Als Abhilfe kann bei einigen Boxen, der analoge Anschluss als "Fax" definiert werden.

AVM nutzt dann für Verbindungen dieses Teilnehmers den unkomprimierten Codec G711 aLaw und deaktiviert jede Optimierung wie Echo Cancellation, Rauschunterdrückung und passt die Jitter-Einstellungen an. meine 7390 hat das Menü aber nicht mehr. Vielleicht erkennt hier AVM den CNG/CED-Ton und nutzt die für Fax optimierten Einstellungen mit G711.

Das geht natürlich nur, wenn die Gegenseite auch T.38 unterstützt. Und das ist gar nicht so normal. Diverse Anbieter bieten daher einen "FAx2Mail Service an, bei dem der Provider das Fax bei sich empfängt und per Mail zustellt. für den Versand gibt es entsprechende Webportale um z.B. eine PDF-Datei zum Versand hoch zu laden.

Provider T.38 Support Stand

Telekom Deutschland GmbH

Nur zu anderen IP-Anschlüssen aber angeblich nicht ins Festnetz

Aug 2014

Kabeldeutschland

Nein, Fax über G.711

Aug 2014

Unitymedia

Keine technische Information, Kein Treffer in der KB
Fax "funktioniert" laut Werbung

Aug 2014

SipGate

Nein

Aug 2014

Net Cologne

Nein

Aug 2014

1und1

Ja

Aug 2014

Ich wollte es erst nicht glauben aber anscheinend beschreibt aktuell nur 1und1, dass die T.38 Option in der Fritz!Box aktiv sein soll. Alle anderen übertragen die Faxe von Privatanschlüssen anscheinend per G711, was durchaus zu Problemen führen kann. Vielleicht sind Privatkunden einfach toleranter ?

SIP-Trace

Exemplarisch habe ich ein FAX von meinem Home Office zu Net at Work gesendet. Im gekürzten Audiocodes-CDR Log ist zu erkennen, wann der Call startet und dass er mit G711 als Codec beginnt aber beim Ende ein T38 drin steht:

CALL_START  |ISDN|N/A            ||UNKN |REASON N/A               ||AUDIO
CALL_CONNECT|ISDN|g711Alaw64k    ||UNKN |REASON N/A               ||AUDIO
CALL_END    |ISDN|t38fax         ||RMT  |GWAPP_NORMAL_CALL_CLEAR  ||AUDIO

Mit meinen Tool Syslog2Snooper habe ich die SYSLOG-Ausgabe in ein Snooper-Format gebracht, um die SIP-Konversation anzuzeigen. Man sieht gut den initialen INVITE vom Gateway an de Port 5060 der XCAPI aber dann gegen 23:59:53:135 den "ReINVITE" von der XCAPI zurück zum Gateway mit der Bitte den Codec zu wechseln:

Schaut man die die SDP-Daten in dem INVITE jeweils an, dann sieht man:

  • INVITE vom Gateway zu XCAPI kündigt einen Audiocall an
INVITE sip:+495251304650@192.168.100.40;user=phone SIP/2.0 user-Agent: Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004

v=0
o=AudiocodesGW 1855390566 1855390265 IN IP4 192.168.100.107
s=Phone-Call
c=IN IP4 192.168.100.107
t=0 0
m=audio 6700 RTP/AVP 8 0 18 13 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=yes
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv
  • Die 200 OK Antwort bietet ebenfalls nur die Audiocodecs und DTMF an
SIP/2.0 200 Ok user-Agent: www.te-systems.de XCAPI V3.3.153.0

v=0
o=sip 5734438 1 IN IP4 192.168.100.40
s=SIP session
c=IN IP4 192.168.100.40
t=0 0
m=audio 60742 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15,32,36
a=sendrecv
a=rtcp:60743 IN IP4 192.168.100.40
  • Dann kommt aber de ReINVITE der XCAPI, die nun auf T.38 schwenken will
INVITE sip:192.168.100.107:5060;transport=tcp SIP/2.0 user-Agent: www.te-systems.de XCAPI V3.3.153.0

v=0
o=sip 5734438 2 IN IP4 192.168.100.40
s=SIP session
c=IN IP4 192.168.100.40
t=0 0
m=image 60742 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FillBitRemoval:0
a=T38FaxTranscodingMMR:0
a=T38FaxTranscodingJBIG:0
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy
  • Was dann Seitens des Gateway mit einem 200 OK akzeptiert wird
SIP/2.0 200 OK
Server: Audiocodes-Sip-Gateway-Mediant 1000/v.6.40A.042.004

v=0
o=AudiocodesGW 1855390566 1855390266 IN IP4 192.168.100.107
s=Phone-Call
c=IN IP4 192.168.100.107
t=0 0
m=image 6702 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxMaxBuffer:1024
a=T38FaxMaxDatagram:238
a=T38FaxRateManagement:transferredTCF
a=T38FaxUdpEC:t38UDPRedundancy

Die abschließenden BYE am Ende der Verbindung erspare ich ihnen.

T.38 in WireShark

Da ich für die Analyse sowohl die Verschlüsselung bei SIP (SIP/TCP statt SIP/TLS) als auch RTP statt SRTP deaktiviert habe, kann man mit WireShark auch die Pakete nachverfolgen. Hier sieht man zum einen dass der erste INTIVE auf 5060 geht aber dann eine zweite TCP-Connection gestartet wird. aber dann über UDP schon T.38 übertragen wird.

Die Statistik der Paketgrößen zeigt auch hier, dass selbst mit T.38 die Pakete nicht "gesammelt" werden sondern weiterhin "klein" bleiben.

Über die Funktion VoIP Call lässt auch auch ein sehr umfangreicher Trace erstellen, wen ich hier nur um ein paar HDLC-Datenpakete gekürzt habe:

Leider kann man mit WireShark aktuell noch kein T.38 wieder in ein Bild zusammensetzen, wie dies mit G711 Audio möglich ist.

Fax testen und optimieren

Nur weil ein Fax einmal erfolgreich übertragen wurde, ist das noch kein Freibrief, dass es immer und überall hin geht. Solange es noch "analoge" Stecken gibt, findet eine Umsetzung statt und da werden aus digitalen Bits natürlich "analoge" Pegel und wie im Telefon kann auch ein Fax unterschiedlich laut in die Leitung sprechen. Bei einigen Gateways kann das sogar eingestellt werden. Dazu müssten Sie aber natürlich wissen, wie passend die aktuelle Einstellung ist.

In Australien betreibt die Firma "Telstra" ein Fax-Testgerät, an welches Sie ein Fax senden können und einige Minuten später einen Report zurück bekommen. Unter der Rufnummer 1300 368 999 nimmt ein Fax ihren Anruf an. Die Nummer ist auch aus Deutschland unter +61 1300 368 999 erreichbar.

Damit die Gegenstelle ein Fax zurück senden kann, muss natürlich ihre Faxrufnummer richtig übermittelt worden sein. Die Funktion ist durchaus nicht nur für Firmen interessant, sondern auch für Privatpersonen, deren Anschluss auf einen "IP-Anschluss" umgestellt wurde.

Mir ist es übrigens mit einem HP8600 an einem "echten" ISDN-Anschluss nicht gelungen, ein entsprechendes Fax zurück zu bekommen. Die Gegenseite hat abgenommen der Handshake kam auch zustande (Anzeige der CSID der Gegenseite in meinem Display) und das Fax wurde übermitteln. Aber obwohl ich die Rufnummer in meinem Faxgerät richtig eingerichtet hatte und sicher auch per D-Kanal übermittle, kam kein Fax zurück.

Es gibt noch andere kostenfreie, teils werbefinanzierte Dienste, an die sie ein Fax senden und dann auf einer Webseite anschauen können oder wo Sie ihre Faxnummer in einem Formular eintragen können und dieses dann zugesendet wird.

Weitere Links