Asterisk ok, verliert aber Verbindung zu Sipgate

[rowitech]

Hallo,

meine 8007207 bei Sipgate liegt auf einem Server mit fester IP. Ich nutze Asterisk 1.0 (Debian) und alles funktioniert normalerweise bestens.

Nach einiger Zeit (habe ich nicht geschafft zu ermitteln, vielleicht einige Stunden) kann ich diese Nummer nicht mehr anrufen. Bin ich auf diesem Rechner, dann gibt mir sip debug auch keine einlaufenden Pakete mehr raus. Also sieht alles danach aus, als sei die Registrierung abgelaufen und er hätte sich nicht neu registriert. Doch die Kommandos zeigen etwas anderes:

(Das jetzt in CODE zu packen wäre unsinn, daher hier "normal"):

vl13s14*CLI> sip show registry
Host Username Refresh State
sipgate.de:5060 8007207 585 Registered
vl13s14*CLI> sip show peers
Name/username Host Dyn Nat ACL Mask Port Status
sipgate/8007207 217.10.79.9 255.255.255.255 5060 Unmonitored
vl13s14*CLI> sip show inuse
Username incoming Limit outgoing Limit
sipgate 0 N/A 0 N/A
vl13s14*CLI> sip debug
SIP Debugging Enabled

Soweit ich das richtig lesen kann, ist die Registrierung bei Sipgate noch ok, kein Anruf ist derzeit in der Leitung und alles ist ok.

Da ist kein Endgerät angeschlossen, das ist ok so.

Nach einem restart now ist wieder alles ok, also funktioniert bestens...

Gruß
Rolf

 

[TinTin]

Hi Rolf,

das UNMONITORED sieht nicht gut aus - dort sollte OK stehen, wenn alles i.O. ist. Poste doch mal Deine sip.conf (Passwörter entfernen)

Gruß
Tin

 

[betateilchen]

UNMONITORED bedeutet lediglich, daß in der SIP.CONF kein "qualify=yes" steht (was ja auch nicht zwingend notwendig ist) und hat mit dem beschriebenen Problem nichts zu tun.

 

[TinTin]

Ich denke schon, dass mit sipgate und einem qualify=yes sein Problem ggf. gelöst werden kann, dann hält Asterisk von sich aus die Verbindung aufrecht.

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

Tin

 

[rowitech]

Danke für die Antwort. Habe bei meinem Asterisk mit dynamischer IP keine solchen Probleme und da sollte es doch mehr Ärger geben können als mit statischer IP. Oder liegt es daran, dass da keine Nebenstellen dran sind? Vielleicht triggern diese ja und das qualify=yes macht das dann. Wie dem auch sei, es waren nur wenige Sekunden, das einzupflegen und ein Hoffnungsschimmer ist es allemal . Ich werde berichten, wie sich das nun verhält.

Gruß
Rolf

 

[rowitech]

Das qualify=yes war es offensichtlich nicht, der Fehler tritt nach wie vor auf.
ich kann mir das nicht erklären, warum sollte gerade bei einer festen IP sowas auftreten und hier, mit dem gleichen Kram bei dynamischer IP eben nicht?

Gruß
Rolf

 

[TinTin]

Hallo Rolf,

ich habe auch sowohl einen Asterisk mit öffentlicher IP (dedicated server bei Strato) als auch einen lokal zum testen hinter einem Router hier bei mir zu Hause, beide mit Debian. Mit sipgate habe ich mit keinem der beiden * Server Probleme ( es sei denn sipgate selbst hat gerade mal ein Problem ). Ich kann nur anbieten meine sip.conf mal mit Deiner zu vergleichen, wenn Du sie hier posten magst. Ausserdem interessant wäre vielleicht noch die Datei etc/network/interfaces .

Gruß,
Tin

 

[rowitech]

>Ausserdem interessant wäre vielleicht noch die Datei etc/network/interfaces

Da habe ich auch schon dran gedacht, denn der Server ist ein virtueller Server und ich habe die bindaddress angegeben, er sollte sich aber eigentlich wie ein dedicated Server verhalten.

