[Problem] Nach Umsytellung auf VOIP kommt Sprache von der Gegenstelle nicht an

[testfix4711]

Hallo,
nun hat es mich auch erwischt. Zwecks schnelleren Internets musste ich meinen ISDN-Anschluss aufgeben und auf VDSL / VOIP umstellen.
Dies ist Gestern einigermaßen problemlos von Statten gegangen. Nur muss ich leider feststellen, dass der Support von Vodafone sich nicht mit den VOIP-Parametern auskennt, sobald man keine Easy-Box verwendet.

Zu meiner Struktur:
Ich verwende als Internet-Router einen Bintec RS353JV im Vectoring Modus in Verbindung mit einem VDSL-100 Zugang. Funktioniert soweit auch ohne Probleme.
Aus den ISDN-Zeiten habe ich eine Elmeg ICT46, die ich jetzt mit einem VOIP VPN-Modul plus 4-Kanal DSP für die Telefonie ergänzt habe. Sie hängt ganz normal im LAN und lässt sich erreichen und Konfigurieren.

Alle internen Teilnehmer sind auf die "neuen" VOIP-Nummern umgestellt. Wenn Anrufe von außen kommen klappt das auch, die entsprechenden Telefone klingeln und die Verbindung kommt zustande. Von Innen nach Außen wählen geht ebenso.

ABER, nun zum eigentlichen Problem:
Es hapert mit der Sprachverbindung. Sie wird ohne Probleme aus dem LAN rausgeleitet, es ist alles gut zu hören. Unabhängig davon, ob ich anrufe oder angerufen werde kommt von Außen nichts rein, der Hörer im internen Telefon ist Tod. Ich vermute, dass der Router die eigehende Sprache abweist, kann allerdings keine Einstellung finden, mit der das klappt.
Ich habe schon mit der Funktion "VOIP PBX im LAN" herumprobiert, allerdings hat das nicht wirklich etwas gebracht. Im NAT wurden zwei ausgehende Regeln für das VOIP-Modul erstellt für full-cone. Allerdings keine eingehende Regel

Vielleicht kann mir hier jemand weiterhelfen, so langsam weiß ich mit meinem Latein nicht weiter?

Christian

 

[thtomate12]

Kannst du in der ICT STUN eintragen?

Eigentlich unsichtbarer Text: Ob eine be.ip hier hilft?

 

[testfix4711]

Hi,
STUN lässt sich am SIP-Provider hinterlegen, aber laut Aussage der Hotline wird STUN nicht angeboten.

 

[KunterBunter]

STUN funktioniert unabhängig davon, ob es laut Aussage der Hotline angeboten wird oder nicht. Auch wenn du deren eigenen STUN-Server stun.vodafone.de nicht verwenden willst, kannst du jeden beliebigen anderen verfügbaren eintragen, z.B. stun.sipgate.net, stun.1und1.de oder stun.o2.de.

 

[Andre]

Das Session Initiation Protocol handelt nur die Verbindung aus, die Sprachpakete werden direkt von den Endgeräten über das Real-Time Transport Protocol befördert.
Dein "Endgerät", das Elmeg VoIP-Modul, registriert sich mit SIP beim Provider. Da die Registrierungsanfrage vom LAN ins WAN geht, weis der Router, an welche interne IP die Antworten (insbesondere eingehende Anrufe) gemeldet werden sollen. Damit der Router das nicht vergisst, wird die Registrierung in kurzen Intervallen wiederholt.

Das Endgerät handelt über SIP aus, welche Ports für den Audiotransport im RTP verwendet werden sollen. Das ist allerdings nur eine Anfrage nach dem Motto "sende mir bitte die Audiodaten an Port xy" zwischen den Endpunkten (bzw VoIP-Provider und deiner Elmeg). Nach Aufbau der Verbindung streamen beide Enden der Verbindung ihre Audiodaten dann an die IP (externe) an den ausgehandelten Port.

Von innen nach außen ist das kein Problem, der Provider hat eine echte IP und verwendet die Audiodaten (z.B. um sie an einen anderen Nutzer oder ins normale Telephonnetz zu übergeben). Die andere Seite hört einen also.
Der ankommende Audiodatenstrom wird aber an die externe IP und damit an Deinen Router gestreamt. Da kommen also Daten, die er selber nicht angefordert hat und von denen er nicht weis, was er damit machen soll. Ergo verwirft er sie, du hörst den Gegenüber also nicht.

Soweit vereinfacht das Problem.

Wenn die Elmeg - wie ich vermute - das einzige VoIP-Gerät ist, das direkt nach draußen Verbindung aufnimmt, ist eine Lösung, dem Router zu sagen, dass er alle RTP-Pakete, welche als User Datagramm (UDP) auf den von der Elmeg augehandelten Ports reinkommen, doch bitte an die interne IP der Elmeg weitergeben möge. So gehts bei mir jedenfalls mit pfsense al Roter und Asterisk als Telephonanlage.
Man muss also zunächst rausfinden, welche Ports das Elmeg-VoIP-Modul für das RTP verwendet. Eine exakte Angabe habe ich nicht gefunden, nur ein Beispiel, wo als Startport 10000 eingetragen war. Könnte also das sein, was Du brauchst, eventuell ist im Setup des VoIP-Moduls eine Angabe zu finden oder eine Einstellung zu machen. 10000 ist z.B. auch der Standard bei Asterisk (in der Beispieldatei der rtp.conf), also ein Wert, der plausibel klingt..

