T.38 FoIP Erfahrungsaustausch

Hallo!

olaf_TT schrieb:
1.Asterisk & T.38 Unterstützung
-Er soll ja jetzt T.38 passthrough Unterstützung haben. Ab Version 1.2.4?!?
http://bugs.digium.com/view.php?id=5090
-Asterisk verhält sich vollkommen transparent beim Empfang von Faxen mit T.38? Ist dies wirklich so?


Gibt es jemanden der die T.38-Pass-Through Unterstützung bestätigen kann?
Aus obigem Link werde ich leider nicht ganz schlau.

Sollte T.38 eigentlich auch bei " canreinvite=no" weitergereicht werden?

christian
 
T.38 Fax nur wenige Seiten möglich ?

Auch wenn Fax dann über IP möglich ist, gibt es Probleme bei Mehrseitenfaxe.
So ab 5 Seiten steigen die Geräte gerne aus. Gut sagen jetzt viele, soviele Seiten faxe ich nie. Es gibt aber eine Berufsgruppe die Vieleseitenfaxe häufig benutzen: Rechtsanwälte ! und wenns dort nicht funktioniert ist der Ärger sehr groß ... !
 
Die Mehrseitenproblematik kann ich nur bestätigen - ab 3 Seiten wird es problematisch, ggf. ab 2 treten schon "Unschönheiten" / "Ungenauigkeiten" auf.
 
Moin,
...man hab ich einen Schädel! Warum tut man sich jedes Jahr wieder diesen Vatertag an ;-) ?

@Mehrseitenproblematik:
Das ist ja eines der Probleme weshalb wir hier über T.38 reden.
Mit der Unterstützung sollten diese Probs ja der Vergangenheit angehören.
Ich kann nur sagen, dass es an Alcatel TK-Anlagen mit T.38 keine Fax Probleme über IP gibt.

Gruß
Olaf
 
VoIptester schrieb:
moin moin forum !!!

beide Daumen hoch fuer diesen Thread ... probiere auch grade mit dem T38 Patch von http://bugs.digium.com/view.php?id=5090

einfach mal ein anaologes fax geraet an sipura 2100 -> an asterisk (1.2.7.1 mit aktuellem patch) -> kapanga(softphone mit t38 unterstuezung)

aber ich bekomme es nicht zum laufen ...

das kapanga erkennt zwar das ein t38 kommt aber sobald die Verbindung augebaut werden soll bricht es ab

Meldung in der asterisk console

Apr 26 12:15:00 WARNING[14594]: chan_sip.c:3490 process_sdp: Unknown SDP media type in offer: image 5124 UDPTL t38


hat schon mal jemand den asterisk zum laufen bekommen mit dem asterisk-1.2.7.1-t38-20060423.tar.bz2 Patch ??

kann hier auch gerne mal den gesammten call-flow posten aber vieleicht ist ja schon jemand weiter ;-)

bis dahin

gruss torben

Hi VoIptester,

also ich habe genau das selbe Prob wie du mit T.38 und dem oben genannten Patch. Hast du schon eine Lösung?

-- Attempting native bridge of SIP/192.168.92.248-081b2bd0 and SIP/402-ab14
Jun 15 21:13:59 WARNING[2742]: chan_sip.c:3745 process_sdp: Unknown SDP media type in offer: image 16418 udptl t38
Jun 15 21:14:06 WARNING[2742]: chan_sip.c:3745 process_sdp: Unknown SDP media type in offer: image 6666 udptl t38

Gruß
Olaf
 
Zuletzt bearbeitet:
Wie konfiguriere ich T.38 im Asterisk???

Was muss man alles im Asterisk konfigurieren damit T.38 läuft?

udptl.conf:

; UDPTL Configuration (UDPTL is one of the transports for T.38)
;
[general]
;
; UDPTL start and UDPTL end configure start and end addresses
;
udptlstart=4000
udptlend=4999
;
; Whether to enable or disable UDP checksums on UDPTL traffic
;
;udptlchecksums=no
;
; The error correction type to be sent
;
T38FaxUdpEC = t38UDPFEC
;T38FaxUdpEC = t38UDPRedundancy
;
; The maximum length of a UDPTL packet
;
T38FaxMaxDatagram = 400
;
; The number of error correction entries in a UDPTL packet
;
udptlfecentries = 3
;
; The span over which parity is calculated for FEC in a UDPTL packet
;
udptlfecspan = 3

Habt ihr hier etwas geändert?

sip.conf:

[general]
context=Rufnummernplan
port=5060
bindaddr=0.0.0.0
localnet=192.168.92.0/24
externip=blaaa.dyndns.org
srvlookup=yes
language=de
disallow=all
allow=alaw
defaultexpirey=120
maxexpirey=3600
language=de
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no


[402]
type=friend
username=402
secret=402
callerid="Linksys Port1 Fax"= <402>
host=dynamic
disallow=all
allow=alaw
canreinvite=yes
insecure=very
qualify=yes
dtmfmode=rfc2833
context=Rufnummernplan
callgroup=1
pickupgroup=1
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no

Wenn ich bei dem User die T.38 Parameter setze kommt immer folgende Meldung:

Jun 15 21:44:48 ERROR[2742]: chan_sip.c:7013 register_verify: Peer '402' is trying to register, but not configured as host=dynamic
Jun 15 21:44:48 NOTICE[2742]: chan_sip.c:11696 handle_request_register: Registration from '402 <sip:[email protected]>' failed for '192.168.92.102' - Username/auth name mismatch

Sobald ich die T.38 Paramter auskomentiere funktioniert es sofort.
Muss ich sie überhaupt beim Teilnehmer setzen?
Wie habt ihr es eingerichet?

Gruß
Olaf
 
olaf_TT schrieb:
Wenn ich bei dem User die T.38 Parameter setze kommt immer folgende Meldung:



Sobald ich die T.38 Paramter auskomentiere funktioniert es sofort.
Muss ich sie überhaupt beim Teilnehmer setzen?
Wie habt ihr es eingerichet?

Gruß
Olaf

Das habe ich jetzt so gelöst:

[402]
type=friend
username=402
secret=qwertz402
callerid="Linksys Port1 Fax"= <402>
host=dynamic
allow=all
t38pt_udptl=yes
t38pt_rtp=no
t38pt_tcp=no
canreinvite=yes
insecure=very
qualify=yes
dtmfmode=rfc2833
context=Rufnummernplan

Wenn die T.38 Parameter unter allem stehen kann der User sich nicht mehr verbinden.

Trotzdem rennt T.38 immer noch nicht!!!

Hat keiner ERFAHRUNGEN??????

Gruß
Olaf
 
olaf_TT schrieb:
Das habe ich jetzt so gelöst:



Wenn die T.38 Parameter unter allem stehen kann der User sich nicht mehr verbinden.

Trotzdem rennt T.38 immer noch nicht!!!

Hat keiner ERFAHRUNGEN??????

Gruß
Olaf

Ich verwende den T38 Patch zusammen mit Asterisk 1.2.9.1.
Versuche ich mit Kapanga (und 1 und 1 als Provider) ein Fax zu schicken habe ich ähnliche Probleme.
In den Logfiles erscheint immer folgendes:

Code:
Jun 25 21:56:34 NOTICE[2945] rtp.c: Unknown RTP codec 100 received
Jun 25 21:56:34 NOTICE[2945] rtp.c: Unknown RTP codec 100 received
Jun 25 21:56:34 NOTICE[2945] rtp.c: Unknown RTP codec 100 received
Jun 25 21:56:37 WARNING[2608] chan_sip.c: Unknown SDP media type in offer: image 18456 udptl t38
Jun 25 21:56:42 WARNING[2945] rtp.c: RTP Read too short
Jun 25 21:56:43 WARNING[2945] rtp.c: RTP Read too short
Jun 25 21:56:43 WARNING[2945] rtp.c: RTP Read too short

