RTP Problem zu SIP Provider

[patricio]

Hallo,

Ich kann von extern (Handy) über SIPGATE auf ein internes Softphone rufen (X-Lite). Die Signalisierung funktioniert. Nachdem ich jedoch den Call entgegen nehme, sehe ich zwar dass die Verbindung steht, jedoch habe ich keine Verständigung. Nun scheint es mir, dass der RTP Stream nicht richt funktioniert. Ich vermute, dass es sich um ein NAT Problem oder Port Problem handelt. Genau kann ich es jedoch nicht sagen. Kann mir einer sagen, wie ich herausfinde woran es scheitert ?

thx
patricio

 

[magic911]

Was für einen Router hast du denn im Einsatz? Hast du auf dem Xlite Stun aktiviert ?

In welche Richtung geht denn das Audio nicht (nur eine oder beide) ?

Hast du mal von einem Festnetztelefon angerufen ? Geht dann alles ?

Gruß Magic911

 

[patricio]

Hallo,

Mein Aufbau sieht folgendermaßen aus:

Asterisk auf Vmware Debian -> Softphone Xlite
Ob über Firmen-Access wo alle RTP Ports offen sind oder zu Hause mit DSL ->
ich habe zu Festnetz oder Handy keine Verständigung in beide Richtungen. Signalisierung funktioniert jedoch !

 

[gandalf94305]

Dies dürfte ein Fall von STUN sein... bzw. von STUN nicht zu benutzen, je nach Art des NAT in den Fällen. Ist in der Firma das Netzwerk direkt geroutet oder auch per NAT angeschlossen? Im ersten Fall wäre der Firewall zu prüfen, ob er UDP korrekt durchläßt.

--gandalf.

 

[patricio]

In der Firma wird natürlich auch NAT genutzt. UDP Ports sollten trotzdem alle offen sein, denn ein Call über Skype funktioniert ja auch. Welche Einstellungen müssen für STUN gemacht werden ? Hab die Bedeutung noch nicht ganz herausen !

 

[gandalf94305]

Natürlich ist gar nichts... in der Firma, in der ich arbeite, wird kein NAT genutzt...

Für NAT ist ggf. STUN erforderlich, damit ein Client seine externe IP-Adresse und ein Portmapping erfahren kann. Zu STUN findest Du eine Erläuterung z.B. in der Wikipedia: http://de.wikipedia.org/wiki/STUN

UDP-Ports sind auch nicht "offen", sie sind höchstens nicht geblockt, denn die Zuordnung erfolgt ja dynamisch und erst bei Anfrage. Merkt sich der NAT-Router ausgehende UDP-Datenpakete, dann läßt er ggf. die Antworten automatisch wieder rein (für RTP erforderlich). Tut er dies nicht, benötigt man Portweiterleitungen (statisch für ein System oder dynamisch per Triggerport).

--gandalf.

 

[patricio]

Ok, wenn ich recht verstanden habe sollte STUN die funktionalität der Einträge Localnet und ExternIP ersetzten (automatisierung)

Ich weiß jedoch die fixe externe IP Adresse unserer Fimra - die ändert sich auch nicht - somit sollte die Funktion keine Rolle spielen , oder ?

 

[gandalf94305]

Nun, das kommt auf den Router zum Internet an...

Mal ein konkretes Beispiel:

SIP läuft per TCP von 5060/tcp des lokalen Systems an 5060/tcp des VoIP-Provider-Servers. NAT macht daraus z.B. 17228/tcp des öffentlichen Interfaces des Internet-Routers und merkt sich diese Abbildung für eine gewisse Zeit. Pakete, die über die gleiche TCP-Verbindung zurückkommen, werden korrekt von 17228/tcp am Router auf 5060/tcp an Deinem lokalen System weitergeleitet.

Will nun jemand zurückverbinden und einen eingehenden Ruf signalisieren, so erfordert dies etwas mehr. Entweder der Router kennt SIP und weiss damit, daß eingehende Verbindungen auf 17228/tcp an das entsprechende lokale System weiterzuleiten sind.

Kann das der Router nicht (einfach weiterleiten darf er nicht, da sonst jede ausgehende Verbindung auch zugleich eine eingehende erlauben würde, was ein enormes Sicherheitsrisiko wäre), so muss eine Portweiterleitung eingerichtet werden. Dazu muss jedoch bei der SIP-Registrierung schon dafür gesorgt werden, daß der richtige Zielport angegeben wird - beispielsweise 5060/tcp am Router. Damit dies funktioniert, muss man die Art des NAT testen und nicht nur die externe IP-Adresse, sondern auch die Art des Portmapping herausfinden.

Kommt nun irgendwie eine Handvoll SIP-Pakete für ein eingehendes Gespräch zu Deinem lokalen System durch, so ist die nächste Frage, wie die RTP-Pakete für die Sprachdaten es schaffen, zu Dir zu kommen.

Kennt der Router SIP/RTP, so wird er bei eingehenden SIP-Paketen und internen Antworten auch den entsprechenden Bereich für RTP freischalten. Kennt er dies nicht, so kann man beispielsweise RTP auf einen festen internen Zielport legen und dann per Portweiterleitung oder Porttrigger (eine Weiterleitung, die nur dann erfolgt, wenn zuvor auf einem anderen Port abgehender Verkehr erfolgte) dafür sorgen, daß die Sprachdaten den Weg ins lokale Netz finden.

Es gibt Router, die es einem sehr schwer machen, SIP von beliebigen Endgeräten im LAN zu betreiben (Cisco gehört dazu). Konfigurierbar ist jedoch viel...

Als Endanwender muss man daher leider mit Optionen für Outgoing Proxy und STUN etwas experimentieren, wenn man keine Gewalt über den Router hat.

--gandalf.

 

[patricio]

Danke dir für die ausführliche Information. Für mich bedeutet des, dass ich mich mit STUN ausseinandersetzten muss. Ich werde meine Versuche nun dahingehend führen.

 

[patricio]

Hmmm - bis dato noch keine positiven Ergebnisse. Wie funktioniert das dann mit Skype. Da werden wohl auch RTP Pakete verwendet. Skype funktioniert bei mir ....

 

[patricio]

Hat keiner irgendwelche neuen Informationen ? NAT Problem eventuell ? Wie kann ich das Debuggen wo das Problem liegt, dass cih zwar Signalisiere jedoch keine Kommunikation habe !

 

[fsiggi]

Schau mal in die rtp.conf und stelle sicher, dass die dort eingetragenen Ports auch durch die Firewall kommen.

In der sip.conf sollte nat=yes gesetzt sein.

Dann klappt es auch mit nat und ohne STUN.

 

[patricio]

Hallo, Danke an alle, es war eindeutig ein Firewall Problem.

 

[Timmbo]

Hi,

und was haste gemacht das es jetzt geht?

Grüße
Timm

 

[patricio]

Habe die Ports auf der Firewall dynamisch freigegeben -> RTP (UDP)