Welcher Anbieter unterstützt T.38

dscampari · 18 Mrz 2008

Auch wenn es eher eine Nebenbemerkung ist:

Wenn man die Geschwindigkeit des Faxgerätes reduziert, dann funktioniert faxen über Voip auch ganz prima ohne T38.

Wir benutzen dass bei uns um Office so.

Gruss.

woprr · 26 Mrz 2008

sipgate basic (ohne guthaben) von analog FAX auf CW spandsp T.3x terminierung eingehend kann ich bestätigen:

http://www.ip-phone-forum.de/showpost.php?p=1065127&postcount=6

ausgehend nicht getestet.

dass sipgate in der FAQ schreiben, sie könnten es gar nicht, dürfte rein rechtliche gründe haben, man kann es halt nicht garantieren.
oder spandsp/RxFax schaltet automatisch zurück. hab ich noch nicht nachgeschaut.

joggo · 26 Mrz 2008

Ich habe jetzt einen Sipcall Account und sehe in der FritzBox (mit aktiviertem T.38 ) das für ausgehende Faxe T.38 verwendet wird. Allerdings bricht der Verbindungsaufbau gleich am Anfang wieder ab. Ohne T.38 funktioniert die Übertragung zumindest ebenso unzuverlässig wie über 1&1.

Jetzt ist nur die Frage was die Ursache für das T.38 Problem ist. Ein technisches Problem bei Sipcall oder die Firmware meiner 72720 ??

Ich werde mich jetzt mal an den Sipcall Support wenden, allerdings verspreche ich mir nicht wirklich viel davon.....

woprr · 26 Mrz 2008

liegt sicher nicht an einer 7270er fritzenbox, sondern am provider, die betamaxen haben scheins kein T.38 gateway, hab inzwischen dialplan für T.38 senden im CallWeaver, einmal nachts gings mit vielen zeilenfehlern, tagsüber geht nichts von T.38 über betamax auf analogfax:

Code:

tom3:~# grep RECV /var/log/syslog
Mar 26 10:39:40 tom3 FaxGetty[6484]: RECV FAX (000001241): from xxxxx T.38 FAX, page 1 in 1:35, INF, 7.7 line/mm, 1-D MH, 9600 bit/s
Mar 26 10:39:40 tom3 FaxGetty[6485]: RECV FAX (000001241): recvq/fax000000033.tif from xxxxxxx T.38 FAX, route to <unspecified>, 1 pages in 1:45
Mar 26 10:39:43 tom3 FaxGetty[32067]: RECV FAX: bin/faxrcvd "recvq/fax000000033.tif" "ttyS0" "000001241" ""
Mar 26 11:40:58 tom3 FaxGetty[6759]: RECV FAX (000001242): from , page 1 in 1:33, INF, 7.7 line/mm, 1-D MH, 9600 bit/s
Mar 26 11:40:58 tom3 FaxGetty[6760]: RECV FAX (000001242): recvq/fax000000034.tif from , route to <unspecified>, 1 pages in 1:34
Mar 26 11:41:02 tom3 FaxGetty[32067]: RECV FAX: bin/faxrcvd "recvq/fax000000034.tif" "ttyS0" "000001242" ""
Mar 26 12:30:49 tom3 FaxGetty[32067]: RECV: REJECT page quality, 33% good lines (95% required)
Mar 26 12:30:49 tom3 FaxGetty[6972]: RECV FAX (000001245): from , page 1 in 1:34, INF, 7.7 line/mm, 1-D MH, 9600 bit/s
Mar 26 12:30:49 tom3 FaxGetty[6973]: RECV FAX (000001245): recvq/fax000000035.tif from , route to <unspecified>, 1 pages in 1:43
Mar 26 12:31:19 tom3 FaxGetty[32067]: RECV FAX (000001245): session with  terminated abnormally: Unspecified Phase C error, including too much delay between TCF and +FDR command
Mar 26 12:31:19 tom3 FaxGetty[32067]: RECV FAX: bin/faxrcvd "recvq/fax000000035.tif" "ttyS0" "000001245" "Unspecified Phase C error, including too much delay between TCF and +FDR command"
Mar 26 12:51:26 tom3 FaxGetty[7057]: RECV FAX (000001246): from , page 1 in 0:16, INF, 7.7 line/mm, 1-D MH, 7200 bit/s
Mar 26 12:51:26 tom3 FaxGetty[7058]: RECV FAX (000001246): recvq/fax000000036.tif from , route to <unspecified>, 1 pages in 0:28
Mar 26 12:51:26 tom3 FaxGetty[32067]: RECV FAX (000001246): session with  terminated abnormally: Unspecified Phase D error
Mar 26 12:51:26 tom3 FaxGetty[32067]: RECV FAX: bin/faxrcvd "recvq/fax000000036.tif" "ttyS0" "000001246" "Unspecified Phase D error"

