Fax-Empfang funktioniert nicht richtig

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
R

robinsonR

Mitglied
Mitglied seit
17 Apr 2006
Beiträge
560
Punkte für Reaktionen
0
Punkte
16
Ich versuche wieder einmal, Faxe zu empfangen. Zwar kommen die Testseiten an, aber die Fehlermeldungen irritieren mich doch. Und auch Asterisk meint gemäss Fax Status, dass der Fax-Empfang fehlerhaft ist. Die Konsole sagt:
Code: 
 Executing [s@ext-fax:3] StopPlayTones("SIP/sipcall-0000006d", "") in new stack
    -- Executing [s@ext-fax:4] ReceiveFAX("SIP/sipcall-0000006d", "/var/spool/asterisk/fax/1435004847.144.tif,f") in new stack
    -- Channel 'SIP/sipcall-0000006d' receiving FAX '/var/spool/asterisk/fax/1435004847.144.tif'
[2015-06-22 22:27:35] NOTICE[22460][C-00003243]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:19150'
[2015-06-22 22:27:35] NOTICE[22460][C-00003243]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:19150'
[2015-06-22 22:27:35] NOTICE[22460][C-00003243]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:19150'
[2015-06-22 22:27:38] WARNING[19670][C-00003243]: chan_sip.c:10320 process_sdp: Failed to initialize UDPTL, declining image stream
[2015-06-22 22:27:38] WARNING[19670][C-00003243]: chan_sip.c:10464 process_sdp: Insufficient information in SDP (c=)...
       > 0xb5b0ddd8 -- Probation passed - setting RTP source address to 212.117.203.76:19150
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
  == Spawn extension (ext-fax, s, 4) exited non-zero on 'SIP/sipcall-0000006d'
    -- Executing [h@ext-fax:1] GotoIf("SIP/sipcall-0000006d", "0?failed") in new stack
    -- Executing [h@ext-fax:2] GotoIf("SIP/sipcall-0000006d", "0?noemail") in new stack
    -- Executing [h@ext-fax:3] Set("SIP/sipcall-0000006d", "DELETE_AFTER_SEND=true") in new stack
    -- Executing [h@ext-fax:4] System("SIP/sipcall-0000006d", "/var/lib/asterisk/bin/fax2mail.php --to "[email protected]" --dest "4144xxxxxx" --callerid '"Adelheid Aregger" <0627528911>' --file /var/spool/asterisk/fax/1435004847.144.tif --exten "Telefax (329)" --delete "true" --attachformat "pdf"") in new stack
    -- Executing [h@ext-fax:5] Macro("SIP/sipcall-0000006d", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] ExecIf("SIP/sipcall-0000006d", "0?Set(CDR(recordingfile)=.wav)") in new stack
    -- Executing [s@macro-hangupcall:2] GotoIf("SIP/sipcall-0000006d", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,4)
    -- Executing [s@macro-hangupcall:4] Hangup("SIP/sipcall-0000006d", "") in new stack
  == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/sipcall-0000006d' in macro 'hangupcall'
  == Spawn extension (ext-fax, h, 5) exited non-zero on 'SIP/sipcall-0000006d'
pbx*CLI>

Irritiert bin ich wegen:
Code: 
[2015-06-22 22:27:38] WARNING[19670][C-00003243]: chan_sip.c:10320 process_sdp: Failed to initialize UDPTL, declining image stream
[2015-06-22 22:27:38] WARNING[19670][C-00003243]: chan_sip.c:10464 process_sdp: Insufficient information in SDP (c=)...
       > 0xb5b0ddd8 -- Probation passed - setting RTP source address to 212.117.203.76:19150
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-22 22:27:53] WARNING[22460][C-00003243]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found

Habe leider keine für mich Informationen zu diesen Meldungen gefunden.
 
Moins

Das sind nur Warnungen.
Bei entsprechenenden Loglevel, der zum Beispiel nur Fehler anzeigt, siehst du sowas gar nicht.
Also kannst du, wenn das Fax OK ist, diese auch getrost ignorieren.
 
