Starface Appliance hinter DeutschlandLAN IP Voice/Data (S/M/L) Telekom-Profil

  • Hi zusammen,

    ich bin relativ neu im Bereich Starface und dies ist mein erstes Thema, dass ich in die Community poste. Ich hoffe, dass jemand bereits ein paar Tipps/Erfahrungen in der Konstellation sammeln konnte, die wir bei einem unserer Kunden haben und mir eine Antwort zu meinen offenen Fragen hat.

    Nun zum eigentlich Thema:

    Wir haben eine Starface Compact SIP Appliance auf der Version 8.1.2.2 bei einem unserer Kunden ausgerollt. Wie im Titel genannt, hat der Kunde einen Telekom Company Pro 250 Internetanschluss (samt Telefonie), was auf der Starface nur mit dem DeutschlandLAN IP Voice/Data Profil betrieben werden kann (Die Telefonie kann meiner Erfahrung nach nur hinter dem Internetanschluss selbst betrieben werden).

    Aus dem internen Netzwerk heraus funktioniert die Telefonie einwandfrei. Da nun einer der Mitarbeiter die Telefonie aus dem Homeoffice heraus nutzen möchte war meine Überlegung die Starface aus dem öffenltichen Netz erreichbar zu machen und sie in ein DMZ zu stellen und zu testen, ob die Telekom das mitbekommt, immerhin ist die Starface TK-Anlage ja hinter dem richtigen Internetanschluss aktiv, dass sich der Softphone-Client ganz woanders befindet, dürfte die Telekom doch gar nicht mitbekommen, das dachte ich jedenfalls :)

    Bisher habe ich es nur geschafft mich mit dem Starface UCC Client an der Starface anzumelden. Wenn ich versuche einen Anruf zu führen, klingelt es auch, nur war es das und Audiodateien werden nicht übertragen.

    Da wir in diesem Konzept zum allerersten Mal auch eine Lancom UF260 Firewall als Gateway eingesetzt haben, dachte ich mir, dass es auch an der Firewall liegen könnte und diese die UDP-Pakete blockiert und eventuell deshalb die Telefonie nicht sauber funktioniert. Allerdings sehe ich auf der Firewall keine gedroppten UDP-Pakete, weder von der Starface TK zum UCC Client noch umgekehrt. Deshalb vermute ich, dass die Telekom das unterbindet, nur frage ich mich, wie die Telekom das macht. Ich bin ehrlich gesagt nicht ganz fit im Bereich SIP Rufaufbau, UDP Audiodateiübertragung und ob die UDP Pakete der Gesprächsteilnehmer über die Starface TK-Anlage laufen oder direkt über die Starface UCC Clients etc....

    Jedenfalls ist der Einsatz eines VPN-Clients am Home-Office-Standort keine Alternative, da alle Clients eine OpenVPN VPN-Client-Verbindung für Drittsoftware nutzt/braucht und zwei parallele VPN-Verbindungen gefühlt die größere Hürde darstellen.

    Ich hoffe, dass ich mich halbwegs verständlich ausgedrückt habe und mir jemand weiterhelfen kann. Ich tappe nämlich im Dunkeln :(

    Vielleicht weiss jemand von Euch welcher Host die UDP-Pakete (Audiodateien-Übertragung) initiiert. Allein diese info würde mich schon etwas schlauer machen.

    Herzlichen Dank schon mal für eure Antworten...

  • Also wie ich es jetzt verstehe:

    was hängt vor dem Lancom noch für das Internet? Modem? Galsfaser? ein anderer Router?


    von aussen brauchst Du die Ports

    10.000 bis 20.000udp


    gehend muss die Anlage das erlaubt bekommen.

    1.025 bis 65.535UDP

    die restlichen Poprts findest Du hier.

    Übersicht der Portnutzung der STARFACE - STARFACE WIKI (Deutsch) - STARFACE WIKI


    Die Telekom bekommt garnichts mit wo der softphone Client ist.

    Der meldet sich ja an der Anlage an und telefoniert auch darüber.


    Es können also nur die rtp Ports sein die nicht richtig funktionieren, wenn die SIP Anmeldung vom Client funktioniert.

    Edited once, last by F7_SG (May 8, 2024 at 9:00 AM).

  • Ist auf der LANCOM Firewall auch der SIP ALG aus? Die SIP ALGs machen gerne Probleme mit RTP und SIP Paketen.

    Was hast du in der Starface unter Server konfiguriert? Hinter NAT ja/nein?

    Ansonsten hätte ich wie F7_SG noch die Ports geprüft.


    Ich würde eventuell noch ein PCAP machen und schauen, was die Starface in den SIP/SDP Paketen zur App schickt. Vermute, dass entweder die Ports nicht freigegeben sind oder die IP der Starface falsch geschickt wird.

  • Hi und Danke für Eure schnelle Reaktionen/Antworten und Tipps.

    Hier meine Antworten:

    zu "was hängt vor dem Lancom noch für das Internet? Modem? Galsfaser? ein anderer Router?" -> Vor der Lancom-Firewall ist einfaches Glasfaser-Modem im Einsatz.


    zu "Ist auf der LANCOM Firewall auch der SIP ALG aus? Die SIP ALGs machen gerne Probleme mit RTP und SIP Paketen." -> Auf der Firewall existiert kein Punkt, der sich SIP-ALG nennt, den ich deaktivieren kann. Ist halt kein gewöhnlicher Lancom-Router mehr, sondern eine Lancom-Firewall, mit einem Linux-OS unten drunter... Bei Lancom-Routern dagegen existiert er. (Ich habe auch schon bei Lancom ein Ticket eröffnet, da kippe ich gleich mal die Frage ein, wie sie das auf der Firewall umgesetzt haben...)

    Hinsichtlich der eingehenden/ausgehenden Ports

    Die habe ich alle beachtet und gesetzt, bis auf einen eingehenden Port -> Nämlich Port 4500 UDP (Den brauchen wir um das VPN via IPsec zur Firewall aufzubauen) Den Port musste ich extra ausklammern, da bei meinen Tests der VPN-Zugriff nicht mehr möglich war. Das VPN-Protokoll IKEv2 nutzt nämlich UDP 4500 eingehend.

    Zu "Was hast du in der Starface unter Server konfiguriert? Hinter NAT ja/nein?" -> Dort ist Hinter NAT auf "ja" aktiv.

    Sobald ich den Datenverkehr-Mittschnitt gemacht habe, melde ich mich erneut. Das die Telekom das nicht mitbekommt beruhigt mich schonmal ein Wenig. Ich Danke Euch.

  • Unter dem Range der "ausgehenden RTP-Audiodateien" ist der Port 4500 mit dabei. Als ich die Starface TK in der Lancom -Firewall als DMZ-Host deklariert hatte, konnte ich kein VPN zur Firewall mehr aufbauen.

    image.png

    In der Firewall kann man Dienstegruppen erstellen und alle notwendigen Ports in eine Dienstgruppe, z.B. Namens "Starface" aufnehmen. Da die Dienstgruppe nicht zwischen ausgehend und eingehend unterscheidet, wurde wohl der UDP-Port 4500 zur Starface gelenkt, anstatt zur Firewall. Habe dann als Lösung zwei Dienstegruppen erstellt "Inbound" und "Outbound" und den Port 4500 UDP eingehende damit ausgeklammert. Sorry, ich habe mich etwas knapp ausgedrückt..

  • In der Firewall kann man Dienstegruppen erstellen und alle notwendigen Ports in eine Dienstgruppe, z.B. Namens "Starface" aufnehmen. Da die Dienstgruppe nicht zwischen ausgehend und eingehend unterscheidet, wurde wohl der UDP-Port 4500 zur Starface gelenkt, anstatt zur Firewall. Habe dann als Lösung zwei Dienstegruppen erstellt "Inbound" und "Outbound" und den Port 4500 UDP eingehende damit ausgeklammert. Sorry, ich habe mich etwas knapp ausgedrückt..

    Ok, da muss ich sagen, finde ich die Arbeitsweise des Lancoms etwas fragwürdig, aber ich arbeite nicht mit den Geräten, wenn man das weiß wird das schon seine Richtigkeit haben :rolleyes:

    Viele Grüße
    Rouven

  • Hallo zusammen,

    ich melde mich mit neuen Erkenntnissen zum Thema zurück.

    1. Lancom Firewalls haben einen eigenen Bereich für die Konfiguration der VoIP-Telefonie. Dieser heißt VoIP-Proxy-Einstellungen und ist unter UTM -> Proxy zu finden. Ich habe den VoIP/SIP-Proxy aktiviert und die Telefonie erneut getestet, jedoch hat sich am Verhalten nichts geändert. Hier das Starface Support-Log zum Anruf.

    [2024-05-16T13:42:11,087] [ 1790 ] ********* Call created **********
    [2024-05-16T13:42:11,093] [ 1790 ] Starting call routing : SIP/1024.SFiphone-0000053c dial number 0049987654321 CallerId [firstname=Max, lastname=Mustermann, number=33]
    [2024-05-16T13:42:11,117] [ 1790 ] Routing call "CallerId [firstname=Max, lastname=Mustermann, dialedNumber=0049987654321, number=33]" to number 0049987654321 over service OutgoingService
    [2024-05-16T13:42:11,117] [ 1790 ] CallLeg: e9e91fdf-12b9-4c1c-8df5-c1bdf279b9a9
    [2024-05-16T13:42:11,120] [ 1790 ] Found lines for LINE routing
    [2024-05-16T13:42:11,120] [ 1790 ] - SIP/+49123456789
    [2024-05-16T13:42:11,121] [ 1790 ] Signalnumber of caller account 1004
    [2024-05-16T13:42:11,121] [ 1790 ] SignalNumberByParticipantAndLine 0049123456789
    [2024-05-16T13:42:11,121] [ 1790 ] Signal number after calculate 0049123456789
    [2024-05-16T13:42:11,121] [ 1790 ] SipconnectDisplayNumber +49123456789
    [2024-05-16T13:42:11,122] [ 1790 ] Normalized Name Max Mustermann
    [2024-05-16T13:42:11,122] [ 1790 ] Normalized Number +49123456789
    [2024-05-16T13:42:11,122] [ 1790 ] Signalling on Line Telekom Deutschland LAN IP Voice Data 3(1004) | SIP/1024.SFiphone-0000053c
    [2024-05-16T13:42:11,123] [ 1790 ] CALLERID(all) 0123456789 <0123456789> channel | SIP/1024.SFiphone-0000053c
    [2024-05-16T13:42:11,124] [ 1790 ] P-Asserted-Identity <sip:0123456789@tel.t-online.de> sipheader | SIP/1024.SFiphone-0000053c
    [2024-05-16T13:42:11,127] [ 1790 ] Dialing line SIP/+49123456789 with extension +49987654321
    [2024-05-16T13:42:11,279] [ 1790 ] Dial | SIP/1024.SFiphone-0000053c -> SIP/+49123456789-0000053d
    [2024-05-16T13:42:11,484] [ ---- ] Sending push request: for callId 8380993e-1670-4902-b7d4-99c5df9d87b5 returns code 200
    [2024-05-16T13:42:12,033] [ 1790 ] Channelstate is RINGING | SIP/+49123456789-0000053d
    [2024-05-16T13:42:19,113] [ 1790 ] Channelstate is UP | SIP/+49123456789-0000053d
    [2024-05-16T13:42:19,114] [ 1790 ] DialEnd with dialstatus ANSWER | SIP/1024.SFiphone-0000053c -> SIP/+496924404433-0000053d
    [2024-05-16T13:42:19,116] [ 1790 ] Link | SIP/1024.SFiphone-0000053c -> SIP/+49123456789-0000053d
    [2024-05-16T13:42:30,052] [ 1790 ] Hangup Request Event | SIP/+49123456789-0000053d
    [2024-05-16T13:42:30,059] [ 1790 ] Hangup Cause: NORMAL_CLEARING | SIP/+49123456789-0000053d
    [2024-05-16T13:42:30,154] [ 1790 ] Got dialstatus DialReturnCodes(hc=NORMAL_CLEARING, ds=ANSWER, cr=UNKNOWN)
    [2024-05-16T13:42:30,158] [ 1790 ] Hangup Cause: NORMAL_CLEARING | SIP/1024.SFiphone-0000053c
    [2024-05-16T13:42:30,158] [ 1790 ] ********* Call finished *********

    2.Ich habe zusätzlich aus der Firewall ein Alert-Log zum Zeitpunkt eines Gesprächs ohne Audioübertragung erstellt, exportiert und aufbereitet. Jetzt sind UDP-Pakete zu sehen, aber irgendetwas an der Konfiguration scheint noch nicht ganz zu stimmen. Laut der Lancom-Firewall ist das erste UDP-Paket ein Paket der Starface TK-Anlage, mit einem dynamischen Port in Richtung des Clients.

    2024-05-16T13:42:04Connection FinishedFinished:ORIG:SRC=10.100.100.100DST=213.XXX.XXX.XXXPROTO=UDPSPT=18484DPT=57593PKTS=217BYTES=45570


    Die Antwort des Clients, so listet es das Log ist 0 Bytes groß?!

    REPLY:SRC=213.135.22.17DST=80.XXX.XXX.XXXPROTO=UDPSPT=57593DPT=18484PKTS=0BYTES=0


    3. Da mich das etwas stutzig gemacht hat und mich der Status "Connection Finished" irritiert hat, habe ich zwei Wireshark-Mittschnitte erstellt, einmal mit aktiviertem VPN-Client, bei dem die Telefonie erfolgreich läuft und Audiodateien übertragen werden und ein zweites Mal ohne VPN, also eine Verbindung aus dem Public IP-Netz ohne Audioübertragung.

    Auf der Clientseite sieht es so aus, als ob UDP-Anfragen nicht beantwortet werden. Bei einem erfolgreichen Anruf hingegen sieht man deutlich das UDP-Ping-Pong. Scheint mir die Firewall zu sein, die irgendwo noch eine fehlerhafte Konfiguration hat, nur wo ist die Frage ☹. Auch scheint das allererste UDP Paket ein Paket vom Client zur Starface PBX zu sein und nicht umgekehrt.

    Da das Log der Firewall etwas anderes aussagt und angeblich Anfragen rausgeschickt werden, also auch nicht blockiert werden, warte ich auf die Antwort vom Lancom Support. Ich bin kein Experte im Lesen von Logs, vielleicht weiß jemand, wie ich das gegenprüfen kann?

    Ich melde mich wieder mit neuen Erkenntnissen...

  • Update - Nun funktionierts auch über das Public-IP Netz. Endlich :)

    Die Ursache war folgendes:

    In der Starface TK-Anlage war unter Netzwerk "Externe Adresse" die Externe IP-Adresse nicht eingetragen. Das führte dazu, dass der Client versucht hat die UDP-Pakete an die interne IP der TK-Anlage zu verschicken. Deshalb waren auch keine eingehenden UDP-Pakete auf der Firewall zu sehen.

    Ich danke Euch für die Unterstützung :)

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!