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

ATA286: langsames rotes Blinken

Dieses Thema im Forum "Grandstream" wurde erstellt von stan, 10 Juli 2004.

  1. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hi!

    Ich bin ein absoluter Anfänger auf dem Gebiet. Also mein neuer ATA286 hat kurzfristig teilweise funktioniert über sipgate, jetzt loggt er sich dort jedoch nicht mehr ein, sondern blinkt nur noch rot (im Sekundentakt etwa). Was kann das bedeuten? Firmware ist 4.68, IP Adresse bekommt er zugewiesen, Web-Konfigurationsmenu funktioniert, Internet-Verbindung ist da, alle eingehenden Internet-Verbindungen sind auf den ATA286 geforwarded, aber immer nur dieses rote Blinken. Versuche ich eine Nummer zu wählen, quittiert der ATA286 das sofort nach Senden von '#' mit einem Besetztzeichen. Neukonfiguration, Reset auf Factory-Settings, Power-Cycle, 2.ter Testaccount bei Nikotel, alles schon ausprobiert, kein Erfolg.
     
  2. OrkUs

    OrkUs Neuer User

    Registriert seit:
    20 Apr. 2004
    Beiträge:
    88
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Langsames blinken heisst auf jeden F keine Verbindung zu Sipgate...

    Welchen Firewalltyp erkennt denn der ATA? Steht im WebKonfigMenü ganz oben neben/unter der FW

    Wählen mit "#" sieht nach Benutzung der kurzwahl aus...die ergibt bei mir auch immer ein Besetztzeichen...funzt schon seit längerem nicht...also einfach normal wählen mit Tonwahl...bei rotblinkendem ATA macht wählen aber eh keinen Sinn..;)

    Was hast Du denn für nen Router?
     
  3. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hmm, detected NAT type is open Internet

    Das ist natürlich irgendwie falsch, heute morgen als er kurz funktioniert hatte, stand da auch korrekt "symmetrisches NAT" oder so. Fragt sich nur, warum erkennt er das plötzlich nicht mehr korrekt?

    Ne, also ich meinte die '#' Taste am Analog-Telefon zum Absenden der Nummer, also z.B. 08003302000#

    Linux 2.4 + iptables
     
  4. OrkUs

    OrkUs Neuer User

    Registriert seit:
    20 Apr. 2004
    Beiträge:
    88
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    hmm..also eigentlich gehört da "detected NAT type is full cone " hin...jetzt weiss ich aber nicht, ob das bei Linux Routern anders ist. :gruebel:

    Zum Wählen: Ich wähle mit meinem Analogtel. immer mit Tonwahl, da muss man dann # nicht drücken

    Tja..da ich von den Linux Routern null Ahnung habe musst Du jetzt wohl gezwungenermaßen auf nen Experten warten :blonk: :keks:
     
  5. atze

    atze Neuer User

    Registriert seit:
    5 Juli 2004
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Bei meinem ATA 486 brachte die Option "use random port" den Durchbruch. Vorher ging da auch nichts. Vielleicht gibt es so etwas beim 286er auch. Wahrscheinlich sind die Standardports bei meinem Provider gedrosselt.
     
  6. exim

    exim Admin a.D.

    Registriert seit:
    27 Apr. 2004
    Beiträge:
    1,013
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Mit Kernel 2.4.x und korrektem Portforwarding muss "full cone" kommen, sonst ist was faul. Vorausgesetzt Du hast einen "normalen" I-Net-Zugang und Dein I-Net-Provider klemmt nicht so eine Zwangs-NAT-Büchse dazwischen, wie es wohl teilweise bei KabelDeutschland der Fall ist.

    Erklärung der NAT-Varianten findest Du unter
    http://www.morgenlan.de/bp/sipgate/nat.shtml#natdetail
    und ein paar iptables-Zeilen im Linux-Router-Bereich unter http://www.ip-phone-forum.de/forum/viewtopic.php?p=7053

    Gruß,
    exim
     
  7. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Nö, also ich have einen ganz normalen Internetzugang, auch keine Portdrosselungen, also von der Seite sollte es eigentlich keine Probleme geben. Kann man denn evtl. sagen, wo ich noch weiter suchen muß? Weil, egal, was ich mache, ich bekomme jetzt immer "Open Internet" zurück als NAT-Type, und ich sehe auch keine Möglichkeit, wie ich diese Erkennung beeinflussen könnte. Ich habe da wohl noch ein paar Einstellungen im Web-Interface, die Sipgate nicht angibt. Könntet ihr die mal vergleichen mit euren Configs?

    iLBC frame size: 20 ms
    iLBC payload type: 99
    Use DNS SRV: no

    Gerade hat es mal wieder funktioniert, und der erkannte NAT-Typ stand dabei auch wieder auf "detected NAT type is symmetric NAT". Also hier liegt offenbar die Ursache meiner Probleme. Aber scheinbar erkennt er es mal so, mal so, hmm, grübel...
     
  8. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Der ATA 286 muß definitiv "Full Cone" erkennen - bei allen anderen Einstellungen (außer "open Internet" - das lassen wir aber mal außen vor) ist ein zuverlässiger Betrieb nicht gewährleistet.

    Bitte poste mal einen Screenshot Deiner ATA-Konfiguration hier. HIer scheinen nämlich 2 Probleme gleichzeitig vorzuliegen: Fehler in iptables und eine Ungereimtheit in der ATA-Konfiguration.
     
  9. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ausnahmsweise tut er das jetzt auch mal...

    Das mit den Screenshots klappt wohl nicht....

    Code:
    DHCP: yes
    SIP server: sipgate.de
    Outbound Proxy: sipgate.de
    SIP User Id: XXXXXXX
    Authenticate Id: XXXXXXX (same as above)
    Authenticate Pw: blah
    Preferred Vocoder: PCMA, PCMU, G729, G723, G726-32, G728, G722, iLBC
    G723 rate: 6.3 kbps
    iLBC frame size: 20 ms
    iLBC payload type: 99
    Silence Suppression: no
    Voice Frames per TX: 2
    Layer 3 QoS: 48
    Layer 2 QoS: 802.1Q/VLAN Tag: 0, 802.1p priority value: 0
    Use DNS SRV: No
    User ID is phone number: No
    SIP Registration: Yes
    Unregister On Reboot: No
    Register Expiration: 60
    Early Dial: No
    Dial Plan Prefix: <empty>
    Dial Plan Length: 0
    No Key Entry Timeout: 4
    Use # as Dial Key: Yes
    local SIP port: 5060
    local RTP port: 5004
    Use random port: No
    NAT Traversal: Yes
    STUN server is: stun.sipgate.net:10000
    keep-alive interval: 14
    Use NAT IP <empty>
    TFTP Server: 217.10.79.21
    Voice Mail UserID: 50000
    SUBSCRIBE for MWI: No
    Offhook Auto-Dial: <empty>
    Disable Call-Waiting: No
    Send DTMF: via SIP INFO
    DTMF Payload Type: 101
    Send Flash Event: No
    FXS Impedance:  CTR21
    NTP Server: ntp.sipgate.net
    Time Zone: GMT+1
    Daylight Savings Time: Yes
    Send Anonymous: No
    Lock keypad update: No
    Meine iptables rule sieht so aus:

    Code:
    Chain PREROUTING (policy ACCEPT)
    target     prot opt source               destination
    DNAT       udp  --  0.0.0.0/0            0.0.0.0/0          multiport dports 5060,5061,5004,5005,5006,5007,10000 to:192.168.100.22
     
  10. atze

    atze Neuer User

    Registriert seit:
    5 Juli 2004
    Beiträge:
    15
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ich bin auch bei keinem dieser blacklistet Provider, sondern bei Lycos. Kann aber auch sein, daß die verwendete Fritz!DSL Box nicht so ganz unschuldig war.
    Ich hatte jedenfalls so ziemlich das gleiche Fehlerverhalten. Nach einigen Stunden habe ich dann halt Dinge ausprobiert, an denen "es eigentlich nicht liegen" kann.
     
  11. betateilchen

    betateilchen Grandstream-Guru

    Registriert seit:
    30 Juni 2004
    Beiträge:
    12,882
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ort:
    am Letzenberg
    Nimm mal den Eintrag bei TFTP-Server raus (auf 0.0.0.0) setzen. Denn wenn Deine Firewall den Port 69 nicht durchläßt, sucht Dein ATA sich tot nach dem angegebenen TFTP-Server.
     
  12. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hmm, TFTP baut Verbindungen von Server zum Client auf, also von aussen nach innen? Weil von innen nach aussen geht eigentlich alles durch. Einfaches NAT, keine "Firewall".
     
  13. Fux

    Fux Mitglied

    Registriert seit:
    3 Juni 2004
    Beiträge:
    420
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Nur mal so ne dumme Frage:
    Die UDP-Ports 5004 bis 5007, 5060 & 10000 hast du auf die interne IP des ATA geforwardet ?
    Falls das nicht reicht, stell in deinen Firewall regeln noch ein, daß Pakete von den IPs 217.10.79.1 bis 217.10.79.31 (Sipgate DE) sowie 217.10.66.69 (Sipgate UK) komplett (Port 0 bis 65535) zum ATA durchgereicht werden.
    Nach meinen Erfahrungen sind insbesondere die von den Sipgate UK Servern kommende Pakete nicht immer an die Standard-Ports adressiert, weshalb viele, die nur die Standard Forwardings in ihren Routern programmiert haben keinen Rufton hören.
     
  14. stan

    stan Neuer User

    Registriert seit:
    10 Juli 2004
    Beiträge:
    22
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Ja, natürlich :)

    Also ich wollte irgendwann nochmal alle eingehenden Pakete mitloggen am NAT-Router, um zu sehen, was da so passiert. Ich habe nämlich auch noch ein zweites Problem, wenn der ATA dann mal Full Core erkennt und es dann in der Regel funktioniert, sind doch häufig Gespräche dabei, wo ich nicht nur kein Freizeichen höre, sondern gar nichts, auch wenn die Gegenstelle abnimmt. Auch die Gegenstelle hört mich dann ebenfalls nicht. Und das, obwohl ganz normal Datenpakete übertragen werden, also nicht mehr oder nicht weniger Datendurchsatz als bei Gesprächen, die normal funktionieren.

    Wegen diesem zweiten Problem hatte ich auch schon einmal sämtliche eingehenden Pakete forgewarded zum ATA, so wie du vorschlägst, aber selbst dann passierte das. Muß eine ziemliche Krankheit sein, das SIP Protokoll. Wie man auf die Idee kommen kann, in einer Zeit, wo praktisch die Mehrzahl aller Breitbanduser hinter einem NAT-Router sitzt, IP-Adressen in höhere Protokollschichten als Layer 3 einzubauen, ist mir sowieso ein Rätsel. :)

    Weiss jemand, wo man eine genaue Protokollbeschreibung von SIP und STUN findet? rfc Dokumentnummer oder so?
     
  15. Fux

    Fux Mitglied

    Registriert seit:
    3 Juni 2004
    Beiträge:
    420
    Zustimmungen:
    0
    Punkte für Erfolge:
    16
    Alle Pakete forwarden (also IP des ATA als Exposed Host [bei den HW Routern fälschlich als DMZ bezeichnet] eintragen) hat bei mir nichts genützt. Erst das explizite freigeben der IPs in den Firewall-Regeln half...
    Es kann auf jeden Fall nicht schaden, mal zu gucken was genau passiert. Da muß ich meinen D-Link wieder loben: Auch wenn er manchmal macht was er will; er sagt es einem zumindest im Log, wenn man "show dropped packets" einstellt.
     
  16. cybermike

    cybermike Neuer User

    Registriert seit:
    18 Juli 2004
    Beiträge:
    32
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Datenschutz- und IT-Sicherheitsbeauftragter
    Ort:
    Niederösterreich
    Bist Du bei Sipgate? Ich hatte vor einigen Tagen genau das gleiche Problem - eine Mail an Sipgate hat geholfen und nach 1 Tag hats wieder funktioniert.

    lg Michael