[solved] Sprachverbindung "zeitweise" nur in eine

[jui]

Hallo!

Ich habe ein eigenartiges Problem das normalerweise typisch für falsches Portforwarding wäre was hier aber wohl ausscheidet. Nach dem Start des Asterisk habe ich eine saubere bidirektionale Kommunikation von einem an der HFC angeschlossenen Telefon über ein SIP-Gateway zu externen Teilnehmern im Telefonnetz (ich gehe hierbei über 1und1 raus). Wenn Asterisk dann einiges Stunden läuft und ich eine Verbindung wähle wird diese zwar aufgebaut und der Gesprächspartner am anderen Ende hört mich auch (ob dies immer der Fall ist konnte noch nicht geprüft werden), aber ich höre nichts. Ein reload am CLI behebt dieses Problem umgehend wieder und alles funktioniert wie es soll.

Woran kann das wohl liegen? Wo soll ich mit der Fehlersuche anfangen? am CLI gibt Asterisk nichts hilfreiches aus, die Protokollierung ist identisch wenn das Problem auftritt wie auch nach einem reload wenn das Problem behoben ist..
Portforwarding odr mein Router dürfte eigentlich ausscheiden, denn ein reload des * würde das Problem ja dann nicht beheben.

Wer hat ein paar Ideen für mich?

Ich verwende ein analoges DECT-Telefon an einer Fritz!Box Fon die hier nur als Terminaladapter eingesetzt wird und nicht für SIP. Die Box ist an der im NT-Mode betriebenen HFC eingesetzt.

Bin für alle Tipps dankbar.

Gruß,

Jui

 

[rollo]

Re: Sprachverbindung "zeitweise" nur in eine Richt

Portforwarding odr mein Router dürfte eigentlich ausscheiden, denn ein reload des * würde das Problem ja dann nicht beheben.

Wer hat ein paar Ideen für mich?

Hast Du es trotzdem mal mit einem Routerreload probiert, nur um ganz sicher zugehen, dass es daran nicht liegt?

jo

 

[jui]

@rollo

