Registration timed out

Lomas

Neuer User
Mitglied seit
1 Mai 2015
Beiträge
41
Punkte für Reaktionen
0
Punkte
6
Ich habe meinen Asterisk dazu gebracht, sich über eine VPN-Verbindung an einer Auswald Compact 5020 anzumelden. Das hat auch eine Weile funktioniert. Nun sehe ich aber im CLI, das der Asterisk alle 20s versucht, sich erneut zu registrieren. Mit einem Softphone über die gleiche VPN-Verbindung funktioniert es jedoch ohne Probleme.

Hat jemend eine Idee, was die Ursache dafür ist bzw. wie ich dem Problem auf die Spur komme?

Danke im Voraus.
Lomas
 
Idee habe ich keine, aber ein Ansatz zur Fehlersuche wäre sip set debug on und dort überprüfen, ob sämtliche Adressangaben im REGISTER Paket korrekt sind. Als nächstes wäre dann die Firewall / IP-Forwarding an der Reihe.
 
Diese Pakete erhalte ich:

Code:
Retransmitting #1 (no NAT) to 192.168.37.3:5060:
OPTIONS sip:192.168.37.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.36.202:5060;branch=z9hG4bK11438767
Max-Forwards: 70
From: "asterisk" <sip:[email protected]>;tag=as4fe15196
To: <sip:192.168.37.3>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: Asterisk PBX 13.11.2
Date: Mon, 13 Feb 2017 15:16:08 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Length: 0
Mit meinen beschränkten Kenntnissen kann ich hier nichts Schlimmes entdecken. Oder?
 
"Schlimm" ist relativ. Aber eins nach dem anderen.

Das Paket da ist ein OPTIONS Paket. Das hat nichts mit der Registrierung zu tun, sondern wird periodisch gesendet um zu sehen ob die Gegenstelle noch "lebt". Die Häufigkeit dieser Prüfung wird über den Parameter "qualify" gesteuert.

Dann ist das ein Paket das du sendest (transmit) und nicht empfängst. Genauer geht das Paket von 192.168.36.202 nach 192.168.37.3. Was die letztere IP dabei eigentlich ist, die Auerswald oder eines deiner Endgeräte, musst du wissen. Was dir aber in jedem Fall zu denken geben sollte ist das "Re" in "Retransmitting". Dh dieses Paket wird nochmal gesendet weil beim ersten mal keine OK Antwort von der Gegenstelle 192.168.37.3 gekommen ist. Könnte ein Hinweis auf ein Firewall/Routing Problem sein. Generell sollte auf jedes OPTIONS Paket ein OK Paket antworten (erkennbar am CSeq Parameter des OK Paketes).

Und dasselbe gilt für REGISTER Pakete. Das sind die, nach denen du im Debug eingentlich Ausschau halten solltest. Und insbesondere, ob diese Pakete ein OK von der Gegenstelle bekommen. Dabei kann auch eine Unauthorized Antwort dazwischen kommen weil dein Asterisk beim ersten REGISTER Paket keine Authentifizierung mitschickt, die Gegenstelle das reklamiert, Asterisk dann nochmal ein REGISTER mit Auth Info schickt und dann das OK kommt. Das OK von der Gegenstelle muss aber da sein, sonst geht nix.

Also, es könnte ein Routing Problem sein (Hin-/Rückroute zu/von der Auerswald). Oder könnte eine Authentifizierungsproblem sein (Passwort auf der Auerswald geändert?). Guck dir im Debug einfach die relevanten Pakete an, dann siehste schon ob Antworten eintreffen, und welche.
 
Zuletzt bearbeitet:
Danke für deine Antwort. Ich habe einen neuen Versuch gestartet und jetzt folgende Pakete gefunden:

Code:
[2017-02-15 15:27:15] NOTICE[1584]: chan_sip.c:15583 sip_reregister:    -- Re-registration for  [email protected]
REGISTER 11 headers, 0 lines
Reliably Transmitting (no NAT) to 192.168.37.3:5060:
REGISTER sip:192.168.37.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.36.202:5060;branch=z9hG4bK704243e3
Max-Forwards: 70
From: <sip:[email protected]>;tag=as580a9231
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.11.2
Expires: 120
Contact: <sip:[email protected]:5060>
Content-Length: 0



