Asterisk Port Hilfe bitte

[Pascalxx]

Guten morgen

wir haben folgendes Problem haben seid gester einen DLink DIR-100 Router.
Und mit dem Anschluß diesen können wir nicht mehr über die voreingestellte Standart Voip Provider rauswählen über alle andere ja...

Wenn ich mir auf der Weboberfläche der Vlines den Sip Status anschaue erscheint folgendes...

Sipgate 217.10.79.9 5060 Unmonitored
Sipgate1 217.10.79.9 5060 UNREACHABLE

Wobei Sipgate1 unsere Standart Verbindung ist. Mit einem anderen Router erscheint anstatt UNREACHABLE - 50ms

Ich schätze das der Router dieses blockt... Kann einer helfen

Besten Dank

 

[britzelfix]

@Pascalxx


in der sip.conf externip und localnet einstellen.
"Unmonitored" bekommt man wenn "srvlookup = no"
gesetzt ist.

Gruß
britzelfix

 

[Thomas007]

Unmonitored kommt wenn qualify = no, mit srvlookup hat das nichts zu tun

 

[britzelfix]

@Thomas007

Ok, danke fürs Berichtigen.

Gruß
britzelfix

 

[Pascalxx]

Besten Dank für eure Hilfe...

wenn ich qualify = no klappt es mit dem raustelefonieren
es klappte deshalb bei den anderen Leitungen da das "Qualify" gar nicht auftaucht.
Was bewirkt es überhaupt???
Mit unserem alten Netgear klappte auch mit qualify = yes nur mit dem neuen DLINK DR-100 nicht... der läuft das qulify über einen anderen Port???

Besten Dank

 

[britzelfix]

@Pascalxx

Um jetzt nicht zehn mal fragen zu müssen
und Dir die Infos aus der Nase ziehen zu
müssen. Was hast Du denn in der
general-section der sip.conf eingetragen?
(ohne die passwörter bitte)

Was bewirkt es überhaupt???

Da schaust Du mal besser auf www.voip-info.org
bzw. benutzt die Suchfunktion.

Gruß
britzelfix

 

[Netview]

Hier steht es genau:

http://www.voip-info.org/wiki/index.php?page=Asterisk+sip+qualify

Der Parameter sollte nie in Verbindung mit einem Provider verwendet werden, da er unnötig traffic verursacht und dazu führt, dass der sip-proxy des Anbieters überlastet wird (er muss ja nicht nur deine requests verarbeiten)!

Sinn macht das imho nur wenn du prüfen willst ob "eigene" interne/externe Endgeräte online sind!

