Faxempfang bricht bei eingehenden Faxen ab

[btkbp]

Hallo, ich habe eine 3CX in der Version 15.5.0 auf einer virtuellen Maschine (Hyper-V) unter Windows Server 2012 R2 laufen. Auf dieser Maschine läuft zusätzlich die XCAPI und der GFI-Faxmaker.
Das vorliegende Szenario sieht folgendermaßen aus:
Telekom-SIP-Trunk NGN -> LanCom-Router 1781AV-4G -> 3CX-Telefonanlage -> XCAPI -> GFI-Faxmaker.

Faxe können aus dem GFI-Faxmaker an fast alle Empfangsgeräte problemlos verschickt werden.
Bei eingehenden Faxen bricht die Übertragung bei ca. 40% der anwählenden Gegenstellen nach etwa 7 Sekunden ab.


Im Whireshark-Mitschnitt ist zu erkennen, dass zunächst der Ruf normal aufgebaut wird. Beide Seiten einigen sich auf G.711 a-Law und auf einen DTMF-Codec. Die Telekom schlägt für G.711 zwei Varianten vor ("8" und "118"), was die 3CX entsprechend beantwortet.

Nach dem Rufaufbau kommt von der Telekom ein neues Invite, mit dem die Faxübertragung vorbereitet werden soll. Dabei entfernt die Telekom alle unnötigen Codecs und schlägt nur noch G.711 ("8") vor.
Die 3CX beantwortet das ebenfalls mit einem einzigen Codec, allerdings der "118".
Direkt danach beendet die Telekom den Ruf.

Die 3CX schlägt der XCAPI völlig andere Codecs vor, als amtsseitig ausgehandelt wird. Die XCAPI antwortet wie auch schon die Telekom im Fax-Modus nur noch mit G.711 ("8").

Wie kann man in den Codec-Einstellungen der 3CX dafür sorgen, dass auf beiden Seiten nur noch G.711 mit dem Payload Type 8 gemacht wird?

 

[danielwolf]

Guten Abend,

ich würde mich über einen 1-2 Screenshots oder Kontakt zu Ihnen freuen.
Meine Konfiguration Aufbau ist praktisch identisch. Bislang Nutzen wir Xcapi und Faxmaker ohne den Zwischenschritt 3cx.

Wir möchten die nächsten Monate unser System umbauen. Da wäre es schlüssig alles über 3cx abzuwicklen.

Mit freundlichen Grüßen
Daniel Wolf

 

[sbits]

Hallo, wir haben das gleiche Problem und haben das sowohl von 3CX als auch der Telekom analysieren lassen. Hier der letzte Stand. Leider keine Lösung aber ein Interessanter Hinweis. Wir haben dies soeben bei der Telekom eskaliert. Mal schauen ob es was bringt:

Provider (equipment) is configured (implemented) and uses non-standard gpmd payload attribute.
Initial offer is sent with doubled description of PCMA codec. (payload 8 and 118). One is with fmtp attribute, another with non-standard gpmd attribute.

after call is answered (media session is established), provider renegotiates codec set and changes PCMA codec description bound to payload 8 with the description which was bound to payload 118 in initial negotiation of media session.
It causes conflict, because new description of PCMA codec is already bound to payload 118 in initial offer/answer.

Voip provider can configure own side of trunk and avoid usage of non-standard extensions in payload description (remove unnecessary duplication of codecs). Also, provider need to preserve payload definitions when renegotiate media session.
there are three unusual things which are making everything more complicated then it should be:
a). duplicated definitions of the same codec in initial offer.
b). unnecessary instant renegotiation of SDP right after answer is provided.
c). a) and b) are not a problem themselves, the problem appears when on stage b) codec description is changed - it means that payload 8 is different and equal to the payload parameters previously bound to payload 118.
from initial offer:

a=rtpmap:8 PCMA/8000
a=fmtp:8 vad=no
a=rtpmap:118 PCMA/8000
a=gpmd:118 vbd=yes

renegotiation

a=rtpmap:8 PCMA/8000
a=gpmd:8 vbd=yes

We realize that for DT, changing from an ISDN-heavy network to SIP is a big and difficult task, but we cannot make changes to our software to match this incorrect behavior.