Mar 27 06:45:08.14: [32067]: SESSION BEGIN 000001251 49xxxxxxxx
Mar 27 06:45:08.14: [32067]: HylaFAX (tm) Version 4.3.1
Mar 27 06:45:17.17: [32067]: ANSWER: FAX CONNECTION  DEVICE '/dev/ttyS0'
Mar 27 06:45:17.17: [32067]: STATE CHANGE: ANSWERING -> RECEIVING
Mar 27 06:45:25.38: [32067]: RECV/CQ: Bad 1D pixel count, row 102, got 2009, expected 1728
Mar 27 06:45:26.58: [32067]: RECV/CQ: Bad 1D pixel count, row 155, got 1871, expected 1728
Mar 27 06:45:26.67: [32067]: RECV/CQ: Bad 1D pixel count, row 156, got 2995, expected 1728
Mar 27 06:45:27.02: [32067]: RECV/CQ: Bad 1D pixel count, row 157, got 2431, expected 1728
Mar 27 06:45:32.92: [32067]: RECV/CQ: Bad 1D pixel count, row 210, got 1959, expected 1728
Mar 27 06:45:39.42: [32067]: RECV/CQ: Bad 1D pixel count, row 274, got 1801, expected 1728
Mar 27 06:45:45.46: [32067]: RECV/CQ: Bad 1D pixel count, row 331, got 3494, expected 1728
Mar 27 06:45:45.78: [32067]: RECV/CQ: Bad 1D pixel count, row 333, got 1770, expected 1728
Mar 27 06:45:52.16: [32067]: RECV/CQ: Bad 1D pixel count, row 390, got 2759, expected 1728
Mar 27 06:45:52.33: [32067]: RECV/CQ: Invalid WhiteTable code word, row 391, x 112
Mar 27 06:45:52.33: [32067]: RECV/CQ: Bad 1D pixel count, row 391, got 112, expected 1728
Mar 27 06:45:58.76: [32067]: RECV/CQ: Bad 1D pixel count, row 450, got 2490, expected 1728
Mar 27 06:46:05.12: [32067]: RECV/CQ: Invalid BlackTable code word, row 636, x 1517
Mar 27 06:46:05.12: [32067]: RECV/CQ: Bad 1D pixel count, row 636, got 1517, expected 1728
Mar 27 06:46:05.58: [32067]: RECV/CQ: Bad 1D pixel count, row 637, got 2027, expected 1728
Mar 27 06:46:11.68: [32067]: RECV/CQ: Bad 1D pixel count, row 687, got 3250, expected 1728
Mar 27 06:46:12.71: [32067]: RECV/CQ: Bad 1D pixel count, row 694, got 2804, expected 1728
Mar 27 06:46:17.96: [32067]: RECV/CQ: Bad 1D pixel count, row 735, got 2144, expected 1728
Mar 27 06:46:24.50: [32067]: RECV/CQ: Bad 1D pixel count, row 790, got 1836, expected 1728
Mar 27 06:46:24.83: [32067]: RECV/CQ: Bad 1D pixel count, row 791, got 2141, expected 1728
Mar 27 06:46:30.82: [32067]: RECV/CQ: Bad 1D pixel count, row 842, got 3168, expected 1728
Mar 27 06:46:30.84: [32067]: RECV/CQ: Bad 1D pixel count, row 843, got 1729, expected 1728
Mar 27 06:46:30.93: [32067]: RECV/CQ: Bad 1D pixel count, row 844, got 1781, expected 1728
Mar 27 06:46:31.15: [32067]: RECV/CQ: Bad 1D pixel count, row 845, got 1729, expected 1728
Mar 27 06:46:37.22: [32067]: RECV/CQ: Bad 1D pixel count, row 897, got 2851, expected 1728
Mar 27 06:46:43.64: [32067]: RECV/CQ: Invalid WhiteTable code word, row 951, x 1458
Mar 27 06:46:43.64: [32067]: RECV/CQ: Bad 1D pixel count, row 951, got 1458, expected 1728
Mar 27 06:46:43.66: [32067]: RECV/CQ: Bad 1D pixel count, row 952, got 2314, expected 1728
Mar 27 06:46:44.22: [32067]: RECV/CQ: Bad 1D pixel count, row 953, got 1803, expected 1728
Mar 27 06:46:50.09: [32067]: RECV/CQ: Invalid WhiteTable code word, row 2191, x 87
Mar 27 06:46:50.09: [32067]: RECV/CQ: Bad 1D pixel count, row 2191, got 87, expected 1728
Mar 27 06:46:50.20: [32067]: RECV/CQ: Invalid BlackTable code word, row 2192, x 50
Mar 27 06:46:50.20: [32067]: RECV/CQ: Bad 1D pixel count, row 2192, got 50, expected 1728
Mar 27 06:46:50.26: [32067]: RECV/CQ: Invalid WhiteTable code word, row 2193, x 33
Mar 27 06:46:50.26: [32067]: RECV/CQ: Bad 1D pixel count, row 2193, got 33, expected 1728
Mar 27 06:46:50.30: [32067]: RECV/CQ: Bad 1D pixel count, row 2194, got 2645, expected 1728
Mar 27 06:46:50.31: [32067]: RECV/CQ: Bad 1D pixel count, row 2195, got 1738, expected 1728
Mar 27 06:46:50.32: [32067]: RECV/CQ: Bad 1D pixel count, row 2196, got 2043, expected 1728
Mar 27 06:46:50.33: [32067]: RECV/CQ: Bad 1D pixel count, row 2197, got 1754, expected 1728
Mar 27 06:46:50.35: [32067]: RECV/CQ: Bad 1D pixel count, row 2199, got 1925, expected 1728
Mar 27 06:46:50.40: [32067]: RECV/CQ: Bad 1D pixel count, row 2200, got 4519, expected 1728
Mar 27 06:46:51.52: [32067]: RECV/CQ: Adjusting for trailing noise (2 run)
Mar 27 06:47:00.61: [32067]: RECV FAX (000001251): from , page 1 in 1:34, INF, 7.7 line/mm, 1-D MH, 9600 bit/s
Mar 27 06:47:00.62: [32067]: RECV FAX (000001251): recvq/fax000000040.tif from , route to <unspecified>, 1 pages in 1:43
Mar 27 06:47:03.83: [32067]: RECV FAX: bin/faxrcvd "recvq/fax000000040.tif" "ttyS0" "000001251" ""
Mar 27 06:47:03.85: [32067]: SESSION END