Edit: ein sinnvolles Einsatzgebiet von 'qualify=' wäre auch um udp ports offen zu halten, damit diese nicht nach einer gewissen Zeit vom Router geschlossen werden (timeout). Allerdings bedeutet qualify=yes, dass im 2 Sekunden-Rhythmus das Senden eines 'SIP Option Command' erfolgt. Dies ist jedoch gegenüber einem SIP-Provider viel zu oft (man sollte 'qualify=' auf einige Minuten setzen (die Definition erfolgt in ms)!
Wenn udp-ports (speziell rtp) vom Router zu früh geschlossen werden hast du Gesprächsabbrüche. In diesem Fall würde man mal versuchen mit qualify=Wert zu spielen - generell jedoch erstmal qualify=no!

 

[britzelfix]

Macht auch Sinn es auszuschalten, wenn der Server nicht
anpingbar ist, weil es sonst nicht funktioniert.

Gruß
britzelfix

 

[Netview]

@britzelfix

asterisk sendet jedoch 'sip options commands' und keine pings/ICMP-requests bei gesetztem qualify. Ich wäre mir da nicht sicher ob das eine etwas mit dem anderen zu tun hat.

 

[britzelfix]

@Netview

Richtig!, denn sprach auch nicht über das ICMP-Ping.
Ping im ist im Allgemeinen die Abfrage eines
Servers, das kann alles mögliches sein,
wie z. B. den Praktikanten losschicken, um
zu Prüfen ob der Server lebt.

Gruß
britzelfix

 

[Netview]

Ja - aber nur wenn der Praktikant Chinese ist und Pong heisst :mrgreen:

 

[britzelfix]

:mrgreen:

Gruß
britzelfix

 

[Pascalxx]

Besten Dank für eure Hilfe

Wir nutzen das Qualify=yes um zu erkennen ob der Provider erreichbar ist, sollte dies nicht der Fall sein FallBack auf ISDN....

Wir haben nun auch noch einen einen Linksys probiert mit demselben Problem...

Da muß es doch eine Lösung geben...

Besten Dank

 

[betateilchen]

Allerdings bedeutet qualify=yes, dass im 2 Sekunden-Rhythmus das Senden eines 'SIP Option Command' erfolgt. Dies ist jedoch gegenüber einem SIP-Provider viel zu oft (man sollte 'qualify=' auf einige Minuten setzen (die Definition erfolgt in ms)!

AUTSCH... Null Punkte Ja, ich weiß, daß sich voip-info.org da selbst widerspricht, da dort gegenteilige Aussagen zu finden sind!

Die Zeit die bei qualify= angegeben wird, wird tatsächlich in ms angegeben. Aber mit dem Rhythmus, in dem der Asterisk SIP OPTION sendet, hat das überhaupt nichts zu tun. Die angegebene Zeit ist lediglich die Zeit, nach der Asterisk das Gerät als "nicht erreichbar" betrachtet. Standardmäßig ist das nach 2 Sekunden (2000 ms) der Fall. Es wird also mit dem Parameter lediglich der Timeout festgelegt.

Die SIP OPTION Message wird standardmäßig von Asterisk im Abstand von 60 Sekunden geschickt, solange das Ziel REACHABLE ist. Ist das Ziel nicht (mehr) erreichbar (UNREACHABLE), reduziert Asterisk das Intervall automatisch auf 10 Sekunden, um das Ziel schnellstmöglich wieder als "REACHABLE" erkennen zu können.

Grundsätzlich richtig ist, daß man qualify nicht bei Providern aktivieren soll, denn es gibt Provider, die das grundsätzlich nicht zulassen, und teilweise sogar die SIP Verbindung einfach abbrechen.

 

[Pascalxx]

Aber wie bekommen wir es mit unserem Router hin??? Kann es sein das z.B. die Firewall des Routers dies unterbindet???

 

[betateilchen]

Mit der Firewall des Routers hat das eigentlich nichts zu tun. Das Datenpaket mit SIP OPTIONS wird über den Standard-SIP Port 5060 geschickt und der Zielserver antwortet darauf mit einem SIP 200 OK ebenfalls auf 5060. Wenn allerdings der Server generell das qualify nicht mag, dann antwortet er überhaupt nicht. Diese Antwortverweigerung kann übrigens auch erst nach einer gewissen Zeit erfolgen, wenn der SIP Server merkt, daß Du ihn permanent bombardierst. In diesem Fall betrachtet Asterisk den Server als UNREACHABLE und wird erst gar nicht versuchen, dorthin einen Call aufzubauen. Diesen Effekt hast Du ja oben auch schon selbst festgestellt und beschrieben.

Für Deine Callbacklösung solltest Du Dir einen anderen Weg ausdenken. Das qualify ist dafür einfach nicht zuverlässig genug einsetzbar, was Deine darauf basierende Fallbacklösung generell in Frage stellt.

[randbemerkung]
Es gibt übrigens auch SIP (und auch IAX) Clients, die bei einem qualify auf sich einfach den Dienst verweigern.
[/randbemerkung]

 

[Pascalxx]

Besten Dank BETATEILCHEN

das habe ich mir auch schon gedacht jedoch ist auch folgendes....

hänge ich einen alten Netgear Prosafe Router rein klappt es ohne Probleme mit dem Qualify... kommt ein neuer Router rein mit QoS kommt die Problematik... Ich denke nicht das das Problem auf Sipgate oder Dus.net basiert, da diese ja schon wie geschrieben mit Netgear 1A das Qualify schaffen....

 

[betateilchen]

Tja, dann solltest Du mal die QoS Einstellungen überprüfen Es könnte sein, daß Dein QoS die Pakete schlichtweg ausfiltert, da sie einen (Informations-)Inhalt von 0 Byte haben.

Trotzdem würde ich Dir dazu raten, über eine andere Umsetzung der Fallbacklösung nachzudenken.