In der globalen und in den lokalen Sektionen habe ich jeweils folgendes aktiviert:
Code:
t38pt_udptl=yes
t38pt_rtp=yes
t38pt_tcp=no
canreinvite=yes

Ich habe das Gefühl der T38 Patch überhaupt nicht funktioniert. Kann das sein?
 
uholeschak schrieb:
Ich habe das Gefühl der T38 Patch überhaupt nicht funktioniert. Kann das sein?


das gefühl habe ich leider auch, ich bekomme die gleichen fehlermeldungen wie ihr.

gruss
/alex
 
T38 Asterisk

Hallo!

Ich bin auch gerade am testen mit Fax am Asterisk.
Gibt es hier wo eine Kurzanleitung wie man diesen Patch einspielt?

Danke,
Hannes
 
hallo zusammen

mittlerweile habe ich einen * 1.4 testweise in betrieb und etliche T.38 (und auch T.30) tests mit meiner voice plattform gemacht. diese besteht im prinzip aus einem cisco class 4 softswitch mit AS series media gateways, SS7 ins PSTN und via einen Session border controller mit SIP in richtung asterisk (und den rest der welt ;).
habe mir extra für die tests ein linksys SPA-2102 zugelegt. ein kunde von uns hat auch ein paar tests mit seiner openPBX gemacht.

alles in allem sind die resultate erschreckend. eingehende faxe sind relativ unkritisch, aber ausgehend ist ein greuel...

dazu muss ich noch kurz anmerken, dass bei mir T.38 die bevorzugte methode für faxversand ist. d.h. sobald ein media gateway ein fax erkennt (CNG tone via G.711), wird der call agent auf jeden fall für T.38 re-inviten. unterstützt das end device kein T.38, wird dieses invite mit 415 oder 488 rejected und es sollte als fallback G.711 fax passthrough gemacht werden.

mit asterisk 1.2.x hatte ich probleme mit dem fax fallback, habe aber auf 1.4 gewartet, um T.38 zu machen.

hier meine tests mit 1.4:

1. fax fallback (no T.38), zB mit einen cisco ata 186/188.
resultat: http://bugs.digium.com/view.php?id=8677

2. T.38 mit linksys SPA, canreinvite=yes
resultat: je nach SPA config geht das fax raus oder nicht. aber immer macht asterisk einen fehler im SIP chan. wenn das fax durch geht, macht er den fehler zum glück erst danach http://bugs.digium.com/view.php?id=8736

3. T.38 passthrough mit dem SPA, d.h. canreinvite=no
resultat: noch schlimmer, T.38 passthrough scheint gar nicht zu laufen

4. ein call setup von einer als SIP client registrierten openPBX (direkt mit T.38) mag er auch nicht.

kann irgend jemand positives berichten bezogen auf asterisk 1.4 und T.38?

gruss
/alex
 
Moin, werde die Tage auf 1.4.x umsteigen und dann das ganze mal wieder mit meiner Alcatel OmniPCX testen. Aber die Probs die du beschreibst hören sich für mich identisch mit denen an die ich schon bei der 1.2.x mit T.38 Patch hatte.
Bis die Tage...
Olaf
 
alex-911 schrieb:
alles in allem sind die resultate erschreckend. eingehende faxe sind relativ unkritisch, aber ausgehend ist ein greuel...

dazu muss ich noch kurz anmerken, dass bei mir T.38 die bevorzugte methode für faxversand ist. d.h. sobald ein media gateway ein fax erkennt (CNG tone via G.711), wird der call agent auf jeden fall für T.38 re-inviten. unterstützt das end device kein T.38, wird dieses invite mit 415 oder 488 rejected und es sollte als fallback G.711 fax passthrough gemacht werden.

mit asterisk 1.2.x hatte ich probleme mit dem fax fallback, habe aber auf 1.4 gewartet, um T.38 zu machen.
Im Prinzip hat sich an der T.38-Unterstützung zwischen Asterisk 1.2 und 1.4 nicht viel geändert. Die einzige Verbesserung von 1.4 gegenüber 1.2 ist, daß der Medientyp "image udptl" nicht abgelehnt wird. Es gibt aber nach wie vor einige fundamentale Probleme in chan_sip, die viele ATAs und Mediengateways mit T.38-Unterstützung wegen des notwendigen Re-INVITEs und falschen Antworten von Asterisk aus dem Tritt bringen (s. z.B. http://bugs.digium.com/view.php?id=7461, http://bugs.digium.com/view.php?id=8599, http://bugs.digium.com/view.php?id=8524).

Die Ursache für diese Probleme liegt darin, daß das T.38 Passthrough nach wie vor zum größten Teil aus einem mehrere Monate alten Patch von Steve Underwood besteht (http://bugs.digium.com/view.php?id=5090), der voraussetzt, daß T.38 einmal eingeschaltet und dann während der SIP-Session nicht wieder ausgeschaltet wird. Wenn Olle E. Johansson (der Maintainer von chan_sip) Steve Underwood nicht vergrault hätte, dann wäre die T.38-Unterstützung wahrscheinlich inzwischen weiter fortgeschritten :rolleyes:

Im aktuellen Zustand funktioniert die Implementierung aber - wie Du selbst festgestellt hast - nur im Labor, d.h. unter optimalen Umständen und mit Endgeräten, die sich 100%ig an die RFCs halten.

Wenn Du besser funktionierendes T.38 brauchst, dann mußt Du z.Zt. OpenPBX benutzen :-(

Henning
 
T.38

Hallo zusammen,

bei mir sind 2 Siemens Hipath3000 TK Anlagen per S2M über 2 Asterisk 1.4 mit TE110P Zap vernetzt.

HP3k---S2M---*-----VPN(SIP)-----*---S2M---HP3k

In Hoffnung die Faxunterstützung zu verbessern habe ich beide * nun auf 1.4 hochgezogen, und trotz google und Forum bleiben noch einige Fragen offen:

1.
In der sip .conf habe ich die Einstellungen für T.38 vorgenommen:
canreinvite=yes
t38pt_udptl = yes (auch in general)
die Faxübertragung wird im Moment nur für verbindungen zwischen den beiden * genutzt.
Wie kann ich überprüfen ob und wann T.38 genutzt wird? in der CLI und den channelstatus kann ich nichts in diese Richtung erkennen.

2.
bei Faxe vom *1 zum *2 bekomm ich die Meldung:
-- Channel 1 echo canceler disabled due to CED detection
bei Faxe vom *2 zum *1 jedoch nicht.
Beide habe identische Konfigurationen, wieso klappt die CED Erkennung bei dem einen bei dem anderen jedoch nicht?

Im Moment hab ich keinen Peil mehr wo ich noch rumschrauben könnt, wäre für jede Info dankbar,



MfG Frank
 
stoner schrieb:
Hallo zusammen,

bei mir sind 2 Siemens Hipath3000 TK Anlagen per S2M über 2 Asterisk 1.4 mit TE110P Zap vernetzt.

HP3k---S2M---*-----VPN(SIP)-----*---S2M---HP3k
In diesem Setup kann kein T.38 mit Asterisk benutzt werden. Asterisk unterstützt z.Zt. nur T.38 Passthrough. Das heißt, daß das Gateway T.30<->T.38 außerhalb von Asterisk liegen muß. Du benutzt Asterisk aber als Mediengateway zwischen VoIP und ISDN.

stoner schrieb:
Wie kann ich überprüfen ob und wann T.38 genutzt wird? in der CLI und den channelstatus kann ich nichts in diese Richtung erkennen.
Du mußt die SIP-Aushandlung zwischen den SIP-Parteien und Asterisk debuggen. Wenn alle Seiten auf das T.38 re-INVITE mit ACK antworten, dann wird T.38 benutzt. In der CLI von Asterisk kann z.Zt. nicht zweifelsfrei erkannt werden, ob T.38 tatsächlich verwendet wird.

stoner schrieb:
bei Faxe vom *1 zum *2 bekomm ich die Meldung:
-- Channel 1 echo canceler disabled due to CED detection
bei Faxe vom *2 zum *1 jedoch nicht.
Beide habe identische Konfigurationen, wieso klappt die CED Erkennung bei dem einen bei dem anderen jedoch nicht?
Wahrscheinlich ist die Faxtonerkennung auf *1 ausgeschaltet oder sie funktioniert nicht richtig. Probiere mal faxdetect=both (in zapata.conf). Wenn das auch nicht klappt, dann könnte dtmfmode=inband (in sip.conf) noch helfen.

Gruß
Henning
 
Hallo Henning,

besten Dank für deine Antwort, aber etwas ist mir noch unklar:

hehol schrieb:
In diesem Setup kann kein T.38 mit Asterisk benutzt werden. Asterisk unterstützt z.Zt. nur T.38 Passthrough. Das heißt, daß das Gateway T.30<->T.38 außerhalb von Asterisk liegen muß. Du benutzt Asterisk aber als Mediengateway zwischen VoIP und ISDN.

soll das bedeuten, dass der Asterisk T.38 bei SIP Verbindungen zu einem anderen Gateway nutzt, jedoch bei SIP Verbindungen zu einem Asterisk (Gateway) nicht?

Grüsse,

Frank
 
stoner schrieb:
soll das bedeuten, dass der Asterisk T.38 bei SIP Verbindungen zu einem anderen Gateway nutzt, jedoch bei SIP Verbindungen zu einem Asterisk (Gateway) nicht?
Nein. Asterisk unterstützt T.38, wenn es selbst nur die T.38 Datenpakete durchleiten muß oder wenn es nur die SIP-Vermittlung zwischen zwei Endgeräten durchführt, die T.38 verwenden. Es kann kein Gateway zwischen T.38 (Fax über IP) und T.30 (Fax über TDM) sein. Da Deine Hicom-Anlagen aber gemäß Deines Plans über ISDN an Asterisk angeschaltet sind, müßte Asterisk die Konvertierung zwischen T.30 und T.38 vornehmen. Diese Funktion nennt man "T.38 Gateway" und sie wird von Asterisk nicht unterstützt.

Henning
 
Hallo hehol,

da gabs anscheinend bei mir noch Verständigungsprobleme, nun ist mir einiges klarer, besten Dank für deine Hilfe.

demnach gibts keine vernünftige Lösung Faxe über IP zwischen 2 Asterisk Servern zu übertragen?
Inwieweit kann die Übertragung für Faxe optimiert werden? Meine Einstellungen mit denen ich die besten Erfahrungen gamacht habe:
codec=alaw
echocancel=off (bzw. per CID Erkennung off)
hierbei hatte ich mit SIP bessere Ergebnisse als mit IAX2.

wie könnte die Übertragung weiter optimiert werden?

Besten Dank,

Frank
 
stoner schrieb:
demnach gibts keine vernünftige Lösung Faxe über IP zwischen 2 Asterisk Servern zu übertragen?
Wenn sich die beiden Asterisk-Server nicht im selben LAN befinden, würde ich dieser Aussage zustimmen. Im LAN sollte G.711 fehlerlose Ergebnisse liefern, wenn die Modems in den Faxgeräten ordentlich programmiert sind.

stoner schrieb:
wie könnte die Übertragung weiter optimiert werden?
Jemand muß ein T.38-Gateway in Asterisk implementieren, dann kann die Zuverlässigkeit der Übertragung verbessert werden. Es gibt auch mit spandsp bereits einen Open Source Software-DSP, der dies leisten könnte. Es fehlt nur die Integration in Asterisk. Der Aufwand dafür ist aber alles andere als klein und die nötige Programmierleistung ist nicht trivial, weil die notwendigen Schnittstellen im Kern von Asterisk für diese Art von "Codec"-Konvertierung fehlen.

Henning
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.