und in 2 von 5 versuchen erkennt mein faxweichencode, der hylafax aktivieren soll noch nicht einmal die faxtöne und stellt die anrufe auf telefone durch.

UPDATE:
es geht doch noch etwas besser über betamax, alle ergebnisse im anhang.

von analog raus auf sipgate rein nach wie vor top.

versuch über betamax raus und auf sipgate rein gibt den da:
-- Got SIP response 488 "Not acceptable here" back from 217.10.79.9

sipgate und ekiga.net forwarden wenigstens zu Local.

pingping · 29 Mrz 2008

Hallo joggo,

joggo schrieb:
Ich werde mich jetzt mal an den Sipcall Support wenden, allerdings verspreche ich mir nicht wirklich viel davon.....

Hast du schon eine Reaktion vom Sipcall- Support erhalten?
Ich habe die Sache mit T.38 über Sipcall nochmal genauer untersucht und muss in der Folge meine Empfehlung zurücknehemen. Sorry, dass ich dich da hingeschickt habe.
Auf den Seiten von Sipcall ist seit dem 09.01.08 folgender Hinweis zu finden:

Zum jetzigen Zeitpunkt können wir keine 100%ige Verfügbarkeit für Fax over IP garantieren. Falls der Faxempfang oder -versand für den Endkunden sehr wichtig sind (z.B. Bestelleingang via Fax) und eine 100%ige Verfügbarkeit garantiert werden muss empfehlen wir die herkömmliche Lösung über analoge Anschlüsse.

Da ich selbst die Faxfunktion nur sporadisch nutze, war mir noch nicht aufgefallen, dass es inzwischen nicht mehr so gut funktioniert, wie das im Nov/Dez 2007 der Fall war. Jetzt habe ich auch festgestellt, dass es eigentlich gar nicht mehr geht.
Folgende Endgeräte/Firmwares habe ich nun mit T.38 über Sipcall nochmal getestet:

FBF 7170:
FW 29.04.97-9710 funktionierte im Nov. 2008 bestens - Geht jetzt nicht mehr.
FW 29.04.49 funktionierte im Dez. 2008 bestens - Geht jetzt nicht mehr