<------------->
Retransmitting #1 (no NAT) to 192.168.37.3:5060:
REGISTER sip:192.168.37.3 SIP/2.0
Via: SIP/2.0/UDP 192.168.36.202:5060;branch=z9hG4bK704243e3
Max-Forwards: 70
From: <sip:[email protected]>;tag=as580a9231
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 102 REGISTER
Supported: replaces, timer
User-Agent: Asterisk PBX 13.11.2
Expires: 120
Contact: <sip:[email protected]:5060>
Content-Length: 0

Das letzte Paket wird dann ständig wiederholt. Eine Antwort habe ich allerdings keine empfangen. Die 192.168.36.202 ist mein Asterisk, die 192.168.37.3 die Auerswald-Anlage. Ist denn an diesen Paketen irgendetwas verdächtig? Verwunderlich ist auch nach wie vor, dass sich mein Softphone ohne Probleme registriert.

- - - Aktualisiert - - -

Ich habe jetzt mit Wireshark die Pakete bei der Registrierung meines Softphones mitgeschnitten:

Code:
      1 0.000000       192.168.36.26         192.168.37.3          SIP      606    Request: REGISTER sip:192.168.37.3  (1 binding)
      2 0.012235       192.168.36.26         192.168.37.3          SIP      594    Request: SUBSCRIBE sip:[email protected]
      3 0.091629       192.168.37.3           192.168.36.26        SIP      591    Status: 489 Bad Event
      4 0.101390       192.168.37.3           192.168.36.26        SIP      679    Status: 401 Unauthorized
      5 0.102093       192.168.36.26         192.168.37.3          SIP      860    Request: REGISTER sip:192.168.37.3  (1 binding)
      6 0.195870       192.168.37.3           192.168.36.26        SIP      701    Status: 200 OK  (1 binding)
      7 0.204974       192.168.37.3           192.168.36.26        SIP      553    Request: OPTIONS sip:[email protected]:5060
      8 0.205467       192.168.36.26         192.168.37.3          SIP      473    Status: 200 OK
      9 17.958042     192.168.36.26         192.168.37.3          SIP      868    Request: REGISTER sip:192.168.37.3  (remove 2 bindings)
     10 18.044533     192.168.37.3          192.168.36.26         SIP      679    Status: 401 Unauthorized
     11 18.045238     192.168.36.26         192.168.37.3          SIP      868    Request: REGISTER sip:192.168.37.3  (remove 2 bindings)
     12 18.134955     192.168.37.3          192.168.36.26         SIP      587    Status: 200 OK  (0 bindings)

Das scheint beim ersten Versuch auch schief zu gehen. Im Paket 5 tauchen dann diese Authorization-Angaben auf:
Code:
 [truncated]Authorization: Digest username="70", realm="auerswald.local", nonce="3ca754d00cb5c3b065313063b29e331c", uri="sip:192.168.37.3", response="6cb9....

Diese Angaben finde ich beim Asterisk nicht. Wie müsste die Konfiguration aussehen, damit sich der Asterisk genau so registriert?
 
Das sieht mir so aus, als kommen die Pakete nicht bei der Auerswald an, und/oder die Antworten nicht zurück. Check mal das Routing.

Sofern eine Authentifizierung notwendig ist, wird das erste Paket grundsätzlich mit einem 401 abgelehnt. Dieses enthält realm und nonce, worauf hin der Client das Paket mit Authentifizierung wiederholt. Soweit also alles in Ordnung, und auch Asterisk würde es so machen, sobald er eben ein 401 zurück bekäme.
 
Was rentier-s sagt. Die Registrierungspakete, die dein Asterisk schickt, sind nicht nur standardkonform sondern enthalten auch alle nötigen Angaben. Diese Zeile sagt wo Asterisk seine Pakete hinschickt:
Reliably Transmitting (no NAT) to 192.168.37.3:5060:
diese wo die Gegenstelle ihre Antwortpakete hinschicken soll
Via: SIP/2.0/UDP 192.168.36.202:5060;branch=z9hG4bK704243e3
und diese wo später Anrufe für den Account hingeroutet werden sollen
sobald die Registrierung erfolgreich war. Wobei Letzteres an dieser Stelle noch nicht mal relevant ist.

Zum "401 Unauthorized", das ist genau die Antwort, die die Auerswald Anlage jetzt an Asterisk schicken sollte. Weil, wie du vermutlich selber gemerkt hast, das Registrierungspaket noch keine Authentifizierungsdaten (insbesondere Passwort) enthält. Diese Daten würden im nächsten Schritt geschickt werden. Aber von der Auerswald kommt ja nichts, also geht es auch nicht weiter.

