Asterisk SIP Inbound RTP Probleme

[chronoton]

Hallo allerseits,

nach stundenlangem suchen in der Doku, den foren hier, voip-info und sonstigen ressourcen komme ich nicht mehr weiter.

Ich möchte im Zuge von ENUM daß andere SIP User oder Menschen hinter einer SIP/IAX(+ENUM) fähigen TK meine Anlage (Asterisk 1.2.9.1) anrufen können. Das sollte auch ohne VSP funktionieren, indem man seinem Gerät einfach als "rufnummer" die [email protected]
angibt. Das gleiche gilt meines Verständnisses ja auch für die ENUM Funktionalität, nur daß ich im entsprechenden record definieren kann, welche inbound route für welche gemappte Nummer gewählt werden soll.

So weit so gut. Das funktioniert soweit auch. Asterisk sieht den inbound call und gibt ihn auch an die entsprechende inbound route weiter und das Telefon klingelt.

Doch das wars dann auch. Sobald ich den Anruf annehme, hören beide nichts voneinander. Nach allem was ich bisher zu dem Thema gelesen habe, lässt das auf NAT Problematik schliessen.

Die Asterisk steht in einer DMZ mit 192.168.1.x Adresse, die Ports 5060 UDP, 10000-30000 UDP werden direkt per port-forwarding auf die * gemappt und entsprechende Firewall-Rules sind auch vorhanden. Es zerschellen keine Pakete an der Firewall (m0n0wall ). Die Ports 10000 - 30000 stehen auch in der rtp.conf.

Ein Kollege ebenfalls hinter seiner Firewall und NAT versucht nun anzurufen und nichts geht (kein Audio in BEIDE Richtungen). Calls über sipgate / gossiptel funktionieren aber sowohl von mir ausgehend als auch zu mir eingehend.

Wo muss ich anfangen zu suchen ? Liegt das Problem evtl. auf Seite meines Kollegen oder bei mir oder ist es eine Kombi aus beidem ? Was kann ich tun um meine Konfiguration so aufzubauen, damit ich möglichst viele Probleme auf meiner Seite handhaben kann, um anderen Leute ( auch welche hinter NAT ) zu ermöglichen, mich direkt per SIP zu erreichen ?

Ich hoffe jemand hat schon mal eine Vermutung in welche Richtung das geht,bevor ich hier alle config dateien oder logs poste.

Vielen Dank für jeden Hinweis schon mal im Voraus.

 

[Thomas007]

Wenn Portforward für UDP/5060 und die in der rtp.conf definierten Ports funktioniert könnte nur noch externip und localnet in der sip.conf fehlen.
Alles andere ist dann nicht Dein Problem.
Die Portrange rtp.conf ist etwas großzügig. Du brauchst einen Port für ein Gespräch. 100 Ports würden wohl auch reichen.

Die Audio-Probleme treten normalerweise auch nicht auf wenn sich A und B direkt verbinden.
Probleme gibt es regelmäßig wenn B einen C beauftragt Audio zu A zu machen. Die Audio Pakete von C prallen am NAT von A ab, wenn A nicht Portforwarding für die Audio-Ports macht.

 

[isenberg]

Ein Kollege ebenfalls hinter seiner Firewall und NAT versucht nun anzurufen und nichts geht (kein Audio in BEIDE Richtungen).

Wenn er ein SIP-Client verwendet, der STUN unterstüzt, sollte er mal zum Testen einen STUN-Server eintragen, bspw. "stunserver.org".

 

[chronoton]

Wenn Portforward für UDP/5060 und die in der rtp.conf definierten Ports funktioniert könnte nur noch externip und localnet in der sip.conf fehlen.

Hallo Thomas,

danke für die schnelle Antwort. Gleich zum Thema externip :

Das Problem ist, ich habe für den VOIP Traffic eine ADSL Leitung mit Flatrate, da ich den Traffic ungerne über meine volumenbasierte SDSL Leitung jagen möchte. Nur hab ich auf der ADSL halt auch eine dynamische IP Adresse.

