16
Starface vs. Vodafone IP-Anlagenanschluss
Hallo Freunde,
ist jemand unter euch, der eine Starface an einem IP Anlagenanschluss der Vodafone betreibt?
Ich suche händeringend nach einer Anleitung, wie die Leitungskonfig an der Starface aufgebaut sein muss, damit ich darüber einen IP-Ala der VF anbinden kann.
Alle bisherigen Versuche gipfelten darin, dass abgehende Rufe klappen, inkl. Sprachübertragung, eingehende Rufe aber mit "Rufnummer nicht vergeben" abprallen.
Seitens VF gibt es zu dem Thema nichts, ich habe bereits verschiedene Stellen des Vodafone Supports - inkl. 'Spezialisten' des Vertriebspartners kontaktiert, keiner kann mir helfen...
In der Fluxpunkt wiki habe zwar eine Anleitung gefunden, aber auch damit bekomme ich keine funktionierende Telefonie zu Stande.
Die Anleitung ist nun auch schon über 6 Jahre alt und ich bin mir unsicher, ob die überhaupt noch passt.
Wenn also ein guter Geist unter euch zufällig die Kombination aus Starface und VF IP-Ala am laufen hat wäre ich super dankbar, wenn er/sie mir mal zukommen lassen könnte, wie das Providerprofil aussehen muss.
Vielen lieben Dank im Voraus,
Chris
ist jemand unter euch, der eine Starface an einem IP Anlagenanschluss der Vodafone betreibt?
Ich suche händeringend nach einer Anleitung, wie die Leitungskonfig an der Starface aufgebaut sein muss, damit ich darüber einen IP-Ala der VF anbinden kann.
Alle bisherigen Versuche gipfelten darin, dass abgehende Rufe klappen, inkl. Sprachübertragung, eingehende Rufe aber mit "Rufnummer nicht vergeben" abprallen.
Seitens VF gibt es zu dem Thema nichts, ich habe bereits verschiedene Stellen des Vodafone Supports - inkl. 'Spezialisten' des Vertriebspartners kontaktiert, keiner kann mir helfen...
In der Fluxpunkt wiki habe zwar eine Anleitung gefunden, aber auch damit bekomme ich keine funktionierende Telefonie zu Stande.
Die Anleitung ist nun auch schon über 6 Jahre alt und ich bin mir unsicher, ob die überhaupt noch passt.
Wenn also ein guter Geist unter euch zufällig die Kombination aus Starface und VF IP-Ala am laufen hat wäre ich super dankbar, wenn er/sie mir mal zukommen lassen könnte, wie das Providerprofil aussehen muss.
Vielen lieben Dank im Voraus,
Chris
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 91941015261
Url: https://administrator.de/forum/starface-vs-vodafone-ip-anlagenanschluss-91941015261.html
Ausgedruckt am: 25.12.2024 um 07:12 Uhr
16 Kommentare
Neuester Kommentar
Hallo,
Gruß,
Peter
Zitat von @c-webber:
Wenn also ein guter Geist unter euch zufällig die Kombination aus Starface und VF IP-Ala am laufen hat wäre ich super dankbar, wenn er/sie mir mal zukommen lassen könnte, wie das Providerprofil aussehen muss.
Und was sagt Starface zu dein hilfeschrei?Wenn also ein guter Geist unter euch zufällig die Kombination aus Starface und VF IP-Ala am laufen hat wäre ich super dankbar, wenn er/sie mir mal zukommen lassen könnte, wie das Providerprofil aussehen muss.
Gruß,
Peter
Hallo,
also mal ganz pauschal:
Im Router Portforwarding auf die Anlage eingerichtet? Ohne das geht es zwar raus aber eben nicht rein. Anmelden scheint sie ja zu machen, sonst könntest Du ja nicht abgehend telefonieren.
also mal ganz pauschal:
Im Router Portforwarding auf die Anlage eingerichtet? Ohne das geht es zwar raus aber eben nicht rein. Anmelden scheint sie ja zu machen, sonst könntest Du ja nicht abgehend telefonieren.
Rein geht ja offenbar auch, nur lehnt die Anlage den Anruf ab, weil sie nicht weiß wohin mit dem Anruf. Das hat sie mit "SIP/404" quittiert und das erzeugt diese Ansage. Andernfalls käme eine "momentan nicht erreichbar"-Ansage.
Bitte hört auf, Portforwarding für SIP zu empfehlen! Das ist eine komplett unnötige Sicherheitslücke!
@c-webber: Die Anlage wird doch sicher ein Log schreiben — daraus sollte hevorgehen, welche Nummer angerufen wurde und warum die Anlage nicht wusste was sie damit machen soll. Vielleicht ist einfach das Rufnummernformat mit dem Vodafone signalisiert anders als es die Starface erwartet. Oder sie sucht im falschen Teil des Headers nach der angerufenen Nummer (z.B. in der URI statt im To:-Header)
Bitte hört auf, Portforwarding für SIP zu empfehlen! Das ist eine komplett unnötige Sicherheitslücke!
@c-webber: Die Anlage wird doch sicher ein Log schreiben — daraus sollte hevorgehen, welche Nummer angerufen wurde und warum die Anlage nicht wusste was sie damit machen soll. Vielleicht ist einfach das Rufnummernformat mit dem Vodafone signalisiert anders als es die Starface erwartet. Oder sie sucht im falschen Teil des Headers nach der angerufenen Nummer (z.B. in der URI statt im To:-Header)
1
Hallo,
evtl. ist ja auch nicht konfiguriert wo es klingeln soll ;=)
evtl. ist ja auch nicht konfiguriert wo es klingeln soll ;=)
Moin.
Welche Starface-Version? Appliance oder Virtual? Welche Firewall?
VF-Anschluss "standalone" oder gebündelt mit ner DSL-Strecke?
Cheers,
jsysde
Welche Starface-Version? Appliance oder Virtual? Welche Firewall?
VF-Anschluss "standalone" oder gebündelt mit ner DSL-Strecke?
Cheers,
jsysde
Schon mal im Starface Forum versucht? Da gibt es schnelle und kompetente Hilfe.
Dort dürftest Du am ehesten auf Leidensgenossen treffen.
Dort dürftest Du am ehesten auf Leidensgenossen treffen.
Zitat von @LordGurke:
Bitte hört auf, Portforwarding für SIP zu empfehlen! Das ist eine komplett unnötige Sicherheitslücke!
Ja, leider ließt man das alzu oft. Es hält sich hartnäckig.
Hallo,
Ich will ja gerne was dazu lernen;=) Was nutzt man denn da Alternativ?
Ich kennen das nur so z.B. von unseren Agfeo Anlagen, pro angemeldeter Rufnummer werden zwei Ports für RTP-Daten genutzt die via UDP oder manchmal auch als TCP via Portforwarding auf die die Anlage gelegt werden. Für den 5060er SIP Port braucht man das nicht, hab ich aber auch nicht geschrieben. Das ist bei denen so seit es die IP Telefonie gibt. Da wird auch nix anderes erwähnt, egal ob kleine Anlage oder größeres System mit 100 Nebenstellen und mehr.
Zitat von @LordGurke:
Bitte hört auf, Portforwarding für SIP zu empfehlen! Das ist eine komplett unnötige Sicherheitslücke!
Ich will ja gerne was dazu lernen;=) Was nutzt man denn da Alternativ?
Ich kennen das nur so z.B. von unseren Agfeo Anlagen, pro angemeldeter Rufnummer werden zwei Ports für RTP-Daten genutzt die via UDP oder manchmal auch als TCP via Portforwarding auf die die Anlage gelegt werden. Für den 5060er SIP Port braucht man das nicht, hab ich aber auch nicht geschrieben. Das ist bei denen so seit es die IP Telefonie gibt. Da wird auch nix anderes erwähnt, egal ob kleine Anlage oder größeres System mit 100 Nebenstellen und mehr.
Also bei Agfeo benötigt man kein Portforwarding und sollte man auch nicht machen
Wird auch bei Schulungen immer wieder drauf hingewiesen
Wird auch bei Schulungen immer wieder drauf hingewiesen
1
Hallo,
So zu 100% wage ich das mal zu bezweifeln. Wenn der Kunde einen Router hat der mit dem im Agfeo-Netz-Wiki vom 09.01.24 beschriebenen Funktionen wie:
(" Zudem unterstützen alle unsere TK-Systeme vielfältige Mechanismen (wie z.B. VoIP-KeepAlive-Pakete etc.), um trotz einer vorgeschalteten Firewall einen stabilen VoIP-Datenaustausch zu
ermöglichen.")
nicht klar kommt, dann kommt man wohl nicht drum rum, gleiches gilt wohl auch wenn man eine Firewall hat die nicht sowieso alles erlaubt. Bei uns hier werkelt eine Lancom UF-200, ohne Freischaltung tut da gar nix mehr an der ES628.
Wir müssen ja leider meist mit den Kundenroutern leben die wir vorfinden. Und wenn es ohne Eintrag nicht stabil läuft dann tragen wir das eben ein und fertig. Reduziert auf die Ports die benötigt werden und eben auch reduziert auf UDP oder TCP. Ebenso ZU wie notwendig und nicht mehr.
Zitat von @Technikber:
Also bei Agfeo benötigt man kein Portforwarding und sollte man auch nicht machen
Wird auch bei Schulungen immer wieder drauf hingewiesen
Also bei Agfeo benötigt man kein Portforwarding und sollte man auch nicht machen
Wird auch bei Schulungen immer wieder drauf hingewiesen
So zu 100% wage ich das mal zu bezweifeln. Wenn der Kunde einen Router hat der mit dem im Agfeo-Netz-Wiki vom 09.01.24 beschriebenen Funktionen wie:
(" Zudem unterstützen alle unsere TK-Systeme vielfältige Mechanismen (wie z.B. VoIP-KeepAlive-Pakete etc.), um trotz einer vorgeschalteten Firewall einen stabilen VoIP-Datenaustausch zu
ermöglichen.")
nicht klar kommt, dann kommt man wohl nicht drum rum, gleiches gilt wohl auch wenn man eine Firewall hat die nicht sowieso alles erlaubt. Bei uns hier werkelt eine Lancom UF-200, ohne Freischaltung tut da gar nix mehr an der ES628.
Wir müssen ja leider meist mit den Kundenroutern leben die wir vorfinden. Und wenn es ohne Eintrag nicht stabil läuft dann tragen wir das eben ein und fertig. Reduziert auf die Ports die benötigt werden und eben auch reduziert auf UDP oder TCP. Ebenso ZU wie notwendig und nicht mehr.
Ein Router muss überhaupt nichts spezielles unterstützen. Für Keepalive sendet die Anlage einfach Pakete an den SIP-Server, die beantwortet der und damit wird die (NAT-)Session offengehalten. Standard-NAT, beziehungsweise Standard-Stateful Firewall. Wird für viele Dinge verwendet, nicht nur bei VoIP.
Allerdings sehe ich erstaunlich oft bei Kunden die Lancom einsetzen, dass da extrem kurze Session-Lebensdauern konfiguriert sind (ist/war vielleicht Standard) und dann brechen einige Sachen, nicht nur VoIP, auseinander weil der Router vermeintlich inaktive UDP- und TCP-Sitzungen trennt. Wenn die Anlage mit mehr zeitlichem Abstand Keepalive schickt als der Lancom die Verbindungen tötet, hilft das halt wenig.
Oder es liegt an dem für das Preissegment von Lancom erstaunlich kaputten SIP-ALG, den man ausschalten sollte, damit VoIP dahinter funktioniert. Aber der frisst dann natürlich auch die Keepalives auf.
Allerdings sehe ich erstaunlich oft bei Kunden die Lancom einsetzen, dass da extrem kurze Session-Lebensdauern konfiguriert sind (ist/war vielleicht Standard) und dann brechen einige Sachen, nicht nur VoIP, auseinander weil der Router vermeintlich inaktive UDP- und TCP-Sitzungen trennt. Wenn die Anlage mit mehr zeitlichem Abstand Keepalive schickt als der Lancom die Verbindungen tötet, hilft das halt wenig.
Oder es liegt an dem für das Preissegment von Lancom erstaunlich kaputten SIP-ALG, den man ausschalten sollte, damit VoIP dahinter funktioniert. Aber der frisst dann natürlich auch die Keepalives auf.
3
Hallo,
Die Lancoms werden in der Hinsicht bei Agfeo in Bezug auf das UDP-Aging ja auch speziell erwähnt, Vorgabe auf 120 Sekunden hochsetzten. In den Installations-HowTos die die für die Anlagen anbieten wird darauf ja auch hingewiesen, ebenso die Ports eben freizuschalten.
Hier mal zwei Stellen wo das an frei zugänglichen Dokus so beschrieben wird.
Konfigurationsbeispiel SIP-Anschluss Vodafone Trunk als PDF vom 08.03.2023
SIP Trunking & All-IP als PDF vom 11.2021
Beide zu finden wenn man das auf der Agfeo-Site googelt.
Vielleicht haben die in der Hinsicht ja eine etwas eigene Philosophie und wollen selber den Standard setzten;=)
Ich bin jedenfalls froh dass sie noch Modelle mit ISDN-Ports haben, auch wenn man das ja nur noch intern nutzen kann. Diverse Medienkonverter von anderen Anbietern sind da geradezu gruselig in der Nutzung. Agfeo hatte ja auch mal ne Connection zu Swyx. Aber die ganzen VoIP Sachen sind bei denen im Portfolio nicht vertreten auch wenn sie inzwischen sogar eine gebrandete N510 Gigaset DECT im Programm haben/hatten?
Letztlich ist es aber doch in Bezug auf Sicherheit egal on die TK-Anlage den Port aufmacht und der Router ihn offen hält, oder ob man es von Hand so einstellt, oder sehe ich das falsch? Manuell ist er dann immer offen, auch wenn die TK-Anlage eben aus ist, dann fehlt ja aber das Ziel. Und im Modus der automatisch offen gehaltenen Ports wird dieser eben geschlossen nach einiger Zeit wenn jemand die Anlage ausschaltet. Da nimmt der Router dann das Paket erst gar nicht an.
Macht es einen Unterschied ob der Router das Paket von außen nicht annimmt oder es einfach intern nicht weiterleiten kann weil das Zielgeräte offline ist?
Zitat von @LordGurke:
Ein Router muss überhaupt nichts spezielles unterstützen. Für Keepalive sendet die Anlage einfach Pakete an den SIP-Server, die beantwortet der und damit wird die (NAT-)Session offengehalten. Standard-NAT, beziehungsweise Standard-Stateful Firewall. Wird für viele Dinge verwendet, nicht nur bei VoIP.
Allerdings sehe ich erstaunlich oft bei Kunden die Lancom einsetzen, dass da extrem kurze Session-Lebensdauern konfiguriert sind (ist/war vielleicht Standard) und dann brechen einige Sachen, nicht nur VoIP, auseinander weil der Router vermeintlich inaktive UDP- und TCP-Sitzungen trennt. Wenn die Anlage mit mehr zeitlichem Abstand Keepalive schickt als der Lancom die Verbindungen tötet, hilft das halt wenig.
Die Lancoms werden in der Hinsicht bei Agfeo in Bezug auf das UDP-Aging ja auch speziell erwähnt, Vorgabe auf 120 Sekunden hochsetzten. In den Installations-HowTos die die für die Anlagen anbieten wird darauf ja auch hingewiesen, ebenso die Ports eben freizuschalten.
Hier mal zwei Stellen wo das an frei zugänglichen Dokus so beschrieben wird.
Konfigurationsbeispiel SIP-Anschluss Vodafone Trunk als PDF vom 08.03.2023
SIP Trunking & All-IP als PDF vom 11.2021
Beide zu finden wenn man das auf der Agfeo-Site googelt.
Oder es liegt an dem für das Preissegment von Lancom erstaunlich kaputten SIP-ALG, den man ausschalten sollte, damit VoIP dahinter funktioniert. Aber der frisst dann natürlich auch die Keepalives auf.
Vielleicht haben die in der Hinsicht ja eine etwas eigene Philosophie und wollen selber den Standard setzten;=)
Ich bin jedenfalls froh dass sie noch Modelle mit ISDN-Ports haben, auch wenn man das ja nur noch intern nutzen kann. Diverse Medienkonverter von anderen Anbietern sind da geradezu gruselig in der Nutzung. Agfeo hatte ja auch mal ne Connection zu Swyx. Aber die ganzen VoIP Sachen sind bei denen im Portfolio nicht vertreten auch wenn sie inzwischen sogar eine gebrandete N510 Gigaset DECT im Programm haben/hatten?
Letztlich ist es aber doch in Bezug auf Sicherheit egal on die TK-Anlage den Port aufmacht und der Router ihn offen hält, oder ob man es von Hand so einstellt, oder sehe ich das falsch? Manuell ist er dann immer offen, auch wenn die TK-Anlage eben aus ist, dann fehlt ja aber das Ziel. Und im Modus der automatisch offen gehaltenen Ports wird dieser eben geschlossen nach einiger Zeit wenn jemand die Anlage ausschaltet. Da nimmt der Router dann das Paket erst gar nicht an.
Macht es einen Unterschied ob der Router das Paket von außen nicht annimmt oder es einfach intern nicht weiterleiten kann weil das Zielgeräte offline ist?
Letztlich ist es aber doch in Bezug auf Sicherheit egal on die TK-Anlage den Port aufmacht und der Router ihn offen hält, oder ob man es von Hand so einstellt, oder sehe ich das falsch?
Ein Port, der durch die Stateful-Firewall offen ist, lässt nur Pakete durch die zu dieser Verbindung/Sitzung gehören. Also Traffic zwischen IP.A:PortX und IP.B:PortY, nichts anderes.
Ein Portforwarding lässt *alles* von überall rein — also auch die zigtausend Bots die versuchen über deine Ablage zu telefonieren.
3Zitat von @LordGurke:
Ein Port, der durch die Stateful-Firewall offen ist, lässt nur Pakete durch die zu dieser Verbindung/Sitzung gehören. Also Traffic zwischen IP.A:PortX und IP.B:PortY, nichts anderes.
Ein Portforwarding lässt *alles* von überall rein — also auch die zigtausend Bots die versuchen über deine Ablage zu telefonieren.
Letztlich ist es aber doch in Bezug auf Sicherheit egal on die TK-Anlage den Port aufmacht und der Router ihn offen hält, oder ob man es von Hand so einstellt, oder sehe ich das falsch?
Ein Port, der durch die Stateful-Firewall offen ist, lässt nur Pakete durch die zu dieser Verbindung/Sitzung gehören. Also Traffic zwischen IP.A:PortX und IP.B:PortY, nichts anderes.
Ein Portforwarding lässt *alles* von überall rein — also auch die zigtausend Bots die versuchen über deine Ablage zu telefonieren.
Kurz und knapp auf den Punkt gebracht, verstanden - Danke !
Uff - Ich hatte den Post hier ja komplett verwaisen lassen, sry...
Für die, die's interessiert:
Es war alles korrekt konfiguriert, lediglich das Transportprotokoll stand fälschlicherweise auf udp statt tcp.
Nachdem hier angepasst wurde, geht's auch eingehend.
Verstehe zwar nicht ganz, wieso mit falsch eingestelltem Transportprotokoll abgehend telefoniert werden konnte, aber egal - es funktioniert.
Besten Dank euch allen für eure Hilfe!
Für die, die's interessiert:
Es war alles korrekt konfiguriert, lediglich das Transportprotokoll stand fälschlicherweise auf udp statt tcp.
Nachdem hier angepasst wurde, geht's auch eingehend.
Verstehe zwar nicht ganz, wieso mit falsch eingestelltem Transportprotokoll abgehend telefoniert werden konnte, aber egal - es funktioniert.
Besten Dank euch allen für eure Hilfe!
Viele SIP-ALG ignorieren SIP über TCP, weil da normalerweise weniger Probleme auftreten.
