Starface an QSC IPfonie extended connect anbinden

  • Hallo zusammen!


    Ich versuche hier gerade einen QSC IPfonie extended connect an unserer Starface Compact zum laufen zu bringen (SW Stand 5.8.0.12). Die Konfiguration habe ich als SIP Provider Anschluss vorgenommen. Die Anlage befindet sich hinter einem Lancom Router im internen LAN (also hinter NAT, DSL Provider ist Telekom). Die Registrierung bei QSC scheint auch zu funktionieren und ausgehende Gespräche sind möglich aber nur mit one-way audio (sprich: ich höre die Gegenstelle nicht, diese aber mich). Eingehende Gespräche werden an der Starface nicht verarbeitet weil sie offenbar dort gar nicht ankommen. Wenn ich auf dem Router einen Trace mache nach Datenpaketen die von QSC kommen müssten, sehe ich nichts ankommen. QSC schwört aber Stein und Bein das sie Daten senden. Die einzige Antwort die immer vom QSC Support kommt ist "Prüfen sie NAT und Firewall" leider ohne genau zu sagen worauf man denn nun prüfen soll. Nur, so verkehrt kann unsere Routerkonfiguration nicht sein, denn ein Sipgate Trunk an derselben Anlage funktioniert wunderbar. Weiterhin haben wir noch ein paar Telefone von nfon im Hause, die ebenfalls problemfrei laufen. Zu Testzwecken haben wir auch die Firewall im Router temporär abgeschaltet, die kann es also auch nicht sein. Es muss also etwas mit diesem speziellen Setup zu tun haben, also Starface -> QSC IPfonie extended connect.
    Da der QSC Support ziemlich nutzlos ist, dachte ich, ich frag mal hier ob jemand eine Idee hat, was man noch prüfen könnte?


    Viele Grüße,
    der Michael

  • Bitte folgendes prüfen:
    * Ist die im Adminbereich unter Server/Netzwerk eingestellte externe IP Adresse korrekt? Ist "Hinter NAT" dort aktiviert?
    * Sind die RTP-Ports per DNAT auf die STARFACE weitergeleitet? Sprich: Gibt es im Lancom-Router eine Port-Forwarding Regel, die die UDP-Ports 10.000 bis 20.000 auf die interne IP der STARFACE weiterleitet?

  • Bitte folgendes prüfen:
    * Ist die im Adminbereich unter Server/Netzwerk eingestellte externe IP Adresse korrekt? Ist "Hinter NAT" dort aktiviert?
    * Sind die RTP-Ports per DNAT auf die STARFACE weitergeleitet? Sprich: Gibt es im Lancom-Router eine Port-Forwarding Regel, die die UDP-Ports 10.000 bis 20.000 auf die interne IP der STARFACE weiterleitet?


    Und ein weiterer Morgen mit viel Testerei.
    Also: Ja, die externe IP ist korrekt und hinter NAT ist auch aktiv. Was das Port Forwarding angeht hätte QSC laut technischem Dokument gerne die Ports 20000-59999 weitergeleitet. Ich habe jetzt einfach mal 10000-59000 nach intern gemapped. Auch hier: laut Tech-Doku von QSC ist das eigentlich nur ausgehend nötig. Ergebnis: Zwar habe ich jetzt 2-way Audio. Angerufen werden kann die Anlage aber immer noch nicht.
    Also habe ich dann auch mal den Port 5060 fest auf die Starface nach intern weitergeleitet und siehe da, es geht. Nur: eigentlich sollte es doch gar nicht nötig sein den 5060 zu forwarden? Wenn ich mir den Traffic auf dem Router so anschaue (ohne forwarding) kommt die SIP Registrierung auf 5060 immer durch (in beide Richtungen). Danach ist Funkstille von beiden Seiten. Erst mit Forwarding passiert dort mehr. Ähm, ja?


    So und jetzt gleich die nächste Merkwürdigkeit: Ausgehend signalisiert die Starface jetzt offenbar die Rufnummern wie sie gerade Lust hat. Trotz eindeutiger Zuordnung der Benutzer, wird manchmal beim angerufenen Teilnehmer anstatt der Rufnummer die QSC Vertragsnummer angezeigt, manchmal aber auch ganz normal die eingestellte Rufnummer. Ein Muster wann welches Szenario eintritt konnte ich noch nicht feststellen. So wundert es auch nicht, das sich die Starface nicht an eine Umschaltung der Rufnummernsignalisierung hält. Ich kann Benutzer auf Signalisierung der noch vorhandenen (und funktionierenden) ISDN Leitung umstellen wie ich will, sie nimmt willkürlich einen der beiden angeschlossenen SIP Trunks (also meistens jedenfalls, leider so gar nicht reproduzierbar).
    Ergänzung: Schalte ich die Rufnummernanzeige kurz um auf eine andere Nummer und dann wieder zurück funktioniert das ganze exakt ein Mal. Der zweite Anruf danach zeigt wieder die Kundennummer bei QSC. Ach ja, und die Routing Priorität steht auf "Leitung".


    Ach was'n Spaß!


    Für sachdienliche Hinweise dankende Grüße,
    Michael

    2 Mal editiert, zuletzt von MIB ()


  • Also: Ja, die externe IP ist korrekt und hinter NAT ist auch aktiv. Was das Port Forwarding angeht hätte QSC laut technischem Dokument gerne die Ports 20000-59999 weitergeleitet. Ich habe jetzt einfach mal 10000-59000 nach intern gemapped.


    Das ist nicht notwendig, da ein Forwarding auf die Ports 20001—59000 spätestens an der Firewall der STARFACE scheitert. Die dortige iptables-Regel sieht wie folgt aus:

    Code
    target      proto opt source               destination
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpts:10000:20000



    Ergebnis: Zwar habe ich jetzt 2-way Audio. Angerufen werden kann die Anlage aber immer noch nicht.


    Audio ist RTP, Signalisierung ist SIP. Das ist netzwerktechnisch unabhängig voneinander.



    Also habe ich dann auch mal den Port 5060 fest auf die Starface nach intern weitergeleitet und siehe da, es geht. Nur: eigentlich sollte es doch gar nicht nötig sein den 5060 zu forwarden? Wenn ich mir den Traffic auf dem Router so anschaue (ohne forwarding) kommt die SIP Registrierung auf 5060 immer durch (in beide Richtungen). Danach ist Funkstille von beiden Seiten. Erst mit Forwarding passiert dort mehr. Ähm, ja?


    Doch klar ist das notwendig!


    Die Regel bei den meisten NAT-Firewalls ist es, ausgehende Pakete zuzulassen und eingehende Pakete mit Status RELATED und ESTABLISHED entweder lokal durchzulassen oder nach Adressübersetzung weiterzuleiten — eingehende Pakete mit Status NEW, also eine von außen initiierte Verbindung wird nicht erlaubt. Erstens aus Sicherheitsgründen, aber auch viel banaler, weil der Router, ohne dass der die Verbindung zuordnen kann, diese schlichtweg nur an sich selbst adressiert sieht und keiner bestehenden Verbindung zuordnen kann. Wohin sollte er auch weiterleiten.


    Es ist also zwingend eine Regel für vom Provider initiierte SIP-Verbindungen notwendig — es sei denn, die Firewall kann diese einer vorher ausgehenden Verbindung zuordnen. Spätestens nach ein paar Minuten wird ihr das nicht mehr gelingen, da die Zustände altern und wieder verworfen werden.



    So und jetzt gleich die nächste Merkwürdigkeit: Ausgehend signalisiert die Starface jetzt offenbar die Rufnummern wie sie gerade Lust hat. Trotz eindeutiger Zuordnung der Benutzer, wird manchmal beim angerufenen Teilnehmer anstatt der Rufnummer die QSC Vertragsnummer angezeigt, manchmal aber auch ganz normal die eingestellte Rufnummer. Ein Muster wann welches Szenario eintritt konnte ich noch nicht feststellen. So wundert es auch nicht, das sich die Starface nicht an eine Umschaltung der Rufnummernsignalisierung hält. Ich kann Benutzer auf Signalisierung der noch vorhandenen (und funktionierenden) ISDN Leitung umstellen wie ich will, sie nimmt willkürlich einen der beiden angeschlossenen SIP Trunks (also meistens jedenfalls, leider so gar nicht reproduzierbar).


    Ist die Landes- und Ortsvorwahl in der Providerkonfiguration richtig? Stimmen die dort angelegten Rufnummernkreise? Gibt es Module zur Manipulation der Caller-ID?


    Ein Auszug aus dem PBX-Log, während der Testanrufe, wäre hier hilfreich.

  • Das ist nicht notwendig, da ein Forwarding auf die Ports 20001—59000 spätestens an der Firewall der STARFACE scheitert. Die dortige iptables-Regel sieht wie folgt aus:

    Code
    target      proto opt source               destination
    ACCEPT     udp  --  0.0.0.0/0            0.0.0.0/0           state NEW udp dpts:10000:20000


    Gut zu wissen. Dann nehme ich den oberen Bereich wieder raus. Steht halt so bei QSC in der Doku.



    Audio ist RTP, Signalisierung ist SIP. Das ist netzwerktechnisch unabhängig voneinander.


    Das ist mir durchaus klar.



    Doch klar ist das notwendig!


    Bei Sipgate Trunks eben nicht. Das läuft auch ohne ein statisches mapping des Ports 5060. Daher hatte ich das jetzt auch beim QSC Trunk erwartet.



    Die Regel bei den meisten NAT-Firewalls ist es, ausgehende Pakete zuzulassen und eingehende Pakete mit Status RELATED und ESTABLISHED entweder lokal durchzulassen oder nach Adressübersetzung weiterzuleiten — eingehende Pakete mit Status NEW, also eine von außen initiierte Verbindung wird nicht erlaubt. Erstens aus Sicherheitsgründen, aber auch viel banaler, weil der Router, ohne dass der die Verbindung zuordnen kann, diese schlichtweg nur an sich selbst adressiert sieht und keiner bestehenden Verbindung zuordnen kann. Wohin sollte er auch weiterleiten.


    Es ist also zwingend eine Regel für vom Provider initiierte SIP-Verbindungen notwendig — es sei denn, die Firewall kann diese einer vorher ausgehenden Verbindung zuordnen. Spätestens nach ein paar Minuten wird ihr das nicht mehr gelingen, da die Zustände altern und wieder verworfen werden.


    Auch diese Funktionsweise ist mir absolut klar. Das Problem ist hier weniger die Firewall, da diese zum Test ohnehin abgeschaltet war, sondern das der Router Prozess die Pakete nicht zuordnen kann. Auch das ist völlig klar. Es scheint eben so zu sein das die Starface bei Nutzung des Spinate Trunks hier regelmäßig die Verbindung zum Server hält und somit eingehende Pakete zugeordnet werden können. Bei den nfon Telefonen scheint das ähnlich zu funktionieren, da auch diese ohne ein Mapping auskommen. Beim QSC Trunk ist dies offenbar nicht so und es muss "leider" ein statisches Mapping her.



    Ist die Landes- und Ortsvorwahl in der Providerkonfiguration richtig? Stimmen die dort angelegten Rufnummernkreise? Gibt es Module zur Manipulation der Caller-ID?


    Landes und Ortsvorwahl ist korrekt, ebenso die angelegten Nummernkreise. Zusätzliche Module sind nicht installiert. Die Starface ist in dieser Hinsicht "plain vanilla".
    Die Umschaltung der Rufnummernsignalisierung für die Teilnehmer erfolgt in den Benutzereinstellungen.
    Ob aber die Providerkonfiguration korrekt ist, ist hier die große Frage. Ich benutze hier die Voreinstellung für "IPfonie Extended connect" die in der Starface seit 5.8 enthalten ist. Auffällig hierbei ist: Dieser Eintrag ist editierbar, was ja sonst nicht der Fall ist. Die Konfiguration wurde offenbar von Starface erstellt, nicht von QSC.



    Ein Auszug aus dem PBX-Log, während der Testanrufe, wäre hier hilfreich.


    Ich hoffe das ich das in den nächsten Tagen mal zeitlich hinbekomme.


    Es grüßt,
    Michael

  • Hallo,


    ein Update auf die aktuellste Version (5.8.1) könnte da helfen. Wir haben bei der Rufsignalisierung in SIPConnect-Profilen einiges geändert.
    Wenn Sie die ISDN-Nummer über die QSC-Leitung signalisieren wollen, müssen Sie bei der QSC-Leitung CLIP No Screening aktivieren. Sollten Sie CLIP No Screening schon aktiviert haben, dann bitte unbedingt updaten. Die 5.8.0.12 hatte da noch einen Bug.


    Sollte es nach dem Update nicht funktionieren, dann bitte einen Support-Case eröffnen mit Screenshots der Leitungskonfig/Userkonfig und im besten Fall SIP-Trace.


    Vielen Dank.


    Grüße
    Norman

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!