NAT (mit qualify=yes)

[prochmi]

hallo,
ich habe für alle clients nat=yes und qualify=yes aktiviert.

allerdings wird der client trotzdem nach 3 minuten (solange merkt sich meine linux firewall mit der ich das probiert hab die udp verbindung) nicht erreichbar.

als workaround müssen sich meine clients einfach alle <3 min. neu registrieren, dann passt alles (aber genau dafür würd ich ja eigentlich das qualify machen).

wenn ich mitsniffe, dann seh ich auch, das SIP options (das ja durch qualify regelmäßig verschickt wird) alles andere als regelmäßig verschickt wird.

weiß jemand in welchem abstand asterisk bei qualify=yes die packete verschickt?

irgendwelche anderen ideen?

mfg,
michael

 

[Thomas007]

Hallo,

bei den Clients sollte NAT= no stehen sofern die mit dem Asterisk im LAN sind.
Bei den externen peers und in der global section muß nat= yes eingetragen sein, dazu noch externip und localnet.

qualify = yes ist qualify = 2000 in ms, Du kannst aber auch andere beliebige Werte eintragen.
Qualify hat aber so nichts mit der Registrierung zu tun, qualify prüft ob das peer erreichbar ist. Die Verwendung von qualify kann manchmal mehr Probleme machen als qualify= no zu setzen, zumal manche Provider Probleme haben die paar Pakete in normaler Zeit zu beantworten und dann ständig auf nicht erreichbar stehen.

Schau auch mal nach registertimeout
http://www.voip-info.org/wiki/index.php?page=Asterisk+config+sip.conf

Nutzt Du wirklich conntracking für die eingehenden UDP-Pakete?

TimeOuts von UDP Paketen kannst Du hier auslesen
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout_stream
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_udp_timeout

Sollte 180, bzw. 30 ausgeben.

 

[prochmi]

bei den Clients sollte NAT= no stehen sofern die mit dem Asterisk im LAN sind.
Bei den externen peers und in der global section muß nat= yes eingetragen sein, dazu noch externip und localnet.

ich habe ausschließlich externe clients. ich kann zwar nicht ausschließen das ein user NICHT über NAT kommt (wenn er eine öffentliche IP für sein phone verwendet), aber NAT=yes sollte ja auch nicht weiter stören, wenn ein client mal nicht über NAT kommt.

mein asterisk hat eine öffentliche IP (steht also selber nicht hinter einem NAT).

qualify = yes ist qualify = 2000 in ms, Du kannst aber auch andere beliebige Werte eintragen.
Qualify hat aber so nichts mit der Registrierung zu tun, qualify prüft ob das peer erreichbar ist. Die Verwendung von qualify kann manchmal mehr Probleme machen als qualify= no zu setzen, zumal manche Provider Probleme haben die paar Pakete in normaler Zeit zu beantworten und dann ständig auf nicht erreichbar stehen.
[\QUOTE]

ich weiß, es wäre aber interessant in welchen abständen er bei qualify=yes (oder halt was anderes) die erreichbarkeit überprüft. ich kann jedenfalls keine regelmäßigkeit herauslesen.

Schau auch mal nach registertimeout
http://www.voip-info.org/wiki/index.php?page=Asterisk+config+sip.conf

das würde mir nur was bringen wenn der asterisk als client hinter einem NAT sitzt.

Nutzt Du wirklich conntracking für die eingehenden UDP-Pakete?

wie meinst du das?

mit qualify=yes kann man den client dazu bewegen, regelmäßig pakete zum server zu schicken, dadurch wird der port offengehalten. sollte zumindest so sein, bei mir funktionierts leider nicht wie gewünscht.


mfg,
michael

 

[betateilchen]

mit qualify=yes kann man den client dazu bewegen, regelmäßig pakete zum server zu schicken, dadurch wird der port offengehalten.

:shock:

wer hat Dir denn das eingeredet ?

 

[prochmi]

:shock:

wer hat Dir denn das eingeredet ?

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

If you turn on qualify in the configuration of a SIP device in sip.conf, Asterisk will send a SIP OPTIONS command regularly to check that the device is still online. If the device does not answer within the configured (or default) period (in ms) Asterisk considers the device off-line for future calls.

This feature may also be used to keep a UDP session open to a device that is located behind a network address translator (NAT). By sending the OPTIONS request, the UDP port binding in the NAT (on the outside address of the NAT/firewall device) is maintained by sending traffic through it. If the binding were to expire, there would be no way for Asterisk to initiate a call to the SIP device. This can be used in conjunction with the nat=yes setting.

siehst du das anders?

mfg,
michael

 

[betateilchen]

Ja.

mit qualify=yes kann man den client dazu bewegen

Es ist genau umgekehrt - Du bewegst damit den SERVER (=Asterisk) Pakete an den CLIENT (=Endgerät) zu schicken.

 

[prochmi]

Ja.
Es ist genau umgekehrt - Du bewegst damit den SERVER (=Asterisk) Pakete an den CLIENT (=Endgerät) zu schicken.

was wiederum den client dazu bewegt pakete an den server zu schicken.

schon klar das ich mit einer einstellung am server den client nicht direkt (ohne das ihm der server was davon sagt) dazu bewegen kann einfach so ein paket zu schicken

mfg,
michael

 

[Thomas007]

OK,
dann geht es also um die Clients, die hinter einem NAT stehen. Ich bin davon ausgegangen das Dein Asterisk hinter NAT ist.

Ob der Server die Clients noch erreichen kann hängt dann von der NAT-Implementierung des Routers ab hinter dem der Client steht. Diese TimeOuts kann der Server natürlich nicht beeinflussen.


Ohne Gewähr, ich habe diesen Schnipsel aus einem anderen Beitrag und ich meine auch das Qualify = yes 2000 ms entspricht.