Es sieht also ganz nach einem Connectivity Problem aus, und hier wären nun die üblichen Tests durchzuführen. Erstmal Reboot des Asterisk Rechner und erneut versuchen. Dann Pings/Traceroutes vom Asterisk Rechner zur Auerswald. Und falls die erfolgreich sind dann eben auf den Netzwerkinterfaces der involvierten Knoten (Asterisk Rechner, VPN Router) soweit es geht Package Dumps machen (tcpdump) um genau zu sehen wo Pakete verloren gehen. Also systematisches Einkreisen des Problems in klassischer Vorgehensweise.

Du kannst dich vielleicht auch nochmal fragen ob/was du wo geändert haben könntest. Weil du meintest es hätte mal funktioniert.
 
Ihr habt Recht: Auf der Auerswald kommen keine Pakete an. Wo die Pakete verlorengehen, ist mir allerdings schleierhaft, zumal ich die Auerswald anpingen (diese Pakete sehe ich im Trace der Auerswald) und auch das Webinterface öffnen kann. Die Routingeinstellungen sind also nicht prinzipiell verkehrt. Ansonsten ist da nicht viel dazwischen außer je 1 IPCop auf jeder Seite.

Ich bin mir auch ziemlich sicher, dass ich an der Konfiguration nichts geändert hatte. Mit meinem Kopf würde ich dafür aber nicht haften...;)
 
Ich habe jetzt noch einmal die Pakete sowohl vom Asterisk auf dem Raspberry als auch vom Softphone auf meinem PC mitgeschnitten. Ich füge jeweils ein REGISTER-Paket bei, vielleicht macht sich ja jemand die Mühe und sieht sie sich an und findet auch noch eine Unregelmäßigkeit oder noch besser eine Lösungsmöglichkeit.

