Probleme mit Asterisk & Voyage 0.6.5

[eBoy]

Hallo Zusammen,

ich habe mir eine neue Telefonanlage für zu Hause aufgesetzt und verzweifle momentan an eingehenden Anrufen (Ansage "Teilnehmer nicht erreichbar", kein Klingeln, keine Reaktion in der Asterisk-Konsole)...
Asterisk läuft direkt auf meinem Router. Die Clients verbinden sich zu Asterisk aus dem internen Netz. Interne Telefonie und ausgehende Gespräche (z.B. Testansage des Providers Sipgate) funktionieren. Eingehende Gespräche werden auf der Asterisk-Konsole nicht "registriert" bzw. angezeigt,
Die Firewall ist auf den entsprechenden Ports für alle IPs offen und dazu passend in rtp.conf gesetzt.
Auch verlasse ich mich hier nicht auf das Conntracking von iptables, sondern habe die entsprechenden Regeln direkt am Anfang der INPUT-Chain. OUTPUT-Chain steht die Policy auf ACCEPT.

Die Anlage soll 3 Sipgate-Accounts verwalten und jedem Account wird ein User zugeordnet

Sipgate 1 -> Telefon 1
Sipgate 2 -> Telefon 2
Sipgate 3 -> Telefon 3

Testweise wurde aber die Konfiguration abgesehen von einem Account auch bereits komplett gelöscht.

Hardware:
Alix 2d13

Software-Pakete
Voyage 0.6.5 (2.6.30-voyage)
Asterisk 1.4.21.2~dfsg-3+lenny1
Asterisk GUI-version : SVN-branch-2.0-r5001

Da ich die Firewall in der Konfiguration als Ursache eigentlich ausschließen kann, müsste das Problem an der Asterisk-Konfiguration liegen. Die Konfig wurde komplett mit der Asterisk-GUI aufgesetzt. Nach meinem Verständnis könnte der Fehler nur in den Incoming Calling Rules liegen, welche aktuell nur eine Regel enthalten (für den entsprechenden User/ Provider).

always	'_X.' (CatchAll)	Goto User 6011

always -> Montag bis Sonntag rund um die Uhr (also immer)


Hat jemand eine Idee, wo das Problem liegen könnte bzw, habe ich die Incoming Calling Rule irgendwie falsch verstanden und somit falsch gesetzt???
Oder gibt es das einen Bug in der Asterisk GUI?

 

[eBoy]

Ich habe die Konfiguration nun nochmal komplett gelöscht und neu erstellt mit einem Sipgate-Account...

Auch diesmal wieder funktionierten nur ausgehende Gespräche. Eingehende Gespräche bleiben scheinbar trotz Freischaltungen an der Firewall hängen
Anders kann ich es mir momentan nicht mehr erklären...
Wenn ich als Test einen Anruf vom Handy auf meine Festnetznummer tätige sehe ich nur 2-3 ankommende Sip-Pakete inklusive Rückpakete, aber es kommt scheinbar keine Verbindung zustande.

Wobei die ersten Regeln meiner Firewall die entsprechend konfigurierten Ports ausdrücklich zulassen

INPUT-Chain

udp 5060,19500:20000 ACCEPT
tcp 5060 ACCEPT
udp 5060 ACCEPT # <- eigentlich bereits in 1. Zeile abgedeckt...
RELATED,ESTABLISHED ACCEPT

Hab die neue Anlage wieder außer Betrieb und kann die Regeln nicht 1:1 aus der Konsole kopieren (serielle Verbindung, copy & paste funktioniert in dem Programm nicht). Mit der alten Anlage funktioniert es nun wieder (OpenWRT).

In der Firewall sind aber auch entsprechende Module geladen (conntracking,...). Es sind auch die Module für SIP geladen, wobei diese ja eigentlich nicht benötigt werden (denke ich mal), da die Verbindung ja nicht direkt durch die Firewall muss, sondern lediglich zum Router (= TK). Dazu die Ports ja direkt zu Beginn der INPUT-Chain offen sind und nicht auf Conntracking angewiesen sind.

Ich bin ratlos. Vielleicht ist Voyage ja auch einfach nur Mist???

 

[eBoy]

Hat schonmal jemand mit Voyage Linux oder Asterisk GUI 2 eine Anlage aufgesetzt? Kennt hier jemand bestehende Probleme bzw. hat jemand selbiges Problem gehabt?

Ich würde ja auch die Konfigurationen posten, aber diese sind kommentiert und sehr umfangreich... Eine Anleitung zum Einrichten eingehender Gespräche per Asterisk GUI habe ich nicht gefunden....

Müsste Asterisk einen eingehenden Call nicht zumindest registrieren, falls dieser aufgrund der Konfiguration abgelehnt wird??? Dann wüsste ich, dass der Fehler bereits dafür (z.B. Firewall) zu suchen ist. Wobei ich hier auch schon vieles probiert habe.

Bei Problemen mit der Firewall würden auch ausgehende und interne Gespräche ja nicht problemlos und absolut zuverlässig funktionieren (z.B. falls eingehende Pakete geblockt werden).

 

[eBoy]

Gibt es hier wirklich niemanden der mir bei dem Problem helfen kann oder auch nur einen Tipp geben kann?

Ich finde keine Erklärung weshalb die Anrufe nichtmal von der Asterisk-Anlage bemerkt und in der Console gezeigt werden...

Sämtliche in der alten Anlage geladenen Module (conntracking, iptables nat,...) wurden sicherheitshalber nochmal mitgeladen und verglichen. Kein Unterschied.
Mir kommt es immer mehr so vor als würde der Call an der Firewall hängenbleiben, obwohl diese definitiv offen ist.

tcpdump am externen Interface:

17:17:18.303015 IP 217.10.79.9.5060 > <MEINEIP>.5060: SIP, length: 1247
17:17:18.304015 IP <MEINEIP>.5060 > 217.10.79.9.5060: SIP, length: 544
17:17:18.304015 IP <MEINEIP> > 217.10.79.9: udp
17:17:18.374015 IP 217.10.79.9.5060 > <MEINEIP>.5060: SIP, length: 402

iptables INPUT-Chain

 1403  314K ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           multiport dports 5060,19500:20000 
    0     0 ACCEPT     tcp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           tcp dpt:5060 
    0     0 ACCEPT     udp  --  eth0   *       0.0.0.0/0            0.0.0.0/0           udp dpt:5060 
15781 1829K ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0           state RELATED,ESTABLISHED

Die eingehende Freischaltung zählt zwar hoch, aber ich vermute das war ein ausgehender Testanruf (rtp, ankommende Sprache des Testanrufs).

netstat -puntal | grep asterisk

tcp        0      0 127.0.0.1:5038          0.0.0.0:*               LISTEN      8877/asterisk   
tcp        0      0 0.0.0.0:8088            0.0.0.0:*               LISTEN      8877/asterisk   
udp        0      0 0.0.0.0:4520            0.0.0.0:*                           8877/asterisk   
udp        0      0 0.0.0.0:5060            0.0.0.0:*                           8877/asterisk   
udp        0      0 0.0.0.0:4569            0.0.0.0:*                           8877/asterisk

rtp-Portbereich ist wie bei der vorherigen Anlage auch auf 19500-20000 festgelegt in der rtp.conf...