[Frage] Wozu ist Port 5060?

[sippi1]

Guten Tag.
Wozu wird bei der Fritzbox der Port 5060 nach Außen hin geöffnet?
Ist dieser nicht nur dann nötig, wenn die Fritzbox als Registrar dienen soll, man also ein SIP-Telefon daran anmelden will?

Danke
sippi

 

[HabNeFritzbox]

Damit auch gut erreichbar bist wird Port verwendet. Wie oder was dann an bzw. hinter FB verwendest ist egal.

 

[sippi1]

Diese Antwort verstehe ich nicht.

 

[HabNeFritzbox]

Wenn du in FB Rufnummern hast, und dich wer anruft, musst ja erreichbar sein.

Wenn Port dicht ist, gibt es teils Probleme.

Besser erklärt wird ganze wohl hier http://de.wikipedia.org/wiki/Session_Initiation_Protocol

 

[sippi1]

Die Fritzbox meldet sich aber als Client bei zb Sipgate an. Da wird doch niemals rückwärts direkt eine SIP Verbindung aufgebaut?

 

[PeterPawn]

Da wird doch niemals rückwärts direkt eine SIP Verbindung aufgebaut?

Anders als Du vielleicht glaubst, erfolgt die Signalisierung eingehender Anrufe nicht über irgendeine "offen gehaltene" UDP-Verbindung zum Provider. Wenn ein eingehendes Telefonat ansteht, schickt der Provider ein passendes SIP-INVITE-Paket an den Port 5060 und die öffentliche Adresse der FRITZ!Box.

Was verstehst Du denn unter "rückwärts direkt" und einer "aufgebauten SIP-Verbindung"?

 

[sippi1]

Ähm,
und woher weiß der Provider, daß sich inzwischen nicht längst meine IP geändert hat?
Und wenn das nötig wäre, würde ja auch kein sip Client im nat hinter der Fritzbox funktionieren?

 

[PeterPawn]

und woher weiß der Provider, daß sich inzwischen nicht längst meine IP geändert hat?

Das weiß er nicht und wenn sich die FRITZ!Box nach dem Wechsel der IP-Adresse nicht beim Provider mit einem SIP-REGISTER-Request erneut meldet und ihm somit die Änderung der IP-Adresse mitteilt, wirst Du auch gewiß keine Anrufe erhalten (zumindest keine VoIP-Anrufe unter Vermittlung über das SIP-Protokoll).

Die FRITZ!Box wiederholt (solange kein anderer SIP-Verkehr stattfindet) aber ihre REGISTER-Requests auch in regelmäßigen Abständen, selbst wenn sie das nach der Spezifikation des SIP-Protokolls eigentlich nicht müßte.

Ob sie dabei tatsächlich irgendein "expires"-Attribut im "Contact"-Header der Server-Antwort berücksichtigt, weiß ich nicht ... das ändert sich nach meinen Begriffen auch bei AVM von Version zu Version, da der voipd immer noch eine große Baustelle ist, auf der zwar inzwischen SIP-Trunking hinzugekommen ist, bei der aber andere "bread and butter"-Funktionen (wie z.B. eine optionale Verschlüsselung der Kommunikation) immer noch sehr rudimentär ausgeführt sind.

Und wenn das nötig wäre, würde ja auch kein sip Client im nat hinter der Fritzbox funktionieren?

Da kommt dann genau das zum Tragen, was ich - da wußte ich es ja noch nicht besser - als Vermutung Deinerseits in meiner ersten Antwort unterstellte.

Bei einem SIP-Client hinter einem NAT-Router erfolgt die Benachrichtigung seitens des Providers i.d.R. dann tatsächlich an die öffentliche IP-Adresse und den Absenderport des REGISTER-Requests. Für solche Fälle braucht es dann Optionen wie "Portweiterleitung des Routers für SIP-Verbindungen aufrecht erhalten" mit einem einstellbaren Intervall, innerhalb dessen ein weiteres Paket eine UDP-NAT-Connection "offen hält" und das Verfallen dieser "Verbindung" (UDP ist ja eigentlich verbindungslos) verhindert.

Fehlt diese Option oder paßt der dort eingestellte Zeitraum nicht zum "timeout" des Routers für UDP-NAT-Connections, dann treten immer wieder Probleme in solchen Konstellationen auf, weil der Provider eine eingehende Verbindung nicht signalisieren kann.

 

[sippi1]

Super.
Vielen dank! Ich glaube, das habe ich jetzt verstanden.
Wenn also der Registrar keine Verbindung auf port 5060 erhält, versucht er es auf dem Port von dem die Anfrage kommt?

 

[rollo]

Ich denke worauf sippi1 hinaus will ist, weshalb die FbF den UDP-Port 5060 verwendet obwohl es im reinen Clientbetrieb egal ist, welcher Quellport verwendet wird. Wichtig ist der Port nur, wenn er als Zielport verwendet wird. Im Gegensatz zu vielen anderen Anwendungen wird von vielen SIP-Clients der Standardport 5060 verwendet. Nötig wäre das allerdings nicht, da der SIP-Cleint sich mit IPort registriert.

jo

 

[sippi1]

Genau. Es hat mich verwirrt, daß die FB scheinbar einen Sip Registrar laufen hat. Dabei hat sie wohl nur einen Client, der diesen Port als Quellport benutzt.
Blöd, daß man so nicht auf Anhieb erkennt, ob (auch) ein Sip Server läuft.

 

