welche Ports werden wirklich benötigt?

[niemalsaufgeben]

Erstmal ein Hallo in die Runde

Oh nein, nicht schon wieder dieses Thema...
Gibt es keine ultimative Lösung?
Ich lese schon seit Tagen hier rum und teste, logge und wundere mich, jetzt würde ich gerne ALLES aufklären
Meine Konstellation ist denkbar kompliziert. Ich habe einen Speedport W701V als DSL Modem, dann kommt ein fli4l als Ethernetrouter und dahinter soll eine Fritzbox 7270 und ein Gigaset C470IP laufen. Mein SIP Provider ist Sipgate, dort habe ich drei Leitungen.
Ausgehende Telefonate funktionieren immer von beiden Endgeräten bei den eingehenden Telefonaten kommt nicht immer alles an. Das Problem mit der wechselnden IP Ist mir bekannt, allerdings gehen auch manchmal Telefonate unter Tag verloren ohne dass sich die IP geändert hat. Zumindest nach dem ersten rausgehenden Gespräch sollten eingehende ja wissen zu welcher IP sie müssen.
Da liest man jetzt einiges von Ports freischalten, sollte helfen, muss aber nicht, manchmal besser mit STUN Server, manchmal auch nicht...
Ich habe mal meine aktiven Verbindungen im fli überprüft: Die Fritzbox hat immer einen Port 5060 auf stun1.sipgate.de Port 3478 und einen Port 5060 auch sipgate.de Port 5060 verbunden. Das Gigaset zeigt mir nur einen Port 5060 auf sipgate Port 5060 an. Der STUN wird nur angezeigt wenn man ihn in der Konfiguration ändert, dann wird er kurz verbunden, verschwindet dann aber wieder.
Meine Frage ist jetzt, muss ich Ports forwarden wenn ich den STUN eingerichtet habe? Wer initiiert bei einem ankommenden Gespräch die RTP Ports? wenn ich richtig recherchiert habe wird über die 5060er Ports ein Gespräch angekündigt und dementsprechend mit einem ACK bestätigt.
Bei SIpgate konnte ich lesen dass man an jeden Endteilnehmer jeweils einen SIP und einen RTP Port weiterleiten soll. In der Fritzbox konnte ich jedoch nirgends etwas über Ports finden.
Wie wählt die Fritzbox und das Gigaset die Ports??
Kann das der STUN Server feststellen wenn ich an die Fritzbox 5061 und 5062 weiterleite und an das Gigaset 5063???

Ich hab so langsam den Faden verloren...

Gruß und Niemalsaufgeben ;-)

 

[niemalsaufgeben]

Ok, also die Fritzbox geht auf STUN Sevrer Port 3478 weil das in der voip.cfg so steht. Der Port scheint ja zu funktionieren wenn es eine Verbindung gibt.
Ich habe jetzt erstmal das Gigaset auf SIP Port 5062 und RTP Port 5020-5030 gelegt. Da ich in der voip.cfg nichts ändern wollte habe ich da mal die Standardports gelassen.
Portforwarding ist folgendes:
5000-5018 und 5060 auf Fritzbox
5020-5030 und 5062 auf Gigaset
Mal sehen ob das im Langzeittest so klappt.
Was sagt denn die ttl Zeit im voip.cfg aus? Ist das die Zeit bis zur Neuregistrierung oder wird nach dieser Zeit nur die Verbindung überprüft?

 

[frank_m24]

Hallo,

die Gigaset Ports kenne ich nicht, aber die Fritzbox benötigt 5060 UDP für SIP und 7077 - 7087 UDP für RTP.
Der TTL Wert ist der Wert, denn die Box bei der SIP Anmeldung für das Überprüfungsintervall vorschlägt. Der VoIP Provider muss das aber nicht akzeptieren und kann den Wert überschreiben. UI z.B. setzt den auf 8 Stunden.

 

[niemalsaufgeben]

Hallo Frank

Danke für die Antwort. Bei dem Gigaset kann man die Ports frei einstellen. Das finde ich sehr gut.
Ich hab die Portforwardings mal auf die 7077-7087 eingestellt.
Ich frage mich jedoch ob die temporäre Erreichbarkeit überhaupt mit den Portforwardings der RTP Ports zusammenhängen kann. Diese Ports sind doch nur für den Transport der Gesprächsdaten verantwortlich.
Sollte das Problem nicht eher an den Sip Ports liegen? Ich hab sie jetzt ja auch geforwardet, mal sehen ob alle Probleme damit behoben sind...

