[Frage] Asterisk mit T.38

xrated

Mitglied
Mitglied seit
2 Jul 2012
Beiträge
786
Punkte für Reaktionen
1
Punkte
18
Welche Einstellungen muss man bei Asterisk machen damit man mit T.38 senden kann, ich habe nur t38pt_udptl=yes und die sendfax Application mit Parameter z gestartet. Es gibt ja noch diverse Parameter wie redundancy, maxdatagram, fec

[Feb 18 16:27:45] WARNING[5242]: res_fax.c:1934 sendfax_t38_init: channel 'SIP/personalvoip_out-00000000' refused to negotiate T.38
[Feb 18 16:27:45] WARNING[5242]: res_fax.c:2020 sendfax_t38_init: Audio FAX not allowed on channel 'SIP/personalvoip_out-00000000' and T.38 negotiation failed; aborting.
[Feb 18 16:27:45] ERROR[5242]: res_fax.c:2249 sendfax_exec: error initializing channel 'SIP/personalvoip_out-00000000' in T.38 mode

Edit: Laut deren Support ist Asterisk "unüblich" und haben damit keine Erfahrung. Aber gibt es dort überhaupt T.38 ?

Edit2: es soll sich um udptl + redundant handeln, klappt aber auch nicht

[Feb 26 21:21:36] WARNING[15491]: chan_sip.c:3684 retrans_pkt: Hanging up call [email protected] - no reply to our critical packet (see https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions).
[Feb 26 21:21:36] WARNING[11569]: res_fax.c:1506 receivefax_t38_init: error on 'SIP/personalvoip_out-00000040' while waiting for T.38 negotiation.
[Feb 26 21:21:36] ERROR[11569]: res_fax.c:1754 receivefax_exec: error initializing channel 'SIP/personalvoip_out-00000040' in T.38 mode
 
Zuletzt bearbeitet:
Mit Asterisk 11.7 funktionert T.38 eingehend aber ausgehend kommt immer noch:
channel 'SIP/personalvoip_out-00000000' refused to negotiate T.38
Auch mit res_fax_digium brachte es keine Änderung.
 
Eigentlich sollte immer die angerufene Seite das T.38 re-INVITE auslösen. Sprich in deinem Setup ohne z-option für SendFAX. Das T.38 -re-INVITE sollte von pbx-network Gateway kommen, nachdem es die angerufene Seite als Fax erkannt hat.

Also nochmal ohne z-Option testen. Und dann hier den SIP-Trace reinstellen, um zu sehen, ob und was von pbx-network in Sachen T.38 kommt bei einen ausgehenden Fax.

Hier ein wenig Hintergrundinfo dazu:
http://lists.digium.com/pipermail/asterisk-users/2009-March/228699.html
 
Ohne z geht es auch nicht, die Option besagt auch: Initiate a T.38 reinvite on the channel if the remote end does not

Status: FAILED
Faxerror: HANGUP

res_fax.c:1535 generic_fax_exec: channel 'SIP/personalvoip_out-00000007' FAX session '1' failure, reason: 'fax session timed-out' (TIMEOUT)

2 Dinge sind mir in den SIP Logs aufgefallen.
Zum einen wurde das zu ast02.pbx-network.de weitergeleitet, die ich aber noch nicht in iptables erlaubt habe für SIP. Und zum anderen kommt ein:
SIP/2.0 407 Proxy Authentication Required
wohl wegen meiner ungültigen From Adresse:
From: "Anonymous" <sip:[email protected]>;tag=as18bcdf52
Die Fromdomain kann man bei Asterisk mit sendfax oder originate aber leider nicht mitgeben.
 

Anhänge

  • sendfaxpbx.txt
    7.4 KB · Aufrufe: 6
Nun ist beim senden nichts mehr von T.38 zu sehen und die Übertragung fängt mit RTP an. Mit geladenem res_fax_digium wird die Übertragung einfach mitten drin abgebrochen nachdem von pbx ein bye kommt:

Code:
-- Channel 'SIP/personalvoip_out-0000000f' sending FAX:
    --    /tmp/faxconvert-01805237077000.tiff
       > 0xa898b28 -- Probation passed - setting RTP source address to 193.106.16.108:49268
    -- Channel 'SIP/personalvoip_out-0000000f' FAX session '0' started
     > Channel 'SIP/personalvoip_out-0000000f' fax session '0', [ 015.982356 ], channel sent 3 frames (60 ms) of silence.
       > Channel 'SIP/personalvoip_out-0000000f' fax session '0', [ 016.022292 ], channel sent 2 frames (40 ms) of energy.
       > Channel 'SIP/personalvoip_out-0000000f' fax session '0', [ 016.062211 ], channel sent 2 frames (40 ms) of silence.