[PeterPawn]

Es ist eine Kombination ... der voipd arbeitet bei den meisten als Client, ist aber auch in der Lage, auf dem externen Interface als Server zu agieren, wenn entsprechende SIP-Clients in der Box definiert sind.

Der feste Port als Absender führt eben auch dazu, daß die meisten SIP-Sessions mit der Box selbst "straight forward" sind und solche Sachen wie NAT/ALG/Via-Header erst einmal keine Rolle spielen, solange die FRITZ!Box selbst das externe Gateway ist und eine eigene öffentliche (oder provider-lokale) IP-Adresse für die SIP-Kommunikation verwendet.

Das geht ja sogar so weit, daß der voipd die DNS-Abfragen für SIP-Kontakte von einem definierten Absenderport aus macht und diese somit relativ leicht für den Rest des Systems (von QoS bis Routing) zu identifizieren sind. AVM behandelt nach meinem Eindruck so ziemlich alles, was mit Telefonie zusammenhängt, gesondert ... nur dadurch kriegen sie es wohl hin, bei Bedarf ein zweites logisches Interface für die Telefonie-Funktionen zu benutzen, das komplett andere IP-Adressen und ggf. auch andere DNS-Server haben kann.

EDIT:
Weil der erste Satz das nicht richtig zum Ausdruck bringt: Die Box arbeitet natürlich auch nach innen als SIP-Server (und auch da hört sie auf Port 5060), das ist - bei 06.20/7490 mal getestet - auch unabhängig von der Existenz von definierten SIP-Clients für diese Box. Von extern eingehende SIP-Pakete auf 5060 werden eigentlich auch nur über das Portforwarding an die interne IP-Adresse der FRITZ!Box weitergeleitet.

 

[sippi1]

Wie kann ich prüfen, ob die FB von außen als Sip Server läuft?

 

[koyaanisqatsi]

Moins

Durch die nach Aussen freigegebenen SIP/RTP Ports sind Fritz!Box Telefonnummern auch ohne ITSP (VoIP-Provider) erreichbar.
Genauso wie ein echtes freigegebenes IP-Telefon, oder ein Asterisk PBX direkt erreichbar ist.

Im Gegensatz zu einen Asterisk Server oder freigegebenen IP-Telefon antwortet die Fritz!Box jedoch nicht auf eine OPTIONS Anforderung...

OPTIONS sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.178.1:52932;branch=z9hG4bK.7d5f2582;rport;alias
From: sip:[email protected]:52932;tag=6b34909
To: sip:[email protected]
Call-ID: [email protected]
CSeq: 1 OPTIONS
Contact: sip:[email protected]:52932
Content-Length: 0
Max-Forwards: 70
User-Agent: sipsak 0.9.6
Accept: text/plain


send to: UDP:93.220.XXX.XXX:5060

message received:
SIP/2.0 406 Not Acceptable
Via: SIP/2.0/UDP 192.168.178.1:52932;branch=z9hG4bK.7d5f2582;rport=52932;alias;received=93.220.XXX.XXX
From: <sip:[email protected]:52932>;tag=6b34909
To: <sip:[email protected]>;tag=DFAD5FC0792761A5
Call-ID: [email protected]
CSeq: 1 OPTIONS
User-Agent: FRITZ!OS
Content-Length: 0

Direktanruf via SIP URI: <sip:[Land][Vorwahl ohne führende Null][Nummer]@deine-dyndns.org>
...zum Beispiel mit einem registrarlosen Softphone.

 

[PeterPawn]

Mit einem SIP-REGISTER-Request für ein in der FRITZ!Box definiertes "Telefoniegerät" und einem Packetdump? Auf "dev lan" sollte man die SIP-Pakete noch sehen, ansonsten auf "dev dsl" (Routingschnittstelle bei capture.lua) ...

Der Request wird wohl (meine Annahme auf Basis eigener Tests) "ordentlich" an den voipd weitergereicht und von diesem dann mit einer entsprechenden Fehlermeldung quittiert, wenn für den SIP-Client keine externe Anmeldung zugelassen ist.

 

[sippi1]

Danke für die beiden weiteren Erläuterungen.
Das macht es Einleuchtend.
PeterPawn: ich hatte gehofft, es gäbe einen einfachen Scan von Außen, ohne lokale Sniffer und Logs zu wälzen.

 

[PeterPawn]

Der Port ist m.E. immer "offen" (das heißt bei einem UDP-Port ja nur, daß da kein ICMP-Reject als Antwort kommt) und etwas anderes wird ein Portscanner i.d.R. auch nicht feststellen können. Höchstens eben ein SIP-"Sniffer" ... aber auch da ist es am Ende ja nur die Frage, ob ein REGISTER wegen falscher Credentials oder grundsätzlich abgelehnt wird. Bei einer TCP-Verbindung ist das Nichtzustandekommen des 3way-Handshakes ja ein untrügliches Zeichen, daß da keine Verbindung möglich ist, aber ein UDP-Paket ist per se erst mal eine "blinde Sendung" und Erfolg/Mißerfolg bemißt sich entweder am Ausbleiben einer Antwort oder an deren (positivem oder negativem) Inhalt.