Grüße Christian

 

[frank_m24]

Hallo,

Ich frage mich jedoch ob die temporäre Erreichbarkeit überhaupt mit den Portforwardings der RTP Ports zusammenhängen kann. Diese Ports sind doch nur für den Transport der Gesprächsdaten verantwortlich.
Sollte das Problem nicht eher an den Sip Ports liegen?

Genau so ist es. Besonders wichtig ist in dem Zusammenhang der STUN Server.

Siehe auch: Howto: Mein Telefon klingelt nicht bei ankommenden Anrufen? Kapitel Sonderfall VoIP Telefonie: Betrieb einer Box als WDS Client oder im Betrieb "Internet über LAN".

 

[niemalsaufgeben]

Siehe auch: Howto: Mein Telefon klingelt nicht bei ankommenden Anrufen? Kapitel Sonderfall VoIP Telefonie: Betrieb einer Box als WDS Client oder im Betrieb "Internet über LAN".

Da hab ich schon ne ganze Weile gelesen, allerdings stellen sich mir doch noch zwei Fragen:
Macht eine ttl Zeit von 30 min nicht die Diskussion um VOIP-Accounts einer Fritz als IP-Client nach IP-Wechsel registrieren überflüssig? Nach spätestens 30 min sollte dann die Box nach einem Wechsel der externen IP doch wieder Anschluss finden?
EDIT: Ach ja, und durch die Einstellung "Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten" sollte doch auch sofort eine neue Verbindung mit der neuen externen IP Adresse aufgebaut werden...??

Und wie kommt es zu einer temporären Nichtereichbarkeit wenn doch durch den STUN Server die Verbindung über den SIP Port besteht auch ohne POrtforwarding? Das kann doch eigtentlich nur passieren wenn die SIP Verbindung über 5060 nicht einwandfrei ist. Wann baut eigentlich die Fritzbox die RTP Kanäle auf und wann werden sie vom Server initiiert?

Grüße Christian

 

[frank_m24]

Hallo,

Macht eine ttl Zeit von 30 min nicht die Diskussion um VOIP-Accounts einer Fritz als IP-Client nach IP-Wechsel registrieren überflüssig? Nach spätestens 30 min sollte dann die Box nach einem Wechsel der externen IP doch wieder Anschluss finden?

Nein. Dieser TTL Wert wird von der Fritzbox bei der Anmeldung vorgeschlagen. Allerdings muss der SIP Server ihn nicht akzeptieren. Bei 1&1 z.B. wird die ttl auf 8 Stunden gesetzt - unabhängig von der Einstellung in der Fritzbox.

EDIT: Ach ja, und durch die Einstellung "Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten" sollte doch auch sofort eine neue Verbindung mit der neuen externen IP Adresse aufgebaut werden...??

Wieder nein. Diese Option sendet nur ein UDP Paket ohne Inhalt aus - nur, damit die NAT Table nicht veraltet. Es wird keine Neu-Registrierung vorgenommen. Ändert sich also die öffentliche IP - z.B. durch die Zwangstrennung - so kommt am SIP-Server einfach nur ein leeres Paket von einer unbekannten IP an. Aber auch sonst macht der Server nichts mit diesem Paket, da es schlicht keinen sinnvollen Inhalt hat.

Und wie kommt es zu einer temporären Nichtereichbarkeit wenn doch durch den STUN Server die Verbindung über den SIP Port besteht auch ohne POrtforwarding?

Über STUN besteht keine dauerhafte Verbindung. STUN wird nur beim Verbindungsaufbau verwendet, um die öffentliche IP und ggf. Portnummern zu identifizieren. Dann ist STUN aus dem Rennen und die Box kann die Informationen verwenden, um sich am SIP Server zu registrieren.

Wann baut eigentlich die Fritzbox die RTP Kanäle auf und wann werden sie vom Server initiiert?