Asterisk:
Code:
Frame 1: 436 bytes on wire (3488 bits), 436 bytes captured (3488 bits)
Ethernet II, Src: Raspberr_06:98:7f (b8:27:eb:06:98:7f), Dst: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
    Destination: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
        Address: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: Raspberr_06:98:7f (b8:27:eb:06:98:7f)
        Address: Raspberr_06:98:7f (b8:27:eb:06:98:7f)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.36.202, Dst: 192.168.37.3
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 422
    Identification: 0x257c (9596)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 64
    Protocol: UDP (17)
    Header checksum: 0x88ad [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.36.202
    Destination: 192.168.37.3
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
    Source Port: 5060
    Destination Port: 5060
    Length: 402
    Checksum: 0xccc1 [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
Session Initiation Protocol (REGISTER)
    Request-Line: REGISTER sip:192.168.37.3 SIP/2.0
        Method: REGISTER
        Request-URI: sip:192.168.37.3
            Request-URI Host Part: 192.168.37.3
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.36.202:5060;branch=z9hG4bK53e80a3a
            Transport: UDP
            Sent-by Address: 192.168.36.202
            Sent-by port: 5060
            Branch: z9hG4bK53e80a3a
        Max-Forwards: 70
        From: <sip:[email protected]>;tag=as26e5ba9d
            SIP from address: sip:[email protected]
                SIP from address User Part: 70
                SIP from address Host Part: 192.168.37.3
            SIP from tag: as26e5ba9d
        To: <sip:[email protected]>
            SIP to address: sip:[email protected]
                SIP to address User Part: 70
                SIP to address Host Part: 192.168.37.3
        Call-ID: [email protected]
        CSeq: 125 REGISTER
            Sequence Number: 125
            Method: REGISTER
        Supported: replaces, timer
        User-Agent: Asterisk PBX 13.11.2
        Expires: 120
        Contact: <sip:[email protected]:5060>
            Contact URI: sip:[email protected]:5060
                Contact URI User Part: 70
                Contact URI Host Part: 192.168.36.202
                Contact URI Host Port: 5060
        Content-Length: 0

Softphone:
Code:
Frame 1: 606 bytes on wire (4848 bits), 606 bytes captured (4848 bits) on interface 0
Ethernet II, Src: FujitsuT_2d:e4:a8 (90:1b:0e:2d:e4:a8), Dst: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
    Destination: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
        Address: PcEngine_32:1b:98 (00:0d:b9:32:1b:98)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Source: FujitsuT_2d:e4:a8 (90:1b:0e:2d:e4:a8)
        Address: FujitsuT_2d:e4:a8 (90:1b:0e:2d:e4:a8)
        .... ..0. .... .... .... .... = LG bit: Globally unique address (factory default)
        .... ...0 .... .... .... .... = IG bit: Individual address (unicast)
    Type: IPv4 (0x0800)
Internet Protocol Version 4, Src: 192.168.36.26, Dst: 192.168.37.3
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
        0000 00.. = Differentiated Services Codepoint: Default (0)
        .... ..00 = Explicit Congestion Notification: Not ECN-Capable Transport (0)
    Total Length: 592
    Identification: 0x00bf (191)
    Flags: 0x00
        0... .... = Reserved bit: Not set
        .0.. .... = Don't fragment: Not set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: UDP (17)
    Header checksum: 0x6d70 [validation disabled]
    [Header checksum status: Unverified]
    Source: 192.168.36.26
    Destination: 192.168.37.3
    [Source GeoIP: Unknown]
    [Destination GeoIP: Unknown]
User Datagram Protocol, Src Port: 5060, Dst Port: 5060
    Source Port: 5060
    Destination Port: 5060
    Length: 572
    Checksum: 0xfa1e [unverified]
    [Checksum Status: Unverified]
    [Stream index: 0]
Session Initiation Protocol (REGISTER)
    Request-Line: REGISTER sip:192.168.37.3 SIP/2.0
        Method: REGISTER
        Request-URI: sip:192.168.37.3
            Request-URI Host Part: 192.168.37.3
        [Resent Packet: False]
    Message Header
        Via: SIP/2.0/UDP 192.168.36.26:5060;branch=z9hG4bK0069b79541f2e61192cc2d7d42853e9f;rport
            Transport: UDP
            Sent-by Address: 192.168.36.26
            Sent-by port: 5060
            Branch: z9hG4bK0069b79541f2e61192cc2d7d42853e9f
            RPort: rport
        From: "PhonerLite" <sip:[email protected]>;tag=3800979899
            SIP Display info: "PhonerLite"
            SIP from address: sip:[email protected]
                SIP from address User Part: 70
                SIP from address Host Part: 192.168.37.3
            SIP from tag: 3800979899
        To: "PhonerLite" <sip:[email protected]>
            SIP Display info: "PhonerLite"
            SIP to address: sip:[email protected]
                SIP to address User Part: 70
                SIP to address Host Part: 192.168.37.3
        Call-ID: [email protected]
        CSeq: 1 REGISTER
            Sequence Number: 1
            Method: REGISTER
        Contact: <sip:[email protected]:5060>;+sip.instance="<urn:uuid:0005923E-8031-E511-842E-7F6CECF65C5F>"
            Contact URI: sip:[email protected]:5060
                Contact URI User Part: 70
                Contact URI Host Part: 192.168.36.26
                Contact URI Host Port: 5060
            Contact parameter: +sip.instance="<urn:uuid:0005923E-8031-E511-842E-7F6CECF65C5F>"\r\n
        Allow: INVITE, OPTIONS, ACK, BYE, CANCEL, INFO, NOTIFY, MESSAGE, UPDATE
        Max-Forwards: 70
        User-Agent: SIPPER for PhonerLite
        Expires: 900
        Content-Length: 0

Vielen Dank im Voraus!
Lomas
 
Der einzige Unterschied, der vielleicht etwas ausmachen könnte, ist das rport. Den könntest Du mit nat=force_rport erzwingen.

Ansonsten bleibe ich dabei: es ist kein Problem in der Asterisk Config, sondern im Netzwerk.

Ansonsten ist da nicht viel dazwischen außer je 1 IPCop auf jeder Seite.
:noidea:
 
Danke für deine Mühe. Die Ergänzung mit nat=force_rport hat leider auch keinen Erfolg gebracht.

Dann bin ich jetzt am Ende mit meinem Latein. Ich habe keine Ahnung, warum die Pakete von meinem Rechner an der Auerswald ankommen, die vom Asterisk hingegen nicht, während ich sonst die Auerswald anpingen kann und auch das Webinterface erreiche. Vielleicht hat dazu noch jemand einen Hinweis für mich.
 
Kennt die Asterisk Maschine den Gateway? Bekommst Du das Webinterface von der Asterisk Maschine aus auf, oder nur von Deinem PC?
 
Das Webinterface habe ich nur vom PC aus ausprobiert. Der Asterisk läuft auf einem Raspberry, hier habe ich nur den Ping getestet, diese Pakete sehe ich auch auf der Auserswald. Das Gateway ist auf dem Raspberry bekannt, sonst würde der Ping nicht funktionieren, und die Anmeldung bei KDG funktioniert ja auch. Und irgendwelche speziellen Routen habe ich auf dem Raspberry nicht eingetragen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.