.titleBar { margin-bottom: 5px!important; }

Asterisk ok, verliert aber Verbindung zu Sipgate

Dieses Thema im Forum "Asterisk Allgemein" wurde erstellt von rowitech, 14 Nov. 2004.

  1. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  2. TinTin

    TinTin Aktives Mitglied

    Registriert seit:
    6 Mai 2004
    Beiträge:
    1,864
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  3. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    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.
     
  4. TinTin

    TinTin Aktives Mitglied

    Registriert seit:
    6 Mai 2004
    Beiträge:
    1,864
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
  5. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  6. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  7. TinTin

    TinTin Aktives Mitglied

    Registriert seit:
    6 Mai 2004
    Beiträge:
    1,864
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    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
     
  8. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    >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
    Code:
    [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:2MumPiTZ@sipgate.de/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
     
  9. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg

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

    TinTin Aktives Mitglied

    Registriert seit:
    6 Mai 2004
    Beiträge:
    1,864
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    @Rolf
    siehe betateilchens Antwort, das sollte das "no such host" Problem lösen ;)

    Gruß,
    Tin
     
  11. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ö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
     
  12. rowitech

    rowitech Neuer User

    Registriert seit:
    30 Sep. 2004
    Beiträge:
    115
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Heute Nacht ist ein User hängengeblieben (ein Channel noch belegt), danach hatte Asterisk keine Lust mehr:

    Code:
    Nov 17 00:03:44 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 158
    (Critical Request)
    Nov 17 00:03:58 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:07:35 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 163
    (Critical Request)
    Nov 17 00:07:49 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:07:55 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 164
    (Critical Request)
    Nov 17 00:08:09 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:08:15 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 165
    (Critical Request)
    Nov 17 00:08:29 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:08:36 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 166
    (Critical Request)
    Nov 17 00:08:50 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:08:56 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 167
    (Critical Request)
    Nov 17 00:09:10 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:09:16 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 168
    (Critical Request)
    Nov 17 00:09:30 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:09:37 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 169
    (Critical Request)
    Nov 17 00:09:51 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:09:57 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 170
    (Critical Request)
    Nov 17 00:10:11 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:10:17 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 171
    (Critical Request)
    Nov 17 00:10:31 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:10:38 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 172
    (Critical Request)
    Nov 17 00:10:52 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:10:58 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 173
    (Critical Request)
    Nov 17 00:11:12 NOTICE[98310]: Registration for '8007207@sipgate.de' timed out, trying again
    Nov 17 00:11:18 WARNING[98310]: Maximum retries exceeded on call 6b8b4567327b23c6643c986966334873@83.151.17.156 for seqno 174
    (Critical Request)
    Nov 17 00:11:32 NOTICE[98310]: Registration for '8007207@sipgate.de' 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