Werde den router mal neu starten. Es ist ein Draytek Vigor 2500WE den ich erstmal VoIP-fähig machen musste, aber es läuft ja alles problemlos wenn * gestartet wird. Bis irgendwann der eine Sprachkanal weg ist (und zwar immer von extern ZU mir. Ich habe es jetzt noch mehrfach getestet und mein Gegenüber kann mich immer hören. Das ist eigentlich doch typisch für RTP-Probleme, oder?
Ich habe abr 100 UDP-Ports per Forwarding auf den *-Server im Router eingetragen und diese Ports auch korrekt im Asterisk rtp.conf eingetragen.
Ach ja, muss man eigentlich auch 5060 TCP öffenen? Habe da verschiedene Meinungen zu gehört. Aber daran dürfte es kaum liegen da die signalisierung ja erfolgreich ist. Evtl. ist auch der nat-eintrag für meinen SIP-Provider in der sip.conf noch relevant? Der * läuft ja im internen Netzwerk hinter dem Router der NAT macht. Auch da gibt es diverse Meinungen was man in der sip.conf setzen soll (nat= qualify=)
Habe derzeit nat=no und qualify=yes eingetragen für meine 1und1 Registrierung.

Gruß,

Jui

 

[rollo]

5060 TCP muss nicht geöffnet werden aber 5060 UDP.

Wenn der 2500 erstmal läuft macht er eigentlich keine Probleme aber man kann ja nie wissen. Wird nur schwierig mit dem Reboot, da Du dann vermutlcih ein andere IP bekommst und * einige Zeit braucht um das (ohne reload) zu merken.

Hast Du evtl. DoS akitivert? Teilweise werden dadurch eingehende VoIP-UDP-Pakte blockiert. Da könnte ein Blick ins Syslog hilfreich sein.

jo

 

[Netview]

Ich würde den Router erst mal VoIP fähig machen bevor ich groß Fehler im * suchen würde!

Der 2500w sollte mindestens die firmwware 2.51 haben und dann müsste halt noch per telnet ein 'sys sip_alg 0' erfolgen - soll ab der 2.53 dann default sein!

ftp://ftp.draytek.com/VIGOR2500/2.53/RELEASE/FIRMWARE/AnnexB_standard.zip

 

[jui]

@rollo

Danke für das Feedback, werde das gleich prüfen. 5060 UDP ist natürlich offen.

OT: Ich sehe an Deiner Signatur, dass Du die AVM als Router einsetzt und "dahinter" dann offensichtlich Asterisk. Klappt das ohne Probleme? Wie hast Du eine Portrange für RTP in der Fritz einerichtet, Ranges kann man dort ja nicht angeben. Irgendwelche Beonderheiten bei dieser Kombination?

 

[rollo]

Bei der Fritz!Box hab ich die ar7.cfg manual editiert und so 60 UDP ports für RTP geforwardet. Mein * verwendet SIP Listen port 5050, da 5060 von der FBF benutzt wird. Aktuell habe ich allerdings die FBF im "ATA Modus" und nach aussen einen Viogr 2600Vi (und die Box auf 5055 da jetzt der Vigor die 5060 braucht). Vorher mit dem 2500 WE lief es aber seit FW 2.5.1 auch ohne Probleme.

jo

 

[jui]

Der 2500w sollte mindestens die firmwware 2.51 haben und dann müsste halt noch per telnet ein 'sys sip_alg 0' erfolgen - soll ab der 2.53 dann default sein!

Ähm ... nix für ungut Netview, aber hast Du mein Posting gelesen?
Genau um diese Ratschläge zu vermeiden habe ich ja angegeben, dass der 2500WE von mir VoIP-fähig gemacht WURDE!
Daran sollte es nicht mehr legen und wenn er nicht VoIP-fähig wäre wurde wohl garnix klappen, vor allem würde sich nach einem *-Reboot nichts ändern. Der Router IST auf aktuellem Stand und per sys sip_alg 0 VoIP-fähig gemacht worden.

Da das Problem nur nach einer gewissen Laufzeit des * auftritt und nur in eine Richtung existiert (übrigens habe ich auf dem Server die Firewallfunktion deaktiviert) bin ich ja so sehr am rätseln.

Gruß,

Jui

 

[Netview]

@jui

sorry - hatte ich überlesen!

 

[Netview]

Du hast zu deinem provider hin 'qualify=yes' gesetzt (default ist 2s), dadurch hältst du die UDP-Sessions offen - vielleicht führt dies zu Engpässen im Router und zu diesem merkwürdigen Verhalten!

Setze doch mal qualify=no.

"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."

 

[jui]

@Netview

No problem
Das mit qualify=no werde ich mal testen. Aber bei 100 UDP-Ports die geöffnet sind und einem kleinen Testtelefon dürfte es nicht eng werden, ausser es findet ständig irgend eine Art von Kommunikation über udp mit den SIP-Providern statt (was die engl. Zitate ja ggf. hergeben). Ich habe 4 SIP-Provider eingetragen bei denen der * registriert ist. Ob es da eng werden kann auch ohne Gespräche? Einen Versuch ist es jedoch auf jeden Fall wert. Werde wohl auch mal einen tcpdump aufzeichnen mit beiden Einstellungen.

 

[jui]

@Netview


qualify = no bring keine Verbesserung. Ich stelle jetzt mal die Kiste in die DMZ, aber ich nehme an, dass es nicht am Router liegt, sondern woanders auf dem *-Server oder in der *-Konfiguration.

 

[jui]

@all

auch wenn asterisk in der dmz steht keine besserung. nach einer gewissen betriebszeit funktioniert ein verbindungsaufbau weiterhin wie im ursprünglichen posting beschrieben, aber die sprache nur noch unidirektional, d.h. von mir zum Angerufenen, aber ich höre nichts.
Hat niemand sonst ein solches Problem? Wer setzt Asterisk mit 1und1 ein und wählt über 1und1 raus? Möglicherweise ein 1und1 Problem?
Habe keinen Punkt an dem ich mit weiterer Fehlersuche ansetzen kann. Ein asterisk-reload und alles geht wieder für ne gewisse Zeit normal.

 

[jui]

@all
Also: es hängt nun definitiv damit zusammen, dass ich eine dynamische öffentliche IP habe denn es ist reproduzierbar, dass sobald sich meine IP ändert dieses Problem auftritt. eigenartigerweise ist ja nur eine Richtung des Sprachkanals beroffen, alles andere (Signalisierung und Sprache von mir zum Gegenüber) funktioniert. Ich hatte schon von Problemen mit dynamischen IP's gelesen, aber niemand hatte dieses Phänomen beschrieben.
Was sind denn die besten Lösungsansätze um nach IP-Änderung einen automatischen Reload durchzuführen? Gut wäre es wenn ich meinen Draytek (wie es die Frotz!Box Fon bietet) zu einer bestimmten Zeit nachts zu einer kurzen Trennung zwingen könnte und unmittelbar danach den reload ausführe, aber als Fallback muss auch eine erkennung vorhanden sein die ungeplante verbindungstrennungen erkennt und einen reload durchführt. Bin für Hinweise dankbar!

 

[jensx]

das der * nach dem Neueinwählen des Routers manchmal ein Problem hat habe ich auch schon bemerkt. Komischerweise nicht immer, die "Zwangstrennung" nach 24h übersteht er eigentlich immer.

Das Problem kommt wohl daher, daß der SIP-Provider noch die alte IP hat. Einige Dinge kann man dazu ja in der sip.conf einstellen, aber auch mit der Verwendung eines dyndns-namens konnte ich keine Abhilfe schaffen. Problem ist dabei, daß der * nicht merkt, daß die Verbindung nicht funktioniert, da die qualify und auch der channeltest eine funktionierende Verbindung anzeigt.

Warum trennts du aber so oft die Verbindung? Ist doch eigentlich bei Flate oder Volumen nicht notwendig?

 

[jui]

Ich verwende natürlich auch dyndns und habe dieses unter externip eingetragen. Ich dachte genau das würde solche Probleme verhindern, tut es aber nicht. Auch nach langer Wartezeit nach der Zwangstrennung besteht dieses Problem immernoch, erst ein asterisk reload behebt dieses seltsame phänomen. Mich wundert, dass es anscheinend nicht bei allen usern auftritt und schon garnicht in der gleichen Form.
Ich würde gerne mal sip.conf-Auszüge sehen von mehreren usern die betroffen sind von problemen und von welchen die nicht betroffen sind. Alle sollten jedoch von einem an einer HFC angeschlossenen Telefon (ISDN) über SIP-Provider (1&1, sipgate) regelmässig raustelefonieren. Nur dann kann man vielleicht zusammenhänge erkennen.

Hast Du eigentlich srvlookup = yes? Nur so, da ich damit keine registrierung beim sip-provider hinkriege und der * beim starten ne weile hängt bevor er weiterläuft. Werde dazu mal einen extra thread aufmachen..

 

[Netview]

Tja - ich gönne mir halt den Luxus einer festen IP und solche Probleme sind mir gänzlich fremd! :mrgreen:

Gestern führte meine "bessere Hälfte" ein Telefongespräch und merkte nicht mal etwas von der Zwangstrennung!
Asterisk hat einfach mit der festen IP reconnected ohne irgendeine Unterbrechnung im Gespräch. :shock:

Die Kiste läuft bei mir daher durchgehend - (Änderungen mache ich per ssh).

 

[jensx]

meine sip.conf:

[general]
port = 5060 ; Sipport
bindaddr = 0.0.0.0 ; Addresse für den SIP Kanal
tos=lowdelay
;externip = xxxxxx.dnsalias.net //aus, weil es nicht funktionierte
;Localnet = 192.168.0.0/255.255.255.0 //dgl.
srvlookup = yes

register => xxxxx:[email protected]:5060/xxxxxx


[sipgate]
type=friend
username=xxxxxx
fromuser=xxxxxx
secret=xxxxxxPW
context=sipgatein
host=sipgate.de
fromdomain=sipgate.net
canreinvite=no
nat=0
qualify=yes
tos=0x25
DTMF=RFC2833
dtmfmode=info
insecure=very

@jui:
srvlookup=yes funktioniert beim mir, siehe oben

@Netview:
hätte ich auch nicht gedacht, daß das Gespräch sogar durchläuft, wenn die Verbindung danach rechtzeitig steht.
Aber: eine feste IP hat auch Nachteile, ich bin manchmal recht froh nicht ständig sofort und einfach indentifiziert werden zu können, auch wenn sich eine Virenschleuder mal auf die IP eingeschossen hat muß man einfach nur trennen. Feste IP erfordert einfach mehr Vorkehrungen in diese Richtung.
verlockend ist's aber schon als das ständige warten auf den dyndns ;-) ... aber das ist wohl nun doch eher OT

 

[Netview]

@jensjk:

Leider ist das mit den Zugriffsversuchen von Außen bei einer dynamischen Adresse meist schlimmer, da eine IP die dir dyn. zugewiesen wurde zuvor meist für andere Zwecke unter einem anderen account genutzt wurde (p2p: edonkey, emule kazaa ...).

 

[jensx]

ja, leider. Aber dann schneller zu beheben. Die eingehenden Pakete von p2p sind ja an sich nicht so tragisch, aber wie du schon sagst, manchmal hängt noch mehr dran. Langsam eskaliert der Unfug eben wirklich und bringt dem normalen Nutzer einen Riesenaufwand.