Und in einem anderen Thread hast Du jemanden "angemacht" er sollte doch bitte die doku lesen, weil er externhost statt externip verwendet hat Dieser hat daraufhin auf voip-info verwiesen, wo die option externhost als valide option aufgeführt wird. Was ist denn nun richtig ? Ich habe gestern testweise meine aktuelle IP in die externip eingetragen und externhost auskommentiert, was aber auch keine positive wirkung gezeigt hat. Localnet fehlt - könnte das so eine auswirkung haben ? das werde ich gleich noch testen.

Alles andere ist dann nicht Dein Problem.

Na doch, wenn ich jemandem den Service bieten möchte mich per VOIP zu erreichen, möchte ich zumindest meine Infrastruktur zumindest so "optimieren" das mit weniger Problemen für andere zu rechnen ist. Natürlich bekomme ich keine 100% hin, denn ich habe keinen Einfluss auf die Infrastruktur anderer und deren evtl verpruutschter Systeme.

Die Portrange rtp.conf ist etwas großzügig. Du brauchst einen Port für ein Gespräch. 100 Ports würden wohl auch reichen.

Ganz Deiner Meinung. Ursprünglich hatte ich auch in der rtp.conf sowie im portforwarding nur 10000-10010 angegeben, aber der Kollege ging laut tcpdump seiner seite aus bei 30000 raus, weshalb ich zum test mal den range erweitert habe.

Die Audio-Probleme treten normalerweise auch nicht auf wenn sich A und B direkt verbinden.
Probleme gibt es regelmäßig wenn B einen C beauftragt Audio zu A zu machen. Die Audio Pakete von C prallen am NAT von A ab, wenn A nicht Portforwarding für die Audio-Ports macht.

äh, dem abstrakt kann ich nicht folgen. in meiner analogie gibts im moment nur A und B. Wer ist jetzt hier was ?

 

[Thomas007]

Ich habe gestern testweise meine aktuelle IP in die externip eingetragen und externhost auskommentiert, was aber auch keine positive wirkung gezeigt hat. Localnet fehlt - könnte das so eine auswirkung haben ? das werde ich gleich noch testen.

In der sip.conf steht groß und breit externhost nicht für production.
externip und localnet funktioniert mit der Einschränkung dass Asterisk nur beim Start oder reload den Namen zur Adresse auflöst. Hat man eine dynamische IP muss man ein Script benutzen um bei IP Änderung ein reload zu veranlassen

externhost funktioniert anders und soll wohl dieses Manko ausgleichen. Ich benutze es allerdings nicht und kann daher nicht sagen ob es wie gewünscht funktioniert.
Solange man Probleme hat sollte man die Sachen benutzen die funktionieren.

localnet solltest Du anpassen, kann aber hier nicht Ursache für die Problem sein.

PS: NAT= yes sollte natürlich auch noch in der sip.conf in den globals stehen.

Ganz Deiner Meinung. Ursprünglich hatte ich auch in der rtp.conf sowie im portforwarding nur 10000-10010 angegeben, aber der Kollege ging laut tcpdump seiner seite aus bei 30000 raus, weshalb ich zum test mal den range erweitert habe.

Der source port Deines Kollegen ist egal, der kann ruhig 30000 sein. Wichtig ist das der dstn port bei den Paketen zu Dir stimmt.

 

[stefanwillmerot]

Ich hab bei mir noch ein anderes Problem gehabt: Asterisk machte eine "native bridge" zwischen den ein/ausgehenden SIP-Kanälen und den internen Telefonen. Das bedeutet wohl, dass der RTP-Datenstrom direkt zwischen der externen IP und dem internen Telefon fliessen soll, was hier aufgrund Firewall-Regeln aber unmöglich ist. Also war Stille in der Leitung.
Die Lösung war, die internen Telefone mit den Dial-Optionen t und w zu rufen - das zwingt Asterisk, den Datenstrom durchzuleiten. Bei ausgehenden Rufen an SIP verwende ich die Optionen Wr.

Grüße
Stefan

 

[Thomas007]

Ein NAT=yes verhindert das automatisch. Ich hatte es in meinem zweiten Beitrag noch nachgetragen.
Ansonsten canreinvite= no falls mal kein NAT und ein reinvite unterwünscht ist.

 

[chronoton]

so - hier ist jetzt mal der aktuelle auszug :

[general]

port = 5060                            
bindaddr = 0.0.0.0
localnet = x.y.z.0/255.255.255.0
localnet = a.b.c.0/255.255.255.0
externip = 82.83.84.85
;externhost = voip.domain.org
nat=yes

disallow=all
allow=ulaw
allow=alaw
language=de

; If you need to answer unauthenticated calls, you should change this
; next line to 'from-trunk', rather than 'from-sip-external'.
; You'll know this is happening if when you call in you get a message
; saying "The number you have dialed is not in service. Please check the
; number and try again."
;context = from-sip-external ; Send unknown SIP callers to this context
context = from-trunk
callerid = Unknown
tos=0x68

Ich würde gerne erstmal sehen, daß das ganze funktioniert. Hat evtl. jemand mit einem laufenden SIP System - der seine Infrastruktur kennt und ihr auch vertraut - abends mal Zeit verschiedene Einstellungen mit mir auszuprobieren ?

Als Ergebnis können wir gerne ein HOWTO draus machen, was alle Erfahrungen zu dem Thema mal konzentriert zusammenfasst. Das wird sicher auch anderen helfen. Denn zum Thema anonyme Einwahl ist nur sehr wenig und das auch nur an einzelnen Stellen zu finden.

 

[Thomas007]

Es heisst bindport nicht port.
port war wohl mal bei Asterisk uralt.
Zwei mal localnet, ich weiß nicht ob das geht, ich würde sagen nein.
callerid gibt es nicht in den globals
tos funktioniert nicht wirklich

Basis für Deine Konfiguration sollte die gut dokumentierte sip.conf aus make samples aus Deiner Asterisk Version sein.

 

[chronoton]

Hallo Thomas, danke für die Korrekturen, den Port habe ich aus dem ip-phone-wiki und damals von VOIP-INFO. VOIP-INFO hat es schon korrigiert aber unter

http://wiki.ip-phone-forum.de/software:asterisk:einfuehrung

steht noch port statt bindport drin. Leider ist das wiki nicht offen oder ich finde den edit button nicht. Vielleicht korrigiert das dann mal jemand

Zum Thema localnet laut sip.conf.sample:

; You may add multiple local networks. A reasonable set of defaults
; are:
;localnet=192.168.0.0/255.255.0.0; All RFC 1918 addresses are local networks
;localnet=10.0.0.0/255.0.0.0 ; Also RFC1918
;localnet=172.16.0.0/12 ; Another RFC1918 with CIDR notation
;localnet=169.254.0.0/255.255.0.0 ;Zero conf local network

UPDATE :

So, wieder mal neue Erkentnisse :

von innen ohne NAT komme ich jetzt mit einem nicht registrierten SIP Client zur gewünschten DID durch. Auch die transports laufen in beide richtungen. Vielleicht auch als Hinweis

Noch was zu nat=yes in der sip.conf :

Nachdem ich nat=yes in der sip.conf gesetzt habe, wollten die internen SNOMs nicht mehr. Mehr aus Spass habe ich bei den extensions der snom Telefone mal nat=never zu nat=no geändert. Und schon gehen die internen SNOMS wieder. Jetzt ist also in der sip.conf globals nat=yes und für die internen extensions nat=no gesetzt.

 

[Macro]

War bei meinem Cisco 7940 war das gleiche Problem mit dem nat=yes. Die Änderung in der sip.conf biem Cisco auf nat=no hat dann wieder alles zum laufen gebracht. Danke für den Tipp.

Gruss Macro

 

[merkc]

Wenn alles andere, was bisher oben beschrieben wurde auch nicht hilft, dann versuch's mal mit einem CANREINVITE=NO ... das hilft vor allem, wenn der Asterisk "mithören" soll.
gruss
Chris