Danke, erstmal. Hätte trotzdem gewusst, was die zu bedeuten haben. Habe leider nichts für mich Schlüssiges gefunden. Ja, die Faxe kommen rein, aber Fax Status meint eben, die Faxe seien fehlerhaft. Das irritiert eben schon. ;-)
 
OK, ich versuchs mal, die Recherche ergibt viel englischsprachiges...

Begriff: Failed to initialize UDPTL, declining image stream
Antwort:
Code: 
> The appropriate way for Asterisk to indicate that it does not support a
> media stream is to set the port number to 0. We have to inform the
> offerer that we don't support the media stream; removing it from the SDP
> completely is not allowed.
>
> Per RFC 3264, section 6:
>
> "   An offered stream MAY be rejected in the answer, for any reason.  If
>    a stream is rejected, the offerer and answerer MUST NOT generate
>    media (or RTCP packets) for that stream.  To reject an offered
>    stream, the port number in the corresponding stream in the answer
>    MUST be set to zero. "

Quelle

Freie Übersetzung: Asterisk hat einen Mediastream abgelehnt. T.38?
 
Vielen Dank. Soweit war ich auch. Nur, warum hat Asterisk den Media-Stream abgelehnt? Und ich habe T.38 ausgeschaltet; wenn ich T.38 aktiviere, geht gar nichts. Das hatte ich mit «Schlüssiges» gemeint. Ich finde zwar Erklärungen, aber nicht, was ich ändern könnte oder müsste, um dieses Verhalten zu ändern.
Auch zur zweiten Warnung habe ich Infos. Aber es gibt keine Änderung, ob ich ECM aktiviere oder ausgeschaltet lasse.
Liegt das Problem womöglich bei meinem Provider (sipcall.ch) oder am Absender? Der Absender ist eine Fritzbox 7490 mit eingeschaltetem T.38.
 
Naja, ich finds grad interessant, in einem anderen Thread sinnieren wir übers T.38.
Mach das in der 7490 aus, meine Beobachtung zu nichtunterstützten T.38 der Fritz!Box...

1. Versuch mit T.38
2. Versuch ohne

...müsste im Log der 7490 zu sehen sein.

Und wie geschrieben, nur Warnungen, wenns geht sei zufrieden. ;)
 
Aber man kennt das ja. Beim Testen geht alles gut, da man die Situation unter Beobachtung hat. Wenn dann der Absender irgend ein Mistgerät verwendet, stehe ich im Schilf. Darum wäre es doch wichtig, nicht einfach froh zu sein, wenn es zufällig gerade in dieser Kombination funktioniert.
 
T.38 würde, wenn, nur funktionieren, wenn auch alle Beteiligten das können/unterstützen.
Die wenigsten ITSPs tun das. Meiner nicht, deiner?
Du hättest für deinen Test auch die Möglicheit ohne ITSP, das wäre doch mal interessant.
...wenn also T.38 so bei dir funktionieren sollte, sparste Kohle.
Denn ITSPs unterstützen kein T.38, aber zur Flat gehört ein Fax nicht.
Ergo: Sie haben die Faxerkennung nur zum Abkassieren
 