<--- SIP read from UDP:46.182.250.50:5060 --->
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 46.182.250.50;branch=z9hG4bKc078.3a11fef5.0
Via: SIP/2.0/UDP 193.106.16.108:5060;received=193.106.16.108;branch=z9hG4bK4cad482e;rport=5060
Max-Forwards: 69
From: <sip:[email protected]>;tag=as17570b76
To: "Anonymous" <sip:[email protected]>;tag=as4cd1395e
Call-ID: [email protected]
CSeq: 102 BYE
User-Agent: PBX-network SERVER
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0

<------------->
--- (12 headers 0 lines) ---
Sending to 46.182.250.50:5060 (NAT)
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: BYE)

<--- Transmitting (NAT) to 46.182.250.50:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 46.182.250.50;branch=z9hG4bKc078.3a11fef5.0;received=46.182.250.50;rport=5060
Via: SIP/2.0/UDP 193.106.16.108:5060;received=193.106.16.108;branch=z9hG4bK4cad482e;rport=5060
From: <sip:[email protected]>;tag=as17570b76
To: "Anonymous" <sip:[email protected]>;tag=as4cd1395e
Call-ID: [email protected]
CSeq: 102 BYE
Server: DSL-EasyBox/DSL-EasyBox-10.02.012
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0

Mit dem res_fax (spandsp) funktioniert es dagegen, zumindest mit RTP.
Fax eingehend T.38 funktioniert weiterhin.
 
Zuletzt bearbeitet:
Mit 1und1 und freevoipdeal übrigens wie gehabt, T.38 Empfang über Receivefax geht aber Sendfax bricht immer mit Faxerror: T38_NEG_ERROR ab.

sip.conf wie folgt probiert:
t38pt_udptl=yes
t38pt_udptl=yes,redundancy,maxdatagram=400
t38pt_udptl=yes,redundancy
t38pt_udptl=yes,fec,maxdatagram=204
t38pt_udptl=yes,none

udtptl.conf:
udptlstart=4000
udptlend=4099
use_even_ports = yes

res_fax.conf:
statusevents=yes
ecm=yes

Sendfax wird über ein Perl Script mittels originate ausgelöst:
originate("SIP/$peer/$argnumber",$contextoriginate,"fax");
Syntax: originate(channel,context,exten)

Im Dialplan auch schon testweise mit answer und wait vor sendfax probiert. Sendfax wahlweise mit f und/oder z parameter.

Fehler:
Code:
   -- Channel 'SIP/1und1_out998774-00000000' sending FAX:
    --    /tmp/faxconvert-081913055789.tiff
[Sep 18 17:11:50] ERROR[14642][C-00000000]: res_fax.c:2021 sendfax_t38_init: error reading frame while generating CNG tone on SIP/1und1_out998774-00000000
[Sep 18 17:11:50] ERROR[14642][C-00000000]: res_fax.c:2439 sendfax_exec: error initializing channel 'SIP/1und1_out998774-00000000' in T.38 mode
  == Spawn extension (faxoutgoing, 08xxxxx, 6) exited non-zero on 'SIP/1und1_out998774-00000000'

Gemäß Sourcecode heisst das das die Gegenstelle keine Pakete schickt auf den von Asterisk ausgelösten CNG tone.

Vielleicht kann den Thread jemand ins Asterisk Forum verschieben. Da es ja mit allen Providern (pbx,freevoipdeal,1&1) gleichermaßen auftritt.

Version 11.19 habe ich auch schon probiert. T30 geht wie immer ganz normal wenn die Gegenstelle kein T.38 hat. Es handelt sich um spandsp, res_fax_digium hab ich damals überhaupt nicht zum laufen gebracht.

Ausführliches log
Code:
[Sep 19 18:04:46] WARNING[3812]: pbx_spool.c:317 safe_append: Unable to set utime on /var/spool/asterisk/outgoing/testfax.call: Operation not permitted
    -- Attempting call on SIP/freevoipdeal_out/08xxxxxxx for application Sendfax(/tmp/testfax.tif) (Retry 1)
  == Using SIP RTP CoS mark 5
