Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

[Dr.Einstein]

Die Doku geht davon aus, dass du Port 0 statt 5060/5061 einträgst.

[Uller]

Die Doku geht davon aus, dass du Port 0 statt 5060/5061 einträgst.

Stimmt, bei nochmaligem Lesen steht es da...

Was ist denn sinnvoller, 0 oder 5061 und sollte die Verschlüsselung bei "Bevorzugt" bleiben oder besser erzwungen werden? Priorität wäre, dass telefoniert werden kann.

[Dr.Einstein]

Priorität wäre, dass telefoniert werden kann.

Das ist nicht vorgesehen

Lancom hat mehrfach gesagt, 0 wäre eigentlich das bessere, weil dann das LCOS selbst entscheidet, was es tut. D.h. wenn du fest auf UDP stellst, macht er das richtige, oder du wechselst fest auf TLS, macht er auch das richtige, oder auf automatisch, macht er auch das richtige. Die 5060 waren früher vor 10 Jahren mal der Default im LCOS.

Verschlüsselung würde ich auf "Bevorzugt" setzen für die Erreichbarkeit. Wenn's dir um Maximale Sicherheit geht, müsste da erzwungen stehen.

[Uller]

Lancom hat mehrfach gesagt, 0 wäre eigentlich das bessere, weil dann das LCOS selbst entscheidet, was es tut. D.h. wenn du fest auf UDP stellst, macht er das richtige, oder du wechselst fest auf TLS, macht er auch das richtige, oder auf automatisch, macht er auch das richtige. Die 5060 waren früher vor 10 Jahren mal der Default im LCOS.

Verschlüsselung würde ich auf "Bevorzugt" setzen für die Erreichbarkeit. Wenn's dir um Maximale Sicherheit geht, müsste da erzwungen stehen.

Danke Dir noch mal!

Ich habe den Port jetzt auch noch auf 0 umgestellt und werde es damit weiter beobachten. Ich werde dann hier in einigen Tagen noch einmal Feedback geben!

[awi]

Hallo zusammen,

es gibt mittlerweile einen entsprechenden Bugeintrag.
Der Support hat das Problem nachstellen können und ein Ticket erstellt.
Wenn es sich um das gleiche Problem handelt, dann liegt es daran, dass von der Telekom
die 407 Response auf das erste INVITE wiederholt wird obwohl das ACK und das zweite INVITE bereits
gesendet wurde. Diese zweite 407 Response verursacht das Problem, weshalb der VCM dann das Session Progress nicht beantwortet.
Im übrigen kommt dieses 407 immer wieder. Da läuft offensichtlich bei der Telekom auch etwas schief.

Auf jeden Fall ist ein Fix dafür in Arbeit.

Was die Sache mit dem TLS angeht. Eigentlich sollte wenn die Leitung auf 'Auto' steht, zunächst versucht werden eine TLS Verbindung aufzubauen. Dabei sollte auch der Port über SRV erhalten werden. Das sollte eigentlich funktionieren ohne dass der Port extra auf 5061 eingestellt werden muss.
Wenn das nicht so ist, dann müssen wir uns das mal anschauen.
Wenn die TLS Verbindung nicht klappt, dann wird TCP versucht und dann UDP.


Gruß Awi

[Dr.Einstein]

Im übrigen kommt dieses 407 immer wieder. Da läuft offensichtlich bei der Telekom auch etwas schief.

Sieht nach einem Fehler im Lancom aus, Fritzbox macht das nicht. Bei einer Fritzbox sieht der zweite INVITE identisch aus bis auf CSeq + 4 Proxy-Authorization Felder.
Der Lancom dagegen schickt beim ersten INVITE ein Authorization (kein Proxy-Authorization) und ein Date. Beim zweiten INVITE wird ein Proxy-Authorization draus, und die Reihenfolge im SIP-Bereich ist komplett umgewürfelt.

Als VoIP-Laie bin ich der Meinung, die RFC erlaubt keine großartige Veränderung des zweiten INVITES, so es sich denn als Korrektur des 1.INVITES angerechnet werden soll. Die Telekom wartet weiterhin auf die Antwort vom ersten INVITE, und wiederholt die Anfrage mit größeren Abständen. Das zweite INVITE wird als eigenständiger Call wahrgenommen ohne Bezug zum ersten INVITE.

[Uller]

Was die Sache mit dem TLS angeht. Eigentlich sollte wenn die Leitung auf 'Auto' steht, zunächst versucht werden eine TLS Verbindung aufzubauen. Dabei sollte auch der Port über SRV erhalten werden. Das sollte eigentlich funktionieren ohne dass der Port extra auf 5061 eingestellt werden muss.
Wenn das nicht so ist, dann müssen wir uns das mal anschauen.
Wenn die TLS Verbindung nicht klappt, dann wird TCP versucht und dann UDP.

Danke Euch beiden für die Erläuterung, ich merke mal wieder, was ich alles nicht über VoIP weiß…

Die Sache mit dem Port probiere ich gerne noch mal aus, nur um sicher zu sein. Wie schon geschrieben hat es bei „Auto“ aber erst geklappt als ich auch den Port auf 0 umgestellt hatte.

[MoinMoin]

Moin Dr.Einstein,

Als VoIP-Laie bin ich der Meinung, die RFC erlaubt keine großartige Veränderung des zweiten INVITES, so es sich denn als Korrektur des 1.INVITES angerechnet werden soll.

Das 407 fordert genau diese Änderung ein. Ohne den Schwenk auf Proxy-Authentikation würde das nächste Invite genauso mit einer 407 abgelehnt.

Der Dialog des ersten Invite ist mit dem Ack beendet, eine Wiederholung des 407 dazu dürfte es daher nicht geben. Allerdings fehlt im Ack das To-Tag, weshalb das nicht dem Invite zugeordnet wird. In der Tat ein Fehler des VCM.

Ciao, Georg

[Dr.Einstein]

Der Dialog des ersten Invite ist mit dem Ack beendet, eine Wiederholung des 407 dazu dürfte es daher nicht geben. Allerdings fehlt im Ack das To-Tag, weshalb das nicht dem Invite zugeordnet wird. In der Tat ein Fehler des VCM.

Ciao, Georg

Danke für die Klarstellung, wieder was gelernt.

[Uller]

Was die Sache mit dem TLS angeht. Eigentlich sollte wenn die Leitung auf 'Auto' steht, zunächst versucht werden eine TLS Verbindung aufzubauen. Dabei sollte auch der Port über SRV erhalten werden. Das sollte eigentlich funktionieren ohne dass der Port extra auf 5061 eingestellt werden muss.
Wenn das nicht so ist, dann müssen wir uns das mal anschauen.
Wenn die TLS Verbindung nicht klappt, dann wird TCP versucht und dann UDP.

Habe das gerade noch einmal getestet. Mit "Auto" und Port 0 gibt es eine TLS Verbindung, mit "Auto" und Port 5061 auch. Mit "Auto" und Port 5060 gibt es gar keine Verbindung, auch keinen Rückfall auf UDP.

[Uller]

Abschließend noch eine kurze Rückmeldung. Mit der geänderten Konfiguration hatte ich jetzt keine Probleme mehr mit dem Rufaufbau, funktioniert alles wie es soll!