Posts by Niklas

    Hallo Christo!


    Danke für deine Doku, allerdings würde ich auch dringend zum vorgefertigten 1&1 Providerprofil ("1&1 SIP") raten.
    Hab ich nicht?... Ich hab doch mal... Ja genau: Ich hab seiner Zeit mal meine Konfiguration von Daheim gepostet.



    Zu den RTP Ports:
    Die STARFACE wählt bei jedem Anruf einen zufälligen Port aus der Range 10.000-20.000/udp aus. Nur die ersten 512 freizugeben reicht leider nicht aus* ;)
    XMPP / Webinterface / Autoprovisioning würde ich auch nur bei Bedarf in's Internet freischalten (s. Post von Schubbie).


    :* Kann dank comedia auch komplett ohne Freigabe funktionieren, spätestens bei Rufumleitungen wird es aber spannend.



    Eigentlich braucht nur Port 5060 freigegeben zu werden und diesen sollte man auf den IP des Providers begrenzen (kann die FritzBox nicht ohne Änderungen), so bleibt die Blacklist der Starface leer.


    asn 212.227.124.130
    AS | IP | BGP Prefix | CC | Registry | Allocated | AS Name
    8560 | 212.227.124.130 | 212.227.0.0/16 | DE | ripencc | 1998-09-10 | ONEANDONE-AS Brauerstrasse 48, DE

    :cool:

    Hallo FloSa!


    Ich vermute hier was anderes: Was ist unter Server => Netzwerk unter "Hinter NAT?" und "Externe Adresse:" eingetragen?
    Die 1&1 akzeptiert keine REGISTERs die einen RFC1918-Host (private IP Adresse) enthalten, und lehnen diese mit einem "REJECT" ab. Sieht man allerdings nur in einem tcpdump (Systemstatus => Diagnose, auswertbar z.B. mit Wireshark), nicht im Asterisk Log.


    Hab dazu einen alten Thread von mir rausgekramt:
    https://support.starface.de/fo…-1-amp-1-eine-Projektdoku


    Im PDF behandle ich das Thema um die böse IP-Adresse ;)

    Hallo!


    Möglich ist es. Keine Frage. Hast du mal im Providerprofil den Typ "sipconnect" ausprobiert?
    Eine kurze Übersicht über die Typen findest du hier: https://knowledge.starface.de/…viderprofil+konfigurieren (ganz unten im Artikel)


    Wenn da nichts passendes dabei ist, kannst du dir mal die Tabelle "providersignalling" auf der Datenbank anschauen.
    Hier sind wir aber dann sehr weit von dem was wir im STARFACE Support unterstützen entfernt...


    Die saubere Lösung wäre: A1 (oder einer unser Partner mit heißem Draht zur A1) konfiguriert und betreut zertifiziertes Providerprofil auf siptrunk.de.

    Hallo Frank!


    Ich sehe hier keine Möglichkeit das über eine STARFACE zu lösen.
    Selbst mit einem DNS-Alias wirst du ja wieder auf das selbe Netz (AS3320 - 217.0.0.0/13) verwiesen, und damit fällst du wieder auf die Routing-Tabelle zurück.
    Du müsstest hier einen SIP-Proxy oder möglicherweise einen B2B-UA einsetzen, welcher die Trunks auf Applikationsebene splitten und über das richtige Gateway ausleiten kann. Ich denke hier z.B. an Kamallio an dem du später die STARFACE registrierst. Das ist aber alles andere als trivial zu konfigurieren. Und leider auch nicht von uns Supported.


    Alternativ: Ein STARFACE pro Standort, verbunden via Anlagenverbund?

    Hallo Jörg!


    Technisch ist das kein Problem: einfach die SIP Accounts als Leitungen konfigurieren (https://knowledge.starface.de/…ge.action?pageId=23988321) und die Rufnummern den entsprechenden Benutzern / Gruppen / Modulen zuweisen.
    Das ist ja das schöne an VoIP, man ist nicht mehr Standortgebunden.


    Jetzt kommt das aber :p


    1. Ist die STARFACE nicht für mehrere Mandanten ausgelegt. Das fängt bei dem Callrouting an und zieht sich als roter Faden weiter durch die Anrufsauswertung etc.
    2. VDSL mit Telefonie bei 1&1: bisher hat die 1&1 es so gehandhabt das bei SIP Registrierungen die nicht vom mit-gebuchten DSLer erfolgten die Bandbreite selbigen halbierten. Hier solltest du dich mit der 1&1 in Verbindung setzen.

    Ich habe die Datenpakete mitgeschnitten und konnte dann sehen, dass die ausgehenden UDP-Pakete an der Starface die IP-Adresse des Smartphones als Zieladresse beinhalten. Das problematische daran: es handelt sich um eine private IP aus dem 10.0.0.0/8 Netz. Diese IP sehe ich auch, wenn ich beim Smartphone in die Settings gehe. Es handelt sich also nicht um die Public IP, mit der mein Smartphone z.B. in den Logs eines Webservers auftauschen würde, und die tatsächlich auch beim Verbindungsaufbau für XMPP und TLS (Ports 5060 und 5061 sowie 5222) an der Starface ankommt.
    Mir ist natürlich klar, dass ich mit der privaten IP des Smartphones nicht arbeiten kann. Scheinbar macht die Telekom zwischen Mobilfunknetz und Festnet/I-Net noch einmal NAT.


    Handelt es sich ggf. um einen Bug im Client?


    Schwierig schwierig...


    Um das mal zu erläutern:
    Beim SIP INVITE wird via SDP eine Media-Address (host:port) übergeben. Der SIP Client (z.B. UCC) setzt hier meistens die Adresse des primären Netzwerkadapters, in deinem Fall die 10.0.0.0/8er.
    Per Default wird der Asterisk (Telefoniedienst der STARFACE) nun den RTP-Stream an diese Adresse übertragen. Das macht Sinn wenn man z.B. einen Host als Registrar (SIP) und einen anderen für RTP (Media) verwendet.


    Hast du im entsprechenden Telefonprofil unter "Erweiterte Einstellungen" "NAT" auf "Ja" gesetzt?


    Das veranlasst uns bei dem Peer (Endgerät) die Optionen nat=force_rport,comedia zu setzen.
    Damit ignoriert Asterisk die Media-Address des SDPs und sendet den RTP-Stream an die Quell-adresse /-port von der der SDP kam.

    Klemmt da eine BLF? :confused:
    Schau mal im Log zu was das CallLeg 381a7f19-c795-430b-a57a-9b5cb6fd84b4 gehört.


    Der "e" Präfix bei e1074 deutet auf eine Funktionstaste (sprich: kein Besetzlampenfeld eines Benutzers) hin.

    Ich würde dir ans Herz legen die Mails über einen MTA ("externer Mailserver") zu versenden. Das Versenden vom internen Mailsserver wird immer häufiger als Spam geflaggt.
    Solange so wohl STARFACE als auch der Mailserver im eigenen Netzwerk ist kann man daran was machen, bei einem externen Mailsserver wird's schwierig.


    Vielleicht kannst du ja im O365 Exchange einen dedizierten User zum Versand von STARFACE-Mails per SMTP anlegen.

    Erhalte auf der TK Anlage folgenden Fehler from '<sip:140.100.100.31>' failed for '140.100.100.43:5060' - Wrong password
    [...]VOIP - Konto des Telefons bleibt leer.


    Klingt so als würden wir das SIP Passwort bei der Provisionierung nicht mitliefern.
    Hast du mal versucht im Telefonprofil der N720 ein neues Passwort zu vergeben und dann auf die N720 neuzustarten (oder anderweitig ein Provisioning-Request auslösen)?


    Starface Support, konnte nicht helfen, meinte wie in einem Forenbeitrag von 2016?, komplett Reset der DECT Anlage fahren. Wäre nur ein größerer Aufwand.


    Kannst du mir mal die Call# zukommen lassen?


    Hallo Fabian!


    Ich bin mit dem Ticket mittlerweile vertraut, ganz so ist es ja nicht abgelaufen :rolleyes:
    Wenn du schon auf dem doofen Support und dem Produkt rumhackst sollte auch mal ein "mea culpa" drin sein


    Ohne LLDP funktionieren die Telefone nun. Ich hoffe nur nicht, dass sie sich LLDP wieder per Autoprovisioning ziehen.



    Habe es gerade auf einer .20 überprüft:
    Der Parameter static.network.lldp.enable wird nicht provisioniert, und defaultet damit auf "disabled"¹.


    ¹ Quelle: Yealink_SIP-T2_Series_T4_Series_T5_Series_IP_Phones_Administrator_Guide_V83_30.pdf, Seite 39 ff. (33 lt. Footer)


    Edit: Ich muss meinen Beitrag revidieren. Ist static.network.lldp.enable nicht gesetzt ist der Defaultwert "1", bzw. "enabled".

    Ich habe schon einen Dump machen lassen, dieser ist nur leider 11GB gross.


    "Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway." - Andrew Tanenbaum


    O/T:
    Sind bestimmt nur 7,8GB Werbung + Tracker-JS und 1GB Crypto-Miner :rolleyes:


    Mal ganz unabhängig davon: Windows müsste doch auch so was wie proc-limits / ulimit mitbringen? Windows System Resource Manager, oder so ähnlich? - Ist schon lange her, sorry.
    Zumindest solange bis wir das Problem an der Wurzel beheben können.

    Hallo Jens!


    Auf meiner Testmaschine (6.6.0.20) sind die Keystores (mit importiertem CSR) identisch: