XCAPI - Kein Re-INVITE bei fehlgeschlagener T38-Aushandlung

Birken-Apotheke

Customer
Mitglied seit
9. Juli 2019
Beiträge
5
Hallo,

wir haben hier den folgenden Aufbau:
QSC SIP Trunk -> 3CX Prof. 16.0.2.910 -> XCAPI 3.6.84.0 -> GFI FaxMaker 20.1

Der Faxempfang und -versand funktioniert, wenn die Gegenstelle T38 spricht. Sobald die Gegenstelle T38 ablehnt, beendet die 3CX die Verbindung umgehend. Die XCAPI ist als Fax-Extension in der 3CX angelegt. Re-INVITES sind auf dem SIP-Trunk aktiviert. Hier eine beispielhafte, gekürzte Kommunikation:

1 [IP QSC] [IP 3CX] SIP/SDP 1126 Request: INVITE sip:[email protected]:5060;rinstance=e305162b4b8140ab |
2 [IP 3CX] [IP QSC] SIP 399 Status: 100 Trying |
3 [IP 3CX] [IP XCAPI] SIP/SDP 1034 Request: INVITE sip:500@[IP XCAPI]:5000 |
4 [IP XCAPI] [IP 3CX] SIP 570 Status: 100 Trying |
5 [IP XCAPI] [IP 3CX] SIP/SDP 860 Status: 200 Ok |
6 [IP 3CX] [IP XCAPI] SIP 453 Request: ACK sip:500@[IP XCAPI]:5000 |
10 [IP 3CX] [IP QSC] SIP/SDP 926 Status: 200 OK |
14 [IP QSC] [IP 3CX] SIP 677 Request: ACK sip:[email protected]:5060 |
512 [IP XCAPI] [IP 3CX] SIP/SDP 1012 Request: INVITE sip:00221XXXXXXXX@[IP 3CX]:5060, in-dialog |
520 [IP 3CX] [IP QSC] SIP/SDP 1133 Request: INVITE sip:[IP QSC]:5060;transport=udp;line=sr-N6IAzJd4z.VLM.Vsz.MfWlNlPxVfMLZfzxV7M.P4OBN6zBjAWByXp9WINBuACSQ7g.14NEt7Nw05NhPQpRaA, in-dialog |
522 [IP QSC] [IP 3CX] SIP 428 Status: 100 Trying |
523 [IP 3CX] [IP XCAPI] SIP 372 Status: 100 Trying |
531 [IP QSC] [IP 3CX] SIP 589 Status: 488 Not Acceptable Here |
532 [IP 3CX] [IP QSC] SIP 558 Request: ACK sip:[IP QSC]:5060;transport=udp;line=sr-N6IAzJd4z.VLM.Vsz.MfWlNlPxVfMLZfzxV7M.P4OBN6zBjAWByXp9WINBuACSQ7g.14NEt7Nw05NhPQpRaA |
537 [IP 3CX] [IP XCAPI] SIP 385 Status: 488 Not Acceptable Here |
538 [IP 3CX] [IP QSC] SIP 722 Request: BYE sip:[IP QSC]:5060;transport=udp;line=sr-N6IAzJd4z.VLM.Vsz.MfWlNlPxVfMLZfzxV7M.P4OBN6zBjAWByXp9WINBuACSQ7g.14NEt7Nw05NhPQpRaA |
539 [IP 3CX] [IP XCAPI] SIP 453 Request: BYE sip:500@[IP XCAPI]:5000 |
540 [IP XCAPI] [IP 3CX] SIP 511 Status: 200 Ok |
541 [IP XCAPI] [IP 3CX] SIP 576 Request: ACK sip:00221XXXXXXXX@[IP 3CX]:5060 |
546 [IP QSC] [IP 3CX] SIP 584 Status: 200 OK |

Nach der Meldung "488 Not Acceptable Here" würde die XCAPI eigentlich einen Re-INVITE auf G711 schicken. Allerdings beendet die 3CX die Verbindung sofort.
Wodurch kommt es zu diesem Verhalten? Lässt sich das irgendwie beeinflußen?

Gruss,
Alex



das
 
Das gleiche Verhalten zeigt sich auch bei einem provisionierten Grandstream HT802. Auch hier beendet die 3CX-Anlage die Verbindung vor dem Re-INVITE auf G711. Kann das Verhalten jemand erklären?

Viele Grüße,
Alex
 
Das gleiche Verhalten zeigt sich auch bei einem provisionierten Grandstream HT802. Auch hier beendet die 3CX-Anlage die Verbindung vor dem Re-INVITE auf G711. Kann das Verhalten jemand erklären?

Viele Grüße,
Alex
Hallo! Hast du für das Problem eine Lösung gefunden? Ich hab ziemlich genau das Problem wie beschrieben, nur ich hab auch getestet von einer ganz normalen Telefonnebenstelle auf eine Faxnummer anzurufen, gewisse Nummern funktionieren, bei gewissen Nummern wird der Call nach 6-8 Sekunden von der 3CX beendet
 
Hallo avido_3cx,

die folgende, unbefriedigende Antwort habe ich vom 3CX-Support erhalten:

"Hallo Bell,
in dem Zeitpunkt wo uns Provider oder ATA ein "488 Not acceptable" sendet beendet die 3cx den Anruf.
Dieses ist auch laut RFC erlaubt.Die 3cx muss kein Re-Invite senden.
Das Verhalten kennen wir und leider muss ich Ihnen mitteilen das wir dieses nicht ändern werden.(nach Absprache mit unserem zuständigem Department)
Gerne können Sie das ATA direkt an provider verbinden um das Verhalten zu umgehen."

Viele Grüße,
Alex
 
Hallo avido_3cx,

die folgende, unbefriedigende Antwort habe ich vom 3CX-Support erhalten:

"Hallo Bell,
in dem Zeitpunkt wo uns Provider oder ATA ein "488 Not acceptable" sendet beendet die 3cx den Anruf.
Dieses ist auch laut RFC erlaubt.Die 3cx muss kein Re-Invite senden.
Das Verhalten kennen wir und leider muss ich Ihnen mitteilen das wir dieses nicht ändern werden.(nach Absprache mit unserem zuständigem Department)
Gerne können Sie das ATA direkt an provider verbinden um das Verhalten zu umgehen."

Viele Grüße,
Alex
Gut, wie soll das ATA direkt an den Provider verbunden werden? Ich versteh den Vorschlag nicht. Mein Fax ist eine DW des SIP-Trunks, wie soll das gehen?
 
Genau das Problem haben wir hier auch. Wir werden nun die Rufnummern auf einen Trunk bei easybell portieren. Dort kannst du einzelne Durchwahlen eines Rufnummernblocks in SIP-Accounts umwandeln. Schön ist anders...
 
Genau das Problem haben wir hier auch. Wir werden nun die Rufnummern auf einen Trunk bei easybell portieren. Dort kannst du einzelne Durchwahlen eines Rufnummernblocks in SIP-Accounts umwandeln. Schön ist anders...
Ja genau das is auch mein Problem...ich hab jetzt nochmals mit unserem Netzbetreiber gesprochen. Die sagen das Re-Invite muss ja nicht von der 3CX kommen, das macht ohnehin der Netzbetreiber selbst, die 3Cx müsste nur auf das Re-Invite warten, was sie eben nicht tut sondern einfach auflegt. Ich werd das jetzt nochmals an 3CX weiterleitet, kann doch nicht sein, dass man das nicht sauber zum Laufen bringt ohne einen Trunk für ein simples Fax auslagern zu müssen.
 
Zuletzt bearbeitet:
Bitte gib doch hier noch mal ein Feedback, wenn du eine Antwort erhältst.
Ich bin gespannt...
 

Statistik des Forums

Themen
44.414
Beiträge
232.721
Mitglieder
78.331
Neuestes Mitglied
b2daniel