Es gibt in dem Sinne keinen Server und keinen Client. Die RTP Verbindung wird ja nur zwischen beiden VoIP Teilnehmern direkt aufgebaut, von daher ist die Rollenverteilung unklar. Der SIP Server hat jedenfalls mit RTP nichts zu tun. Der sorgt nur dafür, dass beide VoIP Endgeräte die Adressen, Ports und Einstellungen des jeweiligen Gesprächspartners aushandeln können. Diese beiden bauen dann mit diesen Informationen die beiden erforderlichen RTP Verbindungen auf - für jede Sprachrichtung eine. Dabei ist es so, dass jeder einmal Server und einmal Client ist.

 

[marcus1907]

Hallo!

Ich bin auch ein wenig irritiert, ich betreibe eine FritzBox Fon 5050 hinter einem Router mit Sipgate und habe überhaupt keine Ports weitergeleitet, die Funktion "Portweiterleitung des Internet-Routers für Internettelefonie aktiv halten" ist aus.
Ich habe das ganze an 2 verschiedenen Router (Fli4l und Bafallo-Router) getestet, die jeweils eine PPPOE-Verbindung zu T-Online aufbauen und somit den Zugang zum Internet ermöglichen die Funktion UPnP ist abgeschaltet.
Ich kann ganz normal telefonieren, es kommen eingehende Anrufe rein und natürlich geht auch raustelefonieren.

Hier mal ein Log aus den Bafallo für die Sip-Verbindung:

11-21-2008	15:09:44	User.Warning	192.168.5.1	Nov 21 15:09:39 kernel: ACCEPT IN=br0 OUT=ppp0 SRC=192.168.5.10 DST=217.10.67.6 LEN=80 TOS=0x00 PREC=0x00 TTL=63 ID=32746 PROTO=UDP SPT=7079 DPT=14569 LEN=60
11-21-2008	15:09:42	User.Warning	192.168.5.1	Nov 21 15:09:37 kernel: ACCEPT IN=br0 OUT=ppp0 SRC=192.168.5.10 DST=217.10.67.6 LEN=280 TOS=0x00 PREC=0x00 TTL=63 ID=32664 PROTO=UDP SPT=7078 DPT=14568 LEN=260
11-21-2008	15:08:06	User.Warning	192.168.5.1	Nov 21 15:08:01 kernel: ACCEPT IN=br0 OUT=ppp0 SRC=192.168.5.10 DST=217.10.79.9 LEN=774 TOS=0x00 PREC=0x00 TTL=63 ID=24007 PROTO=UDP SPT=5060 DPT=5060 LEN=754

Weiß jemand, ob Sipgate an Ihren Servern was verändert haben, dass es eben jetzt möglich ist hinter einem Router ohne Portforwarding zu telefonieren?
Vor einiger Zeit konnte ich ohne Portweiterleitung nicht telefonieren, die Anrufe worden nicht signalisiert.


marcus1907

 

[niemalsaufgeben]

Hallo Marcus

So war das bei mir auch, allerdings lief das nicht von Dauer so gut. Zwischendurch gab es immer wieder Anrufe die nicht durchgestellt wurden.
Nun hab ich eben die SIP Ports 5060 und 5062 und die RTP Ports jeweils weitergeleitet und es scheint besser zu gehen. Ich schätze mal das ein Weiterleiten nicht immer zwischen geht und geht nicht unterscheiden muss, sondern dass es auch oftmals die Zuverlässigkeit verbessert.
Der Härtetest kommt erst in den nächsten Wochen, dann müssen alle drei Nummern zuverlässig gehen. Ich beobachte mal die Log so long...
In deinem Fall steht da ja aber auch was von wegen "ACCEPT IN", das heißt ja dass die Port nicht geblockt werden?!
Teste mal morgens nach der Zwangstrennung mit einem eingehenden Gespräch, bevor du mit Voip raustelefoniert hast. Die Ports werden im Router ja auch immer eine Weile gehalten. Bei mir wird dauerhaft eine Verbindung zum STUN Server angezeigt, obwohl die wohl schon nicht mehr aktiv ist. Ich denke mal dass der Router diese bei einem erneutem Verbindungsaufbau dann auch wieder zulässt, auch ohne Portforwarding.

PS: Nochmal danke für die ausführliche Erklärung an Frank. Ich beobachte, hoffentlich bleibt es so und wird dann auch zuverlässig!

Christian