*It should actually be qualify=1000 if you'd like for the peer to be
made unavailable when we don't get a response to SIP OPTIONs within
1000ms (1 second).

*If the host is reachable, the next SIP OPTION attempt will not come
until 60 seconds later. If the host isn't reachable, it will proceed
to schedule SIP OPTION attempts every 10 seconds.

*These are defined constants in chan_sip.c

Man könnte es also im Source Code nachschauen.

Und wennDu nun die Register Expiration beim Client kurz setzt, z.B. 30 Sekunden?
Dazu defaultexpirey und maxexpirey beim Asterisk entsprechend konfigurierst.
Dann sollte der Client sich laufend registrieren und die Connection-Tracking Tabelle im Router sollte noch gültig sein.

 

[speedy1980]

Was sagt denn "sip show peers"?

 

[prochmi]

Ohne Gewähr, ich habe diesen Schnipsel aus einem anderen Beitrag und ich meine auch das Qualify = yes 2000 ms entspricht.

*It should actually be qualify=1000 if you'd like for the peer to be
made unavailable when we don't get a response to SIP OPTIONs within
1000ms (1 second).

*If the host is reachable, the next SIP OPTION attempt will not come
until 60 seconds later. If the host isn't reachable, it will proceed
to schedule SIP OPTION attempts every 10 seconds.

*These are defined constants in chan_sip.c

Man könnte es also im Source Code nachschauen.

#define DEFAULT_MAXMS 2000 /* Must be faster than 2 seconds by default */
#define DEFAULT_FREQ_OK 60 * 1000 /* How often to check for the host to be up */
#define DEFAULT_FREQ_NOTOK 10 * 1000 /* How often to check, if the host is down... */

stimmt also => einmal in der minute (tut er aber bei mir offensichtlich nicht).

hmm, irgendwie tut er nicht so wie er soll. wenn jetzt aus irgendeinem grund eine sip options message nicht durchkommen sollte, dann prüft er ja maximal noch schneller (alle 10 sekunden).

Und wennDu nun die Register Expiration beim Client kurz setzt, z.B. 30 Sekunden?
Dazu defaultexpirey und maxexpirey beim Asterisk entsprechend konfigurierst.
Dann sollte der Client sich laufend registrieren und die Connection-Tracking Tabelle im Router sollte noch gültig sein.

das hab ich im ersten beitrag eh schon erwähnt, wenn ich mit entsprechend kurzer register expiration arbeite, dann hab ich eh keine probleme.

ich denk mir nur, das die lösung mit qualify weit weniger traffic verursachen würde (bei 5 clients ist das egal, aber bei 2000 nicht mehr unbedingt).



sonst noch irgendwelche ideen?


@speedy1980
gar nix => realtime

mfg,
michael

 

[Thomas007]

keine weitere Idee, da ich (noch) nicht mit Realtime arbeite habe ich diese Probleme von den externen Phones nicht.

Da Du mit realtime arbeitest wie wäre es damit:

Using Realtime SIP peers does not allow for "NAT Keepalive" packets to
be sent, so the firewall/NAT devices that those phones are connected to
are closing the SIP port hole after an expiration timeout.

To fix this, you'll need to upgrade to newer Asterisk (you really should
be running 1.2) and use 'realtime caching' for your SIP peers.

Ansonsten würde ich Dir empfehlen die Frage hier zu wiederholen.
http://lists.digium.com/mailman/listinfo/asterisk-users

Solltest Du auch abbonnieren, seit Aug 05 31.000 Beiträge.

 

[speedy1980]

...

@speedy1980
gar nix => realtime

...

Der Punkt ist:

...
To fix this, you'll need to upgrade to newer Asterisk (you really should
be running 1.2) and use 'realtime caching' for your SIP peers.
...

Du mußt in der sip.conf also rtcachefriends auf yes setzen. Nur dann funktioniert auch das Qualify. Letzter Absatz "Realtime Caching" auf http://voip-info.org/wiki/view/Asterisk+RealTime+Sip klärt das auch etwas, ebenso Absatz "Olle explains the world" auf http://www.voip-info.org/wiki-Asterisk+RealTime.

 

[prochmi]

Der Punkt ist:
Du mußt in der sip.conf also rtcachefriends auf yes setzen. Nur dann funktioniert auch das Qualify. Letzter Absatz "Realtime Caching" auf http://voip-info.org/wiki/view/Asterisk+RealTime+Sip klärt das auch etwas, ebenso Absatz "Olle explains the world" auf http://www.voip-info.org/wiki-Asterisk+RealTime.

das wars leider nicht ganz, weil das hab ich eh auch schon probiert.

außerdem muß man

rtnoupdate=no

setzen.


also mit rtcachefriends=yes und rtnoupdate=no funktionierts endlich

jetzt würd mich noch brennend interessieren wo (außer im sourcecode) die ganzen rtxxx attribute (es gibt ja dann zumindest noch rtautoclear) dokumentiert sind (der zumindest kurz was es ca. bewirkt).

auf asteriskguru findet man bei der iax.conf folgendes:

rtcachefriends yes | no Cache realtime friends by adding them to the internal list just like friends added from the config file only on a as-needed basis.

example: rtcachefriends=yes

rtnoupdate yes | no Do not send the update request over realtime.

example: rtnoupdate=yes

rtautoclear yes | no | <seconds> Auto-Expire friends created on the fly on the same schedule as if it had just registered when the registration expires the friend will vanish from the configuration until requested again. If set to an integer, friends expire within this number of seconds instead of the same as the registration interval.

example: rtautoclear=yes

is halt die frage inweifern man das 1:1 für sip übernehmen kann.

mfg,
michael