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

Cisco 7940G Konfiguration für T-Online

Dieses Thema im Forum "Cisco" wurde erstellt von REigner, 24 Sep. 2005.

  1. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo,

    ich habe heute mein Cisco 7940G Telefon bekommen und möchte damit
    nun bei T-Online meine Freiminuten nutzen...

    Allerdings komme ich mit der Konfiguration leider nicht klar.
    T-Online liefert ja eine Vielzahl von Daten, wobei in der Cisco
    SIP-Konten Konfig nur sieben Punkte sind.

    Hat das schon jemand am laufen und kann mir sagen wie die
    Parameter im Telefon gesetzt werden müssen, damits mit dem
    Nachbarn klappt?

    TIA
    Reinhard
     
  2. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Hallo, Reinhard, und willkommen im Forum!

    Hilfe-Seite von T-Online zum Thema bietet eigentlich alle Informationen.

    Ich habe es selber nicht ausprobiert, aber theoretisiere hier mal:
    Code:
    proxy1_address: "tel.t-online.de"    ; Can be dotted IP or FQDN
    # Proxy Server Port (default - 5060)
    proxy1_port: 5060 
    # Line 1 appearance
    line1_name: "<Rufnummer (032222....)>"   ; ohne Leerzeichen/Sonderzeichen!
    # Line 1 Registration Authentication 
    line1_authname: "<T-Online-E-Mail-Adresse>"  ; Kleinbuchstaben z.B. "rumpelstilzchen@t-online.de"!
    # Line 1 Registration Password
    line1_password: "........"
    # Line 1 Display Name (Name, der beim Angerufenen angezeigt werden soll)
    line1_displayname: "<eigener Name>"
    # Line 1 Short Name (Name, der fuer die Line-Taste benutzt werden soll)
    line1_shortname: "T-Online"
    Probier's mal aus und gib dann Rückmeldung. Viel Spaß!
     
  3. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo RB,

    ich habe mir mal die SIPdefault und SIPmacadress vom
    Cisco Einstieg Thread geladen und die T-Online Daten eingetragen.
    Dazu habe ich mir noch einen Account bei SIPgate geholt und diesen
    für die Line2 definiert.

    Jetzt kann ich mich nur vom Festnetz aus anrufen (zu T-Online).
    Abgehend steht im Display nur "Calling (out INV)"

    Wenn ich auf der console einen "debug sip-task" absetze bekomme
    ich Folgendes:

    SIPTaskProcessMessage: Line filter: Determing destination line ...
    SIPTaskProcessMessage: Line filter: Previous Call ID. Message not in reTx list.
    SIPTaskProcessMessage: Line filter: Call ID match not found: Rejecting.

    2. Versuch

    Ich habe daraufhin den sipgate account entfernt. Nun funktionierts
    abgehend aber wenn ich am Festnetz abhebe habe ich am
    7940G weiterhin das Freizeichensignal.
    Im Display: Ringing destination (in 180)"
    Auf beiden Telefonen hört man nichts vom anderen.
    Ankommend höre ich nur auf dem Festnetz Sprache, jedoch auf
    dem 7940G nicht.

    3. Versuch

    Im Router (Draytek Vigor 2200E) folgende Portbereiche geöffnet:
    16384-32766 UDP (diesen Bereich habe ich deswegen erhöht, da T-Online ja 30000-30005 benutzt, oder ist das hier was anderes?)
    5060 UDP
    5070 UDP
    3478 UDP
    3479 UDP
    80 TCP

    Nun habe ich das "normale" Freizeichen über dem Cisco-Freizeichen,
    also ich habe nun mit leichtem Versatz zwei Freizeichen in der Leitung.
    Das angerufene Festnetztelefon kann nun die Sprache zum 7940G
    übertragen, aber auf dem Festnetztelefon kommt keine Sprache an.
    Wenn ich mit dem Festnetz anrufe, geht die Sprachübetragung wieder
    in beide Richtungen.

    Wenn ich die Ports, welche bei T-Online angegeben sind zusätzlich
    forwarde passiert gar nichts - alles bleibt gleich.

    Was soll ich denn nun einstellen?
    Ach ja, nach einigen abgehenden Anrufen mit oben genanntem
    Problem, kommt nur noch "Reorder" und sofort besetzt.
    Wenn ich den Strom vom 7940G abziehe und damit neu starte
    funktioniert es wieder...


    HILFE, ist das kompliziert
     
  4. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ach ja: Die Firmware ist 7.5
     
  5. CTU

    CTU Mitglied

    Registriert seit:
    16 Mai 2005
    Beiträge:
    622
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Hallo Reinhard ,

    also ich weiß , dass die meisten hier im Forum mit der SIP-Version 7.5 Probleme hatten , was die Sprachübertragung angeht.

    Aufgrund mangelnder Erfahrung kann ich dir jetzt nicht sagen , ob bei dir vielleicht auch andere Einstellungen falsch sind , aber mit einem Downgrade auf 7.4 waren die meisten hiesigen User gut beraten.

    Warte einfach mal die Antwort von RB ab und dann sehen wir weiter. :wink:

    CTU
     
  6. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hallo,

    ich bin nun Deinem Rat gefolgt und habe mir bei Cisco die Firmware 7.4 gezogen und aufgespielt.
    Man glaubt es kaum - es funktioniert, zumindest was die Tests bis jetzt angeht.
    Hätte ich nicht gedacht, daß mit einem Firmwaredowngrade alles getan ist. Wurde wohl nicht recht getestet.. :?

    Dann muß ich auch noch herausfinden, wieviel Einträge ich aus dem Router wieder entfernen kann, denn ich will die Einträge möglichst gering halten.
    Ein Draytek ist schließlich kein Cisco, dem man ne seitenlange Konfig reinladen kann ;-)


    cheers
    Reinhard
     
  7. CTU

    CTU Mitglied

    Registriert seit:
    16 Mai 2005
    Beiträge:
    622
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Freut mich , dass Fortschritte zu verzeichnen sind.
    Ja , also leider hat 7.5 noch etliche Bugs und daher 7.4.
    Habe ich auch auf meinem 7960 und das ist die im moment neueste verlässliche Firmware.

    Wünsche weiterhin gutes gelingen !

    CTU
     
  8. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Moin!

    Tja, die 7.5 ist leider eher unbenutzbar. Ich hatte auch die Probleme, daß das Telefon nach einiger Zeit sogar komplett eingefroren war und nur noch ein Reset geholfen hat. Mit 7.4 ist es deutlich besser zu betreiben.

    Zu den Ports:
    Grundsätzlich sind alle Portangaben Client-spezifisch, haben also nichts mit dem Provider zu tun. Du mußt die Ports ans Telefon weiterleiten, die Du mit voip_control_port und start_media_port bis end_media_port festgelegt hast. Alles sind UDP-Ports. Der Rest ist zumindest für das Cisco-Telefon irrelevant.

    Hier im Forum gibt es noch ein paar Threads, die sich mit den RTP-Ports (aka Media-Ports) und deren Parametrierung im Cisco befassen. Da gibt es auch noch ein paar kleine Stolperstellen dahingehend, daß das Telefon nicht immer die Eintragungen für den Start- und Ende-Port übernimmt. Das sind ebenfalls Firmwarefehler. Zum Glück kann man das aber gut per Telefon-Menü kontrollieren...
     
  9. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Hi,

    wegen den Ports muß ich halt mal suchen oder hast Du gleich nen Link für mich?

    Wenn das Clientspezifisch ist, warum sagt mir T-Online, ich solle die Ports,
    welche ich weiter oben schon aufgezählt habe, freischalten.
    Oder meinst Du, die haben ihr Softwaretelefon so vorkonfiguriert?
    Wieviele RTP-Ports brauche ich eigentlich? Könnte ja auch nur einen oder zwei angeben...

    Portweiterleiten mußte ich nicht - nur die Ports generell öffnen, und selbst
    da bin ich mir noch nicht ganz sicher ob das nötig ist.
    Heute bin ich wieder zuhause und kann das Telefon an meinem Router,
    auch Draytek, aber 2600Gi, ausprobieren.
    Am 2200E gabs Probleme mit dem DNS. Dafür gabs aber ne Firmware,
    die genau dieses Problem am Router behebt.


    Grüße
    Reinhard
     
  10. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    T-Online ist halt Telekom - die erzählen schnell mal irgendwas ohne fundierte Kenntnisse. Ich habe damit auch schon so meine Erfahrungen gemacht. Ausnahmen sind hier nur die Techniker, an die man aber nur schwer drankommt. Ich habe schon öfter damit Erfolg gehabt, daß ich die Call-Center-Mitarbeiter solange mit Fachbegriffen bombardiere, bis sie freiwillig zur Technik durchstellen ;-)

    Ich gehe davon aus, daß es sich bei den Angaben um eine Mixtur aus den Einstellungen verschiedener Clients handelt - wohl weil man den Mitarbeitern nicht zutraut/zumuten möchte, detailliert nachzufragen, was denn nun eingesetzt wird. Das würde ja auch erhebliche Kenntnisse respektive eine größere Datensammlung voraussetzen.

    Die Thematik mit der Portweiterleitung bzw. Portöffnung hat mir schon öfter ein :? abverlangt. Mir ist nicht klar, wie ein Router wissen soll, wohin die Daten für einen bestimmten Port denn nun geschickt werden sollen, wenn man es nicht explizit als Weiterleitung angibt ?!
    Außerdem ist mir auch nicht klar was dieses "Öffnen" von Ports eigentlich sein soll. Das ist auch alles eine Frage der Terminologie des jeweiligen Herstellers bzw. Übersetzers.

    Wenn's bei Dir so läuft - prima!

    Zu der Anzahl Ports: Generell würde ich mindestens zwei vorsehen. Das hängt aber auch mit der Anzahl gleichzeitig aufgebauter Gesprächsverbindungen zusammen. Ich selber habe immer 5-6 RTP-Ports je Endgerät vorgesehen (und weitergeleitet :) )
     
  11. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Ich habe nochmal nachgelesen:
    Eine Portöffnung ist idR nichts anderes als eine Portweiterleitung, aber:

    - bei der Portöffnung kannst Du Portbereiche angeben, aber die Zielports bleiben gleich
    - bei der Portweiterleitung kannst nur einen Port angeben, diesen aber auf einen anderen Zielport umleiten

    LAN IP-Adresse muß man ja bei beiden angeben.

    Und forwarden muß ich die Ports, weil die mit UDP arbeiten.
    Wären das TCP-Ports müßte es eigentlich auch ohne Forwarding funktionieren, da Du ja sagtest, das RTP clientinitiiert ist...

    Gruß
    Reinhard
     
  12. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    OK, dann ist das "Port öffnen" bei Deinem Router einfach eine der Varianten des Port Forwardings bei mir. Leider ist die Terminologie nicht wirklich einheitlich.

    Nee, das ist ein Mißverständnis. Die Realtime-Streams können durchaus von draußen gestartet werden. Der Client sagt nur der Gegenseite, welche Ports dafür genommen werden sollen (über den Kontroll-Port, meist 5060). Grundsätzlich kann bei SIP alles von beiden Seiten aus initiiert werden.

    Daher auch die Notwendigkeit, daß die eigene öffentliche IP-Adresse allen Beteiligten bekannt und die Ports von draußen erreichbar sein müssen.
     
  13. REigner

    REigner Neuer User

    Registriert seit:
    24 Sep. 2005
    Beiträge:
    66
    Zustimmungen:
    0
    Punkte für Erfolge:
    6
    Gut. Mit dem SIP-Protokoll muß ich mich mal genauer beschäftigen.
    Mit dem STUN-Server braucht man ja diese Portforwardings nicht, oder?
     
  14. RB

    RB Aktives Mitglied

    Registriert seit:
    22 Juni 2004
    Beiträge:
    1,311
    Zustimmungen:
    0
    Punkte für Erfolge:
    0
    Beruf:
    Selbständiger Bitbeißer
    Ort:
    40883 Ratingen
    Die STUN-Geschichte ist eigentlich ein recht ausgeklügeltes Test-Verfahren, das dem STUN-Client ermöglichen soll, festzustellen, welche Art von NAT (bzw. ob überhaupt NAT) zwichen ihm und dem STUN-Server existiert. Es wird auch ausprobiert, ob man von einer anderen IP-Adresse (Ein STUN-Server ist immer eine gespaltene Persönlichkeit mit zwei Adressen) auf den abgehenden Port der STUN-Abfrage antworten kann, oder ob das nur für die ursprüngliche Adresse klappt. Außerdem wird die öffentliche IP-Adresse ermittelt.

    Aufbauend auf den Ergebnissen wird dann wohl der ermittelte externe Port den Providern als zu benutzender Port mitgeteilt. Damit macht man sich die Tabelle der NAT-Einträge zunutze, um von außen ein Loch durch den Router zu finden. Ist m.E. aber keine sonderlich zuverlässige Lösung, da es ja je nach NAT-Variante auch wieder Timeouts gibt, die die Tabelleneinträge zumindest für UDP nach einer Zeit ohne Datenfluss (bei den RTP-Ports ja normal) wieder löschen. Eine bessere Chance hat man da wohl mit dem Kontroll-Port.

    Bei "gehobenen" Router-Varianten mit symmetrischem NAT geht sowas gar nicht (abgesehen von der Ermittlung der öffentlichen IP-Adresse).

    Das war jetzt das, was ich mir so zusammengereimt habe - wirklich intensiv nachgelesen hab ich das nicht, da es bei mir sowieso nicht funktioniert (ich habe symmetrisches NAT).