VCM/Fax: T.38-Aushandlung und T.38-Übertragung schlagen fehl

[Jirka]

EDIT: Mittlerweile hat sich rausgestellt, dass meine ursprüngliche Vermutung, dass es an einer falschen Call-Sequenze liegt, falsch ist. Dadurch wurden einige Postings erzeugt, die den Thread jetzt etwas in die Länge ziehen, ich bitte das zu entschuldigen.

Hallo,

ich habe das Problem, dass Faxe nicht per T.38 an einem SIP-Client empfangen werden können. Die T.38-Aushandlung schlägt fehl wegen einer falschen Call-Sequenze-Nummer im INVITE vom LANCOM.
Firmware ist die 9.24.0334-SU9.

Aufbau: LANCOM-Router mit VCM und SIP-Leitung, daran angeschlossen (als SIP-Client) eine FRITZ!Box im IP-Client-Modus, die T.38 macht und für das Faxgerät eine analoge Schnittstelle zur Verfügung stellt.

Ablauf: Es geht ein Ruf ein, das Faxgerät (bzw. aus Sicht des LANCOMs die FRITZ!Box) nimmt ab, die FRITZ!Box schlägt dem LANCOM T.38 vor ((Re-)INVITE), das geht soweit auch durch, der LANCOM will das mit der Wandlung auf T.38 jetzt dem Provider vorschlagen und macht da den Fehler, im SIP-Packet nicht den Call-Sequenze-Zähler (CSeq) hochzuzählen und stattdessen mit dem alten "1 INVITE" fortzufahren. [DAS IST DAS HAUPTPROBLEM.] Daraufhin knallt es beim Provider (488 Not Acceptable Here, obwohl der Provider T.38 unterstützt). Anschließend bestätigt der LANCOM (trotzdem) der FRITZ!Box die T.38-Umstellung zu vollziehen, antwortet also auf das T.38-(Re-)INVITE der FRITZ!Box mit OK, - die FRITZ!Box legt jetzt also schon los mit T.38 - und denkt sich, dann wandel ich das zum Provider ("try T.38 to G.711 transcoding") und macht dann nach meinem Verständnis wieder einen Fehler und schlittert durch das hier fett gedruckte Hauptproblem dadurch in das nächste Problem: Jetzt kommt nämlich der Vorschlag auf T.38 umzustellen vom Provider. Den leitet der LANCOM-Router erstens zur FRITZ!Box weiter, obwohl er das nach meinem Verständnis nicht machen dürfte, weil er ja der FRITZ!Box bereits das T.38 bestätigt hat. Das ist nach dem schon erfolgten T.38-OK nach meinem Verständnis, ich habe jetzt aber nicht die RFC dazu gelesen, falsch. Im Prinzip verrennt der LANCOM sich jetzt meiner Meinung nach auch. Die FRITZ!Box sendet bereits mit T.38 und zum Provider soll erst umgestellt werden. Das bedeutet, dass der LANCOM das Fax per T.38 annimmt und dann per T.38 an den Provider weitergeben muss, das Fax also nicht direkt durchgeleitet wird. Ich glaube dieser Modus (T.38 zu T.38) ist gar nicht vorgesehen, weil er ja eigentlich Quatsch ist. Und zweitens leitet der LANCOM das T.38-(Re-)INVITE jetzt mit der CSeq "2 INVITE" an die FRITZ!Box weiter, das ist falsch, da die FRITZ!Box ja längst bei "3 INVITE" war (die 1 war das erste INVITE vom LANCOM zur FRITZ!Box, die 2 war das erste (Re-)INVITE der FRITZ!Box mit T.38, was der LANCOM allerdings mit Proxy Authentication Required beantwortet hat und somit die 3 der letzte und gültige Versuch der FRITZ!Box war, auf T.38 umzustellen). Die FRITZ!Box ist aber genügsam und segnet das mit OK ab. Jetzt schickt (nur in folgendem Wireshark-Screenshot zu sehen, nicht im Trace) der LANCOM-Router der FRITZ!Box vier defekte T.38-Pakete. Alle mit der gleichen Sequenze von 32776. Keine Ahnung, wie diese Sequenze-Nummer zu stande kommt und was das überhaupt soll. Nachfolgend der Wireshark-Screenshot dazu, der Trace ist in der Anlage (Platz ihn hier direkt zu posten hat nicht gereicht).
Noch eine Bemerkung zur CSeq: Das zieht sich bis zum BYE durch, auch dieses wird mit einer falschen CSeq an den Provider gegeben, hier müsste die CSeq 3 sein, der LANCOM nimmt aber die 2.
Und noch eine Bemerkung: Ich hatte dieses Problem außerhalb von T.38 schon mal gemeldet und das wurde auch gefixt, aber vermutlich läuft das T.38 im LANCOM noch mal wieder extra und da wurde es nicht gefixt. Oder aber, ich weiß es nicht, das Problem existiert auch außerhalb von T.38 wieder.