FBF 7270:
FW 54.04.55 Geht nicht.

Dabei sind folgende Verhaltenweisen im SIP-Trace erkennbar.
Verbindungsrichtung Sipcall-Voip zu einem Festnetzanschluss (T-Com):
Verbindungsaufbau mit G.711. Dann wird für die Verbindung T.38 verhandelt. Vom Sipcall- Mediagateway/Voicegateway wird auch T.38 gesendet. Die FritzBox kann vermutlich mit den Inhalten der T.38-Pakete nichts anfangen und antwortet nicht. Im weiteren Verlauf wird die Verbindung ausgelöst (ca. 30-40 sec).

Verbindungsrichtung Festnetzanschluss (T-Com) zu einem Sipcall-Voip-Account:
Verbindungsaufbau mit G.711. Es wird von der FritzBox versucht für die Verbindung T.38 auszuhandeln, seitens Sipcall wird das aber nicht akzeptiert. Die Faxübertragung mit G.711 schlägt fehl. Abbruch nach verschiedener Dauer.

Ich frage mich da, wie ein VoIP-Anbieter es schafft, ein Feature das sehr gut funktionierte, so zu schrotten

Da aber Sipcall offensichtlich mindestens seit dem 09.01. schon weis, dass das Faxen nicht mehr richtig funktioniert, ist m.E. auch nicht mit einer schnellen Lösung zu rechnen. Läge es nur an einer Kleinigkeit, wäre das Problem nach so langer Zeit sicher schon behoben.
Interesant wäre nun, ob T.38-Fax mit mit dem Fax-Softclient den Sipcall selbst anbietet, derzeit funktioniert. Bei Gelegenheit werde ich das noch ausprobieren. Wenn du Lust dazu hast, kannst du das selbst auch mal testen. Den Faxclient gibt es hier:
http://support.sipcall.ch/index.php?_m=downloads&_a=view&parentcategoryid=3&pcid=0&nav=0

Gruß pingping

woprr · 29 Mrz 2008

den disclaimer hat jeder provider vorsichtshalber, man kann fürs internet und die vielfalt der ausrüstungen beim kunden nunmal keine 100% faxübertragung garantieren, zu störanfällig.

und lieber http://www.comisdn.com/tsp/download.htm um auch sicher die version mit T.38 FoIP support zu erhalten. das seh ich beim sipcall download nicht.

ist T.38 support in der firmware der fritzenboxen vielleicht zur zeit kaputt?

UPDATE:
muss wohl bis montag auf freischaltung von testaccount warten bei sipcall, pfff

pingping · 29 Mrz 2008

woprr schrieb:
den disclaimer hat jeder provider vorsichtshalber, man kann fürs internet und die vielfalt der ausrüstungen beim kunden nunmal keine 100% faxübertragung garantieren, zu störanfällig.

Schon, aber das bezieht sich doch immer auf Fax via G.711. Sipcall schreibt ja selbst:

sipcall schrieb:
Faxe können bei guter Verbindungsqualität auch über den Sprach-Codec G.711 übertragen werden, welchen alle Adapter unterstützen. Eine jederzeit zuverlässige Übertragung in hoher Geschwindigkeit ist jedoch nur mit dem Fax over IP Protokoll T.38 möglich.

Da kann man dann schon erwarten, dass es mit T.38 zuverlässig klappt.

ist T.38 support in der firmware der fritzenboxen vielleicht zur zeit kaputt?

Daran dachte ich zuerst auch. Drum habe ich meine 7170 auf die Beta 29.04.97-9170 downgegradet. Mit dieser FW hat es definitiv funktioniert. Dass es damit jetzt aber auch nicht mehr funktioniert, lässt m.E. eindeutig darauf schließen, dass Sipcall was verändert hat. Wäre ja gut möglich, dass die T.38-Funktion für die eigenen Produkte optimiert wurde und gerade das zur Disfunktion der AVM-Geräte führt.

muss wohl bis montag auf freischaltung von testaccount warten bei sipcall, pfff

Bin mal gespannt was du da rausbekommst. Meine Möglichkeiten da weiter zu analysieren sind derzeit stark beschränkt.

Gruß pingping

woprr · 29 Mrz 2008

nee, den output von komprimierenden codecs wie GSM erkennt kein DSP mehr, auch T.38 geht nur über alaw/ulaw (G.711), und das muss man natürlich auch verlangen beim handshake, siehe meinen dialplan:
http://www.ip-phone-forum.de/showpost.php?p=1065127&postcount=6

hohe geschwindigkeit, marketing blablub, selbst mit T.3x über sipgate geht hier max 9600Baud

joggo · 29 Mrz 2008

Das ist die tolle Antwort vom Sipcall Support:

"sipcall unterstützt T.38 und der Faxversand sollte überwiegend funktionieren. Leider ist es momentan so, dass wir keinen 100% zuverlässigen Betrieb garantieren können. Es sollte jedoch möglich sein, die FB 7270 in Kombination mit sipcall zu konfigurieren, dass ein einigermassen zuverlässiger Betrieb möglich ist. "

100%ig nichtssagend

woprr · 1 Apr 2008

pingping schrieb:
Bin mal gespannt was du da rausbekommst. Meine Möglichkeiten da weiter zu analysieren sind derzeit stark beschränkt.

zugangsdaten erhalten, der sipcall.ch server mag mich aber nicht:

Code:

<-- SIP read from 212.117.200.148:5060:
SIP/2.0 501 Not Implemented
CSeq: 102 OPTIONS
Server: Sippy

wenn sipcall deutschland laut DNS den gleichen hat, dann wars das.
mit dem provider kann ich dann nix anfangen.

pingping · 1 Apr 2008

woprr schrieb:
wenn sipcall deutschland laut DNS den gleichen hat, dann wars das.
mit dem provider kann ich dann nix anfangen.

Versteh ich nicht

Egal ob sipcall in Deutschland, Österreich oder Schweiz. Der Registrar (mal voipgateway.org, mal sip.backbone.ch) zeigt immer auf den selben SIP-Proxy - eben die 212.117.200.148
Welcher SIP-Server dann für dich zuständig ist (vermutlich auch immer der gleiche) entscheidet sich doch anhand deiner Accountdaten. Ebenso auch die Authorization, d.h. auch wenn du schon einen anderen Account, der auf den selben Proxy zeigt hast, sollte das kein Problem sein.
Oder hat das "mit dem provider kann ich dann nix anfangen" ganz andere Gründe?

woprr · 2 Apr 2008

was gibts anner 501 antwort nicht zu verstehen? sipcall.ch kann anscheins nicht mal richtig SIP, der support ist informiert, aber leuten, die laut log nichtoptimierte i386 binaries von SER auf hochleistungsservern verwenden, trau ich ehrlich gesagt nicht viel zu. bisher auch keine antwort ausser dass der support agent meinen report noch nicht einmal kapiert hat und um triviale erklärung gebeten hat, tsts.

pingping · 5 Apr 2008

woprr schrieb:
was gibts anner 501 antwort nicht zu verstehen?

Schon, das meinte ich ja auch nicht, sondern

mit dem provider kann ich dann nix anfangen

Um eine Verbindung aufzubauen brauchts doch gar keine "Options".

dass der support agent meinen report noch nicht einmal kapiert

Da erwartest du vieleicht etwas zu viel. Bei dem Kostendruck heutzutage, kann man doch als Kunde nicht erwarten auch noch auf geschultes Personal zu treffen

Ach ja, hatte ich schon ganz vergessen. Ich habs jetzt auch noch mit einem Grandstream HT486 und T.38 über Sipcall probiert. Gleiches Ergebnis wie mit den FritzBoxen - geht nicht.

Gruß

woprr · 7 Apr 2008

auf meine trivialere fehlerbeschreibung kam heute diese antwort:

Diese Nachricht betrifft Ihre Support Anfrage #UXJ-5812xx. Sie haben sich bei uns innerhalb von 120 Stunden nicht gemeldet. Daher betrachten wir Ihren Fall als gelöst.

pingping · 7 Apr 2008

woprr schrieb:
Sie haben sich bei uns innerhalb von 120 Stunden nicht gemeldet. Daher betrachten wir Ihren Fall als gelöst.

:blonk: :-Ö

Gruß

doc456 · 17 Apr 2008

Hallo,

um das Thema mal in die richtigen Bahnen zu lenken, hat informerex eine Umfrage eröffnet.

Alle, bei denen es mit T38 wirklich funktioniert, bitte um Abstimmung und Kommentare...

Welcher Anbieter unterstützt T.38

dscampari

Guest

Aktives Mitglied

Neuer User

Aktives Mitglied

Anhänge

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

Aktives Mitglied

Neuer User

IPPF-Urgestein

Statistik des Forums