Da jeder Audiokanal einen RTP-Stream braucht, werden je Gespräch 2 Ports benötigt, bei 8 möglichen gleichzeitigen externen Gesprächen also 16 Ports. Die Elmeg würde also die Portrange 10000-10015 benötigen.

Im Router stellt man ein, dass UDP 10000-10015 an die lokale IP der Elmeg zugestellt werden sollen. Schon sollte eingehd auch der Ton zu hören sein.

Ist die Elmeg nicht das einzige VoIP-Gerät, das direkte Verbindung nach außen aufbaut, gibt man den Geräten entweder unterschiedliche Portranges (und stellt ein Portforwarding im Router ein) oder verwendet STUN oder VPN.

STUN ist von der Funktion ziemlich komplex, bei Interesse lies den guten Wikipediaeintrag. Extrem vereinfacht wird in deinem Fall wohl veranlasst, dass der benötigte eingehende Port durch eine Anfrage von innen nach außen für eingehende Antworten von außen nach innen geöffnet wird. Dies funktioniert normalerweise, nicht immer aber bei echten Firewalls im Router.

VPN geht nur, wenn der VoIP-Anbieter dies unterstützt. Da wird eine eigene verschlüsselte Verbindung von der Telephonanlage zum Provider aufgebaut. Dabei erhält die Telephonanlage eine zusätzliche interne IP des VoIP-Anbieters. Aus Sicht des Routers ist es eine von innen nach außen gehende Verbindung auf einem Port, so dass alles, was vom Provider kommt, eine eindeutig zuzuordnende Antwort ist. Mit den Protokollen auf dieser Verbindung hat der Router nichts zu tun und muss nichts übersetzen. Also funktioniert diese Verbindung, als gäbe es keinen Rozer mit Netzwerkaddressübersetung (NAT)-
Leider wird das nur von wenigen Providern unterstützt.


Probier am Besten, ob ein Portforwarding der UDP Ports 10000-10015 auf die interne IP der Elmeg das Problem löst.

 

[testfix4711]

Hallo,
das klingt ziemlich genau nach meinem Problem.
Die ICT ist tatsächlich das einzige VOIP-Gerät, sollten später noch reine IP-Telefone ergänzt werden integriere ich die dort.
Im VOIP-Modul ist bei mir auch ein Startport mit 10000 gesetzt, ich werde heute Abend mal das Portforwarding so hinterlegen und schauen, ob es mich weiterbringt.
Ich werde berichten...

 

[testfix4711]

Hallo,
weder STUN noch das Portforwarding bringen etwas.
Ich habe sogar im NAT alle Anfragen vom SIP-Registrar direkt auf die ICT durchgeroutet, aber immer noch ohne Erfolg.
Im Log vom Router kann ich keine eingehenden RTP-Anfragen erkennen, es kommt nur eine Meldung bei Port 5060 "SSRC check Failed". Was könnte das bedeuten?
Im Control Center der ICT kann ich erkennen, dass alle SIP-Provider online sind und der Anruf eingeht, ein Codec wird ebenfalls ausgehandelt alaw (8). Allerdings kann ich den Partner außerhalb nicht hören

 

[KunterBunter]

es kommt nur eine Meldung bei Port 5060 "SSRC check Failed". Was könnte das bedeuten?

Das könnte bedeuten, dass aus irgendeinem unerfindlichen Grund SRTP benutzt wird, aber der Synchronization Source (SSRC) Identifier scheint nicht übereinzustimmen.

 

[Pololu]

In meiner Fritzbox werden folgende Ports für Telefonie offengehalten:

5060 UDP, TCP, IPv4 Telefonie (SIP) Bearbeiten
7078-7109 UDP, IPv4 Telefonie (RTP)

 

[testfix4711]

Sooo,
ich kann endlich Vollzug melden. Ich habe das Problem gefunden und beseitigt.
In dem Moment, als ich alles abschalten wollte und eine Fritzbox aus dem Karton holte, ging es schlagartig.
Spaß beiseite, das Problem lag nicht beim Protokoll oder Portforwarding, sondern anscheinend in den Einstellungen der SIP-Profile. Nachdem ich komplett zurückgesetzt habe und alle SIP-Profile auf Bündel gelegt habe und die Anzahl an Verbindungen auf unendlich gestellt habe erzeugte das VOIP-Modul auf einmal ein zusätzliches Bindung im SIP auf der eigenen IP. Jetzt kann ich in beide Richtungen ohne Probleme telefonieren.
Im NAT ist das Forwarding sogar komplett abgeschaltet, sprich die Firewall ist wieder schön dicht.
Vielen Dank für die viele Unterstützung!