So, hier jetzt eines der vier defekten T.38-Pakete (evt. ja auch ein Folgefehler):

2017-11-30 13_08_11-Router-Trace-LAN-1.pcap.png

Vielen Dank und viele Grüße,
Jirka

Und hier der Trace:

[MoinMoin]

Hi Jirka!

Grundsätzlich zu den Sequenznummern: Die werden separat für beide Richtungen nummeriert, d.H. es gibt zwei Nummernkreise. Diese werden unabhängig voneinender hochgezählt. Ein Gerät zählt die lokale Sequenz um eins hoch, wenn es einen neuen Request sendet und beantwortet Requests von der anderen Seite mit der darin enthaltenen Sequenznummer (sofern diese höher ist, als beim zuletzt empfangenen Request).

Ciao, Georg

[MoinMoin]

Moin Jirka!

Und noch eine Anmerkung zu Wireshark und T.38: UDPTL-Paqkete haben keinen Header, an dem man sie von RTP unterscheiden könnte. Daher nimmt Wireshark an, daß UDPTL verwendet wird, wen ein entsprechendes SDP gesehen wurde. UDPTL-Pakete, die als fehlerhaft angemeckert werden, sind meist normale RTP-Pakete.

Ciao, Georg

[Jirka]

Moin Moin,

vielen Dank erst mal für die schnelle Reaktion. Das macht mir Mut, dass das Problem nicht erst in 3 Monaten gefixt wird. Weil ich habe den Laden innerhalb von zwei Wochen fast arbeitsunfähig gemacht nach der Umstellung von FRITZ!Box auf LANCOM.

Grundsätzlich zu den Sequenznummern: Die werden separat für beide Richtungen nummeriert, d.H. es gibt zwei Nummernkreise. Diese werden unabhängig voneinender hochgezählt.

Genau der Meinung bin ich eigentlich auch. Willst Du jetzt damit sagen, ich habe den Trace falsch interpretiert? (Aber Du hast den Trace ja noch gar nicht angeschaut?) Ein (Re-)INVITE ist doch aber ein neuer Request (oder nicht?!) und müsste demnach also eines höher zählen (die CSeq), macht der LANCOM aber nicht. Vielleicht solltest Du das mal mit awi besprechen, wie das funktioniert?

Und noch eine Anmerkung zu Wireshark und T.38: UDPTL-Paqkete haben keinen Header, an dem man sie von RTP unterscheiden könnte. Daher nimmt Wireshark an, daß UDPTL verwendet wird, wen ein entsprechendes SDP gesehen wurde. UDPTL-Pakete, die als fehlerhaft angemeckert werden, sind meist normale RTP-Pakete.

Ok, danke für den Hinweis. Sowas habe ich schon vermutet, weswegen ich auch schrieb, dass ich es für einen Folgefehler halte. Irgendwie konnte man Wireshark doch in solchen Fällen auch mitteilen, wie er solche Pakete zu interpretieren hat, aber ich habe es jetzt nicht auf Anhieb gefunden

P.S.: Danke auch noch mal für den Hinweis aus dem anderen Thread ("kann das LANCOM das T.38 terminieren und zur unwilligen Seite hin G.711 machen").

P.P.S.: Den Trace oben hast Du ja noch gar nicht angeschaut. Der ist verhältnismäßig übersichtlich. Ok, 3 Minuten brauch man jetzt schon, um den zu überfliegen, aber auch nicht mehr, weil Müll ist da nicht drin in dem Trace.

[MoinMoin]

Moin Jirka!

In der Tat. den Trace hatte ich mir noch nicht angesehen. Das waren nur generelle Anmerkungen zu möglichen Problemen in deiner Analyse.

Ich bin den Trace eben mit Stift und Zettel durchgegangen. Meiner Meinung nach sind die Sequenznummern korrekt.

Was mir aufgefallen ist: Die Fritz-Box kommt mit T.38 Version 1, das "Amt" kommt mit T.38 Version 0. Mag sein, daß das erste ReInvite wegen der T.38-Version abgelehnt wird. Kann man die Version in der Fritz-Box konfigurieren?

Ein anderer möglicher Grund: Die Fitz-Box meldet sowohl Redundancy als auf FEC als Fehlerkorrekturmechanismen:
a=T38FaxUdpEC:t38UDPRedundancy\r\n
a=T38FaxUdpEC:t38UDPFEC\r\n

Soweit ich weiß, darf T38FaxUdpEC nur einmal verwendet werden. Korrekt würde die Fritz-Box also nur FEC melden (was auch Redundancy als Fallback enthält). Das LANCOM filtert das nicht, sondern gibt es so weiter, wie es von der Box kommt.

Funktioniert die Fritz-Box denn "direkt" an der Leitung?

Was das erneute ReInvite angeht: Prinzipiell sollte das erlaubt sein. Ich bin mir aber ziemlich sicher, daß das LANCOM damit nicht korrekt umgehen würde. Aber man weiß ja nie. Gesehen habe ich sowas bisher nicht.

Das hier ist genau so ein Fall, bei dem man einen Schalter braucht, um die T.38-Transkodierung von SIP nach SIP unterbinden zu können. Da du FAX nur über die Fritz-Box betreibst, solltest du das T.38 im LANCOM abschalten.

Ciao, Georg

[Hans]

Hallo Jirka,

wenn ich es richtig verstehe, soll die Fritzbox einfach nur die Faxe annehmen.
Das Problem hatte ich vor kurzem auch. FB 7490 per SIP am 1783VAW (10.12), Telekom All-IP
Hatte keine Zeit zum Tracen und wollte nur die Funktion herstellen.

Wir haben in der Fritzbox > Eigene Rufnummern > Anschlußeinstellungen: "Faxübertragung auch mit T.38" deaktiviert

Läuft seitdem ohne Probleme.
Das ist eine Apotheke. Habe für heute 31 eingehende Faxe gezählt.

Gruß Hans

[Jirka]

Moin Moin,

Ich bin den Trace eben mit Stift und Zettel durchgegangen. Meiner Meinung nach sind die Sequenznummern korrekt.

hmm, ich bin da wie gesagt anderer Meinung! Aber solltest Du Recht haben, will ich auch verstehen, warum. Deswegen habe ich, weil Dein Zettel hier nicht abfotografiert drin war, auch einen digitalen Zettel erstellt (siehe auch Anlage):

2017-12-01 02_44_08-T.38-Problem-Call-Flow.xlsx - Excel.png

Daran können wir das jetzt ausdiskutieren. Vergleichst Du das bitte mit Deinem Zettel, bzw. schaust es Dir an?

Was mir aufgefallen ist: Die Fritz-Box kommt mit T.38 Version 1, das "Amt" kommt mit T.38 Version 0. Mag sein, daß das erste ReInvite wegen der T.38-Version abgelehnt wird. Kann man die Version in der Fritz-Box konfigurieren?

Gegenfrage : Kann man die Version im LANCOM konfigurieren? Ok, also in der FRITZ!Box auch nicht, jedenfalls nicht auf der offiziellen Oberfläche.

Funktioniert die Fritz-Box denn "direkt" an der Leitung?

Ja.
Funktioniert die FRITZ!Box hinterm LANCOM (SIP-ALG aus), wenn sie sich direkt beim Provider registriert?
Ebenfalls ja. Ohne Beanstandungen.

Was das erneute ReInvite angeht: Prinzipiell sollte das erlaubt sein. Ich bin mir aber ziemlich sicher, daß das LANCOM damit nicht korrekt umgehen würde.

Das denke ich eben auch. Darüber hat nie jemand nachgedacht.

Das hier ist genau so ein Fall, bei dem man einen Schalter braucht, um die T.38-Transkodierung von SIP nach SIP unterbinden zu können.

Ich bin der Meinung hier liegt die grundsätzliche Fehlerursache aber woanders, z. B. in der CSeq, die der LANCOM einfach falsch vergibt.
Normalerweise sollten solche Situationen ja eigentlich gar nicht entstehen.

Da du FAX nur über die Fritz-Box betreibst, solltest du das T.38 im LANCOM abschalten.

Ich denke darüber nach. Ich tue mich damit aber etwas schwer.
Das würde in dem Fall dann nämlich dazu führen, dass das LANCOM in Excel-Zeile 20 ("try T.38 to G.711 transcoding") der FRITZ!Box mit "488 Not Acceptable Here" antworten würde, und T.38 wäre ganz gestorben! Das will ich aber nicht. Ich bin ein Freund von T.38 und habe damit, wenn es denn funktioniert, sehr gute Erfahrungen.

Vielen Dank und viele Grüße,
Jirka

Hallo Hans,

wenn ich es richtig verstehe, soll die Fritzbox einfach nur die Faxe annehmen.
Das Problem hatte ich vor kurzem auch. FB 7490 per SIP am 1783VAW (10.12), Telekom All-IP
Hatte keine Zeit zum Tracen und wollte nur die Funktion herstellen.

aha, vielen Dank für die Info. Ja, die Zeit habe ich auch nicht, denn an dem Problem habe ich jetzt mal eben über 10 Stunden verbraten.

Wir haben in der Fritzbox > Eigene Rufnummern > Anschlußeinstellungen: "Faxübertragung auch mit T.38" deaktiviert

Ja, das geht hier auch, dann aber eben nur mit G.711.

Verstehe mich nicht falsch, aber ich kaufe mir ja auch kein Auto, um damit im verkehrsberuhigten Bereich zu fahren, da kann ich auch mit dem Fahrrad fahren. Wenn ich dem Kunden einen LANCOM hinstelle, dann soll gefälligst auch T.38 funktionieren, sonst hätte ich die FRITZ!Box besser stehen gelassen und nichts angerührt.

Ich bin also nicht alleine betroffen, was mir ja manchmal so vorkommt, das beruhigt ja schon mal. Und wenn wir das Problem hier gefixt kriegen, dann kannst Du da ab der nächsten Release-Version auch von profitieren, bzw. die Apotheke.

Vielen Dank und viele Grüße,
Jirka

hier noch der Call-Flow als editierbare Excel-Datei:

[Hans]

Hallo Jirka,

ich bin grundsätzlich völlig deiner Meinung, wenn T.38 drin ist sollte es auch korrekt funktionieren.
Hut ab, vor dem Aufwand den du gerade reinsteckst. Ich weiß das sehr wohl zu würdigen.
Vor allem war ich mir nicht sicher, ob du einen befriedigenden Workaround hast, um nicht gelyncht zu werden.
Mein Elan in T.38 ist allerdings extrem gebremst.
Mein letzter Stand ist, dass die Telekom kein T.38 unterstützt und auch nicht vorhat etwas daran zu ändern.
Alle in der Kette müssen T.38 unterstützen, sonst funktioniert es nicht.
Unsere Kunden sind zu 98% bei der Telekom.
Habe ich einen Denkfehler in dem Ansatz, oder etwas verpasst?

Gruß Hans

[Jirka]

Hallo Hans,

Mein letzter Stand ist, dass die Telekom kein T.38 unterstützt und auch nicht vorhat etwas daran zu ändern.

das stimmt. Soweit ich weiß, war T.38 für Geschäftskunden im Gespräch, mehr kann ich aber dazu auch nicht sagen. Dazu müssten sich die Telekomiker in diesem Forum äußern.

Alle in der Kette müssen T.38 unterstützen, sonst funktioniert es nicht.

Korrekt, sonst kommt es nicht zur Verwendung von T.38. Wobei die Kette ja im Normalfall mit Absender und Empfänger recht kurz ist.

Ist die All-IP-Umstellung vollzogen, dann braucht die Telekom eigentlich auch kein T.38 mehr zu unterstützen. Dann können es Absender und Empfänger selber untereinander aushandeln.
Aber auch jetzt schon sind es erstaunlich viele Faxe die per T.38 reinkommen, auch an einem Telekom-Anschluss. Da kann der IP-Zusammenschluss der Telefonnetze endlich seine Vorteile ausspielen. Ein Fax von 1&1 wird nicht mehr über das herkömmliche Telefonnetz als G.711 an die Telekom übergeben, sondern kommt eben direkt mit T.38 rein. Das gleiche gilt für Vodafone-Kabel-Deutschland (unterstützt prinzipiell auch kein T.38) oder andere Provider.

Unsere Kunden sind zu 98% bei der Telekom.

Innerhalb der Telekom sind Faxe mit G.711 auch schon ungewöhnlich zuverlässig. Da zeigt sich, dass die Telekom sich bemüht QoS auch wirklich zu gewährleisten. Wenn es da hakt, hakt es oft in den Endgeräten, die, weil z. B. anderweitig ausgelastet, hohe Latenzen reinbringen. Aber beim LANCOM vertraue ich eigentlich darauf, dass das ordentlich funktioniert, weil QoS da immer schon ein Thema war und das ja mittlerweile aus den Kinderkrankheiten raus ist.

Viele Grüße,
Jirka

[Koppelfeld]

Hallo zusammen,

Mein letzter Stand ist, dass die Telekom kein T.38 unterstützt und auch nicht vorhat etwas daran zu ändern.

das stimmt. Soweit ich weiß, war T.38 für Geschäftskunden im Gespräch, mehr kann ich aber dazu auch nicht sagen. Dazu müssten sich die Telekomiker in diesem Forum äußern.[\qoute]

T.38 ist nicht nur BAD (broken as designed), es läuft seit Jahren, wenn überhaupt, extrem unzuverlässig.

Vorausgesetzt, der 'Line echo canceller' ist richtig eingestellt und der Dejitterbuffer im ATA ist nicht allzu groß, gibt es seit 5 Jahren keinen Ärger mehr mit Analogfaxen.

Es sei denn, man will es "besonders schön" machen, aber das orientiert sich dann doch an einer Heilpraxis, welche gegen Beulenpest "Clerasil" verschreibt: "Guckt 'mal, die Pickel sind jetzt weg...).


Gruß Ha "alles was Hans heißt, taugt nix" ns

[Jirka]

Hallo Koppelfeld,

T.38 ist nicht nur BAD (broken as designed), es läuft seit Jahren, wenn überhaupt, extrem unzuverlässig.

nein Koppelfeld, da hast Du keine Ahnung. T.38 selber ist nicht unzuverlässig oder "BAD". Was nichts taugt ist die schlechte Implementierung in vielen Geräten.

Da wäre einerseits das Problem, dass die Aushandlung von T.38 fehlschlägt, weil irgendwas nicht stimmt - den Fall sehen wir aktuell hier gerade. Es ist unglaublich, wie das immer und immer wieder zu einem Problem wird. Ich hatte schon vor 9 Jahren ähnliche Probleme. Man muss hier sagen, dass T.38 aber auch der Sündenbock ist, der da herhalten muss. Ich habe die gleichen Probleme auch ohne T.38 bei einem Re-INVITE. Insgeheim hoffe ich, dass das Ding dann vielleicht auch gleich mit gefixt ist, sonst muss ich mir das auch noch mal anschauen. Es ist also eher SIP ein Problem und fehlerhafte Implementierungen von SIP, als T.38.

Und andererseits ist da das Problem, dass es fehlerhafte Implementationen von T.38 gab und gibt, die es einfach nicht ordentlich machen. Da wäre z. B. Intel, die den Chip in der alten VoIP-Reihe (1722/1723/1724/1823) hergestellt haben und da T.38 saumäßig implementiert hatten. Wer also tatsächlich versucht hat, T.38 bei einem an dem LANCOM angeschlossenen Faxgerät (also über ISDN oder analog, NICHT SIP) zu verwenden, der hat das nie zuverlässig zum Laufen bekommen. Das lag aber daran, dass da Bugs in der Implementierung nie beseitigt wurden. Der Chip war längst nicht mehr von Intel supportet, wo LANCOM ihn noch verbaut hat und ihn sich sogar auf Lager gelegt hat, denn ein Nachfolger der VoIP-Reihe war ja idiotischerweise vom Management nicht gewollt. Erst als der größte Kunde gesagt hat, na gut, dann kaufe ich keine LANCOMs mehr, kam LANCOM auf die Idee, ja dann müssen wir wohl doch was machen, wenn wir noch ein paar Geräte verkaufen wollen.

Ich habe hier seit vermutlich 8 Jahren ein Hardware-T.38-Fax von Sagem, das Ding kann zwar bedauerlicherweise kein NTP, aber telefon-fax-technisch ist das top, weil das haben noch Leute entwickelt, die wussten, was man beachten muss, wenn man die Telefonie plötzlich auf VoIP umstellt. Da kannst Du mit T.38 40 Seiten ohne Probleme faxen. Und auch schon vor Jahren und mit nicht funktionierendem QoS - wenn denn die Gegenseite nicht von oben aufgeführten Problemen betroffen ist.

Vorausgesetzt, der 'Line echo canceller' ist richtig eingestellt und der Dejitterbuffer im ATA ist nicht allzu groß, gibt es seit 5 Jahren keinen Ärger mehr mit Analogfaxen.

Das habe ich, zwar nicht so detailliert, ja auch geschrieben, dass das besser geworden ist und innerhalb der Telekom schon als gut bezeichnet werden kann. Aber ich habe auch einen Kunden, da gehen jeden (Werk-)Tag 350 Faxe raus. Da weißt Du dann, dass gut eben noch nicht gut genug ist!

Viele Grüße,
Jirka

[MoinMoin]

Moin Jirka!

Nur kurz zu den Sequenznummern. Wie gesagt, die Sequenznummern in Senderichtung und Empfangsrichtung werden getrennt gezählt, Für die Senderichtung ist das jeweilige Gerät verantwortlich, für die Empfangsrichtung die Gegenseite. Das LANCOM schickt den ersten Request immer mit der Sequenznummer 1.

Zeile 4: Das LANCOM schickt den ersten Request zur Fritz-Box => Sequenznummer 1
Zeile 26: Das LANCOM schickt den 2. Request zur Fritz-Box => Sequenznummer 2
Zeile 18: Das LANCOM schickt den ersten Request zum Amt => Sequenznummer 1
Zeile 32: Das LANCOM schickt den 2. Request zum Amt => Sequenznummer 2

Ich bin mir nicht sicher, aber ich glaube, es reicht, wenn die Sequenznummer streng monoton steigend ist. Daher wäre es auch korrekt, wenn die für einen Request verwendete Sequenznummer höher als die höchste bisher Verwendete ist (egal, ob in Sende oder Empfangsrichtung).

Ciao, Georg

[MoinMoin]

Moin Jirka!

Was mir aufgefallen ist: Die Fritz-Box kommt mit T.38 Version 1, das "Amt" kommt mit T.38 Version 0. Mag sein, daß das erste ReInvite wegen der T.38-Version abgelehnt wird. Kann man die Version in der Fritz-Box konfigurieren?

Gegenfrage : Kann man die Version im LANCOM konfigurieren? Ok, also in der FRITZ!Box auch nicht, jedenfalls nicht auf der offiziellen Oberfläche.

Das LANCOM kann nur Version 0. Da hilft auch eine Konfigurationsmöglichkeit nicht weiter.

Funktioniert die Fritz-Box denn "direkt" an der Leitung?

Ja.
Funktioniert die FRITZ!Box hinterm LANCOM (SIP-ALG aus), wenn sie sich direkt beim Provider registriert?
Ebenfalls ja. Ohne Beanstandungen.

Hast du davon auch einen Trace? Wäre interessant, wie das Amt da auf das ReInvite der Fritz-Box reagiert.

Was das erneute ReInvite angeht: Prinzipiell sollte das erlaubt sein. Ich bin mir aber ziemlich sicher, daß das LANCOM damit nicht korrekt umgehen würde.

Das denke ich eben auch. Darüber hat nie jemand nachgedacht.

Ich habe so ein Verhalten nicht erwartet. Schließlich kann man ja in der Antwort ein SDP angeben, daß einem genehm ist. Man muß nicht erst ablehnen und dann selber neu Einladen.

Das Verhalten im Trace nach dem ReInvite vom Amt ist schon soweit korrekt. Ich bin mir nur nicht sicher, ob das LANCOM sich nach dem OK von der Fritz-Box korrekt aus dem Datenstrom rausnimmt oder ob da der Transcoder weiter zwischengeschaltet bleibt.

Ich denke darüber nach. Ich tue mich damit aber etwas schwer.
Das würde in dem Fall dann nämlich dazu führen, dass das LANCOM in Excel-Zeile 20 ("try T.38 to G.711 transcoding") der FRITZ!Box mit "488 Not Acceptable Here" antworten würde, und T.38 wäre ganz gestorben! Das will ich aber nicht. Ich bin ein Freund von T.38 und habe damit, wenn es denn funktioniert, sehr gute Erfahrungen.

Nein, dann würde die Verbindung erst mal auf G.711 bleiben, bis das ReInvite vom Amt kommt. Wie oben schon geschrieben, hast du schonmal beobachtet, was im SIP passiert, wenn die Fritz-Box direkt mit dem Amt redet?

Ciao, Georg

[Jirka]

Hallo Georg,

erst mal vielen Dank fürs Nachvollziehen und Durcharbeiten...

Wie gesagt, die Sequenznummern in Senderichtung und Empfangsrichtung werden getrennt gezählt

Auch wenn ich da definitiv anderer Meinung bin, verstehe ich jetzt immerhin Deine Zählweise!
Gibt es hier Experten, die das so bestätigen können?
Ich kann da nur sagen, dass ich so aus dem Bauchgefühl behaupten würde, dass alle Geräte, die ich kenne, das nicht so machen. Bei der FRITZ!Box habe ich mir das ja nun zwangsläufig auch angeschaut, was die anders macht als der LANCOM-Router. Und die zählt den Zähler der Gegenseite weiter, das siehst Du ja schon, dass sie das (Re-)INVITE in Zeile 12 mit der CSeq 2 angibt!

Man müsste da jetzt genau in der RFC nachlesen, aber ich kann das aus Zeitgründen frühestens morgen. Weil da reichen ja 10 Min. leider nicht.

Vielen Dank und viele Grüße,
Jirka

[MoinMoin]

Moin Jirka!

Die Fritz-Box übernimmt jeweils die Sequenznummer aus dem empfangenen Request in ihren eigenen Zähler, wenn die höher ist, als der eigene Zählerstand. Ich denke, das Verhalten ist korrekt, aber nicht zwingend notwendig.

Ciao, Georg