Audio is at 7086
Adding codec 100004 (alaw) to SDP
Adding codec 100003 (ulaw) to SDP
Adding codec 100002 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 77.72.174.128:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK306885f9;rport
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: FRITZ!OS
Date: Sat, 19 Sep 2015 16:04:47 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 282

v=0
o=root 1824551446 1824551446 IN IP4 84.134.163.8
s=Asterisk PBX 11.19.0
c=IN IP4 84.134.163.8
t=0 0
m=audio 7086 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:77.72.174.128:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK306885f9;rport
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 102 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
WWW-Authenticate: Digest realm="freevoipdeal.com",nonce="xxxx",algorithm=MD5
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---
Transmitting (NAT) to 77.72.174.128:5060:
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK306885f9;rport
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: FRITZ!OS
Content-Length: 0


---
Audio is at 7086
Adding codec 100004 (alaw) to SDP
Adding codec 100003 (ulaw) to SDP
Adding codec 100002 (gsm) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 77.72.174.128:5060:
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK3cd6a3b9;rport
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 INVITE
User-Agent: FRITZ!OS
Authorization: Digest username="ghost", realm="freevoipdeal.com", algorithm=MD5, uri="sip:[email protected]", nonce="xxxx", response="xxx"
Date: Sat, 19 Sep 2015 16:04:47 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 282

v=0
o=root 1824551446 1824551447 IN IP4 84.134.163.8
s=Asterisk PBX 11.19.0
c=IN IP4 84.134.163.8
t=0 0
m=audio 7086 RTP/AVP 8 0 3 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:77.72.174.128:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK3cd6a3b9;rport
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 103 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---

<--- SIP read from UDP:77.72.174.128:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK3cd6a3b9;rport
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 103 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---

<--- SIP read from UDP:77.72.174.128:5060 --->
SIP/2.0 183 Session progress
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK3cd6a3b9;rport
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>;tag=320313ac55ee95e3a7147
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 103 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Type: application/sdp
Content-Length: 215

v=0
o=ghost 1442678718 1442678718 IN IP4 80.239.235.60
s=SIP Call
c=IN IP4 80.239.235.60
t=0 0
m=audio 10028 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv
<------------->
--- (11 headers 10 lines) ---
list_route: hop: <sip:[email protected]:5060>
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - (gsm|ulaw|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 80.239.235.60:10028
       > 0x7fe9dc014ba0 -- Probation passed - setting RTP source address to 80.239.235.60:10028

<--- SIP read from UDP:77.72.174.128:5060 --->
SIP/2.0 200 Ok
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK3cd6a3b9;rport
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>;tag=320313ac55ee95e3a7147
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 103 INVITE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Content-Type: application/sdp
Content-Length: 215

v=0
o=ghost 1442678721 1442678721 IN IP4 80.239.235.60
s=SIP Call
c=IN IP4 80.239.235.60
t=0 0
m=audio 10028 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=ptime:20
a=sendrecv
<------------->
--- (11 headers 10 lines) ---
Found RTP audio format 8
Found RTP audio format 101
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - (gsm|ulaw|alaw), peer - audio=(alaw)/video=(nothing)/text=(nothing), combined - (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 80.239.235.60:10028
list_route: hop: <sip:[email protected]:5060>
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 77.72.174.128:5060
Transmitting (NAT) to 77.72.174.128:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 84.134.163.8:5060;branch=z9hG4bK0371bbf9;rport
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as26f7863a
To: <sip:[email protected]>;tag=320313ac55ee95e3a7147
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 ACK
User-Agent: FRITZ!OS
Content-Length: 0


---
       > Channel SIP/freevoipdeal_out-00000003 was answered.
       > Launching Sendfax(/tmp/testfax.tif) on SIP/freevoipdeal_out-00000003
    -- Channel 'SIP/freevoipdeal_out-00000003' sending FAX:
    --    /tmp/testfax.tif
       > 0x7fe9dc014ba0 -- Probation passed - setting RTP source address to 80.239.235.60:10028

<--- SIP read from UDP:77.72.174.128:5060 --->
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 77.72.174.128:5060;branch=z9hG4bK3cd6a3b9
From: <sip:[email protected]>;tag=320313ac55ee95e3a7147
To: "asterisk" <sip:[email protected]>;tag=as26f7863a
Contact: sip:[email protected]:5060
Call-ID: [email protected]
CSeq: 1 BYE
Server: (Very nice Sip Registrar/Proxy Server)
Allow: ACK,BYE,CANCEL,INVITE,REGISTER,OPTIONS,INFO,MESSAGE
Max-Forwards: 70
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---
Sending to 77.72.174.128:5060 (NAT)
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: BYE)

<--- Transmitting (NAT) to 77.72.174.128:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 77.72.174.128:5060;branch=z9hG4bK3cd6a3b9;received=77.72.174.128;rport=5060
From: <sip:[email protected]>;tag=320313ac55ee95e3a7147
To: "asterisk" <sip:[email protected]>;tag=as26f7863a
Call-ID: [email protected]
CSeq: 1 BYE
Server: FRITZ!OS
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0


<------------>
[Sep 19 18:04:59] ERROR[5166][C-00000003]: res_fax.c:2028 sendfax_t38_init: error reading frame while generating CNG tone on SIP/freevoipdeal_out-00000003
[Sep 19 18:04:59] ERROR[5166][C-00000003]: res_fax.c:2446 sendfax_exec: error initializing channel 'SIP/freevoipdeal_out-00000003' in T.38 mode
[Sep 19 18:04:59] NOTICE[5166]: pbx_spool.c:427 attempt_thread: Call completed to SIP/freevoipdeal_out/08xxxxxxx
pbx*CLI>
 
Zuletzt bearbeitet:
Der übersichtlicherhalber ein neuer Post.
Habe festgestellt das bei T.38 vorher erst ein Verbindungsaufbau über Sprache d.h. RTP und SDP erfolgt, wusste ich gar nicht.
freevoipdeal hat kein T.38. Deswegen wird im obigen Sip Log wohl einfach vom Provider aufgelegt (bye) und Asterisk wartet auf CED Töne.

Bei 1und1 funktioniert T.38 bei manchen Gegenstellen, bei anderen wird statt dessen über G711 gefaxt (dort läuft Telekom ISDN).
Also funktioniert T.38 auch wirklich nur wenn dies am anderen Faxgerät aktiviert ist.
Ich dachte immer das der Provider mein T.38 Fax mit einem Gateway zu PSTN umwandeln würde, dies ist nicht der Fall.
Man sieht auch im Log das die UDPTL Pakete nicht zu meinem Provider laufen.
Bei einer Gegenstelle mit Telekom ISDN erhalte ich keine Antwort und es wird einfach mit T.38 Negotiation Error aufgelegt obwohl sendfax mit der Option f (allow audio failback) läuft.
Das macht T.38 dann doch sehr unzuverlässig. Oder hat die Telekom dort am Anschluss was falsch eingestellt?

Desweiteren sind die T.38 Parameter wie fec,redundancy oder maxdatagram bei jeder Gegenstelle anders!
Wenn ich ein Fax erhalte kommt die IP auch von einem Endgerät und nicht von meinem Provider also machen die nur T.38 Passthough was doch irgendwie sinnlos ist?
Vor allem weil eh kaum jemand T.38 nutzt.

Auch eingehende Faxe über T.38 scheinen recht häufig fehlzuschlagen z.B. Timer T2 expired while waiting for next fax page oder Disconnected after permitted retries.
Der neue Parameter t38timeout in res_fax scheint auch nicht zu helfen. Das war aber nur bei einer Gegenstelle wo T.30 genauso fehlschlägt.

Dazu kommt noch das man T.38 nur device oder peerbasiert ausschalten kann und nicht im Dialplan. Also nur Empfang auf T.38 geht auch nicht.

Da benutze ich doch lieber T.30 mit V29,9600baud,ecm=off (ohne Fehlerkorrektur soll laut Cisco bei Voip besser sein weil ecm nicht sehr fehlertolerant ist)
 
Zuletzt bearbeitet:
[Edit Novize: Völlig überflüssiges Riesen-Fullquote vom Beitrag direkt darüber gelöscht - siehe Forumsregeln]

Hallo xrated, - hier folgt nun zur Abwechslung ein Post von mir. ;)

Die T.38 Thematik ist teilweise wirklich nebulös bzw. mysteriös. Und anscheinend wird es immer komplizierter. Laut folgendem Dokument ist bei T.38 nun doch auch eine nativer Verbindungsaufbau untereinander möglich! http://www.swyxdownload.com/download/kb4427_Faxuebertragung_SIP.pdf

Das nennt sich dann INVITE T.38. Die Funktion ist bei Asterisk und Konsorten wohl aber noch nicht implementiert. Falls zu dieser Thematik jemand aber mehr Infos hat dann bitte hier gleich ein Beispiel mit entsprechender Konfig posten. Danke! :)

Glaube nun aber nicht, dass T.38 auf der ganzen Linie vorhanden / unterstützt werden muss. :confused:
User A --> Provider 1 --> Provider 2 --> User B

Einzig entscheidend ist doch nur, dass der eigene Provider T.38 unterstützt.
Beispiel, ich sende ein "Internet-Fax" per T.38 von einem FoIP fähigen Faxgerät an ein altes analoges Faxgerät bzw. an einen Mailempfänger.

User A, FoIP Faxgerät mit T.38 --> Provider 1 --> Provider 2, wandelt T.38 nach T.30 --> User B, empfängt analoges T.30 Fax (über PSTN)

User A, FoIP Faxgerät mit T.38 --> Provider 1 --> Provider 2, wandelt T.38 nach T.37 --> User B, empfängt T.37 Fax als Mail (im Anhang)

Die grosse Mehrzahl der Probleme mit T.38 hängt aus meiner Sicht mit fehlerhaften Implementierungen seitens der Provider zusammen. Darüber hinaus scheinen viele Provider mit dieser Thematik grundsätzlich selber überfordert zu sein. So kann mir beispielsweise mein Provider sipcall nicht näher erklären wie deren T.38 Anbindung von meiner Seite in Asterisk nun genauer konfiguriert werden soll. Und dass, obwohl die T.38 eigentlich unterstützen!! :mad: Einfach nur schwach... :heul: ;)
 
hmm altes Thema

Glaube nun aber nicht, dass T.38 auf der ganzen Linie vorhanden / unterstützt werden muss. :confused:

doch war bei mir so, T.38 war nicht überall möglich obwohl es mein ISP unterstützt.
Liegt wohl evtl. daran das mein ISP nur T.38 Passthrough macht aber kein Gateway oder bei T.38 generell nur Passthrough möglich ist.
 
[Edit Novize: Völlig überflüssiges Fullquote vom Beitrag direkt darüber gelöscht - siehe Forumsregeln]

So wird es sein, - 1und1 verfügt vermutlich über kein T.38 Gateway. Wie auch immer, dieses alte & leidige T.38 Problemthema wird uns noch für eine Weile erhalten bleiben...
 
"Um ein mit T.38 versendetes Fax an ein übliches Faxgerät übertragen zu können, sind Gateways zwischen den beiden nicht kompatiblen Übertragungsarten notwendig."

Gateways mit s. Wenn also eine Seite T.38 einfach deaktiviert, dann gehts auch nicht.

T.30_Protocol_Figure_01.jpg
 
Ok, werde hier nun definitiv nix mehr quoten.. ;)

Richtig, die Gateways (plural, deutsch Mehrzahl) haben ein s am Schluss. Das einzelne (also singular) Gateway hat hingegen ziemlich ganz sicher keines. :p

Viel wichtiger aber ist, der T.38 sipcall Fehler ist nun tatsächlich (auf)geklärt! Bin & war unschuldig, - sipcall hat's vergeigt. Noch besser aber ist, die Ursache wurde bereits vor sage und schreibe über 6 Jahren festgestellt! :shock:

Aus dem Wiki der innovaphone AG:
"T.38 is stated as supported, but no fax call was possible, due T.38 negotiation problems. The T.38 gateway on provider site exceeds the T4 timer of the T.30 protocol. As a result, fax calls with T.38 do not work." Quelle: http://wiki.innovaphone.com/index.php?title=Howto:Sipcall_business_-_SIP_Provider_Compatibility_Test

Das spricht nun wirklich nicht für sipcall. Die scheinen beim Fehlermanagement ein ernstes Problem zu haben. Ok, hängt vielleicht auch damit zusammen, dass (bis jetzt) kein Schw.. T.38 gebraucht hat. ;)
 
Ich denke jedenfalls das es keinen Provider gibt der T.38 so anbietet das das ganze von ihm komplett nach Analog zur Gegenstelle umgewandelt wird.
Macht ja eigentlich anders auch keinen Sinn da T.38 rein ip basiert ist.

Weil bestimmt 99% der Bevölkerung nicht mal wissen was T.38 überhaupt ist, deswegen wurde das so zögerlich umgesetzt. Sipgate und Vodafone hats immer noch nicht.
 
Ich denke jedenfalls das es keinen Provider gibt der T.38 so anbietet das das ganze von ihm komplett nach Analog zur Gegenstelle umgewandelt wird.
Denke ich auch, da es die Provider keine Analognetze mehr betreiben.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,686
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
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.