Interessanterweise habe ich, seitdem ich die Testnummer 8007207 und meine anderen Nummern getrennt habe (8007207 auf separaten Server), mit meinem DSL-Asterisk keine Probleme mehr. Ich vermute ja auch, dass es eine Angriffsmöglichkeit gibt, so dass Asterisk stirbt, welchen Tod auch immer. Ich könnte mir gut vorstellen, dass eine nicht verbreitete Nummer auch viel weniger Stress machen würde, aber das ist ja das Interessante, eben der Stresstest.

sip.conf

[general]
context=incomingsipgate                 ; Default context for incoming calls
bindaddr=83.151.17.156                ; IP address to bind to (0.0.0.0 binds to all)
srvlookup=no                   ; Enable DNS SRV lookups on outbound calls
;defaultexpirey=600
disallow=all                    ; First disallow all codecs
allow=gsm                       ; Allow codecs in order of preference
allow=ulaw                      ; Allow codecs in order of preference
allow=alaw                      ; Allow codecs in order of preference
allow=ilbc                      ; Note: codec order is respected only in [general]
language=de
tos=reliability
;maxexpirey=600

register => 8007207:[email protected]/8007207

[sipgate]
insecure=very                   ; To match a peer based by IP address only and not peer
type=friend
username=8007207
secret=2MumPiTZ
host=sipgate.de
fromuser=8007207
fromdomain=sipgate.de
;nat=no
;dtmfband=inband
context=incomingsipgate
canreinvite=no

Habe gerade noch was gesehen (schau an, ich hab ein Log gefunden...):
Nov 16 07:46:56 WARNING[98310]: No such host: sipgate.de
Nov 16 23:05:00 WARNING[16384]: Unable to open IAX timing interface: No such file or directory
Nov 16 23:05:00 WARNING[16384]: Unable to get our IP address, Skinny disabled

Hmm, besonders das No such host ist doof...

Gruß
Rolf

 

[betateilchen]

srvlookup=no

ändere das mal auf "yes" damit die im Kontext stehende Adresse sipgate.de richtig aufgelöst wird.

 

[TinTin]

@Rolf
siehe betateilchens Antwort, das sollte das "no such host" Problem lösen

Gruß,
Tin

 

[rowitech]

Örks, klassisches Eigentor. Das hatte ich versuchshalber mal auf no gesetzt, ohne im Kopf zu haben, dass ich sipgate nicht über die IP anspreche...

Habe auch ne Lösung wegen diesem skinny.conf, aber das sieht mir eher nach Kosmetik aus. Da kann man in skinny.conf ebenfalls die bindaddr setzen, warum doppelt, weiss ich nicht.

Gruß
Rolf

 

[rowitech]

Heute Nacht ist ein User hängengeblieben (ein Channel noch belegt), danach hatte Asterisk keine Lust mehr:

Nov 17 00:03:44 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 158
(Critical Request)
Nov 17 00:03:58 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:07:35 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 163
(Critical Request)
Nov 17 00:07:49 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:07:55 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 164
(Critical Request)
Nov 17 00:08:09 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:08:15 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 165
(Critical Request)
Nov 17 00:08:29 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:08:36 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 166
(Critical Request)
Nov 17 00:08:50 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:08:56 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 167
(Critical Request)
Nov 17 00:09:10 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:09:16 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 168
(Critical Request)
Nov 17 00:09:30 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:09:37 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 169
(Critical Request)
Nov 17 00:09:51 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:09:57 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 170
(Critical Request)
Nov 17 00:10:11 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:10:17 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 171
(Critical Request)
Nov 17 00:10:31 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:10:38 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 172
(Critical Request)
Nov 17 00:10:52 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:10:58 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 173
(Critical Request)
Nov 17 00:11:12 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 00:11:18 WARNING[98310]: Maximum retries exceeded on call [email protected] for seqno 174
(Critical Request)
Nov 17 00:11:32 NOTICE[98310]: Registration for '[email protected]' timed out, trying again
Nov 17 04:00:03 NOTICE[65540]: Request to schedule in the past?!?!
Nov 17 04:00:03 NOTICE[65540]: Request to schedule in the past?!?!
Nov 17 07:36:10 WARNING[98310]: No such host: sipgate.de

So ein Mist, kann man evtl. die Logs noch detaillierter machen?

Gruß
Rolf