Zuletzt bearbeitet:
So, jetzt habe ich noch zwei Tests gemacht. Bei der sendenden Fritzbox habe ich T.38 ausgeschaltet. Wenn ich nun bei mir als Empfänger «T38 Pass-Through» aktiviere, funktioniert es überhaupt nicht.
Code: 
 -- Executing [s@ext-fax:4] ReceiveFAX("SIP/sipcall-00000095", "/var/spool/asterisk/fax/1435219122.223.tif,f") in new stack
    -- Channel 'SIP/sipcall-00000095' receiving FAX '/var/spool/asterisk/fax/1435219122.223.tif'
  == Using UDPTL TOS bits 184
  == Using UDPTL CoS mark 5
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:01] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:03] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
[2015-06-25 09:59:03] WARNING[30228][C-00004460]: res_rtp_asterisk.c:3488 ast_rtp_read: RTP Read too short
  == Spawn extension (ext-fax, s, 4) exited non-zero on 'SIP/sipcall-00000095'
    -- Executing [h@ext-fax:1] GotoIf("SIP/sipcall-00000095", "1?failed") in new stack
    -- Goto (ext-fax,h,103)
    -- Executing [h@ext-fax:103] NoOp("SIP/sipcall-00000095", "FAX FAILED for: [email protected] , From: "xxxxxxxxxx") in new stack
    -- Executing [h@ext-fax:104] Macro("SIP/sipcall-00000095", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] ExecIf("SIP/sipcall-00000095", "0?Set(CDR(recordingfile)=.wav)") in new stack
    -- Executing [s@macro-hangupcall:2] GotoIf("SIP/sipcall-00000095", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,4)
    -- Executing [s@macro-hangupcall:4] Hangup("SIP/sipcall-00000095", "") in new stack
  == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/sipcall-00000095' in macro 'hangupcall'
  == Spawn extension (ext-fax, h, 104) exited non-zero on 'SIP/sipcall-00000095'


Bei deaktivierter «T38 Pass-Through» funktioniert der Empfang wie vorher. Es spielt in meiner Situation also keine Rolle, ob der Sender T.38 aktiviert hat oder nicht (ich weiss jetzt nicht, ob der Provider des Senders T.38 überhaupt unterstützt oder nicht.

Code: 
  -- Executing [s@ext-fax:4] ReceiveFAX("SIP/sipcall-00000098", "/var/spool/asterisk/fax/1435220557.226.tif,f") in new stack
    -- Channel 'SIP/sipcall-00000098' receiving FAX '/var/spool/asterisk/fax/1435220557.226.tif'
[2015-06-25 10:22:48] NOTICE[31152][C-00004479]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:20348'
[2015-06-25 10:22:48] NOTICE[31152][C-00004479]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:20348'
[2015-06-25 10:22:48] NOTICE[31152][C-00004479]: res_rtp_asterisk.c:3699 ast_rtp_read: Unknown RTP codec 100 received from '212.117.203.76:20348'
[2015-06-25 10:22:50] WARNING[19670][C-00004479]: chan_sip.c:10320 process_sdp: Failed to initialize UDPTL, declining image stream
[2015-06-25 10:22:50] WARNING[19670][C-00004479]: chan_sip.c:10464 process_sdp: Insufficient information in SDP (c=)...
       > 0xb5b042f8 -- Probation passed - setting RTP source address to 212.117.203.76:20348
[2015-06-25 10:23:05] WARNING[31152][C-00004479]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-25 10:23:06] WARNING[31152][C-00004479]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
[2015-06-25 10:23:06] WARNING[31152][C-00004479]: res_fax_spandsp.c:417 spandsp_log: WARNING T.30 ECM carrier not found
  == Spawn extension (ext-fax, s, 4) exited non-zero on 'SIP/sipcall-00000098'
    -- Executing [h@ext-fax:1] GotoIf("SIP/sipcall-00000098", "0?failed") in new stack
    -- Executing [h@ext-fax:2] GotoIf("SIP/sipcall-00000098", "0?noemail") in new stack
    -- Executing [h@ext-fax:3] Set("SIP/sipcall-00000098", "DELETE_AFTER_SEND=true") in new stack
    -- Executing [h@ext-fax:4] System("SIP/sipcall-00000098", "/var/lib/asterisk/bin/fax2mail.php --to "[email protected]" --dest "41xxxxx" --callerid '"xxxxxxxxx' --file /var/spool/asterisk/fax/1435220557.226.tif --exten "Urs Aregger (64)" --delete "true" --attachformat "pdf"") in new stack
    -- Executing [h@ext-fax:5] Macro("SIP/sipcall-00000098", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] ExecIf("SIP/sipcall-00000098", "0?Set(CDR(recordingfile)=.wav)") in new stack
    -- Executing [s@macro-hangupcall:2] GotoIf("SIP/sipcall-00000098", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,4)
    -- Executing [s@macro-hangupcall:4] Hangup("SIP/sipcall-00000098", "") in new stack
  == Spawn extension (macro-hangupcall, s, 4) exited non-zero on 'SIP/sipcall-00000098' in macro 'hangupcall'
  == Spawn extension (ext-fax, h, 5) exited non-zero on 'SIP/sipcall-00000098'
pbx*CLI>

Zu ergänzen ist vielleicht noch, dass es anscheinend auch keine Rolle spielt, ob ich bei meinem Asterisk ECM-Correction-Mode einschalte oder nicht.
 
Moins

Vielleicht interessiert dich noch was ich in Zusammenhang mit Asterisknummern (Users) in der Fritz!Box erreiche.
Darüber, so habe ich höchstpersönlich :mrgreen: herausgefunden, wie die interne Fritz!Box Faxfunktion auch "Intern" Faxe verschicken kann.
Also...

1. Entsprechende User in Astrerisk anlegen, sagen wir mal fünf 1000er: [1000] bis [1004]
2. Daran die Fritz!Boxnummern registrieren
3. Eine der Faxfunktion zuweisen und die Anderen auf die Memofunktion umleiten
4. Eine Wahlregel für Bereich 100 über eine Asterisknummer einrichten
5. Über internes Fax ein Fax auf eine der umgeleiteten Nummern senden

Der Trick dabei ist die ausgehende Wahlregel, die auf die Asteriskleitung geht, anstatt ins Internet.
Etwas verwirrend dabei ist, dass erst danach die Rufumleitung greift.
Die Memofunktion erkennt dann das Fax und leitet es um zu der internen Faxfunktion.
fb_ast_num_01.pngfb_ast_rul_01.pngfb_ast_dialplan_01.pngfb_ast_fax_01.pngfb_ast_fax_aliste_01.png
...die Faxe können auf USB abgelegt, und/oder als EMail versendet werden.
 
Zuletzt bearbeitet:
sipcall & T.38 Fax

Hallo an alle!

Ich weiss, - der Thread hier ist nicht mehr ganz frisch. Bin seit längerem genau an der gleichen T.38 Thematik dran. Kann die folgenden Infos bestätigen: Der Provider sipcall.ch unterstützt T.38 offiziell. (https://www.sipcall.ch/sipcall-media/docs/Informationen-fuer-Presse/2006.03.01.pdf)

Leider, nun folgt das grosse ABER, - sipcall's T.38 Implementierung / Umsetzung lässt zu wünschen übrig. :sad: Technische Zusatzinfos? FEHLANZEIGE! Zu dem Thema findet sich bei sipcall wirklich absolut nichts, nada. Nach mehrfachem Nachfragen wurde mir nur bestätigt das FEC bei T.38 nicht unterstützt wird, - sondern nur "redundancy".

Aus meiner Sicht wäre folglich folgende Konfig eigentlich richtig:

Code: 
t38pt_udptl=yes,redundancy

Funktioniert natürlich nicht... :sad:, ebenso wenig läuft:

Code: 
t38pt_udptl=yes,redundancy,maxdatagram=400

Dann hab ich noch an den anderen Parameter wie udptlchecksums, use_even_ports, etc herumgeschraubt. Hat leider nix gebracht. :sad: Die Faxe werden einfach nicht entgegengenommen bzw. weitergeleitet. Immerhin "sieht" FreePBX für kurze Zeit den T.38 Verbindungsaufbau seitens Sipcall. Nach einigen Sekunden bricht die Verbindung dann aber ab. An der Firewall liegts wohl eher nicht, - alle UDPTL, RDP & SIP Port's sind entsprechend freigeschaltet und werden zum FreePBX-Server weitergeleitet. Alle normalen Voice (VoIP) Verbindungen laufen gut.

Habe langsam den Eindruck das sipcall nicht wirklich zu T.38 steht, - ist vielleicht mehr eine Marketing Möglichkeit...

Hat jemand hier zufällig weitere Infos zu Sipcall & T.38? Hat das vielleicht jemand am Laufen?
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 692 (Mitglieder: 42, Gäste: 650)

Neueste Beiträge

Statistik des Forums

Themen
244,836
Beiträge
2,219,218
Mitglieder
371,542
Neuestes Mitglied
Andreaskaput
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück