Fritzbox als SIP-Client an Swyx-Tel-Anlage --- Probleme

Bib · 11 Jul 2016

Hallo,
ich habe seit geraumer Zeit (ca. seit dem Update auf 6.50) Probleme mit meiner Fritzbox 7490 in Verbindung mit der Swyx-Software Telefonanlage bei mir in der Firma (läuft auf Windows Server 2008 R2). Die Swyx wurde ungefähr zur selben Zeit geupdatet, daher kann ich nicht sagen, an welcher Seite es liegt. Die 7490 läuft seit einigen Tagen mit der 6.60.

Vielleicht könnte mir hier jemand weiterhelfen, der sich ein wenig mit der Materie auskennet? Ich kann Logs der Fritzbox und Logs der Swyx liefern, ihr müsst mir nur sagen, was ihr benötigt.

Vorher ging alles, an der Konfiguration wurde nichts geändert. Also die Fritzbox ist als Nebenstelle der Swyx eingerichtet, ich konnte von zuhause aus mit meiner Büro-Nummer telefonieren und die Fritzbox war durch meien interne Nebenstelle in der Arbeit auch erreichbar.

Aktuell wird zwar eine Verbindung aufgebaut, wenn ich von Zuhause über die Büronummer nach extern rufen möchte, aber dann herrscht Stille. Ich kann nichts hören, mein Gegenüber genausowenig. Wenn ich jedoch intern egal ob von zuhause in die Arbeit oder umgekehrt rufe, passt alles.

Ich habe ein VPN zu mir in die Firma.

Wie gesagt, es muss mit einem Update einer der zwei beteiligten Tel-Anlagen zusammenhängen.
Hab auch auf beiden Seiten alles schon mal komplett gelöscht und neu eingerichtet, selbes Ergebnis.

Wo könnte ich denn mit der Fehlersuche beginnen? An was könnte es liegen? Firewall/VPN? Codecs?

Der (kostenpflichtige) Support der Swyx konnte mir leider bisher auch noch nicht weiterhelfen. Der Mitarbeiter konnte mir nur berichten, dass er es bei sich zuhause genauso mit der neuesten Swyx-Version und einer Fritzbox 7490 aktuell am laufen hat und alles funktioniert, wie vor den Updates auch. Ich habe seine privtaten Konfigurations-Einstellungen auch schon erfolglos in meiner Fritzbox ausporbiert.

Grundsätzlich habe ich ja nur die Rufnummer 79, das auch zeitgleich mein Benutzername und auch mein Passwort ist sowie die IP des Swyx-Servers, welchen ich über das VPN erreichen kann. So lief es eigentlich auch immer völlig problemlos, ich musste keinen Proxy, STUN oder sonstwas eintragen.

jodost · 11 Jul 2016

1. Vermutung in so einem Fall ist immer, dass das MediaStreaming zwischen Swyx und FBF nicht so geroutet wirdl. NAT dazwischen? Hat der Swyx-Server mehrere IP-Adressen? Wenn ja, sind die einzelnen Swyx-Dienste per RegistryKeys sauber auf die jeweiligen IPs konfiguriert?

2. Vermutung ist die RTP-Verschlüsselung des Users und/oder der Trunks (wenn es SIP-Trunks sind). Die würde ich zum Einkreisen des Fehlers mal jeweils deaktiviere.

Was genau meinst Du mit "kostenpflichtiger Support der Swyx"? Normalerweise läuft der Support Swyx<->Distri<->Partner<->Endkunde oder Swyx<->Partner<->Endkunde, aber dass Swyx direkt Endkunden supportet ist eher die Ausnahme. Wenn Dein Swyx-Partner Dir nicht helfen kann, ist der ja grds. auswechselbar

Bib · 11 Jul 2016

Ich meinte unseren Verkäufer der Swyx, der hat das alles eingerichtet und übernimmt auch den Support.

Ich habe an der Konfiguration ja nichts geändert, bis vor kurzem lief es alles genau so.

1.)
Meine Fritzbox bekommt Internet über LAN von einer anderen Fritzbox mit direktem Internetanschluss - also als IP-Client. Das VPN baut aber meine Fritzbox selber auf, also der Tunnel steht zwischen meiner eigenen Fritzbox und dem Server in der Firma. Der Swyx-Server in der Firma hat nur eine einzige interne IP-Adresse und die Firma hat nach aussen hin nur eine einzige externe (täglich wechselnde) IP-Adresse, das VPN wird über dyndns untereinander gefunden.
Ich kann intern ja von und zur arbeit telefonieren, nur sobal es ins externe Telefonnetz geht, ist schluss.

Liegt dann ein NAT-Problem vor, wenn ich einen direkten Tunnel zu mir in die Firma habe? Ich komme auf sämtliche Server remote drauf. VPN wird von meiner Fritzbox zu einem Linux-Server (Firewall) aufgebaut.

2.)
Es sind ganz normale T-Com ISDN-Anschlüsse, wir haben in der Firma 3 Trunks davon, also 6 Leitungen. Alles die selbe Nummer. Keine SIP-Trunks.

Ich schaue mal, ob ich was zu RTP-Verschlüsselung finden kann.

EDIT: Verschlüsselung scheint im Server deaktiviert zu sein, als Benutzer kann ich das nicht ändern, wird global vorgegeben. Aber auf dem Server ist es nicht aktiviert.

jodost · 11 Jul 2016

Thema NAT: Wie ist denn der Netzwerkaufbau?
Welche IP-Adresse / Netzmaske / Gateway hat die Swyx und das übrige Büronetz
Welche IP-Adresse / Netzmaske / Gateway hat Deine FBF in dem Tunnel drin? Kannst Du beide Richtungen pingen (also auch vom SwyxServer aus die VPN-IP Deiner FBF)?

Bib · 11 Jul 2016

Also bei mir zuhause:
Fritzbox der Eltern mit VDSL-Anschluss ----- meine Fritzbox als IP-Client mit eigenem IP-Bereich (Internet über LAN1)
Fritzbox Eltern 192.168.2.1 / 255.255.255.0
Meine Fritzbox 192.168.102.1 / 255.255.255.0 - diese Box baut das VPN auf, nicht die der Eltern

Firma:
Linux-Firewall - welche auch die Interneteinwahl macht und die VPN-Dienste darauf laufen
direkt über LAN an einem reinen VDSL-Modem (kein Router!)
--- dahinter 8 Server (teils "richtige", teils virtuell)
IP Swyx-Server:
192.168.50.10 / 255.255.255.0
Firewall hat die 192.168.50.254 - Standardgateway in der Firma ist überall 192.168.50.254
alles über DHCP zugewiesen

Ich kann von zuhause auf die Swyx pingen und von der Swyx zu mir nach hause - auch Remote komme ich in beide Richtungen auf die angeschlossenen Computer/Server.

PeterPawn · 11 Jul 2016

Ein Routing-/VPN-Problem ist es nicht, das wissen wir aus dem anderen Thread - die SIP-Messages kommen ja an.

Ein RTP-Problem mit einem externen SIP-Teilnehmer kann es auch nicht geben, solange die Anlage nur mit 3 ISDN-(BRI-)Trunks ans öffentliche Netz angeschlossen ist.

Ich würde erst einmal versuchen zu klären, was bei der Anmeldung schief geht, wenn die Anlage keinen "Contact"-Header mag. Dazu gibt es auf der einen Seite ja die FRITZ!Box-SIP-Messages und - soweit ich das noch kenne - bei der Swyx-Software gab es ein extra Tool, um die ganzen Interna (nach Komponenten getrennt) zu tracen.

Da würde ich mal nachsehen (als ich das noch in den Händen hatte, wurde da tatsächlich noch alles intern von SIP auf H.323 umgesetzt) und versuchen, der Ursache für den Registrierungsfehler nachzugehen.

Wenn ich raten müßte, würde ich vermuten, daß irgendwann mit einem Update eine Verbesserung der Gültigkeitsprüfung für einen SIP-Client dazu kam und jetzt die Anlage darüber stolpert, wenn ein SIP-Client, der nicht in demselben lokalen Netz wie die Anlage ist (das steht ja im "Contact"-Header), jetzt Telefonate mit "Amtsberechtigung" führen soll - wobei es auch sein kann, daß der fehlende bzw. abgelehnte "Contact"-Header jetzt genau dazu führt, daß der Media-Connector der IpPbx die RTP-Daten irgendwo anders hinschicken will.

Stand aber nach meiner Erinnerung alles haarklein in den Trace-Logs ... zumindest die Screenshots sämtlicher Tabs bei den Eigenschaften des SIP-Clients bräuchte man schon, wenn man anhand von Dialogfeldern raten will, welche Einstellung da nun wofür sein mag.

Ich würde aber eher hingehen und die Changelogs der Updates bei der Swyx-Software dahingehend überprüfen, ob da irgendwelche zusätzlichen Filter hinzugekommen sind, deren Standardwerte jetzt die Verwendung eines externen SIP-Client (extern zum LAN der IpPbx) einschränken und diesem ggf. die Benutzung der Trunks zum öffentlichen Netz hin verwehren ... wenn die interne Telefonie funktioniert, wobei da eben auch ein SIP-Client an der Swyx-Anlage mit der FRITZ!Box die RTP-Daten direkt austauschen würde und könnte - bei externem Anruf ist der Media-Connector der Swyx-Anlage der Peer.

jodost · 11 Jul 2016

PeterPawn schrieb:
Ein Routing-/VPN-Problem ist es nicht, das wissen wir aus dem anderen Thread - die SIP-Messages kommen ja an.

ich kenne den angesprochenen anderen Thread nicht, die pauschale Aussage "SIP geht, also kann RTP nicht an IP-Themen liegen" würde ich in Bezug auf die Swyx aber auf keinen Fall unterschreiben. Aber egal. Für die genaue Fehlersuche müsste man wohl aber wirklich mal am besten auf den Server draufgucken oder Traces lesen ... die sind zwar arg groß und nicht gerade übersichtlich, aber dafür steht in der Tat alles und jedes drin.

Ein kompetenter Swyx-Partner sollte das hinbekommen. Ansonsten ist der ja austauschbar...

PeterPawn · 11 Jul 2016

@jodost:
Das mit RTP war auch nur so gemeint, daß die üblicherweise anzutreffenden Probleme, wenn ein RTP-Partner im Internet zu finden ist und der andere in einem (nicht-lokalen) anderen Netz (hier ein VPN zur FRITZ!Box) und die wollen jetzt direkt miteinander verbunden werden, weil die INVITE-Messages entsprechende Einträge enthalten, hier nicht existieren können.

Da die Anlage ans ÖN nur über die erwähnten BRI-Trunks angebunden ist, muß die Anlage einer der Endpunkte einer RTP-Verbindung sein.

Daß das bei internen Telefonen wieder anders aussehen kann (weil die ggf. nach der Initiierung der Session über SIP direkt miteinander kommunizieren könnten) und die Anlage dann eben genau kein Endpoint ist, hatte ich versucht zu schreiben.

Meine Aussage ging also nur in die Richtung, daß "die üblichen Probleme" mit externen SIP-Peers hier nicht auftreten dürften.

Beim RTP-Streaming von der Swyx zur FRITZ!Box kann durchaus der Wurm drin sein ... würde ich persönlich trotzdem hinten anstellen, bis das "Contact-Header"-Problem gelöst ist, weil eben auch das theoretisch schon die Ursache sein könnte.

Immerhin leitet daraus die Swyx-Anlage ja ab, wo und wie der Peer zu erreichen ist ... soweit ich das kenne sowohl für SIP (also Control-Messages, die aber offenbar ankommen, denn die Sessions werden ja wohl aufgebaut) als auch für RTP und während bei SIP noch alle denkbaren "Via"-Header auch ohne "Contact"-Info dafür sorgen könnten, daß Pakete ihr Ziel noch finden (die brauchen dazu ggf. nur auf der Linux-Firewall per NAT umgesetzt werden, der VPN-Peer ist ja eine (unbekannte) Firewall), weil da vielleicht eine Sitzung mit "connection tracking" in der Firewall/dem Access-Server existiert, so schnell kann das bei RTP dann in die Hose gehen.

Aber da macht Raten m.E. wenig Sinn, die Arbeit mit den Trace-Logs muß man sich machen, wenn man das einkreisen will. Steht dort der SIP-Client der FRITZ!Box mit einer Adresse aus dem LAN (der IpPbx) drin, ist die Frage "NAT oder nicht" schon beantwortet und zwar ohne "ich glaube" als Zusatz und dann kann auch die RTP-Session in der Regel nichts werden, wenn man dafür nicht die Firewall (bzw. den Access-Server) durchlöchert auf den richtigen Ports und DNAT betreibt.

Bib · 12 Jul 2016

Ich hab in den Logs mal was dazu gefunden, hier gehts aber nur um die Anmeldung, trotzdem schaut es ein wenig komisch aus:

Vielleicht hilfts ja etwas weiter? Ist von heute nacht.

Code:

12 00:43:19.131 001b44 Info SwSIPReg   07F00100 00000000 SwSIPBinding::EnterStateRegistered      (0) Starting registration expiry timer for 120 seconds.
12 00:43:21.832 000dac Info SwSIPReg   079F8F40 00000000 SwSIPReceiver::HandleSipRequest         () RECV SIP REGISTER
12 00:43:21.832 000dac Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::FwrdReqToBinding        () Received SIP Register without Contact header (or Contact header is empty) -> do not register and send 200 OK
12 00:43:21.832 000dac Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::GetBindingByAOR         () Found binding with AOR '[email protected]' and IP address 192.168.102.1 port 5060 in list of bindings.
12 00:43:21.832 000dac Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::GetAllContacts          (U:37, T:0)
12 00:43:21.832 000dac Info SwSIPReg   079F4018 00000000 SwSIPReg::GetAllBindingsByUserOrTrunkId () Found 1 binding(s) with internal user ID 37
12 00:43:21.832 000dac Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::Send200Ok               () SEND SIP 200 OK
12 00:43:21.883 000dac Info SwSIPReg   079F8F40 00000000 SwSIPReceiver::HandleSipRequest         () RECV SIP REGISTER
12 00:43:21.884 000dac Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::GetBindingByAOR         () Found binding with AOR '[email protected]' and IP address 192.168.102.1 port 5060 in list of bindings.
12 00:43:21.884 001528 Info SwSIPReg   079F4018 00000000 SwSIPRegistrar::GetAllContacts          (U:37, T:0)
12 00:43:21.884 001528 Info SwSIPReg   079F4018 00000000 SwSIPReg::GetAllBindingsByUserOrTrunkId () Found 1 binding(s) with internal user ID 37
12 00:43:21.884 001528 Info SwSIPReg   07F8D638 00000000 SwSIPBinding::Send200Ok                 () SEND SIP 200 OK
12 00:43:21.884 001528 Inf3 SrvGk      07F8D980 00000000 SDeviceImpl::ReRegistered               () [0x07F8D980 SIPClient3rdPty, Reg: (Client,37,Nachname-Test, Vorname-Test), 192.168.102.1, G722 G711a G711u G729 T.38 ]
12 00:43:21.884 001528 Info SwSIPReg   07F8D638 00000000 SFsm::OnProcessEvent                    () Registered    evtRegister    Result: 0    NewSt: Registered
12 00:43:21.885 001528 Info SwSIPReg   07F8D638 00000000 SwSIPBinding::EnterStateRegistered      (0) Starting registration expiry timer for 120 seconds.

Mit diesen Logs kann ich dienen:

Gibt aber noch ein paar mehr, nur muss ich mich da erst mal durchwühlen, was überhaupt darin alles geloggt wird und welche Log-Files für mich von Interesse sein können.

jodost · 12 Jul 2016

hm, ich finde da jetzt nichts auffälliges. Habe mir auch mal den anderen Thread durchgelesen, da ging es ja um REGISTER-Probleme (die sind ja offenbar vom Tisch durch Neueingabe der Zugangsdaten).

Was mir auffällt ist, dass in dem Trace die Swyx in einem anderen Netz liegt als von Dir beschrieben (kann natürlich auch einfach ein Tippfehler sein). Und rein sicherheitshalber nochmal die Frage, ob da irgendwo NAT zum Einsatz kommt oder ob die wirklich sauber geroutet sind (denn es sind ja zwei unterschiedliche Netze). Welche IP-Adressen für public und private zeigt die Swyx denn in den Usereigenschaften unter "Endgeräte" an?

Ich würde mal gerne die INVITE/200 OK/...-Kommunikation bei einem Anruf (und zwar einem funktionierenden = intern und einem nicht-funktionierenden = extern) sehen.

Bib · 12 Jul 2016

Ja, das Netz in der Firma hat die .56. und nicht wie von mir angegeben die .50.

Ich werde versuchen, die Daten so schnell wie möglich nachzureichen.

Stehen die Logs der Anrufe in der selben log-Datei drin wie die Anmeldung am Server? Der Auszug oben war aus der IpPbxSrv___xxx.log

PeterPawn · 12 Jul 2016

Es ist nicht so, daß ich nicht weiter mitlese ... aber ich halte mich jetzt erst einmal raus, ich habe weder aktuelle Admin-Tools (wo man sich Einstellmöglichkeiten ansehen könnte) noch in den letzten drei Jahren Zugriff auf eine IpPbx gehabt (hatte ich ja im anderen Thread schon geschrieben) - damit kann ich außer allgemeinen Kenntnissen zu SIP/RTP und altem Wissen zur Swyx-Software ohnehin nichts beitragen.

jodost · 12 Jul 2016

Bib schrieb:
Stehen die Logs der Anrufe in der selben log-Datei drin wie die Anmeldung am Server? Der Auszug oben war aus der IpPbxSrv___xxx.log

ja die stehen im normalen Srv-Log. Schneller geht's m.E. aber mit Wireshark auf dem Server. Da könntest Du dann anschl. auch versuchen, Dir das Telefonat im Wireshark direkt anzuhören -> ist vielleicht beim Einkreisen, ob überhaupt Ton ankommt, hilfreich.

Bib · 12 Jul 2016

Wireshark ist drauf, muss mich nur erst mal mit dessen Benutzung vertraut machen... Da kommt eine Unmenge an Daten.

In den Endgeräte-Infos des Users mit der Nebenstelle 79 steht in der Swyx-Adminstration drin:

Endgerät: AVM Fritzbox
öfftl. IP: 192.168.102.1

Rest alles leer.

- - - Aktualisiert - - -

@jodost

Du hast eine PN

Den Link bitte ohne Leerzeichen im Domainnamen. Die Forensoftware ersetzt das leider...

- - - Aktualisiert - - -

So, dank jodost´s Hilfe konnte ich nun einen Wireshark-Mitschnitt machen und das Telefonat auch darin anhören.

Wenn ich das Gespräch in Wireshark anhöre, dann höre ich auf beiden Streams etwas, aber grafisch ist nur auf einem der beiden eine Welle zu sehen. Und zwar wird die Welle von meiner Fritzbox zur Swyx hin angezeigt, in die andere Richtung von der Swyx kommend ist die Grafik leer, wo die Sprache zu hören ist.

Was hat das zu bedeuten? Wo kann ich hier weitersuchen?

Die Verschlüsselung ist jedenfalls systemweit ausgeschaltet, da kann nichts dazwischenfunken.

PeterPawn · 12 Jul 2016

Ich wollte mich ja raushalten ... aber mir fällt natürlich auch beim passiven Lesen auf, daß man so gar keine Vorstellung haben kann, an welchem Punkt des gesamten Aufbaus Du denn nun diesen Mitschnitt überhaupt gemacht hast. Es ist ja schon ein Unterschied, ob das auf der FRITZ!Box oder der IpPbx oder irgendwo auf der Firewall/dem Access-Server dazwischen erfolgte. Davon hängt ja auch ab, wo der zweite Stream (wenn er tatsächlich am Tracepoint noch vorhanden ist) abbleiben könnte.

Damit kann man nicht einmal anhand der Beschreibung raten, wo denn nun der Audio-Stream in einer Richtung versanden mag.

Wenn ich das richtig verstehe, geht ja jetzt wenigstens eine Richtung?

Oder ist es auch hier so, daß Du die RTP-Verbindung zwar im Mitschnitt siehst, aber beide Teilnehmer einander gar nicht hören?

Was ist denn "etwas", was Du da hörst?

Manchmal ist das auch nur eine nicht 100%ige "echo cancellation", wenn auf einem Channel nur ein vollkommen unbrauchbares Nutzsignal vorhanden ist - da reicht schon die Einkopplung durch "Körperschall" am Telefon auf einer Seite aus; vielleicht ist die "fehlende Welle" auch nur das Zeichen dafür, daß dort keine wirkliche Amplitude des "Nutzsignals" vorhanden ist und das Gehörte wirklich nur "etwas". Aber das müßte man ja eigentlich hören, notfalls die Audiodaten speichern und mit Audacity genauer untersuchen.

Allerdings würde das auch wieder nur zum Problem, wenn tatsächlich auf einer Seite ein Stream ankommt und wiedergegeben wird ... sonst gibt es auch kein Echo.

Es ist also auch mit den Angaben in #14 wohl noch etwas "verschwommen" ... und es geht doch hier immer noch um die Verbindungen, die von der IpPbx über die ISDN-BRIs gepeert werden, oder? Haben die BRI-Trunks event. auch irgendwo RX-/TX-Counter, die man beobachten kann (natürlich nur für tatsächlich übertragene (Voice-)Daten, auf der ISDN-Seite gibt es ja ansonsten ein permanentes Framing)?

Languages

Suche

Languages

Suche

Fritzbox als SIP-Client an Swyx-Tel-Anlage --- Probleme

Bib

Mitglied

jodost

Mitglied

Bib

Mitglied

jodost

Mitglied

Bib

Mitglied

PeterPawn

IPPF-Urgestein

jodost

Mitglied

PeterPawn

IPPF-Urgestein

Bib

Mitglied

jodost

Mitglied

Bib

Mitglied

PeterPawn

IPPF-Urgestein

jodost

Mitglied

Bib

Mitglied

PeterPawn